¿Qué pasaría si mañana tu servidor principal se muere? ¿O si un ransomware cifra todos tus archivos? ¿O si un incendio destruye tu oficina? La mayoría de las empresas no tienen respuesta a estas preguntas — no porque no les importe, sino porque asumen que "eso no nos va a pasar". Hasta que pasa.
Un plan de continuidad de negocio no es un documento que creas para cumplir un requisito y guardas en un cajón. Es la diferencia entre recuperarte en horas y cerrar en semanas. Esta guía te lleva paso a paso por la creación de un plan práctico y realista — sin la burocracia excesiva de los frameworks enterprise, pero con la rigurosidad que tu negocio necesita.
Por qué necesitas un plan (los números)
Las estadísticas son contundentes:
- El 40% de las PyMEs que sufren un desastre mayor y no tienen plan de recuperación nunca reabren
- El 93% de las empresas que pierden acceso a sus datos por más de 10 días quiebran dentro de un año
- El costo promedio de downtime para una PyME es de $8,000-$25,000 MXN por hora (según la industria)
- El 60% de las empresas que sufren un ciberataque severo cierran en los 6 meses siguientes
No son estadísticas para asustar — son la realidad que justifica la inversión en continuidad.
Los conceptos clave
Antes de crear el plan, entiende estos términos que van a aparecer en todo el proceso:
RTO (Recovery Time Objective)
¿Cuánto tiempo puedes estar sin el sistema? Es el tiempo máximo aceptable de interrupción antes de que el impacto sea inaceptable.
Ejemplos:
- ERP de una distribuidora: RTO = 4 horas (después de eso no puedes facturar ni surtir pedidos)
- Sitio web informativo: RTO = 24 horas (molesto pero no paraliza la operación)
- Sistema de punto de venta en retail: RTO = 1 hora (cada minuto sin POS es venta perdida)
RPO (Recovery Point Objective)
¿Cuántos datos puedes perder? Es la cantidad máxima de datos que puedes permitirte perder, medida en tiempo.
Ejemplos:
- RPO = 0 (cero pérdida): Necesitas replicación en tiempo real
- RPO = 1 hora: Backups cada hora o WAL archiving continuo
- RPO = 24 horas: Backup diario nocturno es suficiente
Impacto al negocio (BIA)
¿Qué pasa cuando cada sistema se detiene? ¿Cuánto dinero pierdes por hora? ¿Qué procesos se paralizan? El BIA cuantifica el impacto de cada interrupción para priorizar la recuperación.
Paso 1: Análisis de impacto al negocio (BIA)
El BIA es el fundamento de todo el plan. Identifica tus sistemas críticos y cuantifica el impacto de perder cada uno:
| Sistema | Procesos que afecta | Impacto por hora de interrupción | RTO | RPO |
|---|---|---|---|---|
| ERP | Ventas, facturación, compras, inventario, finanzas | $15,000 MXN (ventas perdidas + ineficiencia) | 4 horas | 1 hora |
| Base de datos | Todo lo que depende del ERP | $15,000 MXN (igual que ERP — es su motor) | 2 horas | 0 (replicación) |
| Correo electrónico | Comunicación interna y externa | $3,000 MXN (retrasos en comunicación) | 8 horas | 24 horas |
| E-commerce | Ventas en línea | $8,000 MXN (ventas perdidas) | 2 horas | 1 hora |
| WMS | Operación de almacén | $10,000 MXN (pedidos detenidos) | 4 horas | 1 hora |
| Telefonía | Atención a clientes | $2,000 MXN | 4 horas | N/A |
| Red / internet | Todo | $20,000 MXN (toda la operación se detiene) | 1 hora | N/A |
Este ejercicio te dice dos cosas: qué sistemas recuperar primero (los de mayor impacto y menor RTO) y cuánto invertir en protección (el costo de protección debe ser menor que el costo de la interrupción).
Paso 2: Análisis de riesgos
Identifica las amenazas que podrían interrumpir tu operación y la probabilidad de que ocurran:
Riesgos de infraestructura
- Fallo de hardware — disco duro, fuente de poder, memoria. Probabilidad: alta (es cuestión de cuándo, no si). Mitigación: RAID, servidores redundantes, contratos de soporte con reemplazo de partes.
- Fallo de red/internet — proveedor de internet caído, switch dañado, fibra cortada. Mitigación: doble enlace de internet con diferentes proveedores, red redundante.
- Corte de energía — fallo eléctrico prolongado. Mitigación: UPS para 30-60 minutos, planta de emergencia para horas.
Riesgos de seguridad
- Ransomware — cifrado de datos. Probabilidad: media-alta (es la amenaza #1 en México). Mitigación: backups aislados, hardening, capacitación anti-phishing, ciberseguridad.
- Acceso no autorizado — intruso externo o interno. Mitigación: firewall, segmentación de red, auditoría de accesos.
- Error humano — borrado accidental de datos, configuración incorrecta. Mitigación: backups frecuentes, snapshots de VMs en Proxmox, control de cambios.
Riesgos ambientales
- Desastre natural — sismo, inundación, incendio. Probabilidad: baja pero impacto catastrófico. Mitigación: backup offsite (otra ciudad/cloud), seguro de equipo.
- Robo de equipo — especialmente en zonas de riesgo. Mitigación: seguridad física, cifrado de discos, backup offsite.
Paso 3: Estrategias de protección
Basado en el BIA y el análisis de riesgos, define las medidas de protección para cada nivel de criticidad:
Nivel 1: Backup y restauración (básico)
Protege contra: Fallo de hardware, error humano, corrupción de datos. RTO: 4-24 horas. RPO: 1-24 horas.
Implementación:
- Backup diario automatizado de bases de datos y archivos
- Respaldos incrementales con rsync para archivos
- Copia offsite (otro servidor o cloud) siguiendo la regla 3-2-1
- Pruebas de restauración trimestrales documentadas
- Documentación de procedimiento de restauración paso a paso
Costo aproximado para PyME: $5,000-$15,000 MXN/mes (almacenamiento offsite + herramientas).
Nivel 2: Alta disponibilidad local (intermedio)
Protege contra: Fallo de servidor individual, fallo de disco, fallo de red. RTO: 30 minutos - 4 horas. RPO: 0 - 1 hora.
Implementación:
- Servidores con RAID para tolerancia a fallo de disco
- Replicación de PostgreSQL para alta disponibilidad de base de datos
- Cluster de Proxmox con migración automática de VMs si un nodo falla
- Doble enlace de internet con failover automático
- UPS y planta de emergencia
- Monitoreo 24/7 con alertas proactivas
Costo aproximado para PyME: $15,000-$50,000 MXN/mes (hardware redundante + monitoreo + soporte).
Nivel 3: Sitio alterno / disaster recovery (avanzado)
Protege contra: Desastre que destruye el sitio principal completo. RTO: 1-4 horas. RPO: 0 - 15 minutos.
Implementación:
- Réplica completa de la infraestructura crítica en otro sitio (físico o cloud)
- Replicación continua de bases de datos al sitio alterno
- Procedimiento documentado de activación del sitio alterno (runbook)
- VPN site-to-site entre sitio principal y alterno
- Prueba de failover completo al menos una vez al año
Costo aproximado para PyME: $30,000-$100,000 MXN/mes (infraestructura duplicada + conectividad + administración).
Paso 4: Documentar el plan
El plan de continuidad es un documento vivo que debe incluir:
Información de contacto
Lista de contacto de emergencia con nombres, teléfonos personales (no solo de oficina) y roles:
| Rol | Nombre | Teléfono | Email personal |
|---|---|---|---|
| Líder del plan | Director de TI | +52 1 444 XXX XXXX | personal@email.com |
| Respaldo del líder | Gerente de operaciones | +52 1 444 XXX XXXX | personal@email.com |
| Proveedor de soporte | Syswork México | +52 1 444 XXX XXXX | emergencias@syswork.com |
| Proveedor de internet | ISP principal | 01 800 XXX XXXX | — |
| Proveedor cloud | AWS Support | — | support@aws.com |
Procedimientos de recuperación (runbooks)
Un runbook por cada sistema crítico con pasos exactos que cualquier persona técnica pueda seguir — no solo "restaurar el backup" sino:
RUNBOOK: Recuperación del servidor ERP
Tiempo estimado: 2-4 horas
Requisitos: Acceso SSH al servidor de backup, credenciales (ver bóveda de contraseñas)
1. Verificar que el servidor principal está realmente caído
- Intentar conexión SSH: ssh deploy@10.0.1.10
- Verificar desde panel de Proxmox: https://10.0.1.100:8006
- Si está caído → continuar. Si responde → investigar el servicio específico.
2. Activar el servidor de respaldo
- SSH al servidor de backup: ssh deploy@10.0.1.11
- Promover la réplica de PostgreSQL:
sudo -u postgres pg_ctlcluster 16 main promote
- Verificar que acepta escrituras:
sudo -u postgres psql -c "INSERT INTO test VALUES (1);"
3. Redirigir el tráfico
- Actualizar DNS en Cloudflare: erp.empresa.com → 10.0.1.11
- O actualizar el upstream en Nginx/Traefik
4. Verificar la aplicación
- Acceder a https://erp.empresa.com
- Probar: login, consultar inventario, crear un pedido de prueba
- Verificar integraciones: facturación, WMS, reportes
5. Notificar
- Informar al equipo que el ERP está operando desde el servidor de respaldo
- Notificar al proveedor de soporte para que investigue el servidor principal
6. Documentar
- Registrar hora de incidente, hora de detección, hora de recuperación
- Registrar acciones tomadas y resultado
Inventario de infraestructura
Documento separado (o sección del plan) con toda la información técnica:
- Diagrama de red actualizado
- IPs, puertos y servicios de cada servidor
- Ubicación de backups (local y offsite)
- Credenciales en bóveda segura (Bitwarden, 1Password, KeePass)
- Licencias de software con números y fechas de vencimiento
- Contratos de proveedores con vigencias y contactos
Paso 5: Probar el plan
Un plan que no se prueba es una hipótesis — no una garantía. Define un calendario de pruebas:
| Prueba | Frecuencia | Qué se prueba |
|---|---|---|
| Restauración de backup | Trimestral | Restaurar el backup más reciente de la base de datos en un servidor de prueba y verificar integridad |
| Failover de base de datos | Semestral | Promover la réplica a primario y verificar que la aplicación funciona |
| Failover de servidor | Anual | Apagar el servidor principal y verificar que el respaldo toma el control |
| Activación de sitio alterno | Anual | Simular pérdida del sitio principal y operar desde el alterno |
| Simulacro completo | Anual | Simular un escenario de desastre con todo el equipo involucrado |
Documentar cada prueba
Cada prueba genera un reporte con:
- Fecha y hora de la prueba
- Escenario simulado
- Pasos ejecutados
- Resultado (exitoso / fallido / parcial)
- Tiempo de recuperación real vs. RTO objetivo
- Problemas encontrados y acciones correctivas
- Firma del responsable
Estos reportes son tu evidencia ante auditorías y ante tu propia dirección de que el plan funciona.
Paso 6: Mantener el plan vivo
El plan de continuidad caduca cada vez que algo cambia en tu infraestructura. Establece estas reglas:
- Revisión completa anual — actualizar todo el documento con la infraestructura actual
- Actualización por cambio — cada vez que se agrega un servidor, se migra un sistema o se cambia un proveedor, actualizar la sección correspondiente
- Revisión post-incidente — después de cada incidente real (haya activado el plan o no), revisar si el plan cubría ese escenario y ajustar si no
- Dueño del plan — una persona específica es responsable de mantenerlo actualizado. Si no tiene dueño, se vuelve obsoleto en 6 meses
El error más costoso: no tener plan
Crear un plan de continuidad cuesta tiempo y dinero. No crearlo cuesta mucho más — en el momento exacto en que menos puedes pagarlo. Las empresas que tienen plan se recuperan en horas. Las que no lo tienen se recuperan en días o semanas — si se recuperan.
La pregunta no es "¿nos va a pasar algo?" sino "¿estamos preparados cuando pase?"
Protege tu operación
¿Tu empresa sobreviviría un día sin sus sistemas?
Te ayudamos a crear tu plan de continuidad con análisis de impacto, estrategias de protección, runbooks y pruebas de validación.
