Em resumo: uma estratégia de backup fiável para servidores segue a regra 3-2-1: três cópias, dois tipos de armazenamento, uma cópia fora das instalações. Para que os backups sobrevivam também a um ataque, pelo menos uma cópia precisa de proteção contra eliminação pelo próprio servidor. E só um teste de recuperação bem-sucedido mostra que a salvaguarda funciona no caso real.
O que significa a regra 3-2-1
A regra 3-2-1 é um princípio simples, comprovado há anos, para a salvaguarda de dados:
- 3 cópias: os dados originais e duas cópias de segurança.
- 2 tipos de armazenamento: por exemplo disco local e armazenamento de objetos, ou armazenamento do servidor e fita.
- 1 cópia fora das instalações: noutro local, num fornecedor diferente ou offline.
Para servidores web, isto significa em concreto: uma cópia no mesmo disco do site não conta como cópia independente. Se o servidor falhar ou for comprometido, perdem-se ambas. Para a gestão, a pergunta central não é, por isso, “Temos backups?”, mas “Conseguimos restaurar a operação a partir de uma cópia que o incidente não atingiu?”
Uma estratégia de backup para servidores que sobrevive a um ataque
Os atacantes sabem que os backups deitam a perder o seu trabalho. Quem tem acesso a um servidor procura por isso muitas vezes também cópias de segurança, para as apagar ou cifrar. Uma estratégia moderna alarga, por isso, frequentemente a regra 3-2-1 para 3-2-1-1-0: uma cópia adicional offline ou imutável e zero erros no teste de recuperação.
Três princípios tornam os backups resistentes:
- Pull em vez de push: um sistema de backup separado vai buscar os dados ao servidor web. O próprio servidor web não tem credenciais com que pudesse apagar backups.
- Imutabilidade: armazenamento de objetos com bloqueio de retenção ou snapshots que não podem ser apagados durante um tempo definido.
- Acessos separados: a conta de backup não é a mesma que a conta de cliente do alojamento e tem o seu próprio segundo fator.
Cifre os backups guardados fora das instalações e guarde a chave em separado. Uma chave perdida torna o backup inutilizável, uma chave guardada junto torna a cifragem inútil.
O que tem de ser guardado
Nos servidores web, muitas vezes só se guarda a raiz web. Para uma recuperação completa, faltam então partes importantes.
| Área | Exemplos | Nota |
|---|---|---|
| Ficheiros da aplicação | raiz web, uploads, temas, extensões | os uploads mudam com frequência |
| Bases de dados | MySQL/MariaDB, PostgreSQL | guardar de forma consistente, não apenas copiar ficheiros |
| Configuração | servidor web, pools PHP-FPM, php.ini, tarefas cron | necessária para uma reconstrução rápida |
| Certificados e chaves | certificados TLS, chaves da aplicação | guardar cifrados e em separado |
| Documentação | acessos, dependências, procedimento de recuperação | sem ela, qualquer reconstrução demora mais |
Exemplo: guardar a base de dados e os ficheiros
O exemplo seguinte mostra os blocos de base de uma salvaguarda diária. Na prática, uma ferramenta de backup com cifragem, deduplicação e regras de conservação assume a transferência para fora das instalações.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Guardar a base de dados de forma consistente; credenciais de um ficheiro protegido, não no comando
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Ficheiros da aplicação e configuração
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Somas de verificação para controlo posterior
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
O ficheiro .backup-my.cnf contém as credenciais de um utilizador de base de dados que só pode ler e tem as permissões 0600. O --single-transaction garante, em tabelas InnoDB, um estado consistente sem parar a loja.
Depois, um sistema separado transfere a salvaguarda para fora das instalações. Importante é que este passo seja monitorizado: uma tarefa de backup que falha em silêncio há dias só é notada, de outro modo, no caso real. Basta uma mensagem diária sobre êxito, tamanho e duração, desde que alguém a leia e investigue os desvios.
Se utilizar adicionalmente backups ou snapshots do seu fornecedor de alojamento, esclareça por escrito durante quanto tempo são conservados, se pode restaurar por si e se as cópias se mantêm numa conta cancelada ou bloqueada. Estas cópias são um bom complemento, mas não substituem uma salvaguarda própria e independente.
Conservação: porque são importantes estados mais antigos após o PHP2Shell
Após um ataque, o backup mais valioso não é o mais recente, mas o mais recente que esteja limpo. No PHP2Shell, segundo notícias dos meios de comunicação, foi observada uma primeira tentativa de ataque a 17/10/2026, e os patches surgiram a 21/10/2026. Quem conserva apenas sete dias pode já não ter um estado que esteja com segurança anterior à possível intrusão.
Um esquema comprovado combina vários períodos, por exemplo salvaguardas diárias durante algumas semanas, semanais durante alguns meses e mensais durante um ano. Os períodos exatos dependem da sua necessidade de proteção e das obrigações de eliminação decorrentes da proteção de dados.
Também é importante: um backup do período posterior a uma intrusão pode conter webshells ou ficheiros alterados. Após um incidente, nunca restaure às cegas, compare os ficheiros com um estado limpo e verifique-os antes de o site voltar a ficar online. Indicações sobre o que deve observar encontra-as em Sinais de comprometimento. Um patch não remove software malicioso introduzido, e um backup também não o faz por si só.
Testar e documentar a recuperação
Um backup sem teste é uma suposição. Só a recuperação mostra se todas as partes estão presentes, se a chave funciona e quanto tempo o processo demora realmente.
- Restaure regularmente uma salvaguarda completa num ambiente de teste, incluindo base de dados e configuração.
- Verifique se o site funciona depois por completo: login, encomendas, formulários, e-mails.
- Meça a duração e registe que passos foram manuais. Compare o resultado com o tempo máximo que a sua operação aguenta sem o site.
- Guarde as instruções de recuperação num local acessível mesmo com o servidor em baixo, por exemplo no plano de emergência de TI.
Como ajuda concretamente a PHP SOS?
- Verificamos os seus backups existentes quanto a integridade, conservação, separação do servidor e proteção contra eliminação.
- Configuramos uma salvaguarda 3-2-1 com cópia imutável e testamos consigo a recuperação.
- Após um incidente, identificamos o último estado limpo e restauramo-lo num sistema com patch no âmbito da remoção de malware.
- No contrato de manutenção de segurança, monitorizamos continuamente as salvaguardas e realizamos testes de recuperação regulares.
Perguntas frequentes
O que significa a regra 3-2-1 nos backups?
Três cópias dos seus dados, em dois tipos de armazenamento diferentes, uma delas num local distinto. A regra garante que nem uma avaria de hardware, nem um ataque, nem um incêndio atingem todas as cópias ao mesmo tempo.
O backup do meu fornecedor de alojamento chega?
É um bom complemento, mas raramente suficiente. Esclareça durante quanto tempo o fornecedor conserva os estados, se pode restaurar por si e se um atacante com a sua conta de cliente poderia apagar os backups. Recomenda-se uma cópia própria e independente.
Depois de um ataque, posso simplesmente repor o último backup?
Só com cautela. O último backup pode já conter código malicioso, e a vulnerabilidade por onde o atacante entrou continua depois aberta. Primeiro esclareça e feche a causa, depois restaure um estado verificado num sistema com patch.
Com que frequência devo testar a recuperação?
Regularmente e após alterações maiores ao sistema. Um ritmo fixo, por exemplo uma recuperação completa por trimestre num ambiente de teste, tem-se revelado eficaz. Importante é que o teste seja documentado e as lacunas corrigidas.