Como fazer backup de uma VPS com Restic em armazenamento externo (e testar a restauração)

Fala aí, beleza? Se o único backup da sua VPS mora no mesmo disco do servidor, se liga: no dia que a máquina some, o backup vai junto 😛

Este guia é pra quem administra a própria VPS e quer uma cópia cifrada guardada FORA dela, que continue acessível mesmo se o servidor for perdido ou reinstalado

A gente vai do repositório criado até a parte que quase todo mundo pula: restaurar o backup em outra máquina e conferir que os arquivos voltaram de verdade

O que você precisa antes de começar:

• Uma VPS com acesso root rodando Debian, onde a documentação do restic confirma a instalação pelos repositórios oficiais com apt-get
• Um destino externo: um servidor com SSH e a sua chave pública instalada (login funcionando sem senha) ou um bucket no Amazon S3
• Um lugar seguro pra senha do repositório FORA da VPS, como um gerenciador de senhas
• Uma segunda máquina ou ambiente separado pra testar a restauração

Pro servidor, a recomendação da Hora de Codar é a VPS da Hostinger (este artigo contém links de afiliado da Hostinger)

O roteiro usa acesso de administração para instalar o Restic e acesso de leitura aos arquivos incluídos no backup.

E tem um detalhe que conversa direto com este tutorial: a VPS já inclui backups automáticos semanais, segundo a página oficial da Hostinger. Mais adiante a gente compara esse backup (e o snapshot manual, outro recurso do painel) com o Restic

Passo a passo do backup com Restic em armazenamento externo:

Antes do como, o porquê: o Restic é como uma mala com cadeado que você despacha pra fora do servidor. Ele cifra tudo antes de mandar, então o destino guarda os dados sem conseguir ler nada

1. Instale o restic na VPS

No Debian, o restic está nos repositórios oficiais, então é um comando só:

apt-get install restic

Resultado esperado: o comando restic passa a existir no sistema e responde no terminal

Se você usa os binários oficiais publicados no GitHub em vez do pacote da distro, dá pra atualizar no lugar:

restic self-update

Isso exige restic 0.9.3 ou mais recente, e a autenticidade do download é conferida pela assinatura GPG dos arquivos publicados no GitHub

Se instalou o Restic pelo gerenciador de pacotes, acompanhe as atualizações pelo mesmo gerenciador.

2. Guarde a senha do repositório em um arquivo

Por que isso vem antes de criar o repositório? Porque a senha é TUDO aqui: sem ela não há acesso ao repositório, e quem perde a senha perde os dados de forma irrecuperável

Nada de botão "esqueci minha senha", beleza?

O restic lê a senha de um arquivo com --password-file ou pela variável de ambiente RESTIC_PASSWORD_FILE. O caminho abaixo é só um exemplo:

export RESTIC_PASSWORD_FILE=/root/.restic-senha

Resultado esperado: com a variável definida na sessão, os comandos seguintes pegam a senha desse arquivo

O erro comum deste passo: a única cópia da senha ficar dentro da VPS. Se o servidor some, o arquivo some junto, e o backup externo vira um cofre sem chave

Guarde uma cópia fora do servidor, é ela que você vai usar no teste de restauração

3. Crie o repositório no destino externo

O comando init cria o repositório onde os backups ficam guardados. Via SFTP, fica assim:

restic -r sftp:restic-backup-host:/srv/restic-repo init

O restic-backup-host acima é um apelido, não um endereço real: pra ele funcionar, precisa existir uma entrada Host restic-backup-host no ~/.ssh/config da máquina de onde você roda o comando, com Hostname, User e Port apontando pro servidor de destino

E no Amazon S3, depois de definir as variáveis AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY, use o endpoint da região correta:

export AWS_ACCESS_KEY_ID=<sua-access-key>
export AWS_SECRET_ACCESS_KEY=<sua-secret-key>
restic -r s3:s3.us-east-1.amazonaws.com/bucket_name init

Resultado esperado: o repositório passa a existir no destino, já protegido pela senha do passo anterior

O Restic protege os dados do repositório com criptografia autenticada. Veja a referência oficial sobre chaves, criptografia e autenticação. Guarde a senha do repositório em um local protegido e acessível na hora da restauração.

Traduzindo: quem tem acesso ao destino vê arquivos embaralhados, e só a senha abre a mala 🙂

O erro comum deste passo: no SFTP, o servidor pedir senha no login. Backups automáticos não são possíveis se o servidor pedir credenciais, então teste antes o acesso SSH com a chave pública e confirme que entra direto

4. Rode o primeiro backup

O comando backup cria um novo snapshot com os arquivos e diretórios passados como argumento. Os caminhos abaixo são exemplos didáticos, troque pelos que importam no seu servidor:

restic -r sftp:restic-backup-host:/srv/restic-repo --verbose backup /etc /var/www

Quer ver arquivo por arquivo o que está indo? Use --verbose=2 (ou --verbose em dobro):

restic -r sftp:restic-backup-host:/srv/restic-repo --verbose=2 backup /etc /var/www

Resultado esperado: um snapshot novo no repositório, contendo os caminhos que você passou

Se a VPS roda uma aplicação específica, os caminhos e o cuidado com os dados mudam. Pra esses casos tem guia próprio aqui no blog sobre backups do n8n no VPS e sobre o backup da Evolution API

5. Defina a retenção dos snapshots

Sem retenção, o repositório só cresce. O forget decide quais snapshots manter: --keep-daily mantém os últimos N diários e --keep-weekly os últimos N semanais

O exemplo mantém sete snapshots diários e quatro semanais, de acordo com o agrupamento da política. Ajuste os valores ao histórico de que você precisa.

restic -r sftp:restic-backup-host:/srv/restic-repo forget --keep-daily 7 --keep-weekly 4 --dry-run

Resultado esperado: a simulação lista os snapshots que seriam mantidos ou removidos. Ela não apaga snapshots nem libera espaço.

O comando acima apenas simula a política. Confira a lista de snapshots que seriam removidos e ajuste os números ao seu objetivo de recuperação. Aplique a política sem --dry-run só depois dessa conferência. prune pode liberar o espaço ocupado por dados sem referência. Consulte a documentação de retenção antes de executar a remoção.

Como verificar se o backup restaura de verdade?

Backup que nunca foi restaurado é só uma esperança com nome bonito haha

A verificação tem duas camadas: conferir o repositório e restaurar os arquivos em outra máquina

1. Cheque o repositório com restic check

O check testa o repositório e aponta erros:

restic -r sftp:restic-backup-host:/srv/restic-repo check

Pra ir além da estrutura, o --read-data lê todos os dados do repositório:

restic -r sftp:restic-backup-host:/srv/restic-repo check --read-data

Repositório grande? Use --read-data-subset pra ler só uma parte por vez, no formato n/t, em porcentagem ou por tamanho. Assim dá pra dividir a leitura completa em várias execuções:

restic -r sftp:restic-backup-host:/srv/restic-repo check --read-data-subset=<n>/<t>

Resultado esperado: o check termina sem apontar erros

2. Restaure em um ambiente separado

Aqui está o teste que importa de verdade. Na segunda máquina, com o restic instalado, a chave SSH (ou o acesso ao bucket) e a cópia da senha que você guardou fora da VPS, rode:

restic -r sftp:restic-backup-host:/srv/restic-repo restore latest --target /tmp/restore-work

O latest recupera o último snapshot no diretório indicado em --target

Se o mesmo repositório recebe backup de mais de uma origem, use --host e --path pra escolher QUAL snapshot restaurar (eles servem só pra selecionar o snapshot, não limitam os arquivos restaurados. Para escolher arquivos, use --include ou --exclude):

restic -r sftp:restic-backup-host:/srv/restic-repo restore latest --target /tmp/restore-work --host <nome-da-vps> --path /var/www

Esse comando ainda restaura TODO o conteúdo do snapshot escolhido pra dentro do --target, não só o caminho usado pra filtrar

Checagem final: abra o /tmp/restore-work e confira se os arquivos esperados estão lá. Pega um arquivo que você conhece bem e veja se ele voltou inteiro

O erro comum deste passo: testar a restauração só dentro da própria VPS. Isso não prova que você consegue acessar o backup quando o servidor estiver indisponível, que é justamente o cenário em que você vai precisar dele

Backup da Hostinger ou Restic: quando usar cada um?

A Hostinger documenta o backup e a restauração da VPS. Confira o que está disponível no seu plano e o efeito da restauração no servidor. O Restic permite selecionar os arquivos e testar a recuperação em outro ambiente.

Os dois não brigam, cada um cobre uma responsabilidade diferente

Tome cuidado com um ponto: restaurar um backup ou snapshot da Hostinger substitui todo o conteúdo atual da VPS, não tem volta e leva o servidor ao estado exato do momento da captura

O Restic resolve outra coisa:

• Você escolhe quais arquivos entram no backup
• A retenção é sua, definida no forget
• O destino fica sob o seu controle, fora do provedor
• A restauração pode ser seletiva e em outra máquina, sem sobrescrever a VPS inteira

O snapshot da VPS serve como ponto de retorno antes de uma manutenção. Já o repositório Restic permite restaurar arquivos selecionados em outro ambiente.

Próximo passo: agende o teste de restauração

Coloca na agenda agora uma restauração periódica em ambiente separado, seguindo o restore latest --target e a checagem dos arquivos

Na mesma rotina, rode uma rodada de check --read-data-subset, avançando a parte lida a cada vez até cobrir o repositório inteiro

E aproveita pra conferir onde a senha do repositório está guardada: se a resposta for "só na VPS", resolve isso HOJE

Se você precisa de uma VPS para configurar o fluxo, veja a VPS da Hostinger (link de afiliado da Hostinger). Mantenha o repositório Restic no destino externo que você configurou.

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.