Como restaurar um backup

Restaurar é uma operação destrutiva. Você não está "adicionando" dados de volta: está substituindo o estado atual do servidor pelo estado que ele tinha no momento da cópia. Quem entende isso antes de começar perde muito menos dado do que quem descobre depois.

O que a restauração faz de fato

O Backup da EasyOps guarda cópias agendadas do servidor inteiro. Restaurar grava aquele conteúdo de volta no disco. Tudo que foi escrito depois do horário do backup deixa de existir: pedidos, uploads, linhas de banco, logs, sessões, chaves SSH adicionadas nesse intervalo.

Dois horários importam: o da cópia e o de agora. A distância entre eles é exatamente o que você vai perder. Com agenda diária, isso pode chegar a 24 horas de escrita. Antes de disparar qualquer coisa, decida se esse prejuízo é aceitável — e se não for, leia a seção sobre salvar o estado atual.

Três decisões antes de começar

1. Restaurar sobre o servidor atual ou em um servidor novo

Quando há qualquer incerteza, prefira o servidor novo. Você inspeciona o resultado com calma, copia o que interessa e só então decide se troca o servidor de produção. É a diferença entre um teste e uma aposta.

Se você não puder restaurar diretamente em outro servidor, o caminho equivalente é subir uma VPS nova, restaurar nela o que for possível e trazer os dados que interessam por dump ou rsync. Em dúvida sobre qual das duas rotas se aplica ao seu caso, confirme com o suporte antes de disparar a restauração.

2. Qual ponto no tempo

A cópia mais recente não é automaticamente a certa. Se o problema foi corrupção de dados, migração malfeita ou invasão, a última cópia provavelmente já contém o problema. Descubra primeiro quando as coisas quebraram:

journalctl --since "2026-08-03 18:00" --until "2026-08-04 09:00" -p err
sudo last -F | head -30
sudo grep -E "Accepted (password|publickey)" /var/log/auth.log | tail -40

Escolha a cópia imediatamente anterior ao primeiro sinal de problema, não a anterior ao momento em que você notou.

3. Como você desfaz a restauração

Restauração também dá errado: cópia mais antiga do que você imaginava, aplicação que não sobe, banco em estado inconsistente. Tire um snapshot do servidor antes de restaurar. O snapshot é instantâneo, não exige downtime e você paga pelo espaço ocupado — é o custo mais barato de uma saída de emergência. O raciocínio completo está em backup ou snapshot: qual usar em cada caso e em snapshot antes de uma mudança arriscada.

Se a máquina ainda liga, salve também os dados voláteis antes de sobrescrever:

sudo mysqldump --single-transaction --routines --all-databases \
  | gzip > /root/pre-restore-$(date +%F-%H%M).sql.gz
sudo -u postgres pg_dumpall | gzip > /root/pre-restore-pg-$(date +%F-%H%M).sql.gz
sudo tar czf /root/pre-restore-etc.tar.gz /etc

Esses arquivos estão no disco que vai ser sobrescrito. Tire-os da máquina — um bucket resolve:

aws s3 cp /root/pre-restore-2026-08-04-0930.sql.gz s3://meu-bucket/pre-restore/

O passo a passo dessa parte está em enviar backup de banco para um bucket.

Executando a restauração

No painel, localize o backup do servidor na data escolhida e inicie a restauração. Antes de confirmar, revise o que a operação vai sobrescrever e o custo estimado apresentado.

A partir daí, três coisas valem saber:

• Restauração sobre o servidor atual implica indisponibilidade. O tempo é proporcional ao tamanho do disco, não instantâneo.
• Não reinicie, não desligue e não cancele no meio. Interromper uma gravação de disco pela metade produz um sistema que não boota — e aí você depende do snapshot que tirou antes.
• Pare a aplicação e o banco antes, se conseguir. Serviços escrevendo durante a troca só geram estado sujo.

Recuperar só alguns arquivos

Restauração completa por causa de uma pasta apagada é desproporcional. Restaure em um servidor novo e traga apenas o que precisa:

rsync -avz --dry-run root@203.0.113.45:/var/www/site/uploads/ /var/www/site/uploads/

Confira a listagem do --dry-run e só então rode sem ele. Não use --delete nesse cenário: ele apagaria no destino o que não existia na cópia, que é o oposto do que você quer.

Valide antes de anunciar que voltou

Servidor ligado não significa serviço funcionando. Comece pelo básico:

systemctl --failed
ss -tulpn | grep -E ':(80|443|3306|5432)'
df -h /
curl -sI https://seudominio.com.br | head -1

Depois a integridade dos dados:

sudo mysqlcheck --all-databases --check
sudo -u postgres psql -c "select max(created_at) from pedidos;"

Aquele max(created_at) é o teste que importa: ele mostra qual o registro mais recente que sobreviveu. Confirme que a lacuna é a esperada — se for maior, você restaurou a cópia errada e ainda tem o snapshot para voltar.

Verifique também o que costuma passar batido: tarefas agendadas (systemctl list-timers), certificados (sudo certbot certificates e sudo certbot renew --dry-run, já que o estado de renovação voltou no tempo junto com o disco) e regras locais de rede (sudo ufw status verbose). Regras aplicadas pelo Firewall da plataforma vivem fora do disco e continuam valendo; regras de ufw ou iptables voltam exatamente como estavam na cópia.

O risco de se trancar fora

Se você adicionou uma chave SSH depois do horário do backup, ela não existe no authorized_keys restaurado. Se também trocou a senha de root nesse intervalo, a que vale agora é a antiga. Antes de encerrar a janela, abra uma segunda sessão SSH e confirme que consegue entrar com a credencial que a máquina tem hoje. O console no browser é a saída quando o SSH fecha a porta, e depois vale revisar sua configuração em usar chaves SSH em vez de senha.

Depois que estabilizar

Reconcilie a lacuna de forma consciente: reprocessar filas pode duplicar cobranças e e-mails se a aplicação não for idempotente. Avise quem foi afetado em vez de esperar que ninguém note.

Por último, use o incidente como medida. Se perder 24 horas doeu, a agenda diária não é suficiente para esse workload — encurte a retenção útil com dumps de banco enviados para bucket algumas vezes ao dia. Backup não testado é suposição; a única restauração em que você pode confiar é a que já rodou uma vez.