Como usar um VPS como destino de backup externo

O que um destino de backup externo realmente é

Um destino de backup externo é uma segunda máquina que mantém uma cópia dos seus dados e falha de forma independente da máquina original. Um VPS de outro provedor é a opção mais barata que a maioria dos leitores consegue obter. Existem três opções realistas: executar o Proxmox Backup Server no VPS, usar um repositório restic através de SSH ou S3, ou manter um espelho rsync que o host de backup obtém. A escolha depende do que precisa de restaurar e da rapidez necessária para recuperar os dados. Quem tem permissão para eliminar a cópia define o resto.

Externo significa um domínio de falha diferente. Isso implica usar outro provedor e uma conta que não partilhe credenciais com a conta que executa o seu servidor. Um segundo servidor noutra região do mesmo provedor sobrevive a um incêndio num edifício. Não sobrevive a uma conta comprometida no painel de controlo, porque uma única conta controla as duas cópias.

Um snapshot no seu provedor não é essa segunda cópia. Fica protegido pela mesma palavra-passe do painel. Por isso, quem obtiver essa palavra-passe pode eliminar o servidor e os respetivos snapshots numa única sessão. Os serviços de snapshots também cobram por gigabyte e por mês, com preços muito superiores aos de um disco comum, o que torna caro mantê-los durante noventa dias. A diferença entre snapshots de VPS e backups merece ser lida antes de confiar em qualquer uma das opções.

Qual das três opções se adequa ao seu caso

• Proxmox Backup Server (PBS): a origem é o Proxmox VE (ambiente virtual) e o que restaura é uma máquina virtual completa. O backup é feito ao nível da imagem de disco, e os trabalhos de verificação voltam a ler os dados armazenados no destino.
• Um repositório restic: a origem é um ou vários hosts Linux e o que restaura é um diretório ou um dump de base de dados. A encriptação é feita no cliente, que comunica por SSH e S3, além de utilizar o seu próprio protocolo REST.
• rsync sobre SSH, iniciado pelo host de backup: pretende ter os ficheiros no destino como ficheiros normais, legíveis com ls e cat, sem precisar de software no cliente para os recuperar.

Se não conseguir decidir, use restic. A encriptação é feita antes de os dados saírem da máquina, e no destino só precisa de uma conta SSH e de espaço em disco. Configurar backups restic numa VPS aborda o lado do cliente com mais detalhe, e restic e BorgBackup lado a lado ajuda a escolher se já utiliza Borg.

Dimensionar o destino: quanto custa um mês de retenção

A deduplicação explica por que os valores são menores do que se espera. O restic e o PBS dividem os ficheiros em blocos de tamanho variável e calculam o hash de cada bloco. Cada bloco exclusivo é armazenado uma única vez. A segunda cópia de segurança de um conjunto de dados de 500 GB não acrescenta outros 500 GB. Acrescenta apenas os blocos que foram alterados.

Por isso, o tamanho do repositório acompanha a idade do snapshot mais antigo, não o número de snapshots. Considere 500 GB de dados e 5 GB de dados exclusivos novos por dia. O repositório conterá então os 500 GB de base, mais aproximadamente 5 GB por cada dia até ao snapshot mais antigo mantido pela política.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

A coluna em dólares calcula o preço desse repositório a 10 dólares dos Estados Unidos por TB por mês. É um valor de referência para a operação, não uma cotação de nenhum fornecedor. Substitua-o pelo preço real por TB do plano que está a considerar. Uma semana de cópias diárias ocupa aproximadamente 535 GB. Um ano completo de histórico ocupa 2,325 GB, o que corresponde a $23.25 por mês, contra $5.35 por mês para a semana. O histórico é barato. É pela cópia de base que está a pagar.

A deduplicação não tem efeito sobre dados que já chegam comprimidos ou encriptados. Um dump de base de dados comprimido com gzip muda completamente em cada execução. Por isso, cada dump é armazenado como blocos novos e o repositório cresce o equivalente a um dump completo todas as noites. Grave o dump sem compressão e deixe a ferramenta de cópia de segurança comprimi-lo. O restic suporta repositórios comprimidos desde a versão 0.14, e a versão 0.19 adicionou os modos zstd fastest e better. Bibliotecas de fotografias e vídeos também são mal deduplicadas pela mesma razão. Dimensione-as com base na sua taxa real de crescimento, e não nas linhas acima.

Aqui está a comprar espaço em disco ocioso, e não CPU. É precisamente o caso em que um storage VPS é melhor do que um VPS normal.

Por que a largura de banda e o tempo de restauração determinam o plano

O disco é a parte barata. O primeiro carregamento e a restauração eventual são as partes dispendiosas. 500 GB correspondem a 4 trillion bits, portanto dividir esse valor pela velocidade da ligação dá o limite mínimo de tempo de uma restauração completa.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Esses valores consideram a velocidade nominal da ligação, sem sobrecarga de protocolo, por isso devem ser lidos como o melhor caso. A 100 Mbit/s, uma restauração completa precisa de 11.1 horas antes de alguém poder trabalhar com os dados. Com uma velocidade de upload doméstica de 40 Mbit/s, precisa de 27.8 horas. Numa porta de 1 Gbit/s, a mesma restauração demora 1.1 horas. Muitos ficheiros pequenos tornam o processo mais lento do que o cálculo indica, porque a sobrecarga por ficheiro passa a predominar quando os ficheiros têm menos de algumas centenas de kilobytes.

Duas conclusões resultam daí. Se o seu objetivo de tempo de recuperação (RTO), ou seja, a interrupção que consegue tolerar, for de quatro horas, uma restauração de 500 GB através de uma ligação de 100 Mbit/s já ultrapassou esse limite, e um disco mais barato não ajuda. Além disso, a maioria dos planos VPS contabiliza a transferência de saída, pelo que uma restauração completa consome 0.5 TB da quota mensal do servidor de backups. Verifique essa quota e confirme o que o fornecedor faz quando a ultrapassa, antes de precisar dos dados.

O primeiro backup contém todo o conjunto de dados e é a execução mais lenta que alguma vez fará. Inicie-o numa sexta-feira e limite a velocidade para não saturar o uplink da origem: o restic recebe --limit-upload em KiB por segundo, e o rsync recebe --bwlimit.

Forma 1: Proxmox Backup Server como datastore remoto

O PBS é adequado quando a origem é o Proxmox VE e a unidade de restauro é uma máquina virtual. Um VPS não consegue arrancar a ISO do Proxmox, por isso instale o PBS sobre Debian. A versão 4.2 é a atual em agosto de 2026 e baseia-se no Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Compare esse checksum com o valor publicado na página dos repositórios de pacotes do Proxmox. Um repositório apt só é tão confiável quanto a chave que verificou. Em seguida, escreva /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Dê ao datastore o seu próprio sistema de ficheiros ou o seu próprio volume. Um datastore cheio interrompe as cópias de segurança, e um datastore que partilha o sistema de ficheiros raiz pode deixar todo o servidor indisponível quando fica sem espaço.

Em seguida, crie a conta que a origem vai utilizar e atribua-lhe um token em vez de uma palavra-passe.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

O segredo do token é apresentado uma única vez e não pode ser lido novamente, por isso guarde-o quando aparecer. O papel é tão importante quanto o token. DatastoreBackup pode criar e restaurar as suas próprias cópias de segurança e não tem o privilégio Datastore.Prune, portanto esse token não pode eliminar um snapshot que já tenha criado.

A retenção no PBS tem duas partes, e a segunda é a que muitas pessoas ignoram. O prune remove snapshots. A recolha de lixo remove os chunks que nenhum snapshot sobrevivente referencia. O espaço livre fica disponível depois da recolha de lixo, não depois do prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Remova --dry-run quando a lista de snapshots que planeia eliminar estiver correta. A recolha de lixo decorre em duas fases: atualiza a hora de acesso de cada chunk que ainda é referenciado e, em seguida, elimina os chunks cuja hora de acesso seja anterior ao limite, que corresponde a 24 horas e 5 minutos antes do início da execução. Este período de tolerância impede que um chunk que esteja a ser escrito por uma cópia de segurança em curso seja eliminado durante a operação. Agende o prune diariamente e a recolha de lixo semanalmente no datastore. Adicione também uma tarefa de verificação para que o destino volte a ler os seus próprios chunks e comunique corrupção no disco antes de um restauro a detetar.

Se a origem for uma instância PBS, o servidor remoto pode fazer o pull em vez de receber um push.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Execute essa tarefa de sincronização no VPS, na direção pull predefinida. O VPS acede ao datastore principal, o que significa que o servidor principal não guarda nenhuma credencial com acesso à cópia externa.

Forma 2: um repositório restic sobre SSH ou S3

Debian e Ubuntu disponibilizam o restic nos seus repositórios, mas ambos ficam atrás da versão upstream. A versão 0.19.1 é a atual em agosto de 2026. Instale o binário oficial no host de origem.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version mostra a versão e o compilador Go com que foi compilado. As atualizações posteriores são feitas com sudo restic self-update, que funciona com binários oficiais, mas não com uma cópia instalada através do apt.

No VPS de backup, crie uma conta que não seja proprietária de mais nada e copie a chave pública do host de origem para /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Inicialize o repositório a partir da origem, através de SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Guarde essa palavra-passe num local que não seja este servidor nem o destino de backup. Se a perder, o repositório ficará ilegível, sem qualquer possibilidade de recuperação. É esse o compromisso da encriptação no lado do cliente.

A retenção é feita com um comando, e a segunda parte é a que liberta espaço em disco.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget elimina snapshots. prune elimina os ficheiros pack referenciados apenas por esses snapshots, e --prune executa essa operação automaticamente quando algo é efetivamente removido. Sem esta opção, o repositório nunca diminui. restic check verifica a estrutura do repositório, e --read-data-subset=10% volta a ler e a calcular o hash de um décimo dos ficheiros pack, detetando corrupção no destino sem o custo de ler tudo. A outra forma, --read-data-subset=1/10, verifica sempre o mesmo décimo, pelo que incrementar o primeiro número todas as semanas permite cobrir todo o repositório ao longo de dez semanas.

Se uma execução for terminada à força, a seguinte para com repository is already locked exclusively by PID. Confirme que não está a decorrer nenhum backup e depois limpe-o com restic unlock.

Para armazenamento de objetos, a cadeia do repositório passa a ser s3:https://s3.example.net/web1, com as credenciais em AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Tudo o resto é igual. É assim que o restic comunica com um armazenamento de objetos MinIO autogerido em execução no mesmo VPS.

Forma 3: rsync sobre SSH com uma chave apenas para pull

A propriedade de segurança desta forma é a direção. O backup VPS liga-se à origem e lê os dados. A origem não tem nenhuma chave nem rota para o host de backup, por isso um comprometimento da origem não consegue alcançar os backups.

Gere um par de chaves no backup VPS e instale a chave pública na origem com um comando forçado.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync vem incluído no pacote rsync em /usr/bin/rrsync no Debian 13 e no Ubuntu 24.04. -ro permite apenas a leitura e implica -no-del, por isso esta chave não pode escrever na origem nem eliminar dados. restrict desativa as funcionalidades SSH que não são necessárias neste caso, incluindo o encaminhamento de portas e o pty, por isso a chave não pode ser usada para um login interativo. Os caminhos passam então a ser relativos ao diretório indicado, por isso o caminho remoto / significa /srv na origem.

O pull mantém o histórico com hardlinks. Os ficheiros inalterados na nova árvore são hardlinks para a árvore anterior, por isso ocupam uma entrada de diretório em vez de uma segunda cópia.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

A renomeação no fim é o que torna um diretório datado confiável: o nome só aparece depois de o rsync terminar com código 0, por isso uma transferência interrompida nunca parece um snapshot concluído. Expire as árvores antigas com uma linha, mantendo trinta.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Seja claro sobre o custo desta forma. Os hardlinks deduplicam apenas ficheiros completos, por isso alterar um byte dentro de uma imagem de disco de 4 GB copia os 4 GB, enquanto restic e PBS armazenariam apenas alguns blocos alterados. O destino também mantém os seus ficheiros em texto simples, por isso qualquer pessoa com root no backup VPS pode lê-los.

Criptografia no lado do cliente, para que o destino nunca veja texto simples

Trate o VPS de backup como uma máquina que não controla totalmente. Existe um provedor, com funcionários e discos avariados que podem sair das instalações.

O restic cifra cada bloco na origem antes de o enviar. O repositório contém, portanto, texto cifrado e metadados sobre tamanhos e tempos. No PBS, a criptografia é opcional: crie uma chave e passe-a em cada backup.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Imprima a chave em papel e guarde-a num local físico. A documentação do Proxmox é clara quanto ao risco: sem essa chave, os ficheiros de backup ficam inacessíveis. Mantenha a chave fora do destino de backup, porque uma chave guardada junto ao texto cifrado não protege ninguém.

Os espelhos rsync não têm equivalente. Os ficheiros chegam como ficheiros. Se os dados forem sensíveis, aceite que o destino os pode ler ou use uma das outras duas opções.

Impeça uma origem comprometida de apagar os próprios backups

Um atacante que comprometa a origem procura os backups em seguida, e a credencial que os envia está nessa mesma máquina. Se essa credencial também puder apagar dados, o atacante irá utilizá-la.

O PBS resolve isto com funções. Um token que tenha apenas DatastoreBackup pode gravar novos snapshots e restaurar os seus próprios snapshots. Não pode executar prune, porque apagar um snapshot requer o privilégio separado Datastore.Prune. Execute a retenção no lado do PBS. Assim, a origem nunca terá uma credencial que possa remover dados.

O restic através de SFTP não tem esta separação, porque a chave SSH que grava no repositório também pode apagar dados nele. A solução é utilizar o backend REST. Execute o rest-server no VPS de backup com --append-only. Esta opção permite criar novos backups, mas impede a eliminação e a modificação dos existentes. Depois, aponte o cliente para rest:https://backup.example.net:8000/web1 utilizando RESTIC_REST_USERNAME e RESTIC_REST_PASSWORD. Um restic forget --prune executado na origem falha, que é o resultado pretendido. Assim, a retenção é executada a partir de uma segunda máquina com a sua própria credencial. O manual do restic também recomenda --keep-within em vez de políticas baseadas numa contagem em repositórios append-only, porque um atacante que encha o repositório com snapshots inúteis poderia, caso contrário, expulsar os snapshots reais de uma janela --keep-last.

O rsync resolve o mesmo problema de forma estrutural através de pull, porque a origem não possui nenhuma credencial para o destino.

Uma regra abrange os três modelos: a credencial que pode apagar backups deve estar numa máquina diferente daquela que está a ser salvaguardada.

Coloque o teste de restauração no calendário

Um backup que nunca foi restaurado é apenas uma hipótese. Reserve uma hora a cada trimestre e teste-o.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r não imprimir nada significa que a árvore restaurada corresponde à árvore ativa. No PBS, o mesmo teste é feito com proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, além de uma tarefa de verificação agendada que volta a ler os chunks no destino e comunica falhas de checksum.

O teste tem de comprovar mais do que a integridade dos bytes.

• Faça a restauração a partir de uma terceira máquina, não da origem, porque a origem é precisamente aquilo que está a assumir que deixou de estar disponível. Isso significa que a palavra-passe do repositório ou a chave do PBS tem de estar acessível sem essa máquina.
• Cronometre a restauração e registe o valor. Depois, compare-o com o RTO definido. O gráfico acima mostra o limite mínimo da transferência. O valor real também inclui a desencriptação e a gravação no disco, além do tempo necessário para determinar qual snapshot pretendia restaurar.
• Restaure algo com estado, como um dump de base de dados que depois carregue numa instância de teste. Um ficheiro tar que é extraído não prova que a aplicação inicia.

O disco mais barato do mundo não tem valor até ter restaurado dados a partir dele pelo menos uma vez.

FAQ

Um snapshot no meu fornecedor de VPS é um backup externo?

Não. Um snapshot do fornecedor fica na mesma conta, protegido pelo mesmo início de sessão no painel e na mesma fatura que o servidor copiado. Quem obtiver essas credenciais pode eliminar o servidor e todos os respetivos snapshots numa única sessão. Os snapshots são úteis para uma reversão rápida antes de uma atualização arriscada, mas não constituem uma segunda localização. Uma cópia externa fica numa conta diferente, idealmente noutro fornecedor, com credenciais que a máquina de origem não possui.

De quanto espaço em disco preciso para um mês de backups retidos?

Calcule o espaço com base na idade do snapshot mais antigo, não no número de snapshots. Uma ferramenta com deduplicação armazena cada bloco único apenas uma vez. Por isso, o repositório tem aproximadamente o tamanho da origem mais os novos dados únicos de cada dia, multiplicados pelo número de dias de retenção. Para 500 GB de dados que mudam 5 GB por dia, uma semana de backups diários ocupa cerca de 535 GB e um ano completo de histórico ocupa 2,325 GB. Reserve espaço adicional, porque um disco cheio impede o backup seguinte, e o prune do restic precisa de espaço livre para recompactar os ficheiros pack antes de o poder libertar.

Um servidor comprometido pode eliminar os próprios backups externos?

Sim, exceto se o sistema tiver sido concebido para impedir isso. Num repositório SSH ou SFTP simples, a chave que permite escrever também pode eliminar dados. Dê à origem uma credencial que não possa remover dados: um token de API do PBS com apenas a função DatastoreBackup, que não inclui o privilégio Datastore.Prune, ou o restic ligado a um rest-server iniciado com --append-only, que recusa a eliminação e a modificação de backups existentes. Um modelo pull oferece uma proteção adicional, porque a origem não possui qualquer credencial para o host de backup. Execute a retenção a partir do lado que não é a origem.

Devo executar Proxmox Backup Server ou restic na VPS de backup?

Escolha a ferramenta de acordo com a unidade que precisa de restaurar. Se a origem for Proxmox VE e quiser recuperar uma máquina virtual completa, execute PBS, porque este faz o backup ao nível da imagem de disco e restaura uma VM num único passo. Se a origem for um host Linux e quiser recuperar ficheiros e dumps de bases de dados, execute restic, que precisa apenas de uma conta SSH no destino e cifra os dados antes de os enviar. É normal executar ambos: PBS para o hypervisor e restic para os servidores que não estão nesse hypervisor.

Quanto tempo demora uma restauração a partir de um backup de VPS?

Divida o tamanho dos dados pela velocidade da ligação para obter o tempo mínimo. Depois, acrescente o tempo de desencriptação e gravação. 500 GB através de uma ligação de 100 Mbit/s correspondem a 11.1 horas à velocidade máxima da ligação. A mesma restauração através de uma porta de 1 Gbit/s corresponde a 1.1 horas. Muitos ficheiros pequenos tornam a operação mais lenta do que esse cálculo, devido ao custo por ficheiro. Cronometre uma restauração real e use esse valor medido, porque é o único em que o seu plano de recuperação pode basear-se.