Backup SCADA y Plan de Recuperación ante Desastres en la Industria: Guía Práctica

Keywords secundarias: backup sistemas scada, plan recuperación desastres industrial, disaster recovery ot, copias seguridad scada hmi, backup plc programa, continuidad negocio planta industrial, restaurar scada tras ciberataque Fecha: 2026-09-15 Autor: Carlos @ automatizatodo.com Categoría: Ciberseguridad Industrial / Continuidad de Negocio

---

Tu planta lleva funcionando sin paradas graves desde hace años. Los programas de PLC están en producción, el SCADA corre sobre un servidor que nadie toca “porque funciona” y la última vez que alguien hizo una copia de seguridad fue… bueno, nadie lo recuerda exactamente. Suena familiar, ¿verdad?

Ahora imagina un ransomware que cifra el servidor SCADA un viernes por la noche. O una actualización de firmware que corrompe la configuración de tres PLCs. O un fallo de disco duro en el historiador que almacena los datos de proceso de los últimos cinco años. Sin un plan de backup SCADA y recuperación ante desastres, la pregunta no es si vas a tener un problema — es cuánto te va a costar cuando lo tengas.

En esta guía voy a explicarte cómo montar un plan de backup y recuperación ante desastres para entornos SCADA industriales que funcione en la vida real. No teoría de consultoría: pasos concretos, herramientas reales y una estructura que puedes implementar esta semana.

Por qué el backup en entornos SCADA no es como el backup en IT

Si vienes del mundo IT, estás acostumbrado a respaldar servidores, bases de datos y ficheros. Tienes Veeam, rsync, snapshots de VM y un NAS que se replica en la nube. El backup SCADA comparte algunos principios, pero tiene particularidades que lo convierten en un animal completamente distinto.

Primer problema: la diversidad de activos. En una planta industrial típica no solo tienes servidores Windows o Linux. Tienes PLCs de tres fabricantes distintos, HMIs con configuraciones específicas, switches industriales gestionados, variadores de frecuencia con parámetros críticos, historiadores de proceso, gateways de comunicación y cien cosas más. Cada uno con su formato propietario, su herramienta de programación y su método de extracción de datos.

Segundo problema: la ventana de backup. En IT puedes hacer snapshots a las tres de la mañana porque nadie está trabajando. En una planta 24/7, no existe esa ventana. Extraer el programa de un PLC mientras controla un proceso activo requiere cuidado y, en algunos casos, coordinación con operaciones.

Tercer problema: el versionado importa de forma crítica. No te basta con tener la última copia. Necesitas saber qué versión del programa estaba corriendo en cada PLC hace tres meses, porque ese cambio que hizo el integrador “temporal” se quedó en producción y nadie documentó la versión anterior.

Cuarto problema: la restauración no es dar a un botón. Restaurar un servidor SCADA implica reconstruir comunicaciones con dispositivos de campo, verificar que los tags apuntan a las direcciones correctas, comprobar que las alarmas funcionan y que los históricos se reconectan. Es un proceso que puede llevar días si no lo tienes planificado.

Qué respaldar: el inventario completo de activos SCADA

Antes de hablar de herramientas o frecuencias, necesitas saber exactamente qué tienes que respaldar. Esta es la lista completa, ordenada por criticidad.

Tier 1 — Crítico (sin esto, la planta no arranca)

• Programas de PLC/RTU: El código ladder, structured text, function block o lo que uses. Incluye las tablas de variables, configuraciones de hardware y parámetros de comunicación. Herramientas: TIA Portal (Siemens), RSLogix/Studio 5000 (Rockwell), Unity Pro (Schneider), GX Works (Mitsubishi).
• Configuración del servidor SCADA: El proyecto completo — pantallas, tags, scripts, alarmas, históricos, usuarios y permisos. Cada fabricante tiene su formato: FactoryTalk (Rockwell), WinCC (Siemens), Citect (Schneider), Ignition (Inductive Automation).
• Pantallas y proyectos HMI: Las configuraciones de paneles de operador locales. Un HMI sin su proyecto es una caja con pantalla.
• Base de datos del historiador: Los datos de proceso históricos. En muchos sectores regulados (alimentación, farmacéutica), perder estos datos tiene consecuencias legales.

Tier 2 — Importante (sin esto, pierdes funcionalidad significativa)

• Configuración de red industrial: Topología de switches gestionados, VLANs, reglas de firewall industrial, configuración de routers. Documenta y respalda las configs de equipos como Hirschmann, Cisco IE, Moxa o Stratix.
• Parámetros de variadores y dispositivos de campo: Muchos variadores de frecuencia tienen cientos de parámetros configurados. Un ABB ACS880 o un Siemens G120 con configuración personalizada no se reconfigura en cinco minutos.
• Firmware de dispositivos: Guarda una copia del firmware de cada versión instalada en PLCs, HMIs, switches y gateways. Si necesitas restaurar un dispositivo, necesitas el firmware exacto.
• Certificados y claves de cifrado: Si usas comunicaciones cifradas (OPC-UA con certificados, VPN industriales), pierde los certificados y pierdes la conectividad.

Tier 3 — Operativo (sin esto, reconstruyes con esfuerzo)

• Documentación de ingeniería: Planos eléctricos, P&IDs, listados de señales, manuales de usuario específicos. Idealmente en formato digital versionado.
• Recetas y parámetros de producción: Fórmulas, setpoints, configuraciones de lotes. En industria alimentaria o farmacéutica, esto es tan crítico como el propio SCADA.
• Licencias y claves de software: Seriales de licencia de software SCADA, licencias de runtime de HMI, dongles USB y sus backups. Sin la licencia, el software no arranca aunque tengas todo lo demás.
• Scripts y automatizaciones personalizadas: Scripts de Python, VBScript, SQL o n8n workflows que complementan al SCADA. Si tienes automatizaciones como las que describimos en nuestra guía de automatización SCADA con IA y Python, estas también necesitan respaldo.

Estrategia de backup: la regla 3-2-1 adaptada a entornos OT

La regla 3-2-1 es un clásico de IT: tres copias, en dos medios distintos, con una fuera del sitio. En entornos industriales necesitas adaptarla porque las restricciones son distintas.

Tres copias, dos medios, una fuera de la red OT

• Copia 1 — Local en la red OT: Un NAS o servidor de backup dentro de la red industrial. Acceso rápido para restauraciones urgentes. Protegido por la segmentación de red que ya deberías tener según tu estrategia de ciberseguridad industrial.
• Copia 2 — En la DMZ o red IT: Un servidor de backup en la zona desmilitarizada entre OT e IT. Separado lógicamente de la red de producción. Si un ransomware compromete la red OT, esta copia está en otro dominio de seguridad.
• Copia 3 — Fuera del sitio (offsite): Almacenamiento externo, ya sea en una ubicación física diferente, en la nube (si tu política de seguridad lo permite) o en un medio extraíble que se lleva fuera de la planta periódicamente.

Frecuencia de backup según el tipo de activo

No todo necesita la misma frecuencia. Aquí va una referencia práctica:

Activo	Frecuencia mínima	Trigger adicional
Programas PLC/RTU	Semanal	Después de cada cambio
Proyecto SCADA completo	Diario (incremental), semanal (completo)	Después de cada modificación
Base de datos historiador	Diario (incremental), semanal (completo)	—
Configuración de red	Mensual	Después de cambios en topología
Parámetros de variadores	Trimestral	Después de cada puesta en marcha
Firmware	Al instalar	Después de cada actualización
Documentación	Con cada revisión	—
Licencias	Anual (verificación)	Al renovar o cambiar

El trigger más importante es “después de cada cambio”. Un backup semanal no sirve de nada si el martes hiciste un cambio en el programa del PLC y el miércoles se corrompe. Necesitas un proceso donde cada cambio dispare un backup, idealmente integrado en tu flujo de gestión de cambios.

Herramientas de backup para entornos SCADA

Backup de PLCs: soluciones por fabricante

Siemens (TIA Portal / STEP 7): TIA Portal permite exportar proyectos completos como archivos .zap o .ap17. Puedes automatizar la extracción mediante la TIA Openness API, que expone funciones de scripting para extraer proyectos programáticamente. La alternativa manual es archivar desde el propio IDE periódicamente.

Rockwell (Studio 5000 / RSLogix): Los proyectos se guardan como .ACD. Rockwell ofrece FactoryTalk AssetCentre para gestionar versiones de programas de PLC de forma centralizada — es la solución enterprise, pero no es barata. Para plantas más pequeñas, un sistema de control de versiones (Git con LFS para archivos binarios) combinado con un proceso manual de exportación funciona.

Schneider (Unity Pro / EcoStruxure Control Expert): Proyectos exportables como .STU o .ZEFX. Schneider tiene su propia herramienta de versionado (EcoStruxure Asset Advisor), pero muchas plantas simplemente exportan y almacenan en un repositorio centralizado.

Soluciones multiplataforma: Herramientas como MDT AutoSave, Octoplant (antes AUVESY) y Rockwell AssetCentre permiten gestionar backups de PLCs de múltiples fabricantes desde una interfaz unificada. Octoplant, por ejemplo, soporta Siemens, Rockwell, Schneider, ABB, Mitsubishi y Beckhoff. No son baratas (licencias desde 5.000-15.000€ según el alcance), pero si tienes una planta multivendor con más de 50 PLCs, la inversión se justifica.

Backup del servidor SCADA e historiador

El servidor SCADA suele correr sobre Windows, así que las herramientas de backup convencionales funcionan para el sistema operativo y los archivos:

• Veeam Backup & Replication para entornos virtualizados (VMware, Hyper-V). Snapshots consistentes con restauración granular.
• Windows Server Backup como mínimo vital si no hay presupuesto para más.
• Backup nativo del historiador: OSIsoft PI tiene su propia herramienta de backup de archivo. Wonderware Historian usa SQL Server, así que aplica backup estándar de bases de datos SQL. Ignition de Inductive Automation permite exportar proyectos y backups de gateway desde su interfaz web.

Consejo crítico: No te fíes solo del snapshot de VM. Un snapshot captura el estado del sistema operativo, pero si el software SCADA tiene transacciones abiertas o buffers sin escribir, puedes acabar con una copia corrupta. Usa siempre la función de backup nativa del SCADA además del snapshot de infraestructura.

Backup de configuraciones de red

Los switches industriales gestionados permiten exportar su configuración:

• Cisco IE / Catalyst: copy running-config tftp://servidor/backup.cfg
• Hirschmann: Exportación desde HiVision o por CLI.
• Moxa: Backup desde MXconfig o interfaz web.

Herramientas como Oxidized (open source) o SolarWinds NCM pueden automatizar el backup de configuraciones de red de múltiples equipos. Oxidized es especialmente interesante para plantas con presupuesto ajustado: se instala en un contenedor Docker y soporta cientos de dispositivos de red.

Plan de recuperación ante desastres: de la teoría a la práctica

Tener backups sin un plan de recuperación es como tener un extintor cerrado con llave en un armario cuya llave tiene el responsable de seguridad que está de vacaciones. Necesitas un plan que cualquier técnico cualificado pueda ejecutar bajo presión.

Define tus métricas de recuperación

Antes de diseñar el plan, acuerda con dirección dos números:

• RTO (Recovery Time Objective): ¿Cuánto tiempo puede estar parada la planta? ¿4 horas? ¿24 horas? ¿Una semana? Este número determina cuánto inviertes en redundancia y preparación.
• RPO (Recovery Point Objective): ¿Cuántos datos de proceso puedes permitirte perder? ¿La última hora? ¿El último día? Este número determina la frecuencia de tus backups.

Un ejemplo real: una planta de embotellado con producción continua puede tener un RTO de 8 horas (más allá de eso, empiezan las penalizaciones contractuales) y un RPO de 1 hora (pierdes como máximo los datos del último turno). Estos números guían todas las decisiones que vienen después.

Estructura del plan de recuperación

Tu plan de recuperación debe ser un documento vivo — no un PDF de 200 páginas que nadie lee. Esta es la estructura mínima que funciona:

1. Escenarios de desastre priorizados: No puedes planificar para todo, así que prioriza los escenarios más probables y de mayor impacto:

• Ransomware/ciberataque que cifra servidores SCADA. Probabilidad: media-alta. Impacto: crítico.
• Fallo de hardware del servidor SCADA principal. Probabilidad: media. Impacto: alto.
• Corrupción de programa de PLC tras cambio no controlado. Probabilidad: alta. Impacto: variable.
• Desastre físico (incendio, inundación, fallo eléctrico prolongado). Probabilidad: baja. Impacto: catastrófico.
• Error humano que borra configuraciones o datos. Probabilidad: alta. Impacto: medio-alto.

2. Procedimiento de restauración paso a paso por escenario: Para cada escenario, documenta:

• Quién toma la decisión de activar el plan (y su suplente).
• Contactos de emergencia: equipo interno, integradores, soporte del fabricante.
• Secuencia exacta de restauración: qué se recupera primero, qué después.
• Verificación post-restauración: cómo confirmas que todo funciona antes de devolver el control a producción.

3. Prioridad de restauración: En un desastre total, no puedes restaurar todo a la vez. Define el orden:

1. Seguridad física primero: Sistemas de parada de emergencia, detección de gases, sistemas contra incendios. Estos nunca deberían depender del SCADA, pero verifica.
2. Control básico de proceso: PLCs que mantienen los procesos en estado seguro.
3. SCADA y HMI: Para que los operadores recuperen la visibilidad y el control supervisado.
4. Historiador y reporting: Datos de proceso y cumplimiento regulatorio.
5. Sistemas auxiliares: Gestión de energía, mantenimiento, integración con ERP.

Procedimiento de restauración tras un ciberataque

Este es el escenario que más plantas temen en 2026, y con razón. Un ransomware que cifra tu servidor SCADA requiere un procedimiento específico:

Paso 1 — Contención (primeros 30 minutos):

• Aísla la red OT de IT y de internet. Desconecta cables si es necesario — no es momento de finuras.
• No apagues los PLCs si están controlando procesos activos. Los PLCs suelen seguir funcionando con su último programa aunque pierdan comunicación con el SCADA.
• Documenta todo lo que ves: pantallas de error, mensajes de rescate, equipos afectados.

Paso 2 — Evaluación (primeras 2 horas):

• Determina el alcance: ¿solo servidores Windows? ¿Ha llegado a HMIs? ¿Los PLCs están intactos?
• Verifica que los backups no están comprometidos. Si tus backups estaban en la misma red que el ransomware cifró, tienes un problema serio.
• Contacta con tu equipo de respuesta a incidentes y, si aplica, con las autoridades (bajo NIS2, tienes 24 horas para la notificación inicial).

Paso 3 — Restauración (según tu RTO):

• Reconstruye los servidores desde cero. No intentes descifrar ni limpiar — reinstala el sistema operativo limpio.
• Restaura el proyecto SCADA desde tu backup verificado.
• Reconfigura las comunicaciones con los dispositivos de campo.
• Verifica tag por tag (o al menos los críticos) que los valores leídos son coherentes con el estado real del proceso.

Paso 4 — Verificación (antes de devolver a producción):

• Ejecuta una secuencia de pruebas con operadores presentes.
• Comprueba alarmas: dispara condiciones de alarma conocidas y verifica que se activan.
• Verifica históricos: confirma que los datos se están registrando correctamente.
• Documenta todo el incidente para el análisis post-mortem.

Automatizar el backup: cómo hacerlo sin depender de la memoria humana

Un plan de backup que depende de que alguien se acuerde de exportar un proyecto cada viernes no es un plan — es una esperanza. Automatiza lo que puedas.

Script básico de backup automatizado

Este es un ejemplo simplificado de un script que puedes adaptar para tu entorno. Usa Python para orquestar la copia de proyectos SCADA y configuraciones de red a un repositorio centralizado:

#!/usr/bin/env python3
"""
backup_scada.py — Backup automatizado de activos SCADA
Ejecutar como tarea programada (cron/Task Scheduler)
"""
import subprocess
import shutil
from pathlib import Path
from datetime import datetime

BACKUP_ROOT = Path("/backup/scada")
TIMESTAMP = datetime.now().strftime("%Y%m%d_%H%M")

# 1. Backup del proyecto SCADA (ejemplo Ignition)
def backup_ignition():
    destino = BACKUP_ROOT / "ignition" / f"gateway_backup_{TIMESTAMP}.gwbk"
    destino.parent.mkdir(parents=True, exist_ok=True)
    subprocess.run([
        "curl", "-s", "-o", str(destino),
        "https://scada-server:8088/main/system/backup"
    ], check=True)
    print(f"[OK] Ignition backup: {destino}")

# 2. Backup de configs de switches (via Oxidized o SSH)
def backup_network_configs():
    destino = BACKUP_ROOT / "network" / TIMESTAMP
    destino.mkdir(parents=True, exist_ok=True)
    # Oxidized guarda las configs en Git automáticamente
    subprocess.run([
        "git", "-C", "/var/lib/oxidized/configs.git",
        "log", "--oneline", "-5"
    ], check=True)
    print(f"[OK] Network configs versionadas en Git")

# 3. Copiar backups de proyectos PLC (carpeta compartida)
def backup_plc_projects():
    origen = Path("/shared/plc_projects/")
    destino = BACKUP_ROOT / "plc" / TIMESTAMP
    if origen.exists():
        shutil.copytree(origen, destino)
        print(f"[OK] PLC projects: {destino}")

if __name__ == "__main__":
    print(f"=== SCADA Backup {TIMESTAMP} ===")
    backup_ignition()
    backup_network_configs()
    backup_plc_projects()
    print("=== Backup completo ===")

Este script es un punto de partida. En un entorno real, añadirías:

• Notificaciones por email o Telegram si el backup falla.
• Verificación de integridad (checksum de los archivos).
• Rotación automática para no llenar el disco (mantener últimos 30 backups diarios, 12 semanales, etc.).
• Cifrado de los backups antes de enviarlos fuera del sitio.

Integración con n8n para orquestación y alertas

Si ya usas n8n para automatizar procesos, puedes crear un workflow que:

1. Ejecute el script de backup via SSH o comando local.
2. Verifique que los archivos de backup se han creado y tienen un tamaño razonable.
3. Envíe un resumen por email o Telegram con el estado de cada backup.
4. Escale automáticamente si algún backup falla dos veces consecutivas.

Esto te da visibilidad centralizada sin tener que revisar logs en tres servidores distintos.

Errores comunes que dejan tu plan de recuperación inservible

He visto estos errores en plantas reales. Todos se pagan caro.

1. “Los backups están en el mismo servidor que el SCADA.” Si el ransomware cifra el servidor, cifra también tus backups. Felicidades, ahora no tienes ni sistema ni respaldo. La copia fuera de la red OT no es opcional.

2. “Hacemos backup del proyecto, pero no del sistema operativo.” Reinstalar Windows, instalar el runtime SCADA, configurar servicios, aplicar parches, restaurar el proyecto y reconectar con campo puede llevar 2-3 días. Un backup de imagen completa (VM snapshot o imagen de disco) reduce eso a horas.

3. “Nunca hemos probado una restauración.” El backup que no has probado restaurar es un archivo aleatorio que ocupa espacio. Punto. Haz un simulacro al menos una vez al año. Mejor dos.

4. “Solo respaldamos los servidores, no los PLCs.” El servidor SCADA sin los programas de PLC correctos es un panel de control conectado a nada. Los PLCs son la capa que realmente controla el proceso. Si pierdes un programa de PLC y no tienes backup, te toca reprogramar desde cero — con todo lo que eso implica en tiempo, coste y riesgo de errores.

5. “El integrador tiene una copia.” Quizá. Quizá la versión que tiene es de hace dos años. Quizá cambió de empresa. Quizá su disco duro también se ha roto. Tu backup es tu responsabilidad, no la de un tercero.

6. “No tenemos documentado el procedimiento de restauración.” El técnico que sabe restaurar todo está de vacaciones en agosto cuando ocurre el desastre. Murphy no perdona. Si el procedimiento no está escrito, no existe.

Cumplimiento normativo: lo que te exigen NIS2 e IEC 62443

Si tu planta cae bajo el paraguas de NIS2, el artículo 21 te exige explícitamente planes de continuidad de negocio, gestión de backups y recuperación ante desastres. No es una recomendación — es una obligación legal con sanciones de hasta el 2% de tu facturación global.

IEC 62443 también aborda la resiliencia y la recuperación en varias de sus partes:

• IEC 62443-2-1 (requisitos para el operador): exige procedimientos de backup, restauración y continuidad de operaciones.
• IEC 62443-3-3 (requisitos técnicos del sistema): incluye requisitos de disponibilidad y recuperación a nivel de sistema.

En ambos marcos normativos, no basta con decir “hacemos backups”. Necesitas demostrar que los haces, que los verificas y que tienes un procedimiento de restauración probado. El auditor va a pedirte evidencia: registros de backup, resultados de simulacros y el propio plan documentado.

Checklist de implementación: empieza esta semana

No necesitas un proyecto de seis meses para empezar. Esta es la secuencia práctica:

Semana 1 — Inventario y estado actual:

• Lista todos los activos SCADA/OT que necesitan backup (usa la clasificación Tier 1/2/3 de este artículo).
• Documenta qué se está respaldando actualmente y con qué frecuencia.
• Identifica los huecos: ¿qué activos críticos NO tienen backup?

Semana 2 — Infraestructura de backup:

• Configura el almacenamiento: NAS local en red OT + copia en DMZ o fuera del sitio.
• Implementa backups automáticos para el servidor SCADA (snapshot de VM + backup nativo del proyecto).
• Exporta y almacena todos los programas de PLC actuales.

Semana 3 — Automatización y monitorización:

• Programa scripts o tareas de backup automatizado.
• Configura alertas de fallo (email, Telegram, lo que uses).
• Verifica que los backups se están generando correctamente.

Semana 4 — Plan de recuperación y primer simulacro:

• Documenta el plan de recuperación con los escenarios priorizados.
• Define RTO y RPO con dirección y operaciones.
• Ejecuta un simulacro parcial: restaura un proyecto SCADA en un entorno de pruebas.
• Documenta los resultados y ajusta el plan.

Cada trimestre — Mantenimiento:

• Simulacro de restauración (rota entre escenarios).
• Revisión y actualización del inventario de activos.
• Verificación de integridad de backups almacenados.
• Actualización del plan si ha habido cambios en la infraestructura.

Conclusión: el backup que no existe es la apuesta más cara que puedes hacer

Un plan de backup SCADA y recuperación ante desastres no es un proyecto de innovación ni una inversión de futuro. Es un seguro que esperas no necesitar nunca — pero cuando lo necesitas, lo necesitas en ese momento, no mañana.

Las plantas que tienen un plan probado restauran operaciones en horas. Las que no, pierden días o semanas de producción, pagan rescates que no garantizan nada y a veces pierden datos irrecuperables. La diferencia no está en el presupuesto — está en haber dedicado tiempo a planificarlo antes de que las cosas se tuerzan.

Empieza por el inventario. Implementa los backups de Tier 1 esta semana. Haz un simulacro antes de que acabe el trimestre. No necesitas que sea perfecto; necesitas que exista.

---

¿Necesitas ayuda para diseñar e implementar tu plan de backup y recuperación SCADA? En automatizatodo.com trabajamos con plantas industriales reales, no con PowerPoints. Contacta con nosotros y montamos un plan adaptado a tu infraestructura.

---

Artículos relacionados:

• Ciberseguridad Industrial OT: Guía Práctica para Proteger tu Planta
• NIS2: Cómo Automatizar el Cumplimiento Normativo en la Industria
• IEC 62443: La Guía Definitiva para el Cumplimiento en Ciberseguridad Industrial
• Automatizar SCADA con IA y Python en la Industria

Fuentes externas de referencia:

• NIST SP 800-82 Rev. 3 — Guide to OT Security — Marco de referencia para seguridad en sistemas de control industrial.
• IEC 62443 — ISA Global Cybersecurity Alliance — Estándares internacionales de ciberseguridad para automatización industrial.