# Estratégia de backup para servidores: backups segundo a regra 3-2-1

> Estratégia de backup para servidores segundo a regra 3-2-1: o que guardar, como os backups sobrevivem a um ataque e porque deve testar a recuperação.

Fonte: https://phpsos.de/pt/ratgeber/backups-3-2-1/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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.

> **Importante:**
> 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.

```bash
#!/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](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/). 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](https://phpsos.de/pt/compliance/notfallplan-erstellen/).

## 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](https://phpsos.de/pt/leistungen/malware-entfernung/).
- No [contrato de manutenção de segurança](https://phpsos.de/pt/leistungen/security-wartungsvertrag/), 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.

## Fontes

- [BSI IT-Grundschutz (proteção de base de TI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI (Serviço Federal Alemão para a Segurança da Informação): salvaguarda de dados](https://www.bsi.bund.de/)
- [php.net: avisos de segurança sobre o PHP2Shell](https://www.php.net/)