Planeamento de Backup e Recuperação: Proteja os Seus Ficheiros

Um plano de backup e recuperação responde a duas perguntas numéricas: RPO (quanto dados pode perder, medido em tempo) e RTO (quanto tempo pode ficar inativo). Defina-os para cada carga de trabalho e depois engenharia de trás para a frente. Uma base de dados com RPO de 5 minutos precisa de envio WAL contínuo; um relatório de marketing semanal com RPO de 24 horas precisa de um job noturno. Combine com a regra 3-2-1 — três cópias, em dois tipos de suporte, com uma fora das instalações — e teste restauros trimestralmente. A maioria das histórias de "temos backups" termina mal porque ninguém praticou o restauro.

RPO e RTO: Os Números de Partida

RPO (Recovery Point Objective) = perda máxima aceitável de dados em tempo. RTO (Recovery Time Objective) = tempo máximo aceitável de inatividade.

Exemplos por carga de trabalho:

Base de dados de produção para um site de e-commerce: RPO 5 min, RTO 1 hora
Carregamentos de ficheiros de clientes: RPO 15 min, RTO 2 horas
Servidor de ficheiros interno: RPO 24 horas, RTO 8 horas
Arquivo de e-mail: RPO 24 horas, RTO 48 horas
Análises de marketing: RPO 24 horas, RTO 72 horas

RPO/RTO mais apertados custam mais. Um RPO de 5 minutos significa replicação contínua (infraestrutura cara); um RPO de 24 horas significa um job noturno (barato). Não engenharie em excesso — nem toda a carga de trabalho precisa de hot standby.

A Regra 3-2-1 Ainda Funciona

Três cópias dos dados, em dois tipos diferentes de armazenamento, com uma fora das instalações. A regra 3-2-1 é anterior à cloud e mantém-se válida:

Primária: armazenamento de produção (S3, EBS, disco PostgreSQL)
Secundária: backup em suporte diferente ou noutra região (outro bucket S3 com replicação, Glacier)
Terciária: fora das instalações, idealmente fornecedor diferente ou air-gapped (Backblaze B2, fita no local, discos físicos num cofre)

O ponto da diversidade de fornecedor importa. Uma conta AWS comprometida pode eliminar todos os backups AWS. Uma cópia secundária no Backblaze, Wasabi ou no local sobrevive a esse cenário. Para empresas com receita abaixo de 50M EUR, uma cópia num segundo fornecedor acrescenta talvez 50-200 EUR/mês e protege contra problemas catastróficos ao nível do tenant.

Full, Incremental e Synthetic Full

Três estratégias de backup:

Full: Copia tudo de cada vez. Simples, restauro rápido (um ficheiro), armazenamento pesado.
Incremental: Copia apenas o que mudou desde o último backup. Eficiente em armazenamento, restauro requer full + todos os incrementais.
Synthetic full: Fusão server-side de full + incrementais num novo full virtual. Restauro rápido a partir de qualquer ponto.

Ferramentas de backup modernas (Veeam, Rubrik, restic com prune, BorgBackup) usam incremental-forever com synthetic fulls internamente. O padrão: incremental noturno, synthetic full semanal, reter 30 diários + 12 mensais + 7 anuais (rotação avô-pai-filho).

Para um servidor de ficheiros de 2 TB com taxa de mudança diária de 5%, o incremental-forever armazena cerca de 3-5 TB no total para um ano de retenção — versus 700+ TB com full noturno.

Cifração Antes de Sair

Os backups não devem viajar ou estar armazenados sem cifração. A cifração do lado do cliente com AES-256-GCM (o padrão em restic, Borg, Duplicacy, Veeam e outros) garante que o host de backup nunca vê texto simples.

A gestão de chaves importa mais do que a escolha do algoritmo. Um backup cifrado com uma chave armazenada na mesma conta AWS que o backup é teatro — um atacante com acesso IAM obtém ambos. Armazene chaves em:

AWS KMS com uma chave de conta separada (desencriptação entre contas)
HashiCorp Vault num ambiente out-of-band
Um módulo de segurança de hardware (YubiKey, HSM) para a chave raiz
Uma cópia em papel impressa e selada para chaves verdadeiramente críticas

Rode regularmente (anualmente), registe cada utilização e teste a recuperação com uma chave rodada antes de a rotação entrar em produção.

Imutabilidade: A Resposta ao Ransomware

Os ataques de ransomware em 2025 visam comummente os backups primeiro — encriptam os dados de produção, depois eliminam ou encriptam os backups para impedir a recuperação. Os backups imutáveis derrotam isto.

Implementações:

S3 Object Lock (Compliance Mode): mesmo o root não pode eliminar durante o período de retenção
Armazenamento imutável do Azure Blob: similar, aplicado ao nível do container
Veeam Hardened Linux Repository: append-only, apenas SSH, sem API de eliminação
Fita física num cofre: o air gap definitivo

Para dados críticos de negócio, pelo menos uma cópia de backup deve ser imutável durante o período de retenção. O custo incremental é geralmente zero — ia retê-lo de qualquer forma. O valor quando o ransomware atinge é total.

Testes: A Parte Não Opcional

Um backup que nunca restaurou não é um backup; é esperança. Calendário de testes por prioridade:

Tier 1 (missão crítica): simulação de restauro completo trimestralmente, restauro de ficheiro aleatório mensalmente
Tier 2 (importante para o negócio): simulação de restauro completo semestralmente, restauro de ficheiro aleatório trimestralmente
Tier 3 (padrão): simulação de restauro completo anualmente, restauro de ficheiro aleatório trimestralmente

Registar no teste:

Quanto tempo demorou o restauro (comparar com RTO)
Os dados corresponderam ao estado de produção (checksums contra um ponto conhecido)
Alguma permissão ou configuração falhou no restauro
O que falhou e como foi corrigido

As empresas que saltam os testes aprendem sobre backups corrompidos durante incidentes reais, que é o momento mais caro para aprender qualquer coisa.

Os Backups de Base de Dados Precisam de Plano Próprio

Ficheiros e bases de dados têm backup de formas diferentes. Um diretório .pgdata copiado a meio de uma transação está corrompido. Use ferramentas nativas:

PostgreSQL: pg_basebackup + archiving WAL para PITR, pg_dump para lógico
MySQL: Percona XtraBackup para físico a quente, mysqldump para lógico
MongoDB: mongodump, replica sets com secundários com atraso
Microsoft SQL Server: backup nativo com BACKUP DATABASE, log shipping para PITR

Para uma base de dados PostgreSQL de 500 GB com RPO de 5 minutos, backups base noturnos + archiving WAL contínuo para S3 dá recuperação point-in-time para qualquer segundo nos últimos 30 dias. Tempo de restauro: puxar o backup base (30 min), repetir WAL até ao ponto alvo (5-30 min). RTO apertado significa uma réplica quente pronta para promover.

Snapshots Consistentes com a Aplicação

Os snapshots de sistema de ficheiros (ZFS, Btrfs, AWS EBS, discos geridos do Azure, disco persistente do GCP) congelam um ponto no tempo ao nível do bloco. Para bases de dados, combine com quiesce da aplicação:

pg_start_backup('label') (PostgreSQL) ou FLUSH TABLES WITH READ LOCK (MySQL)
Tirar o snapshot
pg_stop_backup() ou desbloquear

O snapshot é consistente com a aplicação — utilizável para restauro sem recuperação de crash. O AWS Backup, Azure Backup e Google Cloud Backup automatizam este padrão para bases de dados comuns.

Distribuir Arquivos de Backup a Terceiros

Quando os backups precisam de ir a partes externas — auditores, reguladores, trustees sucessores — a transferência em si requer cuidado. O FTP é arcaico; os anexos de e-mail têm limites de tamanho; entregar drives USB é lento.

A transferência de ficheiros com cifração ponta a ponta trata a distribuição ad hoc de backups de forma limpa. O HexaTransfer move ficheiros até 10 GB com cifração AES-256-GCM do lado do cliente e uma ligação de utilização única. Ideal para enviar um snapshot de base de dados a um auditor sem lhe conceder acesso aos buckets S3.

A Documentação Faz Parte do Backup

O melhor backup do mundo é inútil se a pessoa que o pode restaurar está de férias e mais ninguém sabe como. Documente:

O que está em backup e o que não está (exclusões explícitas)
Calendário e retenção por carga de trabalho
Gestão de chaves e acesso
Runbooks de restauro com comandos passo a passo
Lista de contactos (suporte do fornecedor, on-call)
Resultados de testes e datas

Imprima uma cópia. Guarde uma cópia no cofre físico com as chaves de emergência. Se o runbook de backup apenas existe numa página Confluence servida pela mesma infraestrutura que acabou de cair, tem um problema. O papel ainda funciona quando mais nada funciona.

Defina o RPO/RTO, implemente 3-2-1 com imutabilidade, cifre do lado do cliente, teste trimestralmente, documente obsessivamente. O sucesso do backup é 10% tecnologia e 90% disciplina.

Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.