O que é
Além do backup por site, o GW Server tem um módulo que faz um snapshot completo do servidor
inteiro — painel, todos os sites e aplicações — e guarda no S3. Esse snapshot pode ser restaurado
em outra máquina, o que serve para trocar de provedor de cloud ou para recuperação de desastre.
Como funciona
Configurado o destino S3, você pode:
- Criar um snapshot na hora, manualmente.
- Agendar snapshots automáticos (diário, semanal ou mensal, no horário que escolher).
Cada snapshot é uma cópia fiel de tudo que o servidor tinha naquele momento, pronta para ser
restaurada em um segundo ou terceiro servidor.
Free e Pro
Criar o snapshot está incluído no plano Free: dá para guardar cópias completas do servidor
no seu S3 sem licença nenhuma. Restaurar o snapshot em outro servidor é o Módulo de
Recuperação, que exige GW Server Pro. A licença precisa estar ativa no servidor de
destino — é ela que autoriza a restauração ali. Como a mesma chave não fica ativa em dois
servidores ao mesmo tempo, desvincule-a do servidor antigo antes de ativá-la no novo (ver
Licença). Os sites do servidor antigo continuam funcionando mesmo com a
licença desvinculada — só fica bloqueada a instalação de aplicações novas ali.
Restaurando em outra máquina
Para migrar de provedor: crie o snapshot, suba um servidor novo e limpo com o GW Server, e use a
restauração do servidor apontando para o snapshot no S3. Todo o ambiente: painel, sites e
aplicações: é recriado na máquina nova.
- Contrate o servidor novo e instale o GW Server (não precisa que o domínio já esteja apontado —
o SSL fica pendente até o corte de DNS). - Integre a Cloudflare no servidor novo antes de restaurar: é o
que permite ao painel cortar o DNS e emitir SSL sozinho, mais adiante. - Configure o mesmo bucket S3 (e, se possível, a mesma Application Key) usado no servidor de
origem — é isso que faz o servidor novo enxergar os snapshots já existentes. - Abra o módulo de recuperação, liste as origens e escolha o snapshot pela data.
- Restaure site a site (mais controlado) ou todos de uma vez (mais rápido, mas confira o corte
de DNS de cada um depois). - Para cada site/aplicação, use verificar DNS e depois alterar e ativar: o painel corta o
DNS na Cloudflare e emite o SSL automaticamente, sem edição manual.
Servidor maior durante a migração. Restaurar um backup grande com pouca folga de CPU/RAM pode
ser lento ou, em casos raros, corromper algum dado. A recomendação é contratar temporariamente um
servidor maior só para o processo de migração, e redimensionar para baixo depois de tudo
validado.
Nem tudo migra sozinho. IPs diferentes entre origem e destino podem esbarrar na verificação de
DNS de algum site (por exemplo, se ele usa uma conta Cloudflare diferente da integrada no servidor
novo); aplicações com imagem grande (o Typebot, por exemplo, tem uma imagem consideravelmente
maior que as demais) podem esbarrar em limite de disco. Trate isso como um recurso que resolve a
maior parte do trabalho, não 100% dos casos — o mesmo tipo de problema que afeta qualquer backup
(banco corrompido, plugin com falha) pode aparecer aqui também.
Depois de restaurar os sites
O módulo também importa, à parte, as configurações globais do servidor antigo — SMTP,
identidade visual (branding) e usuários do painel. É um passo separado da restauração de cada site.
Ao importar as configurações do servidor antigo, a integração S3 de backup também é
sobrescrita com a do servidor de origem. Se você já está usando o mesmo bucket nos dois
servidores, isso não causa problema; se não, confira antes de importar.
Depois de validar que tudo migrou corretamente (inclusive testando com o servidor antigo
desligado, para confirmar que nada mais depende dele), gere um último snapshot de segurança
do servidor antigo antes de excluí-lo — guardar esse snapshot por mais alguns dias custa muito
menos do que manter o servidor rodando.