Backup y Recuperación ante Desastres

Tabla de Contenidos

Propósito
Configuración de Backup de MongoDB Atlas
Procedimientos de Backup Manual
Procedimientos de Restauración
Redundancia de Azure Storage
Escenarios de Recuperación ante Desastres
Procedimientos de Pruebas de Recuperación

Propósito

Este documento describe los procedimientos de backup y recuperación ante desastres para la plataforma Algesta, incluyendo backups automatizados de MongoDB Atlas, procedimientos de backup manual, operaciones de restauración y escenarios de recuperación ante desastres.

Configuración de Backup de MongoDB Atlas

Configuración de Terraform (desde modules/Base de datos/MongoDB/main.tf:23):

resource "mongodbatlas_cluster" "cluster" {
  cloud_backup                 = true
  auto_scaling_disk_gb_enabled = true
  mongo_db_major_version       = "7.0"
  provider_instance_size_name  = "M0"  # Free tier
}

Funcionalidades de Backup (M0 Free Tier):

Snapshots Automatizados: Snapshots diarios
Retención: 2 días (limitación del tier gratuito)
Restauración Point-in-Time: No disponible en M0 (requiere M10+)
Almacenamiento: Incluido en el tier gratuito

Recomendaciones para Producción:

Actualizar a M10+ para:
- Backup continuo (restauración point-in-time a cualquier segundo en los últimos 7 días)
- Calendarios de backup personalizados
- Periodos de retención más largos (7-90 días)
- Pruebas de restauración automatizadas
Configurar Calendario de Backup:

resource "mongodbatlas_cloud_backup_schedule" "backup_schedule" {
  project_id   = var.project_id
  cluster_name = mongodbatlas_cluster.cluster.name

  reference_hour_of_day    = 3  # 3 AM UTC
  reference_minute_of_hour = 0
  restore_window_days      = 7

  policy_item_hourly {
    frequency_interval = 6  # Every 6 hours
    retention_unit     = "days"
    retention_value    = 2
  }

  policy_item_daily {
    frequency_interval = 1  # Daily
    retention_unit     = "days"
    retention_value    = 7
  }

  policy_item_weekly {
    frequency_interval = 1  # Weekly (Sunday)
    retention_unit     = "weeks"
    retention_value    = 4
  }

  policy_item_monthly {
    frequency_interval = 1  # Monthly
    retention_unit     = "months"
    retention_value    = 12
  }
}

Visualización de Backups en Atlas:

Iniciar sesión en MongoDB Atlas: https://cloud.mongodb.com
Navegar a Project → Clusters → [Nombre del Cluster] → Backup
Ver snapshots disponibles y puntos de restauración

Procedimientos de Backup Manual

mongodump (Backup Manual)

Backup Completo de Base de datos:

# Set MongoDB URI (from Kubernetes secret or Azure Key Vault)
MONGODB_URI="mongodb+srv://admin:SecurePassword@cluster.mongodb.net/algesta?retryWrites=true&w=majority"

# Backup all databases
mongodump --uri="$MONGODB_URI" \
  --out=/backups/algesta-$(date +%Y%m%d-%H%M%S) \
  --gzip

# Backup specific database
mongodump --uri="$MONGODB_URI" \
  --db=orders_db \
  --out=/backups/orders-$(date +%Y%m%d-%H%M%S) \
  --gzip

Subir a Azure Storage:

# Install Azure CLI if not available
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Authenticate
az login

# Upload backup to Azure Storage
az storage blob upload-batch \
  --account-name storagealgestaproduction \
  --destination data \
  --source /backups/algesta-20251120-100000 \
  --pattern "*"

Script de Backup Automatizado (backup.sh):

#!/bin/bash
set -e

# Configuration
MONGODB_URI=$(kubectl get secret mongodb-credentials -n production -o jsonpath='{.data.uri}' | base64 -d)
BACKUP_DIR="/tmp/backups"
BACKUP_NAME="algesta-$(date +%Y%m%d-%H%M%S)"
AZURE_STORAGE_ACCOUNT="storagealgestaproduction"
AZURE_CONTAINER="data"

# Create backup directory
mkdir -p $BACKUP_DIR

# Run mongodump
echo "Starting backup: $BACKUP_NAME"
mongodump --uri="$MONGODB_URI" \
  --out=$BACKUP_DIR/$BACKUP_NAME \
  --gzip

# Upload to Azure Storage
echo "Uploading to Azure Storage..."
az storage blob upload-batch \
  --account-name $AZURE_STORAGE_ACCOUNT \
  --destination $AZURE_CONTAINER \
  --source $BACKUP_DIR/$BACKUP_NAME \
  --pattern "*"

# Cleanup local backup
rm -rf $BACKUP_DIR/$BACKUP_NAME

echo "Backup completed: $BACKUP_NAME"

Programar con Kubernetes CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mongodb-backup
  namespace: production
spec:
  schedule: "0 3 * * *" # Daily at 3 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: mongo:7.0
              command: ["/bin/sh", "-c"]
              args:
                - |
                  apt-get update && apt-get install -y azure-cli
                  /backup.sh
              env:
                - name: MONGODB_URI
                  valueFrom:
                    secretKeyRef:
                      name: mongodb-credentials
                      key: uri
              volumeMounts:
                - name: backup-script
                  mountPath: /backup.sh
                  subPath: backup.sh
          volumes:
            - name: backup-script
              configMap:
                name: backup-script
                defaultMode: 0755
          restartPolicy: OnFailure

Procedimientos de Restauración

Restaurar desde Snapshot de MongoDB Atlas

Vía Interfaz de Atlas:

Iniciar sesión en MongoDB Atlas
Navegar a Cluster → Backup → Snapshots
Seleccionar snapshot → Restore
Elegir opción de restauración:
- Restauración automatizada: Restaura al mismo cluster (sobrescribe datos)
- Restauración point-in-time: Seleccionar timestamp específico (solo M10+)
- Descargar: Descargar snapshot para restauración manual
Confirmar restauración (requiere tiempo de inactividad del cluster)

Tiempo de Inactividad Estimado:

Clusters M0/M2: 10-15 minutos
Clusters M10+: 5-10 minutos

Restaurar desde Backup de mongodump

Descargar Backup desde Azure Storage:

# List available backups
az storage blob list \
  --account-name storagealgestaproduction \
  --container-name data \
  --output table

# Download specific backup
az storage blob download-batch \
  --account-name storagealgestaproduction \
  --source data \
  --destination /tmp/restore \
  --pattern "algesta-20251120-100000/*"

Restaurar a MongoDB:

# Restore full database
mongorestore --uri="$MONGODB_URI" \
  --gzip \
  --dir=/tmp/restore/algesta-20251120-100000

# Restore specific database
mongorestore --uri="$MONGODB_URI" \
  --db=orders_db \
  --gzip \
  --dir=/tmp/restore/algesta-20251120-100000/orders_db

# Restore with drop (replaces existing data)
mongorestore --uri="$MONGODB_URI" \
  --drop \
  --gzip \
  --dir=/tmp/restore/algesta-20251120-100000

Verificación:

# Connect to MongoDB and verify data
mongosh "$MONGODB_URI" --eval "db.orders.countDocuments()"

# Check specific collection
mongosh "$MONGODB_URI" --eval "db.orders.find().limit(5)"

Redundancia de Azure Storage

Configuración Actual:

Storage Account: storagealgestaproduction
Replicación: LRS (Locally Redundant Storage) - 3 copias en un solo datacenter
Contenedores:
- tf-state: Archivos de estado de Terraform
- data: Datos de aplicación, backups

Recomendaciones para Producción:

Actualizar a GRS (Geo-Redundant Storage):

az storage account update \
  --name storagealgestaproduction \
  --resource-group rg-algesta-production \
  --sku Standard_GRS

Beneficios de GRS:

6 copias totales (3 en región primaria, 3 en región secundaria)
Protege contra desastres regionales
99.99999999999999% (16 nueves) de durabilidad

Habilitar Versionado de Blobs (para protección contra eliminación accidental):

az storage account blob-service-properties update \
  --account-name storagealgestaproduction \
  --enable-versioning true

Configurar Gestión del Ciclo de Vida (auto-eliminar backups antiguos):

{
  "rules": [
    {
      "enabled": true,
      "name": "delete-old-backups",
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["data/algesta-"]
        },
        "actions": {
          "baseBlob": {
            "delete": {
              "daysAfterModificationGreaterThan": 90
            }
          }
        }
      }
    }
  ]
}

Escenarios de Recuperación ante Desastres

Escenario 1: Eliminación Accidental de Datos

Impacto: Usuario elimina accidentalmente datos críticos (ej., todas las órdenes)

Pasos de Recuperación:

Detener todas las escrituras para prevenir sobrescritura de backups
Ventana de terminal
```
kubectl scale deployment/api-gateway-production --replicas=0 -n production
```
Identificar punto de restauración
- Verificar snapshots de MongoDB Atlas (últimos 2 días)
- O usar backup manual desde Azure Storage
Restaurar datos (ver Procedimientos de Restauración)

Verificar integridad de datos

mongosh "$MONGODB_URI" --eval "db.orders.countDocuments()"

Reanudar Operaciones

kubectl scale deployment/api-gateway-production --replicas=2 -n production

Prevención:

Implementar eliminaciones lógicas (marcar como eliminado, no eliminar realmente)
Requerir rol de administrador para operaciones destructivas
Habilitar restauración point-in-time de MongoDB Atlas (M10+)

Escenario 2: Falla Completa del Cluster de Base de datos

Impacto: Cluster de MongoDB Atlas se vuelve no disponible

Pasos de Recuperación:

Verificar Estado de MongoDB Atlas:
- https://status.mongodb.com
- MongoDB Atlas Console → Cluster Health
Si el cluster está corrupto:
- Crear nuevo cluster en MongoDB Atlas
- Restaurar desde último snapshot o backup manual

Actualizar cadena de conexión en Kubernetes:

kubectl create secret generic mongodb-credentials \
  --from-literal=uri="<new-cluster-uri>" \
  --namespace=production \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl rollout restart deployment -n production

Verificar conectividad:

kubectl logs -l app=api-gateway -n production | grep "MongoDB connected"

RTO (Objetivo de Tiempo de Recuperación): 30-60 minutos RPO (Objetivo de Punto de Recuperación): Hasta 24 horas (backups diarios)

Mejora: Actualizar a M10+ para backup continuo (RPO: < 1 minuto)

Escenario 3: Falla del Cluster AKS (Interrupción Regional)

Impacto: Región Azure East US no disponible, cluster AKS caído

Pasos de Recuperación:

Crear nuevo cluster AKS en región secundaria (ej., West US):

cd ops-algesta/infrastructure/envs/production/Azure
# Update variables.tf: location = "West US"
terraform apply

Desplegar aplicaciones al nuevo cluster:

az aks get-credentials --resource-group rg-algesta-production-west --name aks-algesta-production-west
kubectl apply -f ops-algesta/resources-k8s/

Actualizar DNS para apuntar al nuevo ingress:

# Get new ingress IP
kubectl get ingress ingress-production -n production

# Update DNS A record: algesta-api-prod.3astronautas.com → <new-ip>

Verificar servicios:

curl https://algesta-api-prod.3astronautas.com/health

RTO: 2-4 horas (aprovisionamiento manual) RPO: 0 (MongoDB Atlas no afectado por interrupción de AKS)

Mejora: Despliegue multi-región de AKS con Azure Traffic Manager

Procedimientos de Prueba de Recuperación

Procedimiento Trimestral de Prueba de DR:

Anunciar ventana de prueba (ej., Sábado 2 AM - 6 AM)

Crear base de datos de prueba de MongoDB:

mongorestore --uri="$TEST_MONGODB_URI" --db=orders_test --dir=/backups/latest

Probar tiempo de restauración:

time mongorestore --uri="$TEST_MONGODB_URI" --drop --dir=/backups/latest

Verificar integridad de datos:

mongosh "$TEST_MONGODB_URI" --eval "db.orders.countDocuments()"

Documentar resultados:
- Duración de restauración
- Completitud de datos
- Problemas encontrados
Actualizar runbooks basado en hallazgos

Calendario de Pruebas:

Prueba completa de DR: Trimestral
Verificación de backup: Mensual
Prueba de tiempo de restauración: Mensual

Documentación Relacionada:

Infrastructure as Code: Configuración de MongoDB Atlas
Runbooks: Procedimientos paso a paso de restauración
Incident Response: Escalación para incidentes de pérdida de datos

Para Soporte:

MongoDB Atlas: https://cloud.mongodb.com → Support
Azure Storage: Azure Portal → Storage Accounts
Contactos de emergencia: Equipo DevOps, administradores de base de datos