Um plugin do WordPress apagou as configurações do site. Uma atualização do WooCommerce estragou os dados dos produtos. Uma importação mexeu nos posts errados. Quase sempre o problema está numa tabela só do banco do WordPress, e restaurar o banco inteiro desfaz junto tudo o que o site fez desde o último backup: pedidos, comentários, cadastros. Dá para trazer de volta só a tabela que quebrou? Em quanto tempo? Ela volta igual?
| A tabela do WordPress | Um arquivo por banco | Uma tabela por arquivo |
|---|---|---|
| wp_options (1,7 MB), banco de 9 GB | 121 s | 3,3 s |
| wp_postmeta (99 MB), banco de 9 GB | 134 s | 14 s |
| wp_options (5,5 MB), banco de 1,3 GB | 17 s | 4,1 s |
| wp_postmeta, a maior tabela (361 MB, 28% do banco de 1,3 GB) | 42 s | 32 s |
| wp_posts (95% do banco de 9 GB) | 783 s | 829 s |
| O banco do WordPress inteiro (9 GB) | 893 s | 922 s |
| Backup da conta (5 sites, 17,6 GB de bancos) | 691 s | 678 s |
| Espaço no storage | 2,03 GB | 2,03 GB |
Método
Cinco bancos de sites WordPress reais, de 1,2 a 13 GB e de 63 a 282 tabelas cada (um blog grande e sites institucionais; nenhum era loja WooCommerce), numa conta do servidor de testes.
O Salvo agora tem dois formatos para os bancos no backup, escolhidos ao criar o job: um arquivo por banco, o padrão, ou uma tabela por arquivo: o mesmo retrato do banco, tirado de uma vez só (todas as tabelas do mesmo instante, como o WordPress espera), guardado tabela por tabela.
Backup da conta nos dois formatos, cada um num storage separado, para medir o espaço de cada um. Tudo pelo painel do Salvo no WHM: criar os jobs, rodar o backup e restaurar as tabelas.
Cada tabela foi restaurada para um banco novo, ao lado do original, e conferida pelo checksum contra a original: todas idênticas, nos dois formatos.
Por que o ganho muda: no formato de um arquivo, o Salvo precisa buscar no storage o banco inteiro para tirar dele uma tabela; no formato por tabela, busca só ela. A importação no MySQL leva o mesmo tempo nos dois. Por isso o ganho cresce quanto menor a tabela em relação ao banco, e some quando a tabela é quase o banco todo, como a wp_posts de um blog muito grande.
O que decidimos
As tabelas que mais quebram no WordPress (wp_options, wp_postmeta, usuários, comentários) são pequenas perto do banco, exatamente onde o ganho é maior. Mas o formato por tabela pesa mais no servidor durante o backup: usa um espaço temporário do tamanho do maior banco e aumenta a carga. Por isso ele é uma escolha do administrador, por job, e o padrão continua um arquivo por banco. Na restauração, pelo painel, dá para colocar a tabela num banco novo ao lado, para comparar antes de trocar, ou substituir só ela no banco do site; antes de mexer, o Salvo guarda uma cópia do banco como está.