Todo site sai do ar em algum momento. A diferença entre um susto de quinze minutos e três dias de prejuízo não está em ter evitado a falha, está no que existia preparado antes dela. Este artigo é sobre esse preparo.
As 5 causas mais comuns de um site fora do ar
- Domínio expirado. A causa mais frequente e a mais evitável. O cartão cadastrado venceu, o e-mail de aviso foi para o spam, e o site some inteiro, junto com os e-mails do domínio. Mantenha renovação automática ativa, o contato do registro atualizado e um lembrete próprio no calendário.
- Certificado SSL vencido. O site continua no servidor, mas o navegador exibe um aviso vermelho de conexão não segura, o que na prática é o mesmo que estar fora do ar. Costuma acontecer quando a renovação automática para de funcionar sem ninguém notar.
- Erro humano em atualização. Um plugin atualizado, um tema trocado, um deploy incompleto, uma configuração salva errada. É a causa mais comum entre sites que estão de fato sendo mantidos.
- Problema na hospedagem. Queda do provedor, limite de recursos estourado, disco cheio, banco de dados fora do ar. Nesses casos o controle está fora das suas mãos, e o que resta é saber quanto tempo o seu plano promete e ter para onde ir se a promessa não for cumprida. O assunto está em hospedagem compartilhada, VPS ou cloud.
- Invasão ou malware. Software desatualizado, senha fraca, plugin abandonado. Além do site fora do ar, existe o risco de o domínio ser marcado como perigoso pelo navegador, o que leva semanas para reverter.
Repare que três das cinco causas não têm nada a ver com código. São administrativas. É por isso que continuidade é assunto de processo, não só de tecnologia.
Antes de qualquer diagnóstico técnico, confirme se o problema é seu. Peça para alguém em outra rede abrir o site, ou use um serviço que testa o endereço a partir de vários países. Cache de DNS local, uma rede corporativa com filtro e até uma extensão do navegador conseguem simular perfeitamente um site fora do ar que está funcionando normalmente para o resto do mundo.
A regra 3-2-1 aplicada a sites
A regra 3-2-1 é um padrão antigo de backup e continua válido:
- 3 cópias dos dados, contando a que está em produção.
- 2 mídias ou serviços diferentes, para que uma falha não atinja tudo.
- 1 cópia fora do local principal, em outro provedor ou outra região.
Traduzindo para um site: a produção conta como uma cópia; o backup automático do provedor de hospedagem é a segunda; e uma cópia baixada e guardada em outro lugar, um serviço de nuvem diferente ou um disco externo, é a terceira. O ponto crítico é o último. Backup guardado apenas dentro do mesmo painel do mesmo provedor não é backup externo: se a conta for suspensa ou invadida, você perde as duas coisas ao mesmo tempo.
O que precisa de backup além dos arquivos
Quase todo mundo lembra dos arquivos do site e esquece do resto. A lista completa:
| Item | Por que importa |
|---|---|
| Arquivos do site | Código, imagens, uploads e configurações do servidor |
| Banco de dados | Conteúdo, artigos, usuários e pedidos. Sem ele, os arquivos não montam o site |
| Caixas de e-mail | Se o e-mail é do mesmo domínio, a conversa com clientes está lá |
| Zona de DNS | Todos os registros. Reconstruir de memória é lento e propenso a erro |
| Certificados e credenciais | Acessos do registrador, do painel, do repositório e das APIs em uso |
| Variáveis de ambiente | Chaves e configurações que não ficam no repositório e ninguém lembra depois |
Vale exportar a zona de DNS em arquivo de texto e guardar junto com o backup. É pequeno, muda pouco e economiza horas em uma migração de emergência. Sobre a titularidade desses acessos, existe um artigo inteiro em de quem é o seu site, e a leitura vale a pena antes que a emergência aconteça.
Preste atenção especial ao TTL dos registros de DNS. Esse número define por quanto tempo os provedores guardam a resposta antes de perguntar de novo. Com um TTL de 24 horas, uma mudança de servidor demora até um dia para valer para todo mundo. Se você já sabe que vai migrar, baixe o TTL para alguns minutos com antecedência e volte a subir depois que tudo estabilizar.
Frequência de backup por tipo de site
A pergunta certa não é com que frequência fazer backup, é quanto conteúdo você aceita perder. Se o backup é diário, o pior caso é perder um dia de trabalho.
| Tipo de site | Arquivos | Banco de dados |
|---|---|---|
| Site institucional estático | A cada alteração | Não se aplica |
| Site com blog atualizado | Semanal | Diário |
| Site com formulários e leads | Semanal | Diário |
| Loja virtual | Diário | Contínuo ou várias vezes ao dia |
Defina também por quanto tempo guardar cada cópia. Manter apenas o backup de ontem é arriscado: se um problema começou há duas semanas e ninguém percebeu, todos os backups recentes já estão contaminados. Uma retenção comum é manter os últimos sete diários, quatro semanais e três mensais.
Backup não testado não é backup
Essa é a parte que quase ninguém faz e que separa um plano real de uma falsa sensação de segurança. Um arquivo de backup que nunca foi restaurado é só um arquivo grande. Ele pode estar truncado, pode estar sem o banco, pode ter sido gerado com erro que ninguém leu no log.
O teste de restauração é simples:
- Baixe o backup mais recente e verifique que ele abre e tem tamanho compatível.
- Crie um ambiente separado: um subdomínio de teste, um servidor local ou uma instalação temporária.
- Restaure arquivos e banco lá, nunca por cima da produção.
- Abra a home, uma página interna, uma imagem e faça um login. Confira se o conteúdo está atualizado até a data esperada.
- Anote quanto tempo levou o processo inteiro. Esse número é a sua estimativa real de tempo de recuperação.
- Apague o ambiente de teste, garantindo que ele não seja indexado enquanto existir.
Faça isso uma vez por semestre, no mínimo. É a única forma de saber que a rede de proteção existe.
Monitoramento de uptime gratuito
Descobrir que o site caiu porque um cliente ligou é o pior cenário possível. Serviços de monitoramento fazem uma requisição periódica ao seu site e avisam por e-mail, mensagem ou aplicativo quando ele para de responder. Existem opções gratuitas com verificação a cada poucos minutos, o que é suficiente para a maioria dos negócios.
Três configurações que valem a pena: monitorar uma página interna além da home, porque a home pode estar em cache e responder mesmo com o resto quebrado; monitorar a expiração do certificado SSL, que muitos serviços oferecem junto; e enviar o alerta para mais de uma pessoa, para o caso de quem recebe estar de férias.
Plano de resposta em uma página
Quando o site cai, ninguém tem cabeça para improvisar. Deixe escrito, em um documento acessível fora do próprio site:
- Quem aciona. Nome e telefone de quem toma a frente e de um substituto.
- Onde estão os acessos. Registrador do domínio, painel de hospedagem, DNS, repositório. Em um gerenciador de senhas com acesso compartilhado.
- Onde estão os backups. Local exato e como baixar.
- Diagnóstico em três passos. O domínio está ativo? O DNS responde? O servidor responde? Cada resposta aponta para um responsável diferente.
- Contato do suporte da hospedagem. Canal, horário de atendimento e número do contrato.
- Comunicação. O que dizer nas redes sociais e para clientes que perguntarem, para evitar improviso.
Uma página. Impressa ou salva onde não dependa do site que caiu. Revise essa página junto com a rotina de manutenção, porque contatos e acessos mudam.
Se você não sabe onde estão os seus backups nem quando foram testados pela última vez, fale com a ALB Seven. Esse é o tipo de conversa que é muito melhor ter antes do problema.