Estratégias de backapp e replicação

Resumo curto

Uma estratégia de dados confiável está em três pilares: bacap, replicação, recuperação. A réplica reduz RTO (tempo de recuperação), o bacap garante RPO (perda de dados) e protege contra erros lógicos/criptografados. Princípios básicos: 3-2-1-1-0 (3 cópias, 2 tipos de mídia, 1 off-site, 1 invariável, 0 erros de verificação), testes regulares de DR. e imunidade de conjuntos críticos.

Termos e objetivos

RPO - Quantos dados podem ser perdidos (por exemplo, ≤ 5 minutos).
RTO - quanto tempo é permitido restaurar (por exemplo, ≤ 15 minutos).
PITR (Point-in-Time Recovery) - Restaurando «no momento X» com replay de registros.
SLO de dados - contrato de nível de serviço para RPO/RTO e sucesso de tarefas de backup.

Modelos de resistência e replicação

Opções de topologia

Ative-Passive (quente/quente/frio): Failowers mais simples, previsíveis.
Ativo-Ativo: alta disponibilidade, mas mais difícil conflito-ressalva e consistência.
Multi-Zona/Region/Cloud: Balanço de atrasos e custos do egress.

Sincronização vs asinharão

Sincronon: RPO≈0, acima latency, limite de distância.
Asinhron: perto de zero RTO com RPO pequeno (minutos), aguenta regiões/nuvens.
Híbrido: Sinchron dentro da zona, asinharão dentro da região remota.

Réplica ≠ Bacap

A réplica leva erros/remoção após a origem. Bacap é uma cópia off-path com versionagem, verificação e isolamento.

Política 3-2-1-1-0 e permanência

3 cópias (prod + reserva local + off).
2 tipos de mídia (bloco/NAS/objeto/fita).
1 off (outro local/nuvem/fita).
1 cópia imutável (WORM: Object Lock, imutable snapshots/fita).
0 erros: verificação regular da integração (checksum/verify/restore-testes).

• Inclua a versionização e o Object Lock (Compliance/Governance) para um objeto com bacapes críticos.
• Para NAS/blocos - snapshots imutáveis com retino e proibição de remoção antes do prazo.

Tipos de bacapes e agendamento

Full é uma cópia completa.
Incremental - apenas mudanças do passado do bacap.
Individual - alterações desde a última edição completa.
Forever-incremental com plano GFS (Grandfather-Father-Son): encartes diurnos, semanais e mensais «completos sintéticos».

• Prod BD: diário full (ou full sintético), encartes/revistas a cada 5 a 15 minutos (PITR).
• Servidores de arquivo: full semanal, incremental diário, arquivos mensais.
• Objeto: lifecyple + versões; frio - para a sala de aula de arquivos/fita.

Aplicativos e BD: práticas PITR

PostgreSQL

Ativar o arquivo WAL e basear o backup; PITR através de 'restore _ command'.
Ferramentas: «pgBackRest», «wal-g» (objeto), «pg _ basebackup» para os completos.
Separar os volumes: dados e WAL; escrevendo WAL para NVMe rápido com PLP.

MySQL/MariaDB

Binary jobs para PITR completos através de 'Percona XtraBackup' (hot backup).
Replicação GTID; para DR. - asinharão na região/nuvem.

MongoDB

Oplog para PITR; para as cópias lógicas.
Testar a consistência da réplica antes do backap.

Redis/Cash

Fora o backap: manter RDB/AOF + offsite; restaurar como warm-cachê ou da fonte da verdade.

Kubernetes e contêineres

Um cluster etCD é um alvo crítico separado (frequentes, off).
Velero: Bacap de manifestos/recursos + CSI-Snapshots/PV; armazenamento em baquete compatível S3 (com Object Lock).
Premiações estateful: app-consistent snapshots (pré/post hooks), senão crash-consistent.
Versionização de artefatos de objetos (modelos/mídia) - nível de baquetes.

Virtualização e servidores de arquivos

SHOTS VM: usar CBT (Changed Block Tracking), armazenar offsite, fazer guest-aware quiesce periodicamente (VSS para Windows).
Servidores de arquivos (NAS): snapshots + réplica e testes de restore de calção regulares (amostra de arquivos).

Segurança dos bacapes

Criptografia em paz (LUKS/ZFF/KMS em nuvem/Vault) e em transferência (TLS/mTLS).
Controle de chaves: papéis individuais, dual-controle, rotação, armazenamento off-line de chaves mestre.
Isolação: contas de software bacap sem permissão para remover cópias imutáveis; redes individuais/VLAN.
Sustentabilidade ransomware: imutável, air-gap (fitas/conta isolada/lab).
Auditoria: registro de operações de backap, alertas de remoção/redução de retino.

Planejamento de janelas e banda larga

Comando window vs carga: trottling I/O/redes, dedução, compressão.
Rede: Encartes a cada N minutos, canais individuais/VPN, réplica à noite ou permanentemente com QoS.
Mudar Block Tracking/CDC para reduzir o tráfego.
Grandes bases: fluxo paralelo/streaming, multipart multicanal no objeto.

Monitoramento, métricas e SLO

• O sucesso das tarefas de backup/replicação (%), duração, velocidade, registro (WAL/binlog/oplog).
• Espaço de armazenamento de bacapes, coeficiente de dedução, outras despesas.
• Tempo e sucesso dos testes de recuperação.

• O sucesso dos bacapes ≥ 99. 9 %/30 dias.
• O RPO foi cumprido ≥ 99% do tempo (lista de revistas ≤ destino).
• RTO (teste-restore) ≤ 15 min para carteira, ≤ 1 h para relatórios.
• DR.-drill mensal: 100% dos cenários regulatórios foram concluídos.

• Bacap omitido/inoperante, PITR> limiar, redução do grau de dedução, falta de espaço, alteração da política de retenção, falta de teste-restore recente.

Exercício DR. e verificação de recuperação

Tabela-top: coordenação de papéis, contatos, comunicações.
Técnica: restauração «para o banco de areia», medição de RTO, comparação de quantias de controle/dados.
Black-start: recuperação completa para «cluster nu/cluster limpo».
Diretórios de dados: etapas de recuperação pré-descritas (runbooks) para cada classe de sistema.
Automação: restore «canarinho» periódico e verificação de quantias de controle.

Modelos práticos

1) PostgreSQL (pgBackRest + arquivo WAL no objeto)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (exemplo ENV)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s - objeto + embutibilidade baqueta)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Política Object Lock (exemplo de 'mc')

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) Exemplo de programação GFS (conceito)

Daily: Encartes a cada 15 min (revistas), full sintético diurno.
Um «completo» (sintético), armazenado 8 semanas.
Monthly: completo, armazenar 12-24 meses (arquivo/fita).

Folha de cheque de implementação

• Definidas classes de dados, proprietários, RPO/RTO/SLO.
• Modelos de replicação selecionados (sync/async) e topologia (AZ/Region/Cloud).
• Os bacapes foram configurados: full/incremental/PITR, agendamentos, diretórios.
• Insertividade (WORM/Object Lock/imutable snapshots) e off/air-gap estão ativados.
• Criptografia e KMS/Vault, papéis separados e rotações de chaves.
• Monitoramento: sucesso de tarefas, registro, local, teste-restore; Alertas.
• Runbooks restauração e feelover; contatos, escalações, modelos de comunicação.
• Exercício DR. mensal + relatório, ajuste de planos.
• Orçamento e FinOps: custo de armazenamento/egress, projeto de arquivamento/tiring.

Erros típicos

«Não é preciso uma réplica - não é preciso um bacape»: remoções lógicas e criptografistas vão para a réplica.
Não há testes de recuperação. O bacap existe em teoria.
A falta de imunidade e off-site é um único ponto de risco.
A mesma conta/chave de prêmios e bacapes - comprometimento = perda de tudo.
Janelas de bacap muito longas → conflito com picos; Não há trottling ou QoS.
PITR sem controle da laje de revistas.
Ignorar o app-consent é um volume de recuperação «sujo».

Especificidades para iGaming/Fintech

Carteira/núcleo de pagamento: RPO ≤ 1-5 min, RTO ≤ 15 min; Registros (WAL/binlog) em um objeto com WORM; sinchron na zona + asinharão região.
Relatórios/regulação: armazenamento imutável, retensas de longo prazo (anos), integridade verificável, procedimentos claros para a emissão de dados aos reguladores.
Logi/eventos crus/antifrode: armazém de longa vida barato (objeto) + lifecyple; índices e vitrines, separadamente.
Picos (jogos/torneios): janelas de bacap fora dos picos, throttling; Planos DR para o período de eventos; restore canário antes das promoções.

Resultado

A proteção de dados é uma disciplina arquitetônica: 3-2-1-1-0, versionização e imutabilidade, RPO/RTO como SLO, exercícios regulares de DR. e verificação de recuperação «de fato». Combine a replicação para farmácias e feelowers rápidos com bacaps para erros lógicos e compromissos. Automatize, mede, documente - e terá sempre um caminho de trabalho para trás, mesmo no pior dia possível.