Runbook: Disaster Recovery

Overview

Propósito: Recuperación del sistema ante fallas catastróficas (pérdida de servidor, corrupción masiva, etc.)

RTO (Recovery Time Objective): 4 horas

RPO (Recovery Point Objective): 24 horas (último backup diario)

Criticidad: 🔴 CRÍTICA - Solo ejecutar en caso de disaster real

Tipos de Desastres

Nivel	Escenario	Acción
L1	Servicio caído (Orchestrator/Sevastopol)	Reiniciar servicio
L2	Corrupción de datos de un tenant	Restore per-schema
L3	Pérdida de base de datos completa	Full database restore
L4	Pérdida de servidor completo	Provisionar nuevo servidor + restore

L1: Servicio Caído

Cuando un servicio individual no responde pero el servidor está accesible.

Verificar estado del servicio
Terminal window
```
pm2 status
```
Revisar logs de errores
Terminal window
```
pm2 logs orchestrator --err --lines 100
```
Reiniciar servicio
Terminal window
```
pm2 restart orchestrator
```
Verificar recuperación
Terminal window
```
curl http://localhost:8000/health
```

Si el reinicio falla repetidamente, escalar a L4.

L2: Corrupción de Tenant Individual

Cuando los datos de un solo tenant están corruptos pero el resto del sistema funciona.

Identificar tenant afectado

SELECT schema_name, last_access, error_count
FROM central.tenant_health
WHERE status = 'corrupted';

Desactivar tenant temporalmente

UPDATE central.tenants
SET active = false
WHERE id = '<TENANT_ID>';

Localizar backup del schema

ls -lht /opt/backups/schemas/ | grep tenant_<ID>

Restaurar schema individual

sudo -u postgres psql -d nostromo -c "DROP SCHEMA tenant_<ID> CASCADE;"
gunzip -c /opt/backups/schemas/tenant_<ID>_<DATE>.sql.gz | sudo -u postgres pg_restore -d nostromo

Reactivar tenant

UPDATE central.tenants
SET active = true
WHERE id = '<TENANT_ID>';

Verificar integridad

SELECT COUNT(*) FROM tenant_<ID>.employees;
SELECT COUNT(*) FROM tenant_<ID>.contracts;

L3: Pérdida de Base de Datos Completa

Cuando se pierde acceso a toda la base de datos PostgreSQL.

Detener todos los servicios
Terminal window
```
pm2 stop all
```

Verificar estado de PostgreSQL

sudo systemctl status postgresql
pg_isready

Si PostgreSQL corrupto, recrear cluster

sudo systemctl stop postgresql
sudo rm -rf /var/lib/postgresql/16/main/*
sudo -u postgres /usr/lib/postgresql/16/bin/initdb -D /var/lib/postgresql/16/main
sudo systemctl start postgresql

Localizar último backup válido

ls -lht /opt/backups/ | head -20
gunzip -t /opt/backups/<LATEST>/backup_<DATE>.sql.gz

Restaurar desde backup

gunzip -c /opt/backups/<LATEST>/backup_<DATE>.sql.gz | sudo -u postgres psql

Verificar restauración

\dn
SELECT COUNT(*) FROM central.tenants;
SELECT COUNT(*) FROM central.users;

Reiniciar servicios
Terminal window
```
pm2 start all
```

Validar sistema completo

curl http://localhost:8000/health
curl http://localhost:4321/

L4: Pérdida de Servidor Completo

Cuando el servidor físico/VM se pierde completamente.

Provisionar nuevo servidor
- Mínimo: 4 vCPU, 8GB RAM, 100GB SSD
- OS: Ubuntu 22.04 LTS o Debian 12
- Acceso SSH configurado

Instalar dependencias base

sudo apt update && sudo apt upgrade -y
sudo apt install -y postgresql-16 nodejs npm nginx certbot

Configurar PostgreSQL

sudo -u postgres createuser nostromo_user
sudo -u postgres createdb nostromo

Descargar backup desde storage remoto

mkdir -p /opt/backups
aws s3 cp s3://nostromo-backups/postgres/backup_<LATEST>.sql.gz /opt/backups/

Restaurar base de datos

gunzip -c /opt/backups/backup_<LATEST>.sql.gz | sudo -u postgres psql

Clonar repositorios

cd /opt/nostromo
git clone [email protected]:org/orchestrator.git
git clone [email protected]:org/sevastopol.git

Configurar variables de entorno

cp .env.production.example .env.production
nano .env.production

Instalar dependencias y build

cd /opt/nostromo/orchestrator && npm ci && npm run build
cd /opt/nostromo/sevastopol && npm ci && npm run build

Configurar PM2

pm2 start dist/server.js --name orchestrator
pm2 start "npm run preview" --name sevastopol --cwd /opt/nostromo/sevastopol
pm2 save

Configurar Nginx y SSL
Terminal window
```
sudo certbot --nginx -d app.nostromo.cl
```
Actualizar DNS

Actualizar registros A en Cloudflare para apuntar a nueva IP.
Validar sistema completo
Terminal window
```
curl https://app.nostromo.cl/health
```

Comunicación Durante Disaster

Notificación Inicial (T+0)

URGENTE: Sistema Nostromo - Incidente en Progreso

Tipo: [L1/L2/L3/L4]
Inicio: [HORA]
Impacto estimado: [DESCRIPCION]
ETA de resolución: [HORA]

Siguiente actualización: [HORA]

Actualizaciones (cada 30 min)

UPDATE: Sistema Nostromo - En Recuperación

Estado: [EN PROGRESO/RESUELTO]
Avance: [PASO ACTUAL]
Nuevo ETA: [HORA]

Cierre de Incidente

RESUELTO: Sistema Nostromo - Servicio Restaurado

Duración total: [X horas]
Datos perdidos: [Ninguno / X horas de transacciones]
Acciones preventivas: [PENDIENTE POST-MORTEM]

Post-Mortem

Después de todo disaster, crear documento post-mortem:

# Post-Mortem: [FECHA] [TIPO]

## Timeline

- HH:MM - Detección
- HH:MM - Inicio respuesta
- HH:MM - Resolución

## Root Cause

[Descripción técnica de la causa raíz]

## Impacto

- Usuarios afectados: X
- Downtime total: X horas
- Datos perdidos: [Ninguno / Descripción]

## Acciones Correctivas

1. [Acción inmediata]
2. [Mejora a mediano plazo]
3. [Mejora estructural]

Checklist de Prevención

Backups diarios ejecutándose (verificar logs)
Backups remotos sincronizados (S3/Azure)
Test de restore mensual completado
Documentación de recovery actualizada
Contactos de emergencia disponibles
Credenciales de cloud storage accesibles

Runbook: Backup - Procedimientos de backup
Runbook: Deploy - Procedimiento de deploy estándar
Infrastructure: Networking - Topología de red
Infrastructure: Docker - Configuración de containers

Changelog

Fecha	Version	Cambios
2026-01-18	1.0	Runbook inicial creado