Backup e recuperação de servidor doméstico — um pequeno exercício de restauração

Um código de saída de backup bem-sucedido não comprova que um serviço pode ser reiniciado a partir dos dados salvos. Separe a restauração de arquivos, a legibilidade do banco de dados e as operações de aplicação necessárias. Comece com um exercício que nunca acesse dados de produção.

Defina recuperação bem-sucedida

Diagram 1 · Use the button to switch views

Um serviço de fotos precisa de relações entre imagens e registros do banco de dados. A autenticação também pode depender da configuração e das chaves de criptografia. Defina a janela de perda de dados aceitável (RPO) separadamente da duração de recuperação aceitável (RTO). A frequência de backup e o tempo de restauração são medidas diferentes.

Execute um exercício isolado

Salve restore_lab.py e execute python3 restore_lab.py . Ele usa a biblioteca padrão do Python 3.12.3. Cada execução cria um novo diretório temporário, um arquivo de texto e um registro SQLite. Não interrompe nem exclui um serviço ou conjunto de dados existente.

O script usa a API de backup do SQLite para copiar o banco de dados, compacta-o com o arquivo de texto em um arquivo ZIP e restaura-o em outro diretório vazio. Ele verifica os hashes SHA-256, PRAGMA integrity_check e um registro SQL conhecido. Consulte a explicação oficial da API de backup do SQLite.

file_hashes: pass
sqlite_integrity: pass
application_read: pass
scope: synthetic fixture only

Todas as três verificações foram aprovadas em 7 de setembro de 2026. Aqui, leitura do aplicativo significa a consulta SQL conhecida, não a inicialização do Immich ou do Nextcloud. O directory impresso contém as evidências retidas. O arquivo ZIP nesse diretório temporário é um artefato de teste, não uma proteção contra a perda do dispositivo de armazenamento.

Capturar serviços reais de forma consistente

A cópia comum de arquivos de banco de dados ativos pode não preservar a consistência necessária para a recuperação. Para PostgreSQL, revise os requisitos de métodos como SQL dumps. A consistência entre o snapshot do banco de dados e os arquivos externos referenciados é uma preocupação à parte.

A correspondência de hashes estabelece igualdade com a cópia capturada. Ela não comprova que toda a aplicação estava consistente no momento da captura.

Verificações adicionais com restic

O procedimento a seguir se aplica a um ambiente onde o restic já está instalado; o restic não foi executado neste exercício. Configure o repositório e as credenciais separadamente e registre restic version . Selecione um snapshot e restaure-o em um destino vazio.

restic snapshots
restic check --read-data
restic restore SNAPSHOT_ID --target /path/to/empty-restore

Substitua o ID e o caminho para o seu ambiente. Restauração e verificação do repositório respondem a perguntas diferentes. Considere os custos de tempo de execução e transferência ao ler dados armazenados com --read-data .

Mantenha um registro de recuperação

Registre a hora de captura, o início e o término da recuperação, o volume de dados, as versões, os resultados da verificação de arquivos e as operações do aplicativo. Verifique em um ambiente isolado antes de substituir os dados de produção, com e-mails de saída e webhooks desativados. A autenticação e as verificações de leitura de arquivos transformam este pequeno exercício em um procedimento específico do serviço para a plataforma home-server.