El día que una empresa descubre que su estrategia de backup empresas no funcionaba es, invariablemente, el peor día de su historia. Un NAS en la oficina, correctamente configurado y con capacidad suficiente, genera una sensación de seguridad que puede ser más peligrosa que no tener ninguna copia. Porque cuando llega el ransomware, el incendio o el fallo en cadena de hardware, esa falsa certeza se convierte en el primer obstáculo para la recuperación.
La realidad es contundente: una única copia local no es una estrategia de backup. Es un punto único de fallo con disco duro. Y sin embargo, un tercio de las organizaciones sigue sin cumplir siquiera la regla 3-2-1, el estándar mínimo de la industria desde hace décadas. Un estándar que, por cierto, ya ha quedado incompleto frente a las amenazas actuales.
En este análisis se examinan los escenarios reales en los que el NAS local falla, se explica por qué la regla 3-2-1 ha evolucionado al modelo 3-2-1-1-0, y se detalla qué significa exactamente tener una copia offsite verificada y recuperable. El objetivo es claro: definir la postura mínima viable de backup para cualquier empresa que no pueda permitirse perder sus datos.
La falsa seguridad del NAS: cuando creer que estás protegido es el mayor riesgo
Es lunes por la mañana. Alguien abre su ordenador y encuentra que todos los archivos del servidor aparecen con extensiones desconocidas y un mensaje de rescate en pantalla. El primer instinto es ir al NAS, esa unidad que la empresa instaló precisamente para estos momentos. Pero el NAS también está cifrado: estaba montado como unidad de red accesible desde los equipos de la oficina, y el ransomware lo encontró antes que nadie.
Este escenario no es hipotético. En España, una empresa sufre un ataque de ransomware cada seis minutos, y el ransomware representa ya el 25% de todos los ciberataques registrados a nivel mundial en 2025. La mayoría de esas empresas creían estar protegidas.
La respuesta más habitual cuando se pregunta a una PYME por su estrategia de backup es directa y tranquilizadora: “tenemos el NAS”. Con esa frase, la conversación suele cerrarse. El NAS existe, los datos se copian allí, el problema está resuelto. Esa percepción es comprensible porque el NAS cumple su función visible: hay una copia de los datos en algún lugar distinto al servidor principal.
El problema es la diferencia entre tener datos copiados y tener una estrategia de recuperación real. Una copia almacenada en la misma red, accesible desde los mismos equipos, ubicada en el mismo edificio, no resuelve los tres vectores de fallo más frecuentes en entornos empresariales: el ransomware que alcanza todo lo que está conectado, el desastre físico que destruye lo que está en el mismo espacio, y el fallo de hardware que corrompe silenciosamente lo que parecía intacto.
La tesis de este análisis es concreta: un NAS local sin una copia offsite verificada no constituye una solución de backup para empresas. Es una ilusión de seguridad que, en el momento equivocado, puede costar la continuidad del negocio.
El error más común en PYMEs: confundir copia local con estrategia de backup
Tener un NAS funcionando en la red no es lo mismo que tener una estrategia de backup. Es un componente, probablemente el más importante de la infraestructura local, pero un componente sigue siendo una pieza suelta, no un plan. La estrategia exige definir qué pasa cuando ese componente falla, arde o queda cifrado.
Como se indica en el apartado anterior, uno de cada tres organizaciones sigue sin implementar completamente este estándar.
Por qué las PYMEs se detienen en el NAS
Tres barreras explican este patrón. La primera es el coste percibido: una vez adquirido el NAS, añadir una capa offsite parece un gasto cuyo beneficio no se materializa hasta el desastre. La segunda es la invisibilidad del riesgo: sin un incidente previo, la diferencia entre “tener una copia” y “tener una copia verificada en otra ubicación” permanece abstracta. La tercera es la ausencia de un responsable TI dedicado: en empresas de cinco a cincuenta empleados, nadie tiene el mandato explícito de revisar si la estrategia de backup sigue siendo adecuada. Este es el perfil de empresa para el que tiene sentido plantearse cuándo subcontratar el soporte informático externo y qué exigirle al proveedor antes de que una crisis lo decida por ti.
El coste real del gap offsite
Cuando la única copia queda inaccesible, los costes se acumulan rápido. El tiempo de inactividad paraliza la facturación desde el primer día. Un ataque de ransomware añade la presión del rescate, que en entornos PYME puede ser devastador para las finanzas de una empresa de este tamaño, sin garantía de recuperación aunque se pague. A eso se suman los daños reputacionales frente a clientes que no entienden por qué su proveedor ha perdido sus datos o contratos.
Instalado no es lo mismo que gestionado
Un sistema de backup que se configura una vez y no se supervisa es, en la práctica, una promesa sin verificar. La diferencia entre un backup instalado y uno gestionado activamente es simple: el primero almacena datos, el segundo garantiza que esos datos son restaurables cuando se necesitan. Esa garantía requiere pruebas periódicas, alertas ante fallos de escritura y monitorización continua, aspectos que se desarrollan en detalle más adelante en este análisis.
La regla 3-2-1: el mínimo que toda empresa debería cumplir
La regla 3-2-1 establece un marco deliberadamente simple:
- Tres copias garantizan que un fallo aislado nunca sea el último. El original puede corromperse; la primera copia puede estar inaccesible; la tercera es la red de seguridad final.
- Dos tipos de soporte protegen frente a fallos de hardware sistémicos. Si ambas copias residen en discos del mismo modelo o del mismo sistema, un fallo de controlador o un defecto de fabricación puede inutilizarlas simultáneamente.
- Una copia offsite es la única defensa real frente a desastres físicos. Un incendio, una inundación o un robo no distingue entre servidor y NAS si ambos están en el mismo edificio.
Cómo se traduce esto en una PYME concreta
La implementación más directa para un sistema de backup para empresas de tamaño medio tiene esta estructura:
- Copia 1: datos activos en el servidor de producción (almacenamiento primario en la oficina)
- Copia 2: backup local en un NAS dedicado, en red interna pero en segmento separado
- Copia 3: réplica en un repositorio cloud o centro de datos externo, en ubicación geográfica distinta
Este flujo, pensado como infografía, iría del servidor de producción (etiqueta: disco local, oficina) al NAS local (etiqueta: almacenamiento NAS, oficina) y de ahí al repositorio externo (etiqueta: cloud o CPD externo, ubicación offsite). Tres nodos, dos ubicaciones físicas, dos tipos de medio.
La regla 3-2-1 es un punto de partida, no un destino
La regla 3-2-1 define el umbral mínimo aceptable, no la postura óptima. El contexto de amenazas actual, dominado por el ransomware moderno, ha expuesto una brecha crítica: la regla no contempla que una copia offsite en la nube pueda seguir siendo accesible y modificable desde la red comprometida. Las secciones siguientes desarrollan por qué eso importa y qué modelo lo corrige.
Por qué el ransomware rompió la regla 3-2-1 clásica y exige el modelo 3-2-1-1-0
La regla 3-2-1 fue diseñada para un mundo donde el enemigo era el accidente: un disco que falla, una inundación, un error humano. El ransomware moderno ha cambiado las reglas del juego de forma fundamental.
El ataque que no para en el servidor
En la sección de apertura se describe el escenario del lunes por la mañana; lo que importa aquí es el mecanismo: el ransomware moderno no actúa solo sobre el servidor primario, sino que despliega movimiento lateral para localizar y cifrar también las copias conectadas.
La diferencia crítica respecto a un fallo de hardware es la intencionalidad. Un disco roto no busca activamente tus copias de seguridad. El ransomware, sí.
El modelo 3-2-1-1-0 como respuesta
El sector ha respondido con una evolución del marco clásico. El modelo 3-2-1-1-0 añade dos dimensiones que la regla original no contemplaba:
- Una copia inmutable o con air gap: un repositorio donde ningún proceso de red, ninguna credencial comprometida y ningún malware puede modificar ni borrar los datos una vez escritos.
- Cero sistemas conectados sin monitorización activa: cualquier destino de backup accesible desde la red y sin supervisión continua es un vector de ataque potencial.
El concepto de air gap, en términos de negocio, significa desconexión real: una copia que existe fuera del alcance de cualquier sesión de red activa. No es una copia en la nube con credenciales compartidas; es un destino al que el ransomware, aunque controle toda la red local, no puede llegar.
Del disaster recovery a la ciberresiliencia
Esta transición implica un cambio de mentalidad para las soluciones de backup para empresas medianas. El objetivo ya no es solo restaurar datos después de un fallo técnico, sino garantizar que exista siempre una copia que un atacante no haya podido tocar. Eso convierte la inmutabilidad y el air gap en requisitos de diseño, no en opciones avanzadas.
Escenario real: qué le ocurre a tu NAS cuando hay un incendio o una inundación
El ransomware no es el único enemigo de tus datos. Imagina que el viernes por la tarde tu equipo cierra la oficina con normalidad. El sábado por la madrugada, un cortocircuito desencadena un incendio. El lunes por la mañana no hay servidores, no hay NAS, no hay equipos de trabajo. Solo cenizas y la pregunta que ninguna empresa quiere responder: ¿dónde está la última copia de nuestros datos?
Si el NAS estaba en el armario de comunicaciones del mismo edificio, la respuesta es devastadora: no existe.
El problema no es el fuego, es la coubicación
Los incendios, inundaciones y robos físicos representan una categoría de riesgo distinta al ransomware, pero con el mismo resultado: pérdida total de datos cuando la única copia está en el mismo espacio físico que los originales. La frecuencia de desastres meteorológicos ha aumentado de forma sostenida en las últimas décadas, y los edificios de oficinas no son inmunes.
Como ya se señaló al explicar la regla 3-2-1, el RAID protege la disponibilidad ante fallos de componente; no protege cuando el entorno físico completo queda destruido.
La geografía es un requisito técnico, no una preferencia
Una copia offsite real exige separación física significativa. Un segundo NAS en la oficina contigua no cumple ese requisito: comparte la misma red eléctrica, el mismo riesgo de inundación, el mismo acceso para un robo. Los marcos de continuidad de negocio exigen ubicaciones que no puedan verse afectadas por el mismo evento físico localizado.
Tener una copia en la nube no equivale a tener una copia recuperable
Una copia en la nube no verificada es simplemente datos almacenados en algún lugar remoto. Sin pruebas de restauración periódicas, sin validación de integridad y sin documentación del proceso de recuperación, esa copia puede resultar inutilizable por corrupción silenciosa, configuración incorrecta o dependencias de software no contempladas.
Una solución de backup para empresas con recuperación testada implica restauraciones de prueba programadas, alertas automáticas cuando una verificación falla y un tiempo de recuperación conocido de antemano. La diferencia no se percibe durante los meses en que todo funciona. Se percibe el lunes después del incendio.
Escenario real: el fallo de hardware encadenado que el RAID no puede detener
El incendio destruye lo que está en la oficina. Pero hay un escenario igual de devastador que no requiere ninguna catástrofe visible: el fallo silencioso del propio hardware de backup.
Imagina que el controlador del NAS empieza a degradarse de forma gradual. No hay alarmas. El sistema sigue respondiendo, los backups nocturnos aparecen como completados en el registro. Semanas después, un empleado borra accidentalmente una carpeta crítica y el equipo intenta restaurar desde la copia. Solo entonces se descubre que el controlador, al fallar, escribió datos corruptos en los discos durante semanas. Tanto los archivos originales como la única copia existente son irrecuperables.
En el escenario anterior se recordó que el RAID no es backup; en este escenario el problema no es la destrucción física sino la corrupción silenciosa que el RAID propaga activamente.
El fallo silencioso: el peor tipo de pérdida
Los errores de escritura no siempre generan alertas. Un sector defectuoso, una escritura incompleta por un corte de tensión, una corrupción lógica progresiva: estos fallos pueden pasar desapercibidos durante meses. El backup existe en los registros, pero los datos almacenados son inutilizables. Este fenómeno, conocido como silent data corruption, convierte las soluciones de backup para empresas basadas en un único sistema local en una apuesta arriesgada.
La respuesta correcta tiene dos componentes. Primero, diversidad de hardware y ubicación: la copia secundaria debe residir en un sistema con arquitectura distinta y en una ubicación separada, rompiendo cualquier dependencia compartida con el sistema primario. Segundo, monitorización proactiva: herramientas RMM permiten monitorizar de forma continua el estado del backup y generar alertas ante anomalías, sin esperar al momento de la restauración para descubrirlo.
La copia offsite verificada: qué significa exactamente que un backup sea recuperable
Detectar fallos antes de un incidente es necesario pero no suficiente si la copia monitorizada nunca ha demostrado ser recuperable.
Almacenar no es lo mismo que recuperar. Una copia no verificada es simplemente datos en algún lugar: puede estar corrupta, incompleta o contener versiones inconsistentes de aplicaciones interdependientes. Ninguno de esos problemas se manifiesta hasta el momento exacto en que más se necesita la restauración. La ISO 27001, control A.12.3, lo recoge con claridad: el requisito no es demostrar que existe un backup, sino demostrar que puede restaurarse con éxito, con evidencia documentada de cada prueba.
RPO y RTO son preguntas de negocio, no de TI. El RPO (Recovery Point Objective) responde a cuántos datos puede permitirse perder una empresa: si el RPO es de 24 horas, un incidente a las 11 de la noche implica perder todo el trabajo del día. El RTO (Recovery Time Objective) responde a cuánto tiempo puede estar la empresa sin operar: dos horas de inactividad tienen un impacto muy distinto para una gestoría que para un e-commerce. Antes de configurar cualquier sistema de backup, estas dos cifras deben estar definidas en términos de euros y operativa real.
La verificación real tiene tres componentes: restauraciones de prueba periódicas sobre entornos aislados, comprobación de integridad mediante hash o sumas de verificación, y validación de que las aplicaciones críticas arrancan correctamente desde la copia restaurada. Este último punto se omite con frecuencia: un archivo de base de datos puede estar intacto y aun así ser incapaz de levantar el ERP si faltan dependencias o la configuración quedó fuera de la copia.
Las pruebas manuales esporádicas no escalan. En un entorno donde los datos cambian cada hora, un test manual mensual deja semanas enteras de copias sin validar. La verificación automatizada comprueba cada ciclo y genera alertas inmediatas cuando una copia no supera las comprobaciones. Esto distingue un sistema gestionado de un backup instalado y olvidado, algo que un socio de IT externo con servicios gestionados reales debe garantizar de forma continua.
Soluciones como Synology NAS combinadas con capas offsite inteligentes como Beeam permiten centralizar esta verificación: cada copia replicada pasa por comprobaciones automatizadas de integridad y cualquier anomalía genera una alerta antes de convertirse en pérdida irreversible.
Almacenamiento inmutable: ya no es una característica premium, es un requisito mínimo
La verificación confirma que una copia existe y puede restaurarse. La inmutabilidad garantiza que esa copia no haya sido alterada antes de que la necesites.
WORM (Write Once, Read Many) es la tecnología que hace posible la inmutabilidad: una vez escrita la copia de backup, ningún proceso, usuario con privilegios elevados ni malware puede modificarla ni eliminarla durante el periodo de retención definido. No es un permiso de archivo convencional que un atacante pueda revocar; es una restricción aplicada a nivel de almacenamiento que opera por debajo del sistema operativo.
Del entorno enterprise a la PYME: un cambio que ya ocurrió
Los ataques de ransomware dirigidos específicamente a infraestructuras de backup han empujado a fabricantes y proveedores cloud a incorporar la inmutabilidad como opción estándar en los últimos años. Lo que antes costaba varias veces el presupuesto TI anual de una PYME hoy está disponible como capa de almacenamiento offsite a costes mensuales comparables a una línea de telefonía empresarial.
El error de asumir que “en la nube” implica “inmutable”
Un backup subido a un servicio cloud sin inmutabilidad habilitada es tan vulnerable como un NAS conectado a la red local. Si las credenciales se ven comprometidas, el ransomware moderno puede acceder a la API del servicio, enumerar los snapshots y eliminarlos antes de cifrar los datos de producción. La diferencia entre un repositorio inmutable offsite y un simple backup en la nube no es de ubicación, es de arquitectura: el primero hace que la eliminación sea técnicamente imposible durante el periodo de retención; el segundo depende exclusivamente del control de acceso.
El cuarto elemento del modelo 3-2-1-1-0
El cuarto elemento del modelo 3-2-1-1-0, ya descrito en detalle, es exactamente esta capa inmutable.
El argumento económico que cierra el debate
El coste mensual de un repositorio inmutable offsite ha bajado de forma significativa y ya se encuentra al alcance del presupuesto TI de una PYME mediana. El coste de un rescate por ransomware para una pequeña empresa puede exceder ampliamente el presupuesto TI anual, sin contar los días de inactividad, que pueden representar pérdidas equivalentes en facturación. La pregunta no es si la inmutabilidad cabe en el presupuesto; es si el negocio puede absorber el coste alternativo de no tenerla.
RGPD y NIS2: cuándo la estrategia de backup deja de ser opcional por ley
La inmutabilidad resuelve el problema técnico de que una copia no pueda ser alterada. Pero existe una capa adicional que convierte el backup en obligación legal, no solo en buena práctica.
El artículo 32 del RGPD exige a cualquier responsable de tratamiento implementar medidas técnicas que garanticen la disponibilidad, integridad y resiliencia de los sistemas que manejan datos personales, incluyendo explícitamente la capacidad de restaurar el acceso a dichos datos de forma rápida tras un incidente físico o técnico. No es una recomendación. La AEPD confirma que la seguridad de los tratamientos es una medida de cumplimiento obligatoria. Un NAS local sin copia offsite verificada que queda cifrado por ransomware deja a la empresa sin capacidad de restauración, lo que puede constituir directamente un incumplimiento del artículo 32.
La Directiva NIS2, en vigor desde octubre de 2024 en la UE, amplía este marco más allá de los operadores críticos tradicionales. Empresas de tamaño medio en sectores como manufactura, servicios digitales o sanidad quedan ahora sujetas a requisitos explícitos de continuidad de negocio y gestión de incidentes que implican, entre otras cosas, disponer de procedimientos de recuperación documentados y operativos.
Las consecuencias de no cumplir son concretas. Cuando se produce una brecha de datos personales, el RGPD impone un plazo máximo de 72 horas para notificar a la AEPD (artículo 33). Si la brecha se debe a un incidente que una estrategia de backup adecuada habría contenido, la empresa enfrenta además sanciones bajo el artículo 83.4(a) y responsabilidad civil frente a los afectados.
El problema real es que muchas PYMEs no identifican su NAS local como un gap de cumplimiento. Asumen que tener alguna copia equivale a cumplir. No es así: el artículo 32 exige también verificación, evaluación y valoración regulares de las medidas aplicadas.
Aquí es donde la documentación deja de ser burocracia. Un plan de backup escrito, con pruebas de restauración registradas y una política de retención actualizada, es la evidencia que distingue a una empresa que cumple de una que simplemente supone que cumple, y esa distinción es la que determina el resultado de una inspección.
Cómo pasar de un NAS local a una estrategia híbrida sin interrumpir el negocio
Conocer las obligaciones legales es el punto de partida; actuar sobre ellas es el siguiente paso. La buena noticia es que la transición desde un NAS local hacia una arquitectura híbrida no exige reemplazar nada ni detener operaciones.
Fase 1: Diagnóstico y auditoría
Antes de añadir ninguna capa, es necesario mapear la situación real: qué datos existen, dónde residen exactamente, y qué flujos de negocio dependen de ellos. Dos métricas concretas deben definirse en esta fase. El RPO (Recovery Point Objective) establece cuántas horas de datos puede permitirse perder la empresa; el RTO (Recovery Time Objective) define en cuánto tiempo necesita volver a operar. Con esos valores sobre la mesa, es posible identificar los gaps respecto al modelo 3-2-1-1-0: qué copias existen, cuáles son inmutables, cuáles están verificadas, y cuáles no están en ninguna ubicación offsite.
Fase 2: Añadir la capa offsite sin tocar el hardware existente
El NAS local no se retira, se complementa. Un sistema como Synology puede configurarse para replicar automáticamente hacia un repositorio cloud externo con inmutabilidad activada, sin modificar la infraestructura de producción. El resultado es una segunda ubicación verificable que cumple el cuarto elemento del modelo 3-2-1-1-0, a un coste de transición significativamente menor que una sustitución completa.
Fase 3: Verificación y monitorización continua
Tener la copia offsite no es suficiente si nadie comprueba que funciona. Esta fase incluye pruebas automáticas de restauración, integración de alertas en el sistema RMM para detectar fallos silenciosos antes de que sean críticos, y una revisión mensual de la política de backup que valide que los RPO y RTO siguen siendo coherentes con el negocio.
Para una PYME sin personal TI interno dedicado, este ciclo completo, desde el diseño de la arquitectura de infraestructura gestionada hasta la instalación y configuración de los servicios gestionados y el mantenimiento continuo de redes e infraestructura, es exactamente el rol que cubre un socio externo como KMU Informatik Support: diseño, implementación y gestión continua sin que la empresa necesite desarrollar esa capacidad internamente.
Conclusión: la postura mínima viable de backup para cualquier empresa
La hoja de ruta anterior demuestra que el camino desde un NAS local hasta una postura de backup sólida no exige partir de cero. Pero completar ese camino requiere antes aceptar un diagnóstico incómodo.
Un NAS local es un activo valioso; sin una copia offsite verificada e inmutable, es también un punto único de fallo. Para cualquier empresa con más de cinco empleados, esa exposición no es un riesgo teórico, es una probabilidad con fecha pendiente de confirmación.
Tres vectores lo demuestran de forma independiente. El ransomware moderno detecta y cifra las unidades de red accesibles, incluido el NAS de backup, antes de que ninguna alerta salte. Un desastre físico, un incendio, una inundación, un robo, destruye simultáneamente los datos originales y la copia si ambos comparten ubicación. El fallo de hardware encadenado corrompe los datos en silencio durante semanas, de modo que cuando se intenta recuperar, la copia resulta inutilizable. Ninguno de estos tres escenarios es excepcional; los tres han ocurrido en PYMEs con infraestructuras similares a la tuya.
El modelo 3-2-1-1-0, descrito en profundidad en las secciones anteriores, es la respuesta estructurada a los tres vectores y hoy es implementable de forma incremental sin sustituir la infraestructura existente.
La diferencia entre las empresas que recuperan sus datos tras un incidente y las que no suele reducirse a una decisión tomada antes de que ocurriera el problema.
Si no tienes certeza de que tu estrategia de backup actual supera los tres vectores descritos, ese es el gap que hay que cerrar ahora. En KMU Informatik Support realizamos auditorías de backup sin compromiso para evaluar tu postura actual, identificar las brechas concretas y proponer una arquitectura híbrida verificada adaptada a tu entorno real. El objetivo es que el próximo incidente, cuando llegue, sea un inconveniente gestionado, no una crisis sin retorno.
La pregunta no es si tu empresa puede permitirse una estrategia de backup híbrida verificada. La pregunta es si puede permitirse no tenerla.
