# Backup centralizado: 5 passos para vários sites

<strong>Backup centralizado</strong> reúne a cópia de toda a sua frota WordPress em uma rotina e um painel único. Segundo o <a href="https://developer.wordpress.org/cli/commands/db/export/">WordPress Developer Resources</a> (2026), o WP-CLI exporta o banco de cada site em um único comando, base de qualquer automação. O ganho real está no destino externo, não no plugin. Configure, agende e teste a restauração antes de confiar.

Backup centralizado é a prática de gerar, armazenar e monitorar as cópias de segurança de vários sites WordPress a partir de um único ponto de controle. Quem administra cinco ou cinquenta sites não tem como entrar plugin por plugin todo dia para conferir se a rotina rodou. A dor que chega no suporte da FULL quase sempre é a mesma: o backup parecia existir, mas ninguém nunca tentou restaurar. Este tutorial mostra como montar um backup centralizado confiável, com destino externo, agendamento real e teste de restauração. Para a visão geral da frota, o <a href="https://full.services/gestao-de-sites-wordpress/">guias de gestão de sites WordPress da FULL</a> complementa cada etapa daqui.

---

## Visão geral: Arquiteturas de backup centralizado

Existem 3 modelos de backup centralizado viáveis para uma frota WordPress, e a diferença entre eles só aparece quando você passa de 5 para 30 sites: plugin por site, painel self-hosted ou SaaS gerenciado. A arquitetura define se a rotina escala ou trava no disco.

Em frota acima de 20 sites no suporte da FULL, a maioria dos incidentes de perda de dados vem de backup que ficava na mesma pasta do site invadido. A tabela abaixo separa cada modelo por onde mora o painel, onde mora a cópia e o custo dominante de cada um.

<table id="arquiteturas-backup-centralizado">
  <caption>Backup centralizado: modelos por painel, destino e custo</caption>
  <thead>
    <tr>
      <th scope="col">Modelo</th>
      <th scope="col">Onde fica o painel</th>
      <th scope="col">Destino da cópia</th>
      <th scope="col">Custo dominante</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Plugin por site (UpdraftPlus)</th>
      <td>Em cada WordPress</td>
      <td>Amazon S3 ou Backblaze B2</td>
      <td>Armazenamento por GB</td>
    </tr>
    <tr>
      <th scope="row">Painel self-hosted (MainWP)</th>
      <td>Site mestre seu</td>
      <td>Servidor mestre + nuvem</td>
      <td>Disco do mestre</td>
    </tr>
    <tr>
      <th scope="row">SaaS gerenciado (ManageWP)</th>
      <td>Nuvem do fornecedor</td>
      <td>Nuvem do fornecedor</td>
      <td>Mensalidade por site</td>
    </tr>
  </tbody>
</table>

A regra que vale para os três: a cópia nunca pode morar no mesmo servidor do site. Backup local na mesma pasta do site somado a uma invasão de servidor resulta em backup criptografado pelo ransomware junto com o site, sem nenhum ponto de restauração.

---

## Pré-requisitos: O que prepare antes de centralizar

Antes de configurar um backup centralizado, 3 decisões técnicas evitam retrabalho: a janela de retenção, o destino externo e a frequência por site. Definir mal a retenção e guardar 30 cópias completas diárias de cada site estoura qualquer disco em poucas semanas.

Essa é a primeira escolha. O destino externo exige credenciais de <a href="https://full.services/glossario/sftp/">SFTP</a> ou chaves de API do Amazon S3 já testadas. A frequência muda por tipo de site: uma loja WooCommerce que vende todo dia precisa de cópia diária, um site institucional estático aceita semanal.

Defina também onde o agendamento vai rodar. O <a href="https://full.services/glossario/cron-wordpress/">cron do WordPress</a> depende de visita à página para disparar, o que é um risco em sites de baixo tráfego. Cron do WordPress dependente de visita somado a um site de baixo tráfego gera um job de backup que nunca dispara à noite e some da janela de retenção. Em frota séria, o agendamento sai do WP-Cron e vai para o cron real do servidor ou para o painel central.

---

## Passo a passo: Configurar o backup centralizado da frota

Configurar um backup centralizado leva 5 passos que valem tanto para painel self-hosted quanto para SaaS, do conector ao teste de restauração. O caminho abaixo usa MainWP como painel e UpdraftPlus como motor de cópia, a combinação que a gente mais vê dar certo na base FULL.

Cada passo termina com um check de validação, porque backup sem validação é só uma esperança. Para gerenciar a frota além do backup, veja <a href="https://full.services/como-gerenciar-varios-sites-wordpress-com-mainwp/">como gerenciar vários sites WordPress com MainWP</a>.

### Passo 1: Conecte os sites ao painel central

Instale o plugin do painel no site mestre e o conector em cada site filho. No MainWP, o site mestre recebe o plugin principal e cada site da frota recebe o MainWP Child com uma chave única. A conexão usa a REST API do WordPress sobre HTTPS, então confirme que todos os sites têm certificado SSL válido antes de conectar. Check de validação: o dashboard deve listar todos os sites com status verde e versão do WordPress 6.x visível.

### Passo 2: Defina o destino externo da cópia

Aponte cada site para um armazenamento fora do servidor de produção. Configure o UpdraftPlus em cada site filho com destino remoto: Amazon S3, Backblaze B2 ou Google Drive funcionam e são lidos pelo painel. Backblaze B2 costuma sair mais barato por GB para frotas grandes, enquanto o S3 entrega mais regiões. Check de validação: dispare um backup manual de um site e confirme que o arquivo aparece no bucket externo, não só no disco local.

### Passo 3: Agende a rotina escalonada

Programe os backups em janelas escalonadas, nunca todos no mesmo horário. Backup completo diário de 30 sites no mesmo horário somado a um servidor compartilhado causa um pico de I/O que derruba o TTFB de todos os sites ao mesmo tempo. Distribua em janelas de 20 minutos e use cópia incremental nos dias entre o backup completo semanal. Check de validação: confira no painel que dois sites quaisquer têm horários de início diferentes e que o log do dia anterior marca sucesso.

### Passo 4: Configure a retenção e o alerta de falha

Limite quantas versões cada site guarda e ligue o alerta de falha. Defina retenção de 7 a 14 cópias por site no UpdraftPlus para não estourar o armazenamento externo, e configure o painel para enviar e-mail quando um job falhar. O alerta é o que transforma backup centralizado em algo confiável, porque ninguém abre 30 painéis por dia. Check de validação: force uma falha removendo a credencial de um destino e confirme que o alerta chega na sua caixa.

### Passo 5: Teste a restauração de um site real

Restaure um site de teste a partir da cópia antes de declarar a rotina pronta. Pegue um <a href="https://full.services/glossario/ambiente-staging/">ambiente de staging</a> e restaure o backup mais recente de um site de produção nele, conferindo banco, uploads e plugins. Restauração não testada não conta como backup. Check de validação: o site restaurado abre, faz login no admin e exibe o conteúdo da data esperada. Para o roteiro completo, veja <a href="https://full.services/como-restaurar-o-wordpress-a-partir-do-backup/">como restaurar o WordPress a partir do backup</a>.

---

## Automação por linha de comando: WP-CLI na frota

A automação real do backup centralizado vive no WP-CLI quando você tem acesso SSH: 1 comando `wp db export` gera o dump do banco de cada site, e `wp media` mais `tar` cuidam dos uploads. Isso tira o backup da dependência do WP-Cron.

Segundo a documentação oficial do <a href="https://developer.wordpress.org/cli/commands/db/export/">WordPress Developer Resources</a>, o export aceita parâmetros de tabela e compressão direto na chamada, o que permite encadear os 30 sites num único script de cron agendado no sistema operacional, não no navegador.

Quem roda frota grande costuma combinar o WP-CLI com rsync para o destino externo, ganhando cópia incremental de verdade. O detalhe que só aparece em produção: em frota acima de 20 sites no mesmo servidor compartilhado, rodar todos os dumps às 3h gera pico de I/O; escalonar em janelas e usar incremental após o backup completo semanal estabiliza o servidor. Para o uso de linha de comando além do backup, o <a href="https://full.services/wp-cli-para-gestao-wordpress/">WP-CLI para gestão WordPress</a> cobre os comandos do dia a dia.

---

## Backup centralizado e monitoramento andam juntos

Backup centralizado sem monitoramento é metade da rotina, porque a falha silenciosa é a regra: um job que para de rodar não avisa, e você só descobre na hora de restaurar. Por isso o painel de backup precisa morar ao lado do painel de uptime e de atualizações.

Essas 3 telas formam uma única operação da frota. A maioria dos incidentes graves que chegam ao suporte da FULL combina backup quebrado com algum sinal que ninguém viu: site fora do ar, plugin desatualizado ou disco cheio acima de 90% de uso.

Integre o alerta de backup ao mesmo canal onde você recebe o status de disponibilidade. O <a href="https://full.services/monitoramento-de-uptime-wordpress/">monitoramento de uptime WordPress</a> e o backup centralizado consultam a mesma frota, então faz sentido vê-los juntos. Quando o backup falha e o site cai na mesma noite, ter as duas informações na mesma tela é o que decide se a recuperação leva minutos ou horas.

---

## Backup centralizado na FULL: 16 plugins por r$85 o site

No plano PRO da FULL, por R$849, você ativa 16 plugins premium em até 10 sites, o que dá R$85 por site para incluir UpdraftPlus, Perfmatters e WP Rocket no mesmo bundle. O motor de backup já entra sem licença avulsa.

Para quem administra uma frota, isso significa o motor de backup, a camada de performance e a de segurança ativados em um clique, sem comprar licença separada de cada plugin. Veja os detalhes em <a href="https://full.services/planos">FULL.services/planos</a>. A gente vê no suporte que o custo de licença avulsa por site é o que trava agências de padronizarem o backup centralizado em toda a carteira.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>As observações deste tutorial vêm da rotina de suporte da FULL com sites WordPress conectados ao painel, entre <time datetime="2026-01">janeiro</time> e <time datetime="2026-06">junho de 2026</time>, em ambientes WordPress 6.x com PHP 8.2 e 8.3. Os modelos de backup centralizado foram comparados em frotas de 5 a 40 sites usando UpdraftPlus, MainWP e ManageWP, com destinos em Amazon S3 e Backblaze B2. Os números de custo por site referem-se ao bundle FULL (R$849 no plano PRO em até 10 sites). Nenhuma proporção de incidentes foi medida em dataset fechado; as afirmações de frequência são qualitativas, baseadas no padrão recorrente dos tickets.</p>
</aside>

---

<aside aria-label="Resumo Técnico">
<h2 id="resumo-tecnico">Resumo técnico do backup centralizado</h2>
<p>Os pontos abaixo condensam as decisões que separam uma rotina confiável de uma falsa segurança numa frota WordPress de 5 a 40 sites.</p>
<ul style="margin-bottom:1.5rem">
  <li><strong>Melhor cenário:</strong> frota acima de 10 sites com destino externo na nuvem e agendamento escalonado fora do WP-Cron, no cron do servidor.</li>
  <li><strong>Pior cenário:</strong> cópia única na mesma pasta do site de produção, sem nenhum teste de restauração em staging.</li>
  <li><strong>Principal conflito:</strong> backup completo simultâneo de toda a frota às 3h gera pico de I/O que derruba o TTFB em servidor compartilhado.</li>
  <li><strong>Melhor alternativa gratuita:</strong> WP-CLI com `wp db export` mais rsync incremental, quando há acesso SSH ao servidor.</li>
  <li><strong>Em uma frase:</strong> backup centralizado só vale quando a restauração já foi testada em staging pelo menos uma vez por mês.</li>
</ul>
</aside>

<h2 id="faq">Perguntas frequentes sobre backup centralizado</h2>

<details>
<summary>Por que um backup centralizado falha mesmo aparecendo como concluído?</summary>
<p>Porque "concluído" no painel só confirma que o arquivo foi gerado, não que ele restaura. Um dump de banco interrompido no meio, uploads que estouraram o limite de memória do PHP ou um destino externo com credencial expirada produzem um arquivo presente mas corrompido. A única prova de que o backup centralizado funciona é restaurar a cópia em um ambiente de staging e fazer login no admin do site restaurado.</p>
</details>

<details>
<summary>É possível fazer backup centralizado de vários sites sem instalar plugin em cada um?</summary>
<p>É possível sim, por dois caminhos. O primeiro é o WP-CLI sobre SSH, em que um único script roda `wp db export` em cada site do servidor sem nenhum plugin. O segundo é um painel SaaS como o ManageWP, que usa um conector leve, mas ainda exige um pequeno worker no site. Sem acesso SSH e sem nenhum conector, não há como ler os arquivos de cada site de fora com segurança.</p>
</details>

<details>
<summary>Qual a diferença entre backup centralizado local e na nuvem?</summary>
<p>O backup centralizado local guarda a cópia no mesmo servidor ou em um disco anexo, e cai junto com o site se o servidor for comprometido. O backup na nuvem envia cada cópia para um destino externo, como Amazon S3 ou Backblaze B2, isolando a cópia do ambiente de produção. Para uma frota, só o modelo na nuvem sobrevive a ransomware ou falha total de disco do servidor de origem.</p>
</details>

<details>
<summary>Quanto custa armazenar backup centralizado de vários sites por mês?</summary>
<p>O custo depende do volume e do destino, não do plugin. O Backblaze B2 cobra por GB armazenado e costuma sair mais barato que o Amazon S3 para frotas grandes, enquanto plugins e painel podem ser zero quando você usa UpdraftPlus com WP-CLI. No bundle FULL, o motor de backup já entra nos 16 plugins por R$85 o site no plano PRO, e você paga só o armazenamento externo à parte.</p>
</details>

<details>
<summary>O que deve entrar na rotina de teste de restauração?</summary>
<p>A rotina precisa restaurar banco, uploads, temas e plugins em um ambiente de staging isolado da produção. Confirme três coisas no site restaurado: o login no admin funciona, o conteúdo bate com a data esperada da cópia e as imagens da biblioteca de mídia carregam. Repita esse teste pelo menos uma vez por mês em um site diferente da frota, porque um backup que nunca foi restaurado não pode ser chamado de backup.</p>
</details>

---

## Próximos passos para padronizar o backup da frota

Backup centralizado deixa de ser planilha e vira operação quando painel, destino externo, agendamento escalonado e teste de restauração estão nos cinco passos deste tutorial. O ponto que separa uma rotina confiável de uma falsa segurança é simples: a cópia mora fora do servidor e a restauração já foi testada em staging. Comece conectando a frota a um painel único, aponte o destino externo e só então confie no agendamento. Para aprofundar a operação de várias instalações em um só lugar, o <a href="https://full.services/painel-de-gestao-de-sites-wordpress/">painel de gestão de sites WordPress</a> e o <a href="https://full.services/backup-wordpress-automatico/">backup WordPress automático</a> são os próximos guias. Para continuar estudando, o FULL Academy reúne tutoriais, guias e reviews em <a href="https://full.services/academy/">FULL.services/academy</a>.

<p class="wp-caption-text">Legenda: um painel central lista o status do backup de cada site da frota, transformando conferência manual em monitoramento.</p>
