Uma Estratégia Prática de Backup para VPS (Regra 3-2-1)

Escrito pela equipe ApexVPS • Última atualização: julho de 2026 • 7 min de leitura

Uma estratégia de backup VPS confiável é a diferença entre uma recuperação em cinco minutos e uma semana muito ruim. Servidores falham, discos corrompem, deploys dão errado, e um único comando digitado errado pode apagar um diretório. O Centro de Aprendizado da Cloudflare e a maioria das equipes de infraestrutura apontam para a mesma disciplina simples: a regra 3-2-1. Este guia mostra como aplicá-la a um servidor virtual real, quais ferramentas usar e como agendar e testar tudo para que uma restauração realmente funcione quando você precisar.

O que a Regra 3-2-1 Significa

A regra 3-2-1 é um princípio de backup com décadas de existência que permanece verdadeiro não importa onde seu servidor esteja:

3 cópias dos seus dados — a cópia ativa mais pelo menos dois backups.
2 mídias ou sistemas de armazenamento diferentes — para que uma única falha não possa eliminar as duas cópias de uma só vez.
1 cópia fora do local — fisicamente ou logicamente separada da máquina que você está protegendo.

Em um VPS, isso geralmente significa seu servidor em execução, um repositório de backup local e uma cópia criptografada enviada para armazenamento remoto em um local diferente. O objetivo é redundância sem um único ponto de falha compartilhado.

O que fazer backup em um VPS

Fazer backup do disco inteiro, bloco por bloco, é desperdício e lento. Um bom plano de backup tem como alvo as três coisas que são genuinamente difíceis de recriar.

Dados e arquivos de aplicativos

Arquivos enviados, raízes de sites, volumes de contêineres e tudo o que os usuários geram. Caminhos típicos incluem /var/www, /srv, /home e o diretório de volumes do Docker. Se você hospeda seus próprios aplicativos, como um servidor de arquivos ou wiki, é aqui que seu conteúdo insubstituível vive — veja nosso guia para executar um VPS para auto-hospedagem para saber como esses diretórios são geralmente organizados.

Bancos de dados

Nunca copie arquivos de banco de dados ao vivo enquanto o serviço está em execução — você pode capturar um estado corrompido pela metade. Em vez disso, exporte um dump consistente. Para MySQL ou MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

A opção --single-transaction fornece um instantâneo consistente das tabelas InnoDB sem bloqueá-las. Para PostgreSQL, use pg_dump em vez disso:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Configuração do sistema e dos serviços

Os arquivos que tornam seu servidor único: /etc (nginx, units do systemd, cron, config SSH), listas de pacotes, certificados TLS e regras de firewall. Reconstruir tudo isso de memória após uma falha é exatamente o trabalho tedioso que os backups existem para evitar.

Escolhendo suas ferramentas de backup

Três ferramentas cobrem quase todos os casos de VPS. Escolha com base em quanto você valoriza a deduplicação e a criptografia.

restic — snapshots criptografados e deduplicados

restic é uma ferramenta moderna de backup em binário único que criptografa e deduplica por padrão. Inicialize um repositório uma vez e execute backups contra ele:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — arquivos deduplicados

O BorgBackup oferece deduplicação e compressão semelhantes com um fluxo de trabalho ligeiramente diferente:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — espelhamento simples de arquivos

Quando você só precisa de um espelho rápido de arquivos para outro host, rsync via SSH é difícil de superar:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

As opções -aAX preservam permissões, ACLs e atributos estendidos; --delete mantém o espelho em sincronia com a origem. O rsync sozinho não mantém histórico de versões, por isso muitas equipes o combinam com restic ou borg.

Automatize o agendamento com cron

Um backup que você precisa lembrar de executar é um backup que não vai acontecer. Coloque suas etapas em um script, torne-o executável e agende-o com cron. Edite seu crontab com:

crontab -e

Em seguida, adicione linhas como estas:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Registre a saída e faça o script sair com código não zero em caso de falha para que você possa conectá-lo aos recursos de monitoramento e alerta que vêm com seu plano. Uma falha silenciosa de backup é pior do que nenhum backup, porque passa a sensação de segurança.

Mantenha uma cópia realmente fora do local

O "1" no 3-2-1 é a parte que a maioria das pessoas pula. Um backup no mesmo servidor que protege desaparece junto com ele. Envie uma cópia criptografada para algum lugar independente — armazenamento de objetos, um servidor SFTP remoto ou outro provedor. restic e borg escrevem diretamente em repositórios remotos, por exemplo via SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Como restic e borg criptografam antes que os dados saiam do seu VPS, o host remoto nunca vê seu texto simples. Pode os snapshots antigos com uma política para que o armazenamento não cresça para sempre:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Teste suas restaurações — sempre

Um backup não testado é um boato. Agende uma restauração periódica em um local descartável e confirme que os arquivos e bancos de dados voltam intactos:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Se a restauração for bem-sucedida e os dados corresponderem, você tem uma estratégia. Se não, você acabou de aprender isso em uma terça à tarde, em vez de durante uma interrupção real.

Snapshots são uma camada, não a estratégia completa

Todo plano da ApexVPS inclui backups automáticos — snapshots diários no Starter Pro e snapshots por hora no Business — e eles são genuinamente úteis para rollbacks rápidos após uma implantação ruim ou exclusão acidental. Mas seja honesto sobre o que eles são: uma camada primeira conveniente que reside na nossa plataforma. Eles não substituem a cópia externa, verificada de forma independente, exigida pela regra 3-2-1. Trate os snapshots da plataforma como seu ponto de restauração local rápido e execute seu próprio job restic ou borg para satisfazer as partes de offsite e restauração testada da regra. Essa abordagem em camadas é o que separa uma configuração esperançosa de uma resiliente, seja hospedando aplicativos como Nextcloud ou executando um banco de dados de produção.

Checklist de Estratégia de Backup para Sua VPS

Juntando as peças, uma estratégia completa de backup para um servidor virtual fica assim. Passe por isso uma vez, automatize, e deixe o cron levar adiante:

Identifique o que importa — arquivos de aplicativos, dumps de banco de dados e a configuração em /etc.
Escolha uma ferramenta — restic ou BorgBackup para backups criptografados, deduplicados e versionados; rsync para mirrors simples.
Faça dumps consistentes do banco de dados — mysqldump --single-transaction ou pg_dump, nunca uma cópia crua dos arquivos em produção.
Automatize — agende o script com cron e alerte sobre qualquer saída não-zero.
Envie uma cópia offsite — criptografada, em armazenamento independente, com uma política de retenção sensata.
Teste restaurações regularmente — restaure para um local temporário e confirme que os dados estão intactos.

Faça essas seis coisas e a regra 3-2-1 deixa de ser teoria e se torna um hábito no qual sua infraestrutura pode confiar. A hora inicial de configuração é trivial comparada ao custo de descobrir, no meio de um incidente, que sua única cópia estava no disco que acabou de falhar.

Precisa de um servidor que você controla totalmente para executar isso? A ApexVPS oferece acesso root completo, armazenamento NVMe e recursos dedicados em 39 data centers — com checkout apenas em cripto, sem cartão e sem KYC. Compare os planos de VPS dedicado →

Perguntas Frequentes

Snapshots do provedor contam como estratégia de backup?

Snapshots são uma camada útil, mas não uma estratégia completa. Nossos snapshots diários e por hora protegem contra a maioria dos erros de curto prazo, mas eles ficam na mesma plataforma que o seu servidor. Uma estratégia completa de backup 3-2-1 ainda precisa de uma cópia independente, offsite, que você controla e restaurações que você realmente testou.

Com que frequência devo fazer backup de uma VPS?

Equilibre a frequência com a quantidade de dados que você pode perder. Arquivos estáticos e configurações podem ter backup diário, enquanto bancos de dados ativos geralmente justificam dumps por hora. Use cron para automatizar o agendamento, para que os backups nunca dependam de lembrar de executá-los.

Qual é a melhor ferramenta para backups de VPS?

restic e BorgBackup são excelentes: eles deduplicam, compactam e criptografam backups, e suportam repositórios offsite. rsync é adequado para espelhamento simples de arquivos, e mysqldump ou pg_dump lidam com exportações de banco de dados. Muitas configurações combinam um dump de banco de dados com uma execução do restic ou do borg.

Como sei que meus backups realmente funcionam?

Teste restaurações em um cronograma. Restaure em um diretório temporário, verifique o conteúdo dos arquivos e checksums, e importe um dump de banco de dados para um banco de dados de teste. Um backup que você nunca restaurou é apenas um palpite esperançoso, não um plano de recuperação.