Voc\u00ea gerou o backup do WordPress, baixou o arquivo, guardou num lugar seguro. Semana passada, o site quebrou. Voc\u00ea restaura a c\u00f3pia e… nada funciona: ou aparece um erro de conex\u00e3o com o banco, ou as imagens somem, ou o site volta para um estado antigo, com posts que voc\u00ea publicou depois do backup. O problema n\u00e3o \u00e9 o backup em si \u2014 \u00e9 que ele estava incompleto ou desatualizado. Um backup que n\u00e3o restaura n\u00e3o serve para nada. Neste artigo, voc\u00ea vai ver exatamente o que precisa estar dentro da c\u00f3pia para ela ser \u00fatil quando voc\u00ea mais precisar.<\/p>\n
Um site WordPress \u00e9 feito de duas partes: os arquivos<\/strong> (o c\u00f3digo do WordPress, temas, plugins, imagens, uploads) e o banco de dados<\/strong> (onde ficam os posts, p\u00e1ginas, coment\u00e1rios, configura\u00e7\u00f5es). Um backup completo precisa incluir as duas coisas. Se faltar uma delas, a restaura\u00e7\u00e3o falha ou o site fica incompleto.<\/p>\n Na pasta Al\u00e9m disso, arquivos da raiz como O banco de dados cont\u00e9m todo o conte\u00fado do site. Voc\u00ea precisa exportar um dump SQL completo, incluindo todas as tabelas (geralmente com prefixo Antes de precisar restaurar, confira o conte\u00fado do backup:<\/p>\n O \u00fanico jeito de saber se o backup funciona \u00e9 restaur\u00e1-lo. Mas voc\u00ea n\u00e3o precisa fazer isso no site em produ\u00e7\u00e3o. Crie um ambiente de staging (uma c\u00f3pia do site em subdom\u00ednio ou subpasta, ou localmente) e restaure o backup ali.<\/p>\n Se tudo funcionar no staging, o backup est\u00e1 bom. Se n\u00e3o, voc\u00ea descobriu o problema antes de precisar do backup de verdade.<\/p>\n O teste de restaura\u00e7\u00e3o em staging \u00e9 sempre recomendado, mas h\u00e1 situa\u00e7\u00f5es em que voc\u00ea n\u00e3o vai conseguir fazer: se o site est\u00e1 fora do ar e voc\u00ea n\u00e3o tem um ambiente de staging dispon\u00edvel, pode ser necess\u00e1rio restaurar direto na produ\u00e7\u00e3o. Nesse caso, o backup \u00e9 a \u00fanica esperan\u00e7a. Por\u00e9m, se o backup estiver incompleto, a restaura\u00e7\u00e3o pode piorar a situa\u00e7\u00e3o. Por isso, a preven\u00e7\u00e3o \u00e9 fundamental: mantenha backups frequentes e testados.<\/p>\nArquivos essenciais<\/h3>\n
wp-content<\/code>, voc\u00ea precisa copiar:<\/p>\n\n
index.php<\/code>, wp-settings.php<\/code> e outros do n\u00facleo s\u00e3o necess\u00e1rios, mas se voc\u00ea reinstalar o WordPress depois, eles s\u00e3o recriados. O importante \u00e9 n\u00e3o esquecer o wp-content<\/code> e o wp-config.php<\/code>.<\/p>\nBanco de dados<\/h3>\n
wp_<\/code>). Se o backup for feito por plugin, ele j\u00e1 faz isso. Se for manual, use phpMyAdmin ou WP-CLI. Um dump incompleto pode faltar tabelas importantes, como wp_posts<\/code> ou wp_options<\/code>, e o site quebra.<\/p>\nComo diagnosticar se o backup est\u00e1 completo<\/h2>\n
\n
wp-content<\/code> com as subpastas uploads<\/code>, themes<\/code> e plugins<\/code>.<\/li>\nCREATE TABLE wp_posts<\/code>. Se n\u00e3o achar, o dump est\u00e1 incompleto.<\/li>\nComo testar a restaura\u00e7\u00e3o sem derrubar o site<\/h2>\n
Passo a passo para testar<\/h3>\n
\n
seusite.com<\/code> e o staging \u00e9 staging.seusite.com<\/code>, voc\u00ea precisa atualizar as URLs no banco. Use WP-CLI: wp search-replace 'seusite.com' 'staging.seusite.com' --all-tables<\/code>. Ou use um plugin como Better Search Replace.<\/li>\nQuando N\u00c3O usar essa solu\u00e7\u00e3o<\/h2>\n
Erros comuns ao gerar backup do WordPress<\/h2>\n