Como testar a restauração de um backup Restic sem sobrescrever sua VPS

Fala aí, beleza? Backup que nunca foi restaurado é só uma esperança guardada em disco haha

Aqui o cenário é bem específico: você já tem um repositório Restic com snapshots da sua VPS e quer provar que ele funciona, sem encostar em nenhum arquivo de produção

Tudo segue o restic 0.19.1, versão estável lançada em 05/07/2026 com correções menores de bugs, que é a versão coberta pela documentação oficial do restic 🙂

O que você precisa antes de testar a restauração

Você precisa de quatro coisas: o restic instalado, acesso ao repositório e à senha, espaço livre em disco e um lugar isolado para restaurar

Vamos por partes

Restic instalado e atualizado:

No Debian, o pacote vem do repositório oficial da distro:

apt-get install restic

Se o pacote da distro estiver desatualizado, a documentação indica usar o binário oficial do projeto, que se atualiza sozinho com restic self-update: disponível a partir da versão 0.9.3 do restic (0.9.4 segundo o anúncio da 0.19.1), e só para os binários oficiais, não para o pacote da distro

restic self-update

Acesso ao repositório e à senha:

O restic lê o repositório da variável RESTIC_REPOSITORY e a senha de um arquivo indicado em RESTIC_PASSWORD_FILE

Isso evita digitar senha toda hora e facilita MUITO quando você for restaurar a partir de outra máquina

export RESTIC_REPOSITORY=<endereco-do-seu-repositorio>
export RESTIC_PASSWORD_FILE=<caminho-do-arquivo-com-a-senha>

Tome cuidado: se você perder a senha, perde o acesso ao repositório. Guarde esse arquivo fora do servidor também

Espaço em disco para a cópia de teste:

Antes de restaurar, confira se há espaço livre suficiente no destino

O restic snapshots mostra, numa coluna Size, o tamanho total dos arquivos do snapshot: essa coluna só aparece para snapshots criados com o restic 0.17.0 ou posterior, e reflete o tamanho no momento em que o backup foi feito. Já o restic ls --long lista cada arquivo individualmente, com permissões, UID, GID, tamanho, mtime e caminho, o que também ajuda a estimar o espaço necessário

De qualquer forma, deixe uma margem extra no destino

Um ambiente isolado:

Você tem duas opções:

• Diretório separado na mesma VPS: mais simples, mas a restauração ainda escreve no disco do servidor de produção
• Segunda máquina apontando para o mesmo repositório: zero escrita em produção, é o teste mais honesto

Para hospedar esse ambiente, a recomendação principal da Hora de Codar é a VPS da Hostinger (este artigo contém links de afiliado da Hostinger)

O motivo é técnico: ela oferece acesso root nos planos KVM 1, KVM 2, KVM 4 e KVM 8, então você tem controle total para instalar o restic e rodar os testes de restauração do seu jeito

Além disso, ela roda em SSD NVMe com processadores AMD EPYC e oferece backups semanais automáticos pelo painel

Se liga num detalhe importante: o backup do painel e o Restic são camadas diferentes

O backup da Hostinger copia o servidor inteiro, o Restic guarda os arquivos que você escolheu em um repositório seu. Um não substitui o outro, eles se complementam

Passo a passo para restaurar o backup Restic em um diretório isolado

A lógica é: primeiro confirmar que o repositório está saudável, depois escolher o snapshot certo, simular, restaurar numa pasta nova e só então validar

Bora ver na prática?

1. Checar a integridade do repositório

O restic check testa a estrutura do repositório:

restic check

Para garantir que os dados realmente estão legíveis, use as flags de leitura. O --read-data-subset lê uma fração, percentual ou tamanho dos dados:

restic check --read-data-subset=1/5
restic check --read-data-subset=10%
restic check --read-data-subset=10G

E o --read-data lê todos os dados do repositório, simulando uma restauração completa:

restic check --read-data

Resultado esperado: o comando termina sem apontar erros no repositório

Erro comum deste passo: rodar só o restic check sem nenhuma flag de leitura e tratar isso como prova de que todos os dados estão legíveis. Para testar o conteúdo de fato, use --read-data ou --read-data-subset

2. Listar e escolher o snapshot

Liste os snapshots disponíveis:

restic snapshots

O comando aceita filtro por host (--host) ou por caminho (--path), o que ajuda MUITO quando o mesmo repositório guarda backup de mais de um servidor

Depois, veja o que tem dentro do snapshot escolhido:

restic ls <snapshot> --long
restic ls <snapshot> --long --sort size --reverse

Se estiver procurando um arquivo específico e não souber em qual snapshot ele está, o restic find busca arquivos e diretórios nos snapshots

Resultado esperado: você sabe o ID do snapshot que vai testar e o que ele contém

Erro comum deste passo: restaurar o latest sem conferir o host. Se o repositório for compartilhado, o snapshot mais recente pode ser de outro servidor

3. Simular a restauração com dry-run

Antes de escrever qualquer coisa, simule:

restic restore <snapshot> --target /tmp/restore-work --dry-run -vv

O --dry-run mostra o que seria restaurado sem executar a restauração completa, e o -vv imprime informações sobre os arquivos

Use um --target que ainda não existe: segundo a documentação, um destino inexistente pula as checagens de conteúdo existente

Resultado esperado: a lista do que seria restaurado bate com o que você viu no restic ls

Erro comum deste passo: apontar o --target para o caminho real da aplicação (tipo a pasta do site em produção). Aí deixa de ser teste e vira restauração em cima de produção

4. Restaurar de fato e verificar o conteúdo

Agora sim:

restic restore <snapshot> --target /tmp/restore-work --verify

O --verify confere o conteúdo dos arquivos depois da restauração

E aqui vale entender o --overwrite, porque o padrão é always: se já existir arquivo no destino, o restic sobrescreve, checando o conteúdo e restaurando só as partes divergentes

As outras opções são:

• --overwrite if-changed: considera atualizado o arquivo com mesmo tamanho e mtime
• --overwrite if-newer: só sobrescreve se o arquivo do snapshot tiver mtime mais novo que o existente
• --overwrite never: nunca sobrescreve arquivos existentes

Se por algum motivo a pasta de destino já existir, o --overwrite never é a proteção extra:

restic restore <snapshot> --target /tmp/restore-work --overwrite never --verify

Resultado esperado: a pasta /tmp/restore-work com a estrutura do snapshot e a verificação concluída sem divergências

Erro comum deste passo: usar --delete no teste. Essa flag apaga do destino tudo que não existe no snapshot, e a documentação manda rodar --dry-run -vv antes dela; além disso, combinada com --target, ela só funciona se você também usar --include ou --exclude. Num teste isolado, ela simplesmente não tem motivo pra estar ali

5. Restaurar só uma parte com --include

Nem sempre você precisa restaurar tudo. O --include (ou -i) restringe a restauração a padrões e pode ser repetido:

restic restore <snapshot> --target /tmp/restore-work --include <padrao1> --include <padrao2>

Repara que um padrão de include já exclui todo o resto

Resultado esperado: só os caminhos que casam com os padrões aparecem no destino

Erro comum deste passo: combinar --include com --exclude no mesmo comando. Os dois são mutuamente exclusivos

Como validar se os arquivos restaurados estão corretos

A validação tem três camadas: o resultado do --verify, a comparação da estrutura com o snapshot e a abertura dos arquivos que importam de verdade

O que o --verify confirma?

Ele verifica o conteúdo dos arquivos restaurados depois da restauração

Se a verificação apontar qualquer divergência, trate o teste como reprovado e volte ao restic check --read-data para investigar o repositório

Comparando a estrutura com o snapshot:

Rode de novo o restic ls <snapshot> --long do MESMO snapshot que você restaurou e compare com o conteúdo de /tmp/restore-work

Você está procurando pastas faltando, arquivos com tamanho estranho ou caminhos que deveriam estar ali e não estão

Abrindo os arquivos críticos:

Aqui não tem comando mágico: abra os arquivos que fariam falta num desastre

Arquivos de configuração, .env, pasta de uploads, certificados e por aí vai. Se eles abrem e têm o conteúdo esperado, o backup está fazendo o trabalho dele 😀

E se eu quiser conferir só poucos arquivos?

Dá pra fazer sem restaurar tudo

O restic mount permite navegar pelo backup como se fosse um sistema de arquivos, o que é útil para conferir o conteúdo de um snapshot ou pegar poucos arquivos (só funciona em Linux, macOS e FreeBSD):

restic mount <ponto-de-montagem>

Já o restic dump extrai um arquivo de um snapshot e imprime no stdout, e o latest seleciona o snapshot mais recente:

restic dump latest <caminho-do-arquivo>

Se o caminho for uma pasta, ela sai como tar (padrão) ou zip, escolhido com -a:

restic dump -a zip latest <caminho-da-pasta> > pasta.zip

Restaurar em outra máquina para testar sem risco à VPS de produção

Restaurar em outra máquina é a forma mais segura de testar, porque o servidor de produção não sofre nenhuma escrita

E ainda testa um cenário real: o dia em que a VPS original simplesmente não existe mais

Se você precisa escolher essa segunda máquina, dá pra conferir a VPS para este projeto: com acesso root você instala o restic e roda o teste de restauração por conta própria

Na máquina de teste, instale o restic e aponte para o mesmo repositório:

export RESTIC_REPOSITORY=<endereco-do-seu-repositorio>
export RESTIC_PASSWORD_FILE=<caminho-do-arquivo-com-a-senha>
restic snapshots
restic restore <snapshot> --target /tmp/restore-work --verify

Depois é a mesma validação da seção anterior

Agora, se liga numa confusão muito comum: o restore do painel da Hostinger NÃO é teste de restauração

No painel, você escolhe o servidor e depois acessa Snapshots & Backups, dentro do menu Backups & Monitoring. De lá é possível restaurar o servidor INTEIRO ao estado do backup ou snapshot escolhido, sobrescrevendo o conteúdo atual: a documentação da Hostinger descreve essa restauração como irreversível, e ela também apaga os snapshots que existiam antes dela

Ou seja: serve para recuperação total, não para conferir se um arquivo está no backup

Por padrão, os backups do painel são semanais e automáticos, com opção de contratar backups diários como add-on. Se você quer entender melhor quando usar cada um, este guia sobre escolher entre backup e snapshot ajuda bastante

Por que restaurar a pasta do banco de dados não garante um banco consistente

Na prática, copiar os arquivos de um banco em execução não é a mesma coisa que fazer um dump

A pasta pode até restaurar sem erro nenhum e o --verify passar, e mesmo assim os arquivos não representarem um banco utilizável

A forma documentada pelo restic é salvar direto a saída do comando de dump:

1. Fazer o backup a partir do dump com --stdin-from-command

restic -r /srv/restic-repo backup --stdin-from-command --stdin-filename production.sql -- mysqldump --host example mydb

O nome padrão do arquivo no snapshot seria stdin, e o --stdin-filename troca para production.sql

O ganho aqui é que, se o comando terminar com código de saída diferente de zero, o backup é cancelado e nenhum snapshot é criado

Erro comum deste passo: usar --stdin com pipe (mysqldump ... | restic backup --stdin). Nesse formato o restic não tem como saber se os dados estão completos: se o mysqldump falhar ao conectar, o backup pode ser criado vazio e com sucesso. Já me imagino descobrindo isso no pior dia possível…

2. Validar que o dump não está vazio

Primeiro confirme o caminho exato do arquivo com restic ls <snapshot>, depois extraia para a pasta de teste:

restic dump <snapshot> <caminho-do-production.sql> > /tmp/restore-work/production.sql
ls -l /tmp/restore-work/production.sql

Um arquivo com tamanho zero é sinal vermelho na hora

Se ele tiver conteúdo, abra e confira se aparecem as tabelas que você esperava. A importação em si depende do seu banco e da documentação oficial dele, então faça isso também num ambiente isolado, nunca no banco de produção

Aproveitando, no canal do Hora de Codar tem vídeo sobre o Sakana Fugu Max e Ultra v2, um orquestrador de modelos de IA:

Próximo passo: transformar o teste de restore em rotina

O próximo passo é colocar esse teste no calendário, porque um restore feito uma vez só prova que o backup funcionava naquele dia

Defina uma frequência que combine com o quanto seus dados mudam e repita: restic check --read-data-subset com uma fatia diferente a cada rodada, restore em /tmp/restore-work com --verify e restic dump do arquivo de banco

Antes de mudanças grandes no servidor (upgrade de sistema, troca de versão da aplicação e tal), os backups automáticos do painel da Hostinger complementam esse teste: por padrão são semanais, com opção de backup diário como add-on. Este guia mostra como funciona o backup e o snapshot da VPS nesse fluxo

Assim você fica com as duas camadas: o backup do painel para voltar o servidor inteiro e o Restic para recuperar arquivos e dumps com precisão

E se ainda não tem um lugar para rodar a máquina de teste, os planos de VPS da Hostinger dão o acesso root que esse fluxo exige

Até o próximo post! 🙂

Perguntas frequentes

O que o restic restore faz com os dados do snapshot?

O restic restore lê um snapshot existente e extrai os arquivos para o diretório indicado em --target. A flag --delete remove do destino os arquivos que não existem no snapshot, mas segundo a documentação oficial, quando usada junto com --target, só funciona se você também usar --include ou --exclude; por isso vale rodar --dry-run -vv antes de aplicá-la de fato.

Qual a diferença entre repositório e snapshot no Restic?

O repositório é o lugar onde todos os seus backups ficam guardados ao longo do tempo. O snapshot é uma versão específica dentro desse repositório, identificada por um ID, e é esse ID que você passa pro restic restore quando quer testar uma restauração.

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.