Backup na nuvem guarda uma cópia do site fora do servidor de hospedagem, em um bucket Amazon S3, para você restaurar mesmo se o disco falhar. Segundo a documentação do WordPress.org (2024), um backup completo cobre 3 camadas: arquivos, banco de dados e uploads. Use chave IAM restrita ao bucket, nunca a credencial root. Configure em 5 passos e agende para a madrugada.

Manter o backup na nuvem significa enviar a cópia do seu WordPress para um armazenamento externo como o Amazon S3, separado da máquina onde o site roda. Quando o backup mora só no mesmo servidor da hospedagem, uma invasão, uma falha de disco ou uma migração mal feita levam o site e a cópia de segurança juntos. Este tutorial mostra o caminho completo: bucket, chave de acesso, plugin, agendamento e teste de restauração. Para o panorama geral de proteção, vale ler antes o guia de como funciona o backup no WordPress e a página de conteúdos de gestão de sites WordPress da FULL.

Diagnóstico rápido: Por que backup na nuvem e não no servidor

Backup na nuvem resolve o ponto cego de quem confia só na cópia local: em boa parte dos tickets de restauração que chegam ao suporte da FULL, o backup existia, mas estava no mesmo disco que falhou ou foi comprometido. Guardar a cópia fora do servidor é o que muda o jogo de verdade.

A tabela abaixo separa onde cada destino protege. O backup do WordPress só é confiável quando a cópia vive em outro lugar geográfico, longe do disco que pode falhar.

O Amazon S3 entrega durabilidade alta e fica em uma conta separada da sua hospedagem, então um problema no site não derruba a cópia. Essa é a diferença que torna o backup na nuvem um seguro real, e não uma falsa sensação de segurança.

O que entra em um backup na nuvem completo do WordPress

Um backup na nuvem completo do WordPress tem 3 partes obrigatórias e qualquer uma que falte quebra a restauração: os arquivos do core e dos plugins, o banco de dados e a pasta de uploads. As três precisam voltar juntas.

Em boa parte dos chamados de “restaurei mas o site voltou vazio”, o que faltou foi justamente o banco, que guarda posts, usuários e configurações. A pasta wp-content/uploads costuma ser a maior, porque concentra imagens e mídia.

Na prática, o backup na nuvem precisa unir o .sql do banco com o conteúdo de wp-content. Ferramentas como UpdraftPlus, WP-Optimize e o próprio WP-CLI tratam essas camadas em jobs separados, o que ajuda em sites grandes. Para entender quando vale dividir, veja o guia de backup incremental no WordPress: ele envia só o que mudou desde a última cópia, reduzindo o tempo de envio para o S3 e o custo de armazenamento na nuvem.

Quanto custa armazenar backup na nuvem na amazon S3

Armazenar backup na nuvem no Amazon S3 custa centavos de dólar por GB ao mês na classe Standard, mais uma taxa pequena por requisição de upload. Um site WordPress de 2 GB a 5 GB com retenção de 4 cópias fica na casa de poucos dólares por mês, acessível até para um único projeto.

O armazenamento em nuvem cobra pelo que você usa, sem mensalidade fixa de servidor. Esse modelo de pagamento por uso é o que mantém o backup na nuvem barato para sites pequenos.

O custo só dispara em dois cenários previsíveis: retenção exagerada (guardar 30 cópias completas de um site de 10 GB) e backup completo diário quando um incremental resolveria. Backblaze B2 e Wasabi competem aqui por preço por GB, enquanto o S3 compete por durabilidade e ecossistema de integrações. Para controlar a conta, mantenha retenção curta e prefira incremental nas cópias do dia a dia, deixando o backup completo para a semana.

Passo a passo: Backup na nuvem com S3 no WordPress

Configurar o backup na nuvem com S3 leva cerca de 20 minutos e envolve 5 passos diretos: criar o bucket, gerar uma chave de acesso restrita, instalar o plugin, apontar o destino e agendar. A regra de ouro é nunca usar a credencial root da AWS no plugin. Uma chave IAM restrita a um único bucket limita o estrago caso o WordPress seja invadido.

Legenda: o destino S3 só fica ativo depois que a chave de acesso e o nome do bucket são validados pelo plugin.

Passo 1: Crie o bucket no amazon S3

Acesse o console da AWS, abra o serviço S3 e crie um bucket com nome único, na região mais próxima dos seus visitantes (por exemplo, sa-east-1, em São Paulo). Mantenha o bloqueio de acesso público ligado: o bucket de backup nunca deve ser legível pela web. Anote o nome exato do bucket, porque o plugin vai pedir esse valor na hora de apontar o destino do backup na nuvem.

Passo 2: Gere uma chave IAM restrita ao bucket

No serviço IAM, crie um usuário só para backup e gere um par de chave de acesso e chave secreta. Anexe uma política que permita gravar e listar apenas naquele bucket, não na conta inteira. Uma chave de acesso da AWS com permissão total gravada no plugin, somada a uma invasão do WordPress, daria ao atacante acesso a toda a conta de nuvem. A permissão mínima por bucket é a camada que segura esse risco.

Passo 3: Instale o plugin de backup

Instale um plugin que fale com o S3, como o UpdraftPlus ou o WP-Optimize. No diretório oficial, confira se o plugin teve atualização recente e nota acima de 4 estrelas antes de instalar. O cron job do WordPress é quem dispara o backup agendado, então mantenha o site recebendo visitas ou configure um cron real no servidor para os horários baterem.

Passo 4: Aponte o destino S3 e valide

Nas configurações do plugin, escolha Amazon S3 como destino remoto e cole a chave de acesso, a chave secreta e o nome do bucket dos passos anteriores. Salve e use o botão de teste de conexão: o plugin grava um arquivo de prova no bucket e confirma se as permissões estão certas. Se o teste falhar, quase sempre é política IAM apertada demais ou nome de bucket digitado errado.

Passo 5: Agende e teste a restauração

Defina backup completo semanal e incremental diário, sempre na madrugada para não competir com o tráfego de pico. Depois, faça o passo que a maioria pula: baixe uma cópia e restaure em um ambiente de teste. Um backup na nuvem que nunca foi restaurado é uma hipótese, não uma garantia. Veja o procedimento em como testar backups de sites WordPress.

Erros comuns que quebram o backup na nuvem

A maior parte das falhas de backup na nuvem não vem da nuvem, e sim de configuração: agendamento em horário de pico, chave com permissão excessiva e retenção mal calibrada. Os três erros têm causa conhecida e correção simples.

Em sites acima de 5 GB rodando em VPS com menos de 2 GB de RAM, o backup completo do UpdraftPlus em horário de pico tende a estourar o max_execution_time do PHP no meio do envio para o S3. Dividir em backup incremental e agendar para a madrugada estabiliza o job.

Outro erro recorrente é confiar no cron do WordPress em site com pouco tráfego: sem visitas, o agendamento não dispara e o backup simplesmente não acontece. A correção é configurar um cron real no servidor apontando para o wp-cron.php. Por fim, a redundância importa: backup na nuvem não substitui o teste de restauração. Para revisar a rotina inteira, o guia de frequência ideal de backup ajuda a calibrar o intervalo certo por tipo de site.

Backup na nuvem em escala: Vários sites de uma vez

Quem cuida de 10, 50 ou 200 sites não configura backup na nuvem site a site no console da AWS: o trabalho vira ingovernável e cada chave avulsa é uma porta a mais. A escala muda completamente o problema de proteção de dados.

A gente vê no suporte da FULL que a dor real de agência não é o primeiro backup, e sim manter a cópia testada e padronizada em toda a carteira. Centralizar a gestão é o que transforma backup na nuvem de tarefa manual em rotina confiável.

Em escala, o padrão que funciona é um painel único que dispara, monitora e alerta sobre falhas de backup em todos os sites, com a mesma política aplicada de uma vez. É exatamente isso que descrevemos no guia de como gerenciar múltiplos sites WordPress. Sem centralização, o ponto fraco aparece sempre no site que ninguém checou: aquele em que o backup na nuvem parou de rodar há meses e ninguém percebeu.

Decisão rápida: Qual destino de backup na nuvem usar

Escolher o destino do backup na nuvem depende de três variáveis: tamanho do site, orçamento e quem vai operar. O Amazon S3 é o padrão seguro para a maioria, mas nem sempre é a melhor escolha de custo. Use a árvore abaixo como atalho de decisão antes de configurar.

• Se você quer durabilidade e integrações maduras → use Amazon S3 com chave IAM restrita ao bucket.
• Se o site é grande e o orçamento é curto → avalie Backblaze B2 ou Wasabi, que cobram bem menos por GB.
• Se você não opera AWS e quer simplicidade → comece com Google Drive como destino e migre para S3 quando crescer.
• Se você gerencia muitos sites → não configure um a um, centralize a gestão em um painel único.

Considere o painel de gestão da FULL para backup em escala

Configurar backup na nuvem em um site é simples; manter dezenas de sites com cópia testada, monitorada e padronizada é onde o tempo some. No plano PRO da FULL, por R$849 por ano, você gerencia até 10 sites com o bundle completo de plugins premium, o que dá cerca de R$85 por site, bem abaixo do custo de licenciar cada ferramenta avulsa. Conheça os planos da FULL para centralizar backup, atualizações e segurança da carteira inteira em um lugar só.

Perguntas frequentes sobre backup na nuvem

Próximos passos para proteger seu site na nuvem

Backup na nuvem com Amazon S3 deixa de ser teoria quando você fecha o ciclo: bucket criado, chave IAM restrita, plugin apontado, agendamento na madrugada e, principalmente, uma restauração de teste já feita. Esse último passo é o que separa quem tem um seguro real de quem tem só uma pasta de arquivos. Mantenha retenção curta, prefira incremental no dia a dia e cheque os relatórios de backup com regularidade. Quando o site for restaurado em emergência, o procedimento de como restaurar o WordPress a partir do backup fecha o ciclo. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de WordPress em um só lugar.