Backup e Restauração¶

Backup não é o arquivo que existe no armazenamento; é a restauração que você consegue executar dentro do tempo que o negócio aceita. Todo cliente que já perdeu dados tinha backup — o que faltou foi a restauração funcionar, caber no prazo, ou cobrir o instante certo.

A política padrão da InteSys combina três camadas: backup completo periódico, incrementos entre eles e um arquivo contínuo do log de transação. Juntas, elas permitem voltar não só ao último backup, mas a um segundo específico antes do erro.

O comando destrutivo às 14:07 não é problema quando existe log contínuo: restaura-se para 14:06:59.

As camadas¶

Todas as camadas saem dos servidores do banco. Backup no mesmo disco do banco não é backup: é uma segunda cópia do mesmo ponto de falha.

Point-in-time recovery¶

O caso que justifica a arquitetura inteira não é o incêndio no datacenter — é o DELETE sem WHERE, o DROP TABLE no terminal errado, o deploy que corrompeu dados por três horas até alguém perceber.

Com log contínuo, a restauração é:

1. restaurar o último backup completo anterior ao incidente;
2. aplicar os incrementos até o ponto disponível;
3. reproduzir o log de transação até o segundo imediatamente anterior ao comando destrutivo;
4. validar e liberar.

O que define quanto se perde é a frequência do envio do log, não a do backup completo.

Snapshot de volume criptografado¶

Nos clusters em Kubernetes, além do backup lógico e físico, usamos snapshots de volume (VolumeSnapshot via CSI): uma cópia do volume inteiro, tirada em segundos, sem varrer a base.

• Snapshot consistente — o operador coordena o flush e o congelamento da escrita antes de disparar o snapshot, para que o volume copiado seja restaurável.
• Sempre em volume criptografado — a chave é gerenciada pela InteSys ou fornecida pelo cliente.
• Cópia cifrada em trânsito — a replicação do snapshot para outro destino trafega criptografada.
• Restauração de cluster inteiro — o snapshot devolve o estado do volume; para voltar a um instante intermediário, o log contínuo continua sendo necessário.

Retenção¶

A política é acordada por cliente, mas o formato padrão é escalonado:

Retenção também é obrigação de descarte. Dado pessoal mantido além do necessário é passivo sob a LGPD; a política define tanto quanto guardar quanto quando apagar.

Criptografia e acesso¶

• Em repouso — todo backup fica em volume ou armazenamento de objetos criptografado.
• Em trânsito — transferência sempre por canal cifrado.
• Acesso separado — quem administra o banco não é necessariamente quem apaga backup. Credenciais de retenção são distintas das operacionais.
• Imutabilidade quando exigida — retenção com bloqueio de exclusão, para cenários de ransomware ou exigência regulatória.

Teste de restauração¶

A parte que quase todo mundo pula, e a única que prova que o resto funciona.

Páginas Relacionadas¶

• Recuperação de Desastres — Onde o backup entra no plano maior
• Replicação — Réplica não é backup: ela copia o DROP TABLE também
• Administração — Verificação diária e revisão de retenção
• Instalação — A política definida no dia um
• Alta Disponibilidade MySQL · PostgreSQL · ClickHouse