Snapshot antes de uma mudança arriscada

Existe uma diferença grande entre uma mudança perigosa e uma mudança reversível. A mudança em si é a mesma: subir uma versão do PostgreSQL, trocar o PHP, mexer no nginx.conf, aplicar meses de apt upgrade acumulados. O que muda é o que acontece quando dá errado. Sem ponto de retorno, você depura sob pressão, no ar, com o cliente esperando. Com um snapshot recente, o pior caso é perder o tempo da restauração.

Abaixo está o processo inteiro: o que preparar antes de capturar, o que o snapshot não cobre e como decidir voltar sem hesitar.

O que o snapshot cobre

Um snapshot é uma foto do disco do servidor num instante exato. Ao restaurar, você volta o sistema, os pacotes instalados, os arquivos de configuração e os dados que estavam no disco para aquele momento. É a ferramenta certa para mudança pontual, feita por você, na hora.

O que ele não é: uma política de retenção. Snapshot você tira por decisão; backup roda em agenda diária e guarda várias gerações sem você lembrar. Os dois resolvem problemas diferentes e não se substituem — a comparação completa está em backup ou snapshot.

E ele não cobre nada que more fora do disco daquela VPS: arquivos no seu bucket, dados num banco em outra máquina, registros de DNS. Se a mudança toca esses lugares, cada um precisa do seu próprio plano de volta.

Consistência: o detalhe que as pessoas ignoram

O snapshot é capturado sem downtime, com o servidor ligado. A consequência técnica é que o estado no disco é crash-consistent: equivale ao que você teria se a máquina perdesse energia naquele instante. Sistemas de arquivos com journal se recuperam bem disso. Bancos de dados costumam se recuperar também, mas transações em voo e páginas ainda em memória podem não estar lá.

Para uma app stateless, isso é irrelevante. Para banco de dados, faça um dump lógico antes de capturar:

# PostgreSQL — formato custom, restaurável com pg_restore
sudo -u postgres pg_dump -Fc app > /var/backups/app-$(date +%F-%H%M).dump

# MySQL/MariaDB — dump consistente sem travar as tabelas (InnoDB)
mysqldump --single-transaction --routines --triggers app \
  > /var/backups/app-$(date +%F-%H%M).sql

sync

O dump dentro do disco entra no snapshot junto. Se a restauração trouxer um banco com problema, você ainda tem um arquivo íntegro para recarregar. Se o dump for grande ou você quiser uma cópia fora da máquina, mande para um bucket — o caminho está em enviar backup de banco para um bucket.

Registre o estado antes de mexer

Restaurar é fácil; descobrir o que exatamente mudou é o difícil. Guarde um retrato do estado atual em arquivos, antes da mudança:

uname -r
dpkg -l > /root/pre-change-packages.txt        # Debian/Ubuntu
rpm -qa > /root/pre-change-packages.txt        # RHEL/Alma/Rocky
systemctl list-units --state=running > /root/pre-change-services.txt
ss -tlnp > /root/pre-change-ports.txt
df -h

Depois da mudança, um diff entre esses arquivos e o estado novo responde em segundos: qual pacote subiu de versão, qual serviço parou de subir no boot, qual porta deixou de escutar.

Tire o snapshot e confirme que terminou

Com o dump feito e o estado registrado, crie um snapshot do servidor no painel. Anote o horário — ele é o seu marco: tudo escrito no disco depois disso será descartado se você restaurar.

Espere a captura concluir antes de começar a mudança. Aplicar apt upgrade no meio de uma captura te deixa com um ponto de retorno de estado indefinido, que é pior do que nenhum, porque você vai confiar nele.

Snapshot é cobrado pelo espaço que ocupa, então ele não precisa viver para sempre — veja preços. Mas não apague no minuto seguinte à mudança: alguns problemas só aparecem no dia seguinte, sob carga real.

Faça a mudança em passos verificáveis

Uma alteração por vez, com verificação entre elas. Se você trocar a versão do PHP e o nginx.conf juntos e o site cair, você tem duas hipóteses e nenhuma pista.

# valide a configuração antes de recarregar o serviço
sudo nginx -t && sudo systemctl reload nginx

# em upgrades longos, rode dentro de tmux para a queda do SSH não matar o processo
tmux new -s upgrade
sudo apt update && sudo apt upgrade

O tmux não é preciosismo: um apt upgrade que morre pela metade porque a sessão SSH caiu deixa o gerenciador de pacotes num estado que dá trabalho.

Dois riscos merecem aviso explícito, porque o snapshot resolve devagar aquilo que a prevenção resolve na hora:

• Trancar-se fora do servidor. Mexer em firewall ou em SSH pode cortar o seu próprio acesso. Mantenha uma segunda sessão aberta enquanto testa e valide a nova regra pela terceira conexão, não pela que você já tem. As precauções estão em configurar regras de firewall e em usar chaves SSH em vez de senha. O console no browser é a sua rota alternativa quando o SSH morre.
• Perder dados novos ao restaurar. Restaurar um snapshot sobrescreve o disco. Pedidos recebidos, e-mails, uploads e logs gerados depois da captura desaparecem. Se a mudança durou horas e o sistema ficou recebendo tráfego, exporte esses dados antes de voltar atrás.

Decida voltar com critério, não com esperança

Antes de começar, escreva duas coisas: como você vai saber que deu certo (a app responde 200, a fila drena, o job noturno roda) e até que horas você tenta consertar. Sem esse limite, todo mundo insiste em depurar até tarde e o rollback vira decisão de madrugada.

Quando o limite chega e o critério não foi atendido, restaure o snapshot no painel e volte ao normal. Depurar em ambiente limpo, no dia seguinte, é mais barato que insistir em produção. O procedimento e o que esperar de uma restauração estão em como restaurar um backup.

Depois de restaurar ou de confirmar o sucesso, verifique de verdade antes de encerrar:

systemctl --failed
journalctl -p err -b --no-pager | tail -40
df -h

Se algo ficou lento sem estar quebrado, VPS lenta: como diagnosticar cobre a investigação. Por último, quando a mudança estiver estável por alguns dias, apague o snapshot para parar de pagar por espaço que já não protege nada — e confirme que a agenda de backup diário continua rodando, porque ela é a rede que fica.