Planejamento de recuperação de desastres para pequenas e médias empresas: proteja sua empresa do inevitável

60% das pequenas empresas que perdem os seus dados encerram as atividades no prazo de 6 meses. No entanto, apenas 23% das pequenas e médias empresas têm um plano de recuperação de desastres documentado e testado. As empresas que sobrevivem aos desastres não são as que os evitaram – são as que se prepararam para eles.

Este guia fornece uma estrutura prática de recuperação de desastres para pequenas e médias empresas, abrangendo tudo, desde estratégias básicas de backup até arquiteturas de failover multirregionais.

Principais conclusões

• Defina RPO e RTO antes de escolher uma estratégia de DR --- esses números determinam sua arquitetura e orçamento
• A regra de backup 3-2-1 (3 cópias, 2 tipos de mídia, 1 externo) é a estratégia de backup mínima aceitável
• Backups não testados não são backups --- agende exercícios de recuperação trimestrais
• Os custos de DR são escalonados linearmente com os requisitos de RTO: o RTO de 24 horas custa 10% do RTO de 1 hora

---

Definindo objetivos de recuperação

RPO (objetivo de ponto de recuperação)

A perda de dados máxima aceitável medida no tempo. Se o seu RPO for de 1 hora, você poderá tolerar a perda de até 1 hora de dados.

RTO (objetivo de tempo de recuperação)

O tempo de inatividade máximo aceitável. Se o seu RTO for de 4 horas, sua empresa poderá sobreviver off-line por até 4 horas.

Combinando objetivos com impacto nos negócios

---

Estratégias de backup

A regra 3-2-1

• 3 cópias de cada conjunto de dados crítico
• 2 tipos de armazenamento diferentes (disco local + nuvem, por exemplo)
• 1 cópia em um local geograficamente separado

Backup automatizado do PostgreSQL

#!/bin/bash
# /opt/scripts/backup-database.sh
# Run via cron: 0 */6 * * * /opt/scripts/backup-database.sh

set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/opt/backups/database"
S3_BUCKET="s3://ecosire-backups/database"
DB_NAME="ecosire"
DB_USER="app"
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Create backup with compression
echo "Starting backup at $(date)"
pg_dump -h localhost -U "$DB_USER" -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Verify backup integrity
pg_restore --list "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" > /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "ERROR: Backup verification failed"
  exit 1
fi

BACKUP_SIZE=$(du -h "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" | cut -f1)
echo "Backup created: ${BACKUP_SIZE}"

# Upload to S3 with server-side encryption
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "$S3_BUCKET/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256

# Upload to secondary region
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "s3://ecosire-backups-dr/database/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256 \
  --region eu-west-1

# Clean up local backups older than retention period
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete

echo "Backup complete at $(date)"

Backup de arquivos de aplicativos

#!/bin/bash
# Backup application files, uploads, and configuration

TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Backup Odoo filestore
tar czf "/opt/backups/files/filestore_${TIMESTAMP}.tar.gz" /opt/odoo/data/filestore/

# Backup uploaded documents
tar czf "/opt/backups/files/uploads_${TIMESTAMP}.tar.gz" /opt/app/uploads/

# Backup configuration (secrets excluded)
tar czf "/opt/backups/config/config_${TIMESTAMP}.tar.gz" \
  --exclude='*.env*' \
  --exclude='*.pem' \
  /opt/app/infrastructure/

# Upload all to S3
aws s3 sync /opt/backups/ s3://ecosire-backups/ --sse AES256

---

Arquiteturas de failover

Camada 1: Cold Standby (RTO: 4-24 horas)

• Backups armazenados em armazenamento em nuvem
• A recuperação envolve o provisionamento de nova infraestrutura e a restauração do backup
• Opção mais barata: pague apenas pelo armazenamento
• Adequado para aplicações internas não críticas

Camada 2: Warm Standby (RTO: 1-4 horas)

• Servidor standby em execução, mas não recebendo tráfego
• A replicação do banco de dados mantém os dados em espera atualizados
• A recuperação envolve a promoção do modo de espera e atualização do DNS
• Custo moderado: pague pelo servidor standby em tamanho reduzido

Primary (active) ----replication----> Standby (warm)
                                         |
                   On failure: promote + DNS update

Camada 3: Hot Standby (RTO: <30 minutos)

• Configuração ativo-passivo ou ativo-ativo
• Failover automático por meio de verificações de integridade
• Banco de dados com replicação síncrona
• Custo mais alto: pague por infraestrutura duplicada completa

                     Health Check
                         |
Load Balancer ------> Primary (active)
       |
       +-------------> Secondary (hot standby, auto-promote)

Camada 4: Ativo-Ativo Multirregional (RTO: <5 minutos)

• Várias regiões atendem tráfego simultaneamente
• Rotas globais do balanceador de carga por geografia
• Resolução de conflitos de banco de dados para gravações multimestre
• Maior custo e complexidade

Comparação de custos

---

Teste de recuperação

Exercício de recuperação trimestral

A cada trimestre, execute um teste de recuperação completo:

1. Selecione um backup aleatório dos últimos 30 dias
2. Provisionar infraestrutura de recuperação (separado da produção)
3. Restaure o banco de dados do backup
4. Restaurar arquivos de aplicativos do backup
5. Implante o código do aplicativo do Git
6. Execute testes de fumaça no ambiente restaurado
7. Meça o tempo de recuperação real em relação à meta de RTO
8. Documente as descobertas e atualize o plano de DR

Lista de verificação do exercício de recuperação

• [] O banco de dados é restaurado com sucesso a partir do backup
• [] O aplicativo inicia e atende solicitações
• [] A autenticação do usuário funciona
• [] Fluxos de negócios críticos concluídos (fazer pedido, gerar fatura)
• [] Os endpoints de integração respondem (gateway de pagamento, e-mail)
• [] O tempo de recuperação real atende à meta de RTO
• [] A equipe conhece suas funções sem consultar a documentação
• Os canais de comunicação funcionam (como você notifica as partes interessadas?)

---

Manual de resposta a incidentes

Níveis de gravidade

Etapas de resposta SEV1

1. Reconhecer o incidente em 15 minutos
2. Avalie o escopo: o que foi afetado, quantos usuários foram impactados
3. Comunicar às partes interessadas: atualização da página de status, notificação ao cliente
4. Mitigar usando a opção mais rápida disponível (reversão, failover, escalabilidade)
5. Resolver a causa raiz
6. Post-mortem dentro de 48 horas: cronograma, causa raiz, itens de ação

---

Perguntas frequentes

Quanto devemos orçar para recuperação de desastres?

Um orçamento de DR razoável é de 10 a 25% do custo da infraestrutura de produção. Para uma empresa que gasta US$ 500/mês em infraestrutura, faça um orçamento de US$ 50-125/mês para DR. Isso abrange armazenamento de backup em nuvem, um servidor de espera quente e monitoramento. O cálculo do ROI: se sua empresa perder US$ 5.000/hora em tempo de inatividade e a DR reduzir uma interrupção potencial de 24 horas para 4 horas, o investimento em DR economizou US$ 100.000.

Precisamos de DR se usarmos um provedor de nuvem gerenciado?

Sim. Os provedores de nuvem protegem contra falhas de hardware e interrupções no data center, mas não protegem contra bugs de aplicativos, exclusão acidental, ransomware ou comprometimento de contas. Seu plano de DR deve cobrir cenários que o provedor de nuvem não cobre: ​​dados corrompidos, recursos excluídos, violações de segurança e risco de dependência de fornecedor.

Como lidamos com DR em nosso sistema ERP Odoo?

Odoo DR requer três componentes: (1) backups de banco de dados PostgreSQL (automatizados, criptografados, externos), (2) backups de armazenamento de arquivos (anexos carregados, modelos de relatório), (3) código de módulo personalizado (no Git). A recuperação envolve: provisionar um servidor, instalar o Odoo, restaurar o banco de dados, restaurar o armazenamento de arquivos, implantar módulos personalizados. ECOSIRE fornece Odoo DR gerenciado backups automatizados e procedimentos de recuperação testados.

Qual é a falha de DR mais comum?

Backups não testados. Mais de 30% das restaurações de backup falham devido a corrupção, backups incompletos, dependências ausentes ou senhas alteradas. A segunda falha mais comum é a documentação desatualizada: o plano de DR faz referência a servidores, credenciais ou procedimentos que não existem mais. Os testes trimestrais detectam ambos os problemas.

---

O que vem a seguir

A recuperação de desastres é um pilar da resiliência operacional. Combine-o com monitoramento e alertas para detecção precoce, implantações com tempo de inatividade zero para mudanças seguras e fortalecimento de segurança para prevenção de ameaças.

Entre em contato com a ECOSIRE para planejamento e implementação de recuperação de desastres ou explore nosso guia DevOps para obter o roteiro completo de infraestrutura.

---

Publicado pela ECOSIRE – ajudando as empresas a se prepararem para o inevitável.