Backup do VPS Ubuntu: confirme que os arquivos voltam
Um backup precisa estar acessível fora do VPS e devolver os arquivos esperados. Neste exercício, você arquiva uma página estática e uma configuração Nginx, copia para outro computador e confere os bytes em uma pasta nova. O site em funcionamento permanece intacto.
Neste guia
Defina o que o teste cobre
Use Bash, GNU tar, sha256sum e OpenSSH no Ubuntu ou em um cliente Linux/WSL. Mantenha um terminal no servidor e outro em um computador separado; não os feche entre as etapas, pois as variáveis precisam continuar disponíveis. Pare a cada erro de comando.
São dois arquivos descartáveis na sua pasta pessoal. O teste não altera Nginx, firewall ou conteúdo publicado, e a extração não usa root. Comece pelos arquivos fictícios. Um site maior precisa de inventário de outros arquivos, redirecionamentos, DNS, certificados e dependências.
Prepare dois arquivos de exemplo
No servidor, crie a pasta privada para o teste. O bloco Nginx abaixo é apenas um arquivo para arquivar, não uma configuração que deve ser ativada.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="pt-BR"><title>Teste de restauração</title><h1>Página estática recuperada</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Pasta de teste: %s\n' "$backup_lab"Opcionalmente, use os dois arquivos reais do tutorial de site estático com o próximo bloco. Eles devem ser legíveis pela sua conta. Inspecione segredos e pause publicações durante a coleta para copiar a mesma versão. Pule esse bloco para continuar com os exemplos fictícios.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"Somente as cópias descartáveis são substituídas; os arquivos de origem não mudam. Chaves privadas TLS e diretórios inteiros do sistema não entram nessa cópia. Acrescente outros arquivos ao inventário e ao manifesto quando forem necessários.
Crie o arquivo tar e os dois níveis de verificação
Ainda no servidor, mantenha o conteúdo estável, gere os checksums dos arquivos, crie o tar com caminhos relativos e calcule o checksum do próprio arquivo compactado.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Pasta para exportar: %s\n' "$backup_lab/export"A listagem deve conter site/, nginx/, os dois arquivos e SHA256SUMS. O checksum externo detecta alteração na cópia transferida; o manifesto interno confere os arquivos extraídos. Eles não garantem autenticidade se alguém puder substituir dados e checksum esperado.
Copie para um computador separado
No terminal cliente, substitua remote_backup pela pasta exata de exportação mostrada pelo servidor. REPLACE é um marcador a substituir, não o sufixo criado por mktemp. Ajuste conta, IP e chave; 203.0.113.10 é um endereço de documentação.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Antes do primeiro login, confirme a chave do servidor por uma via confiável. Se SCP falhar por causa de SSH, use o diagnóstico de conexão. Não desative a verificação de identidade para concluir a transferência.
SCP protege o transporte com SSH. O tar.gz é compactado, não criptografado: proteja a conta e o armazenamento de destino e use criptografia em repouso quando necessário. Outra pasta no mesmo VPS não é uma cópia fora do servidor.
Confira e restaure em uma pasta vazia
No cliente, verifique o arquivo antes de extrair e continue somente após OK. Investigue falhas ou refaça a transferência; não substitua o checksum de referência para esconder um erro.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Extraia esse arquivo confiável em uma pasta recém-criada. keep-old-files impede substituir arquivos existentes, e no-same-owner evita restaurar o proprietário arquivado. Não mude o destino para / e não use sudo.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"Espere OK para site/index.html e nginx/first-site.conf, além do título recuperado. Isso verifica o conteúdo desses arquivos; não comprova proprietários, ACLs, serviços ativos ou todas as dependências do site.
Separe recuperação de arquivos e retorno do serviço
A configuração extraída continua sendo um texto inativo. Em um servidor de substituição separado, revise caminhos, includes, módulos, permissões e certificados. Valide a configuração montada ali antes de recarregar e teste HTTP/HTTPS externamente. Testar a sintaxe do servidor original não valida esta restauração.
As chaves privadas TLS foram excluídas de propósito. Planeje reemitir os certificados ou mantenha uma cópia protegida separada. Não use esta receita tar para copiar arquivos de um banco ativo; adote o backup consistente e a restauração documentados para o banco.
Snapshots podem ajudar a recuperar a máquina, mas confira retenção, domínio de falha e procedimento. A existência de um snapshot não prova que os arquivos exportados podem voltar em outro servidor.
Registre o objetivo e o resultado real
RPO é a perda aceitável de dados medida em tempo; RTO é o prazo desejado para recuperar o serviço. Para um pequeno site estático, 24 horas de RPO e 60 minutos de RTO são exemplos de metas, não resultados medidos neste teste. Cópias diárias só atendem ao plano se terminarem corretamente e forem recuperáveis.
Deslize a tabela para ver todas as colunas →
| Registro | O que demonstra |
|---|---|
| Horário e versão do backup | Qual estado pode ser recuperado |
| Destino externo e retenção | Onde a cópia sobrevive e por quanto tempo |
| Checksums do tar e dos arquivos | Conformidade dos bytes selecionados |
| Início e fim da restauração | Duração das etapas definidas |
| Arquivos e dependências ausentes | Trabalho restante para recuperar o serviço |
| HTTPS externo na máquina de substituição | Retorno efetivo do site |
Meça acesso, criação da máquina, configuração, certificados e DNS antes de considerar o RTO alcançável. Extração local rápida não é um teste completo de recuperação de incidente. Guarde pontos de recuperação adequados e monitore cópias que falharam. Confira também os critérios de recuperação na hospedagem.
Perguntas e respostas
Devo apagar o site original para testar?
Não. A pasta separada e o manifesto verificam a cópia sem causar interrupção. Teste o serviço completo em um ambiente de substituição.
Checksum correto significa que tudo foi salvo?
Ele confirma apenas os arquivos listados. Não descobre um banco, segredo, arquivo ou registro DNS esquecido. Mantenha um inventário e teste as funções do site.
Esse procedimento serve para backup de banco ativo?
Não como receita de consistência de dados. Use as ferramentas e o procedimento de backup/restauração próprios do seu banco.