Plan de recuperación ante desastres para pymes: tu DRP en una página
TL;DR
- El DRP no es para grandes empresas: una pyme sin plan puede estar semanas recuperándose de un incidente que con plan se resuelve en horas.
- RPO y RTO son decisiones de negocio, no técnicas: el gerente tiene que definir cuántos datos puede perder y cuánto tiempo puede estar parado.
- El plan que no se prueba no existe: una restauración fallida en pleno incidente es el peor momento para descubrir que el backup no funciona.
- El documento tiene que ser accesible sin internet: si está solo en Drive y el servidor está caído, no sirve.
- El escenario más probable no es el incendio: es el ransomware el viernes por la tarde o el disco duro del servidor que falla.
La mayoría de pymes no tienen un plan de recuperación ante desastres porque asumen que es algo para grandes empresas con equipos IT dedicados y presupuestos millonarios. Es un error que tiene consecuencias directas cuando ocurre el primer incidente serio. Un ransomware que cifra los servidores un viernes por la tarde, un incendio en el rack del proveedor de hosting o simplemente el disco duro del servidor de la oficina que falla sin aviso pueden paralizar completamente un negocio durante días o semanas. Un DRP útil no tiene que ser un documento de 80 páginas: puede caber en una hoja de papel impresa que alguien pueda ejecutar bajo presión sin necesidad de pensar demasiado.
1. RPO y RTO: las dos preguntas que definen todo lo demás
Antes de escribir una sola línea del plan, el gerente o propietario tiene que responder dos preguntas. No el técnico: el negocio.
- RPO (Recovery Point Objective): ¿cuántos datos puedes permitirte perder? Si el último backup es de hace 24 horas y ocurre algo a las 23:59, pierdes un día completo de trabajo. ¿Es asumible para tu negocio? Si pierdes los pedidos de un día en una tienda online, ¿puedes recuperarlos por otra vía? Si no puedes, necesitas backups más frecuentes, idealmente cada hora o en tiempo cuasi-real.
- RTO (Recovery Time Objective): ¿cuánto tiempo puede estar tu negocio sin los sistemas críticos? Si la respuesta es "4 horas", tu plan de recuperación tiene que garantizar que en 4 horas estás operativo. Si el proceso de restauración tarda 12 horas, tienes un gap que hay que cerrar antes de que ocurra el desastre, no durante.
Una empresa de gestión inmobiliaria de 8 personas en Alicante sufrió un ataque de ransomware en noviembre de 2024. Sin plan de recuperación definido, tardaron 11 días en estar completamente operativos. La pérdida de productividad, el coste del técnico de recuperación y los clientes perdidos durante el período se estimaron en más de 25.000 euros. Con un RTO definido de 4 horas y la infraestructura de backup correspondiente, el mismo incidente habría tenido un impacto económico de menos del 10% de esa cifra.
2. Mapa de sistemas críticos: no todo es igual de urgente
Haz una lista de los sistemas y datos que necesita tu empresa para operar y ordénalos por criticidad. Tres categorías es suficiente para empezar:
- Crítico (sin esto no puedes facturar ni atender clientes): ERP o software de gestión, base de datos de clientes, correo corporativo, sistema de facturación, acceso a banca online. Estos tienen que ser los primeros en restaurarse, siempre.
- Importante (necesario en 24-48h): servidor de ficheros con documentación activa, herramientas de comunicación interna, sistemas de RRHH. Puedes operar sin ellos unas horas pero no días.
- El resto: sistemas de informes históricos, archivos de proyectos finalizados, herramientas no críticas. Pueden esperar hasta que lo crítico y lo importante estén recuperados.
El plan de recuperación se ejecuta en ese orden. Si intentas recuperarlo todo a la vez con los mismos recursos, no recuperas nada a tiempo. Este mapa de criticidad también determina qué datos necesitan backups más frecuentes (los críticos) y cuáles pueden tener retención más espaciada.
3. Contactos de emergencia y accesos documentados: el núcleo del plan
El plan tiene que incluir los números y correos de contacto de las personas y servicios que pueden actuar en una emergencia. Mínimo:
- Proveedor IT o MSP: teléfono de guardia (no solo el correo que puede estar caído).
- Proveedor de servidores o hosting: teléfono de soporte de emergencia 24/7.
- Proveedor de backups: acceso al panel de restauración y credenciales.
- Responsable técnico interno: quién tiene autorización para tomar decisiones en ausencia del gerente.
- Proveedor de internet: número de averías y número de cuenta para identificarse rápido.
También documenta los accesos necesarios para la restauración: URL del panel de backups, referencia del servidor o contrato en el proveedor de hosting, sistemas de autenticación necesarios. Con referencia al gestor de contraseñas del equipo, no en texto plano en el documento del DRP. Y el documento tiene que estar disponible sin internet: imprimirlo, guardarlo en el móvil de las personas clave y mantener una copia en una ubicación física fuera de la oficina.
El servicio de gestión de servidores y backups de NetGoos incluye un número de guardia 24/7 para incidentes críticos que forma parte del DRP de todas las empresas bajo mantenimiento gestionado.
4. Escenarios y pasos de recuperación
Define los pasos concretos para los dos o tres escenarios más probables en tu caso. No hace falta contemplar todos los desastres posibles, solo los que tienen mayor probabilidad dado tu tipo de infraestructura:
Escenario ransomware: 1) Aislar los equipos afectados de la red (desconectar el cable de red o desactivar el WiFi). 2) Llamar al proveedor IT. 3) No pagar el rescate sin consultar con el proveedor. 4) Acceder al panel de backups desde un equipo no infectado. 5) Iniciar la restauración desde el último backup anterior al ataque. 6) Verificar que los sistemas restaurados no tienen el ransomware antes de reconectarlos a la red. 7) Reportar el incidente al INCIBE (017).
Escenario fallo de servidor: 1) Verificar si es un fallo de hardware (disco, RAM, fuente de alimentación) o de software. 2) Contactar con el proveedor de hosting si es un servidor dedicado en datacenter. 3) Acceder al panel de backups y evaluar la última copia disponible. 4) Iniciar la restauración en el mismo servidor (si el hardware está disponible) o en un servidor de sustitución.
5. La prueba de restauración: el paso que casi nadie hace
Un plan que nunca se prueba es papel mojado. Y los backups que nunca se restauran pueden tener problemas que nadie ha descubierto todavía: ficheros corruptos, backups que terminan con error silencioso, procesos de restauración que tardan tres veces más de lo previsto.
Programa una prueba de restauración real al menos una vez al año, preferentemente dos veces: restaura un sistema desde el backup en un entorno de pruebas separado y verifica que el resultado es funcional. El entorno de pruebas puede ser una máquina virtual levantada para la ocasión, no necesita ser infraestructura dedicada. Documenta cuánto tiempo tardó la restauración real: ese es tu RTO real, no el estimado.
La prueba de restauración también sirve para verificar que los backups son consistentes. Un backup de base de datos que nunca se ha restaurado puede estar generando copias incompletas durante meses sin que nadie lo detecte. Cuando lo necesitas de verdad es cuando descubres que los últimos 6 meses de datos no son recuperables.
6. Comunicación durante la crisis: lo que el equipo necesita saber
El DRP debe incluir un protocolo de comunicación para cuando ocurre el incidente. ¿A quién se avisa primero internamente? ¿Cómo se comunica a los clientes si el tiempo de resolución supera X horas? ¿Hay mensajes preparados para la web o las redes sociales si la incidencia es visible externamente?
En empresas pequeñas, la comunicación durante una crisis suele manejarse bien de forma informal. El problema es cuando el gerente está de vacaciones y nadie sabe si tiene que llamarle, cuándo llamarle y qué puede decidir sin él. El DRP debe especificar el árbol de decisión y quién tiene autorización para qué tipo de decisiones (gastar hasta X euros en recuperación sin aprobación previa, comunicar a clientes, etc.).
Consulta nuestro artículo sobre monitorización 24/7 y métricas clave para pymes para ver cómo configurar alertas que detecten los problemas antes de que escalen a incidentes que activan el DRP.
Comparativa de escenarios: tiempo de recuperación con y sin DRP
| Escenario | Sin DRP | Con DRP + backups correctos | Diferencia económica estimada |
|---|---|---|---|
| Ransomware servidor | 5-15 días | 4-24 horas | 15.000-40.000 € |
| Fallo disco servidor | 2-5 días | 2-8 horas | 3.000-10.000 € |
| Caída proveedor hosting | Variable (1-7 días) | 2-4 horas (con backup en otro proveedor) | 2.000-8.000 € |
| Corte eléctrico prolongado | Duración del corte + 2-4h | Trabajo en cloud durante el corte | 1.000-5.000 € |
Por dónde empezar mañana
- Reúnete con el gerente durante 30 minutos para definir el RPO y RTO del negocio. Pregunta: "Si el servidor cae ahora, ¿cuándo tiene que estar todo funcionando como máximo?" La respuesta define qué infraestructura de backup necesitas.
- Lista los tres sistemas más críticos y verifica que tienen backup reciente funcionando. Intenta restaurar un fichero de cada uno para confirmar que el proceso funciona.
- Crea un documento de una página con los contactos de emergencia (proveedor IT, hosting, backups) y los tres primeros pasos en caso de ransomware. Imprímelo y guárdalo en la oficina y en el móvil del gerente.
- Programa una prueba de restauración completa para el próximo trimestre. Bloquea la fecha en el calendario ahora, no cuando te acuerdes.
Si necesitas revisar si tu infraestructura de backups actual cumple los objetivos de RPO y RTO que tu negocio necesita, la auditoría informática incluye la evaluación del sistema de backups con una prueba de restauración real y el informe de gaps.
Preguntas frecuentes
¿Cuánto tiempo lleva crear un plan de recuperación ante desastres para una pyme?
Un DRP básico útil para una pyme de hasta 20 personas lleva entre 4 y 8 horas de trabajo real: identificar los sistemas críticos, definir RPO y RTO con el gerente, documentar los contactos de emergencia y escribir los pasos de los dos o tres escenarios más probables.
¿Cuál es la diferencia entre RPO y RTO?
RPO es cuántos datos puedes permitirte perder. RTO es cuánto tiempo puede estar tu empresa sin los sistemas críticos. Son decisiones de negocio que el gerente debe responder, no el técnico.
¿Con qué frecuencia hay que actualizar el plan de recuperación?
Mínimo una vez al año, y siempre que haya cambios significativos en la infraestructura: cambio de proveedor de hosting, nuevos sistemas críticos, cambio de proveedor de backups, o cualquier incidente real que haya revelado fallos en el plan.
¿El DRP es lo mismo que el plan de continuidad de negocio?
No exactamente. El DRP se centra en recuperar los sistemas IT. El BCP es más amplio: cómo la empresa sigue operando durante la recuperación, qué procesos se hacen manualmente, cómo se comunica con clientes. Para pymes, un BCP simplificado puede incluir ambos en el mismo documento.
¿El ransomware cubre el seguro de ciberriesgo?
Depende de la póliza. Algunos cubren los costes de recuperación, pero muchos tienen cláusulas que excluyen la cobertura si la empresa no tenía medidas básicas de seguridad implantadas, incluyendo backups recientes y MFA activo.
¿Qué hago si el plan de recuperación está guardado solo en el servidor que ha caído?
Eso invalida el plan. El DRP debe estar disponible sin depender de la infraestructura que puede estar caída: impreso, en un gestor de contraseñas accesible desde el móvil, en múltiples copias en ubicaciones independientes.
¿Cuánto cuesta implementar un plan de recuperación ante desastres?
El plan en sí no tiene coste de licencia. Lo que tiene coste es la infraestructura de backup que lo soporta. Una infraestructura adecuada para una pyme de 10-20 personas puede costar entre 50 y 200 euros al mes según el volumen de datos y los requisitos de RPO/RTO.