Comprar un segundo nodo y dormir tranquilo es una de las decisiones más caras y menos eficaces que puede tomar una pyme. La alta disponibilidad resuelve un problema muy concreto, el fallo del hardware, y deja fuera otros tres que aparecen con la misma frecuencia: la corrupción de datos, el borrado accidental y el cifrado malicioso. Los titulares sobre ciberseguridad de 2025 apuntan a unas 122.000 incidencias registradas por INCIBE, con las pymes entre los principales afectados según los patrones de incidentes registrados. La pregunta útil sigue siendo la misma: ¿contra qué está cubierta tu infraestructura?
Este análisis separa continuidad de recuperación y explica por qué se presupuestan por separado. Recorreremos por qué “tenemos dos nodos” no equivale a “estamos protegidos”; los cuatro tipos de fallo y su mapa de cobertura por capa; qué queda realmente fuera de un clúster; por qué la replicación propaga el error al segundo nodo; los requisitos mínimos de una capa de recuperación independiente; cómo cambia el reparto de responsabilidades cuando se trabaja con servidores cloud; qué documentación te van a pedir por escrito; y cinco preguntas de comprobación antes de dar tu protección por buena.
Por qué “tenemos dos nodos” no significa “estamos protegidos”
En muchas pymes circula la misma conclusión: si la máquina virtual sigue arrancando en el segundo nodo, los datos también están a salvo. No se sostiene.
Conviene separar dos preguntas de negocio desde el principio. La primera, ¿cuánto tiempo puedo estar parado?, pertenece a la continuidad. La segunda, ¿puedo volver al estado de ayer a las 14:00?, pertenece a la recuperación. Son preguntas distintas, con presupuestos distintos.
El contexto añade presión: INCIBE gestionó 122.223 incidentes de ciberseguridad en 2025, un 26% más que el año anterior, una tendencia que ya afecta de lleno a la pyme española.
El coste del falso confort es alto: quien cree estar cubierto no prueba restauraciones, no mantiene copias fuera de línea y descubre el problema cuando ya no hay nada que restaurar. Cuando el backup depende de un único NAS local, existe una dependencia que conviene revisar con criterio offsite.
No es una guía de configuración ni un ranking: es un criterio para decidir dónde poner cada euro de protección.
Continuidad y recuperación: dos preguntas, dos capas, dos presupuestos
Continuidad es mantener el servicio operativo mediante redundancia, failover y migración en vivo, sin intervención humana; su indicador es el tiempo de inactividad. Recuperación es devolver datos y aplicaciones a un estado anterior válido, medida por la antigüedad del último punto fiable (RPO) y el tiempo de restauración (RTO). La asimetría: la continuidad es preventiva y automática; la recuperación, reactiva, y exige un punto anterior no contaminado.
Vocabulario del artículo: nodo (PYME de 40 empleados con dos hosts idénticos), réplica (copia que reproduce el mismo error sin distinguirlo de un dato sano), snapshot (instantánea cómoda, no copia permanente), copia inmutable (inalterable incluso para el administrador), punto de restauración probado (con fecha y duración registradas) y copia fuera de línea (sin red ni credenciales de producción).
Una capa no sustituye a la otra: la continuidad resuelve disponibilidad; la recuperación, integridad y recuperabilidad del dato. Confundirlas lleva a comprar continuidad cuando el riesgo real es la pérdida de datos, como ilustran los errores de cutover en migraciones a Microsoft 365.
Advertencia: si una instantánea vive en el mismo almacenamiento y credenciales que el sistema que protege, no es copia de seguridad, sino un snapshot con otro nombre.
Cuatro tipos de fallo: mapa de cobertura por capa
Cada tipo de fallo cae en un lado u otro del mapa.
Cubre la infraestructura redundante
- Fallo físico: disco, placa, fuente, memoria o caída completa de un host. Es detectable y el failover lo absorbe.
Exige restauración desde un punto anterior
- Corrupción lógica: sistema de archivos dañado, base de datos inconsistente, fichero sobrescrito con contenido incorrecto. La réplica copia ese estado dañado sin distinguirlo de uno sano.
- Borrado accidental o malintencionado: un directorio de contabilidad eliminado por error, un script que arrasa una carpeta compartida. Un clúster no tiene memoria del estado anterior.
- Cifrado malicioso: el ransomware cifra ficheros y también volúmenes montados y recursos compartidos de red, exactamente el material que la replicación sincroniza. Ninguna configuración perimetral detiene esa escritura destructiva: conviene saber qué protege de verdad un firewall para PYMEs y qué no.
- Error humano de configuración: un cambio de permisos, una política mal aplicada o una actualización defectuosa se propagan igual que el resto del estado del sistema.
La columna izquierda la sostiene el clúster; la derecha, solo una capa de recuperación independiente.
Qué protege de verdad un clúster y qué queda fuera
Sí resuelve la muerte de un nodo físico. Si el host primario deja de responder, las cargas arrancan en el segundo en un tiempo que depende de la configuración del entorno, sin intervención manual, y el mantenimiento planificado deja de exigir una ventana de parada. La diferencia con un servidor RAID es clara: el RAID sobrevive al fallo de un disco; el clúster, al fallo del host completo.
Las instantáneas y réplicas son útiles, pero si residen en el mismo almacenamiento, la misma cuenta o el mismo plano de administración que el original, no forman una capa independiente, como ocurre con un NAS local sin copia offsite verificada.
Proxmox VE, plataforma de virtualización con arquitectura de hipervisor presente en el portafolio de KMU Informatik Support, aporta continuidad, no sustituye la política de copias ni la prueba de restauración.
Quedan focos organizativos que rara vez se revisan: la configuración de quórum, quién puede borrar una máquina virtual y si un único administrador puede destruir a la vez el original y la copia.
El clúster es una buena inversión y, al mismo tiempo, una protección incompleta. Ambas cosas son ciertas y conviene sostenerlas juntas, porque quien solo ve la primera deja de exigir la segunda.
Por qué la replicación propaga el error al segundo nodo
La ventana de propagación lo decide todo. Un borrado o un cifrado se propagan al segundo nodo con rapidez suficiente como para inutilizar una copia reciente antes de que el incidente sea detectado.
Una secuencia frecuente incluye acceso inicial, localización de recursos compartidos, exfiltración y cifrado; CISA documenta el impacto operativo de ese tipo de ataque. Ese reconocimiento busca precisamente los destinos de réplica.
Queda el punto que más cuesta aceptar: ningún control de infraestructura distingue una escritura legítima de una destructiva. Un script mal lanzado y un proceso de cifrado generan el mismo evento.
De ahí la regla: para esta familia de fallos hace falta un punto de restauración anterior en el tiempo, separado del sistema y preferiblemente inmutable.
La capa de recuperación independiente: requisitos mínimos
La capa de recuperación se diseña con independencia del clúster y responde a requisitos propios.
Regla 3-2-1 adaptada a la PYME. Tres copias, en dos soportes distintos, una fuera del sitio y, además, una copia inmutable o fuera de línea para el escenario de ransomware.
Inmutabilidad y versionado. Las copias no deben poder modificarse ni borrarse con las credenciales de producción, ni siquiera por quien administra la infraestructura.
Separación de planos de control. Cuenta distinta, credenciales distintas y red distinta. Si el mismo administrador puede tocar el original y la copia, no existe capa independiente.
Frecuencia y retención contra el RPO real. No contra lo que permite la herramienta por defecto. Hay que dejar por escrito qué pérdida de datos es tolerable en cada aplicación crítica.
Pruebas de restauración documentadas. Una copia que nunca se ha restaurado no es una copia, es una hipótesis. Defina quién prueba, cada cuánto y qué se registra.
Lo que no vive en tus servidores. Correo, ficheros en la nube corporativa, identidades y configuración de puestos de trabajo suelen quedar fuera del plan tradicional.
Synology NAS, en sus variantes local e híbrida, y soluciones como Beeam figuran en el portafolio declarado del proveedor como componentes de ese diseño de copia local más copia externa, nunca como garantía de resultado. Quien opere en cadenas de suministro con clientes europeos debería revisar además las exigencias contractuales de seguridad.
Servidores cloud y servicios cloud para empresas: el fallo de hardware cambia de dueño, la recuperación no
La capa de recuperación debe viajar contigo a la nube. Migrar cargas a servidores cloud cambia quién responde de la redundancia física: el fallo de un host deja de ser tu problema y pasa a serlo del proveedor. Es un beneficio real y su límite.
El borrado accidental, la corrupción lógica y el cifrado malicioso siguen ocurriendo en la capa que tu empresa administra, con sus usuarios y permisos. De ahí el modelo de responsabilidad compartida: como criterio de diseño general, no como afirmación contractual universal, , el proveedor garantiza la disponibilidad de la plataforma, no la recuperabilidad de tus datos concretos. Son dos compromisos distintos y solo uno figura en el contrato. Un proyecto de servicios cloud para empresas o de servicios de cloud computing bien planteado define la política de copias, retención y restauración en la fase de diseño, no como anexo posterior.
Antes de firmar, pregunta qué tipos de fallo cubre el contrato, qué política de instantáneas existe, si se permiten copias fuera de la plataforma y con qué frecuencia. Y no atribuyas a ningún proveedor capacidades, cifras o garantías que no estén en su documentación contractual. Como en cualquier soporte informático externo para PYMEs: lo que no está pactado, no está cubierto.
Qué te van a pedir por escrito
Sea la infraestructura propia o contratada, la revisión llega y pregunta por documentos, no por diagramas. Una política de copias escrita, un registro fechado de pruebas de restauración y una definición explícita de RTO y RPO por servicio crítico son las evidencias habituales. Declarar que existen copias no cuenta como ninguna de las tres.
La trazabilidad es el punto incómodo. La pregunta no es si hay backups, sino quién puede destruirlos: qué cuenta, con qué aprobación y qué queda registrado. En la documentación de continuidad conviene separar dos afirmaciones que se confunden con facilidad: “sistema disponible” y “dato recuperable”. Tienen evidencias distintas y no se demuestran igual.
Por último, prepare la evidencia antes del incidente; reconstruir registros durante una crisis es la forma más segura de no tenerlos. Definir quién prueba, cada cuánto y con qué constancia es una de las capacidades que debe exigir a un proveedor de servicios gestionados, no un extra del soporte reactivo.
Comprobación práctica: cinco preguntas antes de dar tu protección por buena
Somete tu protección a cinco preguntas cuya respuesta no admite matices.
- ¿Puede el administrador habitual borrar la copia de seguridad? Si sí, no hay capa independiente, solo ilusión de redundancia.
- ¿Cuándo se restauró por última vez un sistema completo y cuánto tardó? Exige fecha y hora. Sin registro, la prueba no se ha hecho.
- ¿Cuál es el punto de restauración más antiguo de cada aplicación crítica? Si son horas, no hay margen frente a un cifrado que tarda en detectarse.
- ¿Qué pasa si el fallo se descubre dos días después? Si las copias ya fueron sobrescritas, la retención está mal dimensionada.
- ¿Existe al menos una copia que no depende de credenciales ni de la red de producción? Es el único escenario que sobrevive a un atacante con privilegios.
Convierte cada respuesta en una acción con responsable y fecha. No lo archives sin cambios. Si acabas de externalizar tu IT, revisa el proceso de incorporación con un nuevo proveedor de IT para integrar estas pruebas desde el inicio.
Conclusión: la alta disponibilidad no sustituye a la copia de seguridad
Con esas respuestas sobre la mesa, el argumento central se sostiene por sí solo: la redundancia de nodo es una buena decisión de infraestructura y no es una estrategia de datos. Ambas conviven en un diseño sólido.
Tres acciones inmediatas si gestionas una PYME: comprobar quién puede borrar tus copias, registrar la fecha de la última restauración real y verificar que hay una copia inmutable o fuera de línea.
Traslada la conversación al negocio: ¿cuánto tiempo puede estar parada la facturación y cuántos días de datos puede permitirse perder la empresa? Esas cifras definen el diseño mejor que cualquier catálogo.
Los criterios de diseño aquí expuestos se basan en práctica profesional reconocida y marcos de referencia como NIST y CISA; las fuentes primarias específicas se indican donde están disponibles.
