Backups de VPS: estratégias e ferramentas

Numa VPS, os backups são responsabilidade sua, mesmo que o plano diga «backups incluídos». Vamos ver o que exatamente copiar, por que o snapshot do provedor não basta, como configurar o restic ou o BorgBackup em meia hora e como ter certeza de que dá mesmo para restaurar a partir da cópia.

Atualizado 31.10.2026 · Encontre um VPS sob medida →

Normalmente a gente só se lembra do backup na hora em que precisa dele: uma atualização quebrou o banco de dados, alguém apagou a pasta do site, o disco do provedor falhou ou o servidor foi invadido. Em cada um desses casos, o que salva não é qualquer cópia, e sim aquela que está em outro lugar, foi feita recentemente e da qual você já restaurou pelo menos uma vez. Abaixo, como montar uma cópia assim num servidor Linux comum.

O snapshot do provedor ainda não é uma estratégia

Muitos provedores oferecem snapshots do disco e backups automáticos no painel. Isso é útil, mas esse tipo de cópia tem três pontos fracos.

Ela fica no mesmo provedor. Um problema de pagamento, o encerramento da conta, uma pane no data center ou uma senha roubada da área do cliente levam embora o servidor e todos os seus snapshots de uma vez.
As cópias são poucas e espaçadas. Muitas vezes são uma ou duas cópias recentes, uma vez por dia ou por semana. Se o problema for notado só depois de alguns dias, pode não restar nenhuma versão boa.
O banco de dados no snapshot nem sempre está íntegro. O snapshot congela o disco num momento qualquer, como se o servidor tivesse sido desligado de repente. O InnoDB e o PostgreSQL normalmente se recuperam disso, mas não há garantia, e tabelas MyISAM podem sair corrompidas.

O snapshot é prático como ponto de retorno rápido antes de uma atualização. Os backups principais devem ser feitos com ferramentas próprias e guardados à parte.

A regra 3-2-1

O esquema clássico é este: três cópias dos dados, em duas mídias ou sistemas diferentes, uma delas em outro lugar. Para uma VPS, isso costuma ficar assim:

Os dados em uso no próprio servidor.
Uma cópia em outro servidor ou num armazenamento de objetos S3 de outro provedor, ou pelo menos em outro data center.
Mais uma cópia: snapshots no painel do provedor, um segundo servidor de backup ou uma cópia num armazenamento em casa.

Vale acrescentar uma regra: pelo menos uma cópia não pode ser apagável a partir do próprio servidor de produção. Se um invasor conseguiu root, ele também vê as senhas do armazenamento de backups. Como resolver isso está explicado abaixo, na seção sobre proteção contra exclusão.

O que copiar

Copiar o sistema inteiro geralmente não é necessário: um servidor limpo sobe a partir de uma imagem em minutos. O que vale são os dados e as configurações.

O quê	Onde costuma ficar	Como copiar
Arquivos dos sites e uploads dos usuários	`/var/www`, `/home`	Como arquivos
Bancos de dados	`/var/lib/mysql`, `/var/lib/postgresql`	Só por dump, não como arquivos
Configurações do sistema e dos serviços	`/etc`	Como arquivos, junto com os certificados de `/etc/letsencrypt`
Tarefas agendadas	`/etc/cron.d`, `crontab -l` dos usuários	Como arquivos ou exportando para texto
Dados de contêineres	Volumes do Docker, normalmente `/var/lib/docker/volumes`	Como arquivos com o contêiner parado ou por dump do banco dentro dele

Exclua caches, arquivos temporários, logs e node_modules: eles incham a cópia e se recriam sozinhos.

Bancos de dados: só por dump

Não se devem copiar os arquivos de um banco de dados em funcionamento: eles mudam durante a cópia, e o resultado fica inconsistente. O caminho certo é o dump. Para MySQL e MariaDB:

mysqldump --single-transaction --routines --triggers shop | gzip > /var/backups/shop-$(date +%F).sql.gz

A opção --single-transaction faz um dump consistente das tabelas InnoDB sem interromper a gravação. Ela não protege tabelas MyISAM: se houver alguma, converta-a para InnoDB ou faça o dump com --lock-all-tables. No Debian e no Ubuntu, o root entra no MariaDB sem senha pelo socket, então o comando como root funciona do jeito que está; para outro usuário, coloque login e senha em ~/.my.cnf com permissões 600.

Para PostgreSQL:

sudo -u postgres pg_dump -Fc shop > /var/backups/shop-$(date +%F).dump
sudo -u postgres pg_dumpall --globals-only > /var/backups/pg-globals.sql

O segundo arquivo guarda os papéis e as permissões, que não entram no dump de um banco individual. Um dump desses se restaura com o comando pg_restore -d shop arquivo.dump. Se o banco tem dezenas de gigabytes e o dump demora demais, considere a cópia física: mariabackup ou Percona XtraBackup para MySQL, pgBackRest para PostgreSQL.

Guarde os dumps numa única pasta, por exemplo /var/backups, e inclua-a no backup de arquivos: assim tudo vai para o armazenamento com um único comando.

Ferramentas: rsync, restic, BorgBackup

	rsync	restic	BorgBackup
Versões das cópias	Só manualmente, com `--link-dest`	Sim, snapshots	Sim, arquivos
Criptografia	Não, só na transferência por SSH	Sempre, no servidor de origem	Sim, opcional ao criar o repositório
Deduplicação	Não	Sim	Sim, mais compressão
Onde salvar	Disco, SSH	Disco, SFTP, S3, rest-server próprio	Disco, SSH com borg do outro lado
Modo «só adicionar»	Não	Via rest-server	Via `borg serve --append-only`

rsync: um espelho, não uma cópia

O rsync sincroniza pastas rapidamente, mas por si só não é um backup: um arquivo apagado ou corrompido no servidor será, na execução seguinte, igualmente apagado ou corrompido no espelho. Dá para ter versões com a opção --link-dest: cada execução cria uma pasta nova, e nela os arquivos que não mudaram são hard links para a anterior, de modo que o espaço só é gasto com as mudanças. É mais prático rodar isso no servidor de backup, que busca os dados no servidor de produção:

rsync -a --delete --link-dest=/backup/web/2026-10-30 root@web.example.com:/var/www/ /backup/web/2026-10-31/

Para um único site isso basta, mas o rsync não oferece criptografia nem verificação de integridade.

restic

O restic é um único programa, sem dependências. Ele criptografa os dados antes de enviá-los, guarda só os pedaços novos dos arquivos e sabe gravar em SFTP, num armazenamento compatível com S3 ou num rest-server próprio. O repositório é criado uma vez, e depois o backup é feito com um único comando:

export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic init
restic backup /etc /var/www /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

O comando forget mantém 7 snapshots diários, 4 semanais e 6 mensais, e o --prune libera o espaço dos demais. Sem a senha de /root/.restic-pass, não há como descriptografar o repositório, então guarde uma cópia dela fora do servidor, por exemplo num gerenciador de senhas.

BorgBackup

O Borg é parecido com o restic, mas costuma comprimir melhor e lidar mais rápido com um grande número de arquivos pequenos. Ele mantém o repositório em disco ou em outro servidor via SSH, onde também precisa haver borg instalado; S3 ele não suporta diretamente. O ramo estável em 2026 é o 1.4; a versão 2.0 ainda está em beta e não é recomendada para backups de produção. Comandos para o 1.4:

export BORG_REPO=ssh://backup@storage.example.com/./web1
export BORG_PASSCOMMAND="cat /root/.borg-pass"

borg init --encryption=repokey-blake2
borg create --stats --compression zstd ::'{hostname}-{now}' /etc /var/www /var/backups
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact

Desde o 1.2, o espaço depois do prune só é liberado com o comando compact. No modo repokey, a chave fica guardada no próprio repositório, protegida por senha; por precaução, exporte-a com o comando borg key export e guarde-a fora do servidor.

Se o servidor tem um painel de controle, veja os backups embutidos dele: no ISPmanager, no FASTPANEL e no aaPanel eles são configurados pela interface e sabem enviar os arquivos para um armazenamento externo. Seleções de planos com painéis: ISPmanager, FASTPANEL, aaPanel.

Onde guardar as cópias

Uma VPS separada em outro provedor. Para backups não é preciso um processador rápido, e sim um disco grande. Planos assim estão reunidos nas seleções VPS para armazenamento de dados, VPS com HDD e VPS para backups.
Armazenamento de objetos S3. Você paga pelos gigabytes ocupados, e o restic grava lá diretamente. Se o armazenamento suporta versionamento de objetos ou bloqueio de exclusão por um prazo, isso também protege contra exclusão.
Um armazenamento em casa ou no escritório. É bom como terceira cópia: o servidor de backup busca os dados por SSH por conta própria, e de fora não é possível se conectar a ele.

Se o banco de dados contém dados pessoais de cidadãos russos, leve em conta a lei 152-FZ: também é melhor manter as cópias em servidores na Rússia; seleção: VPS para a 152-FZ.

Proteção contra exclusão

A situação mais desagradável é quando um invasor ou um script com erro apaga os dados e também as cópias. Há três formas de evitar isso.

Buscar, em vez de enviar. O servidor de backup se conecta ao servidor de produção e busca os dados. O servidor de produção não tem nenhum acesso às cópias.
Modo «só adicionar». Para o borg, no servidor de backup, define-se em authorized_keys um comando para a chave do servidor de produção: command="borg serve --append-only --restrict-to-path /srv/borg/web1",restrict ssh-ed25519 AAAA…. É possível adicionar novos arquivos, mas não apagar os antigos. Para o restic, o mesmo é feito pelo rest-server iniciado com a opção --append-only. Nesse caso, a limpeza das cópias antigas é feita a partir de uma máquina de confiança, com outra chave.
Versionamento e bloqueio de exclusão no S3. O próprio armazenamento guarda as versões anteriores dos objetos pelo prazo definido.

Agendamento e frequência dos backups

A frequência depende de quantos dados você aceita perder. Para um blog, uma cópia por dia basta. Para uma loja em que os pedidos chegam o dia todo, vale fazer o dump do banco a cada hora e copiar os arquivos uma vez por dia. Rode o backup pelo cron ou por um timer do systemd à noite, por exemplo com o arquivo /etc/cron.d/backup contendo a linha 30 3 * * * root /usr/local/bin/backup.sh.

Um backup que parou de ser feito em silêncio é pior do que não ter backup: você acha que está protegido. No fim do script, envie um sinal para um monitoramento externo (um simples curl para o endereço de verificação), e, se o sinal não chegar a tempo, o monitoramento avisa você.

Teste a restauração

Uma vez por mês, restaure a cópia num servidor limpo e confira se o site abre e os dados estão lá. Para isso, a cobrança por hora é prática: o servidor de teste só é pago pelas horas em que fica ligado.

restic restore latest --target /tmp/restore --include /var/www/site
restic check --read-data-subset=10%
borg extract ::web1-2026-10-31T03:30:00 var/www/site   # nome do arquivo: veja borg list
borg check --verify-data

O segundo e o quarto comandos leem os próprios dados do repositório, e não só o índice dele, e encontram pedaços corrompidos. Anote o procedimento de restauração num arquivo separado, fora do servidor: na hora da pane não há tempo para lembrar comandos. Como preparar o novo servidor no qual você vai restaurar está descrito no artigo Primeiros 10 passos depois de comprar uma VPS: segurança, e a migração do site inteiro, no artigo Como migrar um site da hospedagem para uma VPS.

Perguntas frequentes

Qual a diferença entre um snapshot e um backup?

O snapshot congela o disco inteiro num momento e fica guardado no mesmo provedor. O backup é feito com as suas ferramentas, fica guardado em outro lugar e contém várias versões dos dados. O snapshot é prático antes de uma atualização, mas não substitui os backups.

O que é melhor: restic ou BorgBackup?

Os dois criptografam os dados e guardam só as mudanças. O restic é mais fácil de instalar e grava direto no S3; o borg costuma comprimir melhor, mas o servidor de backup também precisa ter borg instalado. Para um ou dois servidores, a diferença é pequena.

Quanto espaço é preciso para os backups?

A primeira cópia ocupa mais ou menos o volume dos dados, no borg menos, graças à compressão. Depois só as mudanças são salvas, então um mês de cópias diárias de um site muitas vezes cabe em uma vez e meia a duas vezes o volume dos próprios dados. O número exato aparece na saída de restic stats ou borg info depois de umas duas semanas.

Posso guardar os backups no mesmo provedor?

Como cópia adicional, sim, de preferência em outro data center. A cópia externa principal é melhor manter em outro provedor: assim, problemas com a conta ou uma pane não atingem os dois lugares ao mesmo tempo.

Com que frequência fazer backup de um site?

Na medida de quantos dados você aceita perder. Para um blog, uma vez por dia basta; numa loja, vale fazer o dump do banco a cada hora e copiar os arquivos uma vez por dia. É razoável manter 7 cópias diárias, 4 semanais e algumas mensais.

Posso copiar a pasta do banco de dados em vez de fazer um dump?

Só se o servidor do banco estiver parado. Num servidor em funcionamento, os arquivos mudam durante a cópia, e a cópia pode nem iniciar. Use o mysqldump com --single-transaction ou o pg_dump.

Planos sobre o tema

VPS para Nextcloud VPS para banco de dados VPS para PostgreSQL Ranking de hospedagem VPS 2026

Mais no guia

Docker em VPS: por onde começarCom o Docker, você roda no servidor um bot, um site, um banco de dados e o monitoramento sem que um atrapalhe o outro, e mudar para outra VPS se resume a copiar alguns arquivos e os dados. A instalação leva cinco minutos; os problemas de verdade aparecem depois: portas do banco abertas para a internet, logs de dezenas de gigabytes e dados que sumiram junto com o contêiner. Veja como evitá-los desde o início.
Como migrar um site da hospedagem para uma VPSA migração em si leva umas duas horas, e os erros costumam acontecer em volta dela: uma tarefa do cron esquecida, regras do .htaccess que o nginx não lê, um registro AAAA com o endereço antigo ou um e-mail que sumiu junto com a troca de IP. Abaixo, a ordem dos passos com comandos e verificações para um site em PHP e MySQL.
Painéis de controle de servidor: ISPmanager, FASTPANEL, aaPanelO painel transforma a VPS em algo parecido com o painel da hospedagem compartilhada: sites, bancos de dados, e-mail e certificados são criados com o mouse, e não editando arquivos de configuração. Os três painéis mais instalados em servidores russos e em servidores baratos no exterior são o ISPmanager, o FASTPANEL e o aaPanel. Eles diferem no preço, na memória que exigem e no quanto tomam conta do servidor.
VPS Windows para 1CUm servidor alugado para o 1C livra a empresa daquele computador debaixo da mesa do escritório que ninguém atualiza nem copia. Mas o 1C em VPS tem particularidades: a licença de software fica vinculada aos parâmetros da máquina virtual, os usuários precisam de licenças tanto do 1C quanto do Windows, e a frequência dos núcleos importa mais que a quantidade. Veja como montar um servidor para o 1C numa empresa pequena.
VPS Windows: licenciamento, RDP e acesso seguroUm servidor Windows custa mais que um Linux não só por causa da memória: o preço inclui uma licença, e a forma como ela é contratada define se o uso está regular e quantas pessoas podem se conectar. Uma porta RDP exposta também é o caminho mais comum para invadir esses servidores. Veja os dois temas.
Quando migrar da hospedagem compartilhada para uma VPSUma VPS não deixa o site mais rápido por si só: ela dá recursos e liberdade e, junto com eles, o trabalho de administrar um servidor. Veja como saber que a hospedagem ficou pequena, quando o problema se resolve sem mudança e como migrar um site sem que os visitantes percebam.
Primeiros 10 passos depois de comprar uma VPS: segurançaTentativas de adivinhar a senha de um servidor novo começam poucos minutos depois que ele ganha um IP público. Abaixo estão dez passos que, em uma hora, fecham as brechas mais comuns: comandos para Ubuntu e Debian, as diferenças para AlmaLinux e Rocky Linux e as verificações sem as quais é fácil perder o acesso ao seu próprio servidor.
Como escolher o país do servidorColoque o servidor onde estão os seus visitantes. Para um público no Brasil, São Paulo dá o menor ping; Miami e a costa leste dos EUA são a alternativa comum, e a Europa fica bem mais longe. A LGPD não obriga a manter os dados no Brasil, mas a transferência para fora precisa de base legal. O preço quase não decide: no mesmo provedor, Europa e EUA costumam custar o mesmo, e só Ásia e Austrália saem bem mais caras.
Cobrança por hora: quando ela compensaA cobrança por hora compensa se você precisa do servidor menos de três semanas por mês: para um teste, um build, uma tarefa pesada pontual. Na maioria dos provedores, a hora custa exatamente o preço mensal dividido por 730 horas, então num mês cheio você quase não paga a mais. O custo extra está em outro lugar: os planos com cobrança por hora são, em média, mais caros, e para um servidor que roda o ano inteiro o plano mensal ou anual costuma sair mais barato.
Quanta memória e quantos núcleos um site precisaA maioria dos sites roda bem com 2 GB de memória e um ou dois núcleos; uma loja com milhares de produtos precisa de 4 GB e dois núcleos. Memória importa mais que núcleos: quando ela falta, o site fica lento ou cai, e um núcleo a mais sem memória quase não ajuda. Abaixo mostro como calcular a memória para o seu site e como descobrir quanto ele gasta de verdade.
KVM ou OpenVZ: o que escolherEm 2026 quase sempre vale escolher KVM: ele custa no máximo uns dois dólares por mês a mais que o OpenVZ, mas nele tudo funciona, do Docker ao Windows. O OpenVZ só se justifica num caso estreito, e abaixo você vê qual; no final estão os comandos para conferir o seu servidor em um minuto.
NVMe ou SSD: faz diferença para um site?Para um site pequeno, a diferença entre NVMe e SSD é quase imperceptível: as páginas saem da memória, não do disco. Ela aparece em lojas virtuais e sites com banco de dados grande. E no mesmo provedor o NVMe custa só uns US$ 0,50–1 por mês a mais, às vezes até menos que o SSD, então o que decide normalmente não é o tipo de disco, e sim o tamanho e como o provedor o limitou.
O que é VPS, explicado de forma simplesUma VPS é um pedaço de um servidor físico potente que você aluga e que se comporta como um computador independente: com sistema próprio, endereço IP próprio e acesso total. Veja como ela se diferencia da hospedagem, para quem serve, quanto custa e o que conferir logo depois da contratação.
VPS para bot do Telegram: do que o bot precisa e como escolher o planoUm bot com menu e alguns comandos roda bem no servidor mais barato, enquanto um bot com disparos, arquivos e banco de dados esbarra em limites totalmente diferentes. Veja o que um bot realmente consome, quais limites do Telegram definem a escolha do servidor e como não pagar a mais.
Como testar ping e velocidade de uma VPS antes de pagarOs números de um plano não dizem qual será a latência até seus usuários nem a velocidade real do disco. Quase tudo pode ser medido antes de pagar, e o resto na primeira hora depois de ligar o servidor. Veja as ferramentas e como interpretar os resultados.
Rede corporativa em VPS: acesso remoto ao escritórioUm servidor alugado pode virar o centro da rede privada de uma empresa: funcionários remotos e filiais se conectam por ele ao ERP, ao servidor de arquivos, ao CRM e ao Git. Veja os esquemas mais comuns, os protocolos, os requisitos do servidor e o básico de segurança.
Como escolher uma VPS: os 7 parâmetros que decidemDois planos com os mesmos «2 núcleos, 4 GB, 50 GB» podem ter velocidade várias vezes diferente e custar o dobro um ano depois. Veja o que existe por trás de cada linha de um plano VPS e o que conferir antes de pagar.
VPS ou VDS: existe diferença e o que realmente importaNa maioria dos mercados, VPS e VDS significam a mesma coisa: um servidor virtual. A diferença que de fato afeta o seu trabalho não está no nome, e sim no tipo de virtualização e em os recursos serem garantidos ou não.