Como reverter (rollback) um deploy que quebrou a aplicação em produção imprimir

  • 0

Como reverter (rollback) um deploy que quebrou o site em produção

Calma, respira fundo. 🙏 Se você acabou de subir uma atualização no site (um novo tema, um plugin, uma alteração de código) e agora a página está com erro, em branco ou fora do ar, isso tem solução — e na maioria das vezes é rápida. Eu sou a Sensei da GeHost e vou te guiar, passo a passo, por dois caminhos: reverter os arquivos manualmente e restaurar por um backup. Bora resolver juntos.

Regra de ouro antes de qualquer coisa: não entre em pânico e não fique "tentando de tudo" às cegas. Cada alteração feita em cima de um site já quebrado pode dificultar a reversão. Siga a ordem abaixo.

1. Primeiro, identifique o que mudou

Pergunte-se: o que foi a última coisa que você fez antes do problema aparecer? Atualizou um plugin/tema? Subiu um arquivo novo via FTP? Trocou uma configuração? Saber exatamente o que mudou já reduz metade do trabalho, porque geralmente o rollback é só "desfazer aquilo".

2. Acesse o cPanel

Todo o processo é feito pelo painel cPanel da sua hospedagem GeHost. Acesse pelo endereço que você recebeu no e-mail de boas-vindas (ou pelo painel.gehost.com.br, que te leva até lá) e faça login com seu usuário e senha.

Tela de login do cPanel com campos de usuário e senha

Caminho A — Reverter arquivos manualmente (quando você sabe o que mudou)

  1. Dentro do cPanel, abra o Gerenciador de Arquivos (File Manager).
  2. Navegue até a pasta public_html (ou a subpasta do seu site, se ele estiver instalado em um diretório específico).
  3. Se você fez upload de um arquivo/pasta novo, localize-o e renomeie ou mova para fora da pasta pública (assim ele para de ser usado, mas não se perde — você pode analisar depois com calma).
  4. Se você tinha uma cópia do arquivo anterior (muita gente salva um ".bak" ou renomeia antes de mexer — um bom hábito!), é só devolver essa cópia para o lugar do arquivo quebrado.
  5. Atualize o site no navegador para conferir se voltou ao normal.
Gerenciador de Arquivos do cPanel mostrando a árvore de pastas, incluindo a public_html
Dica da Sensei: antes de qualquer deploy futuro, faça o hábito de renomear o arquivo antigo (ex.: index.phpindex_old.php) antes de subir o novo. Isso transforma qualquer rollback em "renomear de volta" — trinta segundos de trabalho.

Caminho B — Restaurar por Backup (quando o estrago foi maior ou envolveu banco de dados)

Se a mudança mexeu em várias partes do site, no banco de dados, ou você simplesmente não tem certeza de tudo que foi alterado, o caminho mais seguro é restaurar um backup de um momento em que tudo funcionava.

  1. No cPanel, acesse a ferramenta Backup.
  2. Lá você encontra opções de Backup Completo e também backups parciais (só arquivos de um diretório, ou só o banco de dados) — escolha o que faz sentido pra sua situação.
  3. Selecione um backup de uma data anterior ao deploy problemático e siga a restauração pela tela.
  4. Depois de restaurado, confira o site novamente.
Tela de Backup do cPanel com opções de Backup Completo e backups parciais
Importante: restaurar um backup completo também reverte o banco de dados para a data escolhida — ou seja, pedidos, comentários ou cadastros feitos depois daquele backup podem se perder. Se seu site recebe movimento (loja, formulários, etc.), avalie se vale restaurar tudo ou só os arquivos.

3. Não achou backup, ou o problema persiste?

Sem problema — é exatamente pra isso que existe o nosso suporte. Se você:

  • não sabe exatamente o que foi alterado no deploy;
  • não encontrou um backup do período certo;
  • fez a reversão e o erro continua;
  • ou simplesmente prefere ter uma mãozinha pra não arriscar mexer sozinho(a);

abra um chamado pelo painel.gehost.com.br contando o que aconteceu e o que você já tentou. Nossa equipe assume a partir daí.

4. Depois que o site voltar ao ar

Vale a pena investigar com calma por que o deploy quebrou antes de tentar subir a atualização de novo — assim você evita passar pelo mesmo susto uma segunda vez. E, sempre que possível, teste mudanças grandes em um ambiente de testes antes de aplicar direto em produção.

🌱 Resumo rápido da Sensei: identifique o que mudou → reverta o arquivo/pasta específica (mais rápido) OU restaure um backup anterior (mais seguro para mudanças grandes) → confirme que o site voltou → se travar em qualquer etapa, chame o suporte. Você não precisa resolver isso sozinho(a).

Esta resposta lhe foi útil?

« Retornar