Qué es un backup: tipos, regla 3-2-1 y estrategia en empresa

Un backup (o copia de seguridad) es una copia independiente de los datos de un sistema, guardada en un soporte distinto, que permite recuperarlos si los originales se pierden, se corrompen, se borran o se cifran. La definición parece obvia, pero la palabra "independiente" hace casi todo el trabajo: una copia que comparte fallo con el original no es un backup, es una réplica. Y una copia que nadie ha probado a restaurar no es un backup tampoco, es una esperanza. Esta entrada explica qué es un backup en sentido técnico, los tipos que existen, la regla 3-2-1 que se ha vuelto estándar mínimo y por qué la mayoría de empresas que sufren un ransomware grave tenían backups y aun así no pudieron restaurar.

Qué es un backup: definición técnica

Un backup es una copia coherente de un conjunto de datos en un punto del tiempo, almacenada en un medio diferente del original, recuperable de forma autónoma y verificable. Las tres piezas operativas son:

• Coherente: el sistema desde el que se copia tiene que estar en un estado consistente. Copiar una base de datos en plena escritura sin snapshot o sin pausar las transacciones produce un backup que no se puede restaurar.
• Independiente: la copia tiene que poder sobrevivir al fallo del original. Si el ransomware cifra el servidor y también la unidad de red donde "están los backups", esa unidad no era un backup, era otra copia accesible al mismo atacante.
• Verificable: hay que poder restaurar los datos del backup en un entorno limpio y comprobar que la restauración funciona. Si nunca se ha probado, el backup no existe a efectos prácticos.

El backup es la última defensa de la seguridad de la información, la que se activa cuando todas las demás han fallado. Un plan bien diseñado convierte un ransomware grave en un problema operativo de días; un plan mal diseñado lo convierte en una crisis que paraliza la organización durante semanas.

Tipos de backup por estrategia de copia

Hay tres tipos clásicos según qué datos se copian en cada ciclo. Casi todas las soluciones modernas combinan los tres.

Backup completo (full backup)

Copia todos los datos del conjunto protegido cada vez que se ejecuta. Ocupa más espacio y tarda más, pero permite restaurar leyendo un único conjunto. Suele ser la copia base sobre la que se construyen los siguientes.

Backup incremental

Copia solo los datos que cambiaron desde la última copia, sea completa o incremental. Ocupa poco y va rápido, pero restaurar exige leer el último completo más toda la cadena de incrementales hasta el punto deseado. Si se rompe un eslabón intermedio, la restauración a partir de ese punto se complica.

Backup diferencial

Copia los datos que cambiaron desde la última copia completa, sin importar cuántos diferenciales se hicieron por el medio. Ocupa más que un incremental, menos que un completo, y restaurar es más sencillo: un completo más un diferencial.

Backup sintético

Combina un completo antiguo con incrementales posteriores en el propio almacenamiento de backup, sin tocar al sistema origen, para producir un nuevo "completo" virtual sin coste de red ni de carga en producción. Es la técnica habitual en soluciones empresariales modernas.

Mirror y replicación

Mantienen una réplica continua del conjunto de datos en otra ubicación. No son backups por sí solos: si borras un archivo, el espejo lo replica y lo borras también. La replicación protege contra fallo de hardware o desastre físico, pero no contra ataques o errores humanos. Forma parte de una estrategia, no la sustituye.

La regla 3-2-1 (y su evolución 3-2-1-1-0)

La regla 3-2-1 nació en los 90, sigue siendo el estándar mínimo y se cita en todas las normativas relevantes (ISO 27001, ENS, NIS2, DORA, NIST). Dice:

• 3 copias de los datos: el original más dos backups.
• 2 soportes distintos: si el original está en disco SSD, las copias deberían estar en al menos dos tipos distintos (disco, cinta, cloud, NAS, etc.).
• 1 copia fuera de la ubicación principal: si el original está en la sede, una copia debe estar en otra sede o en cloud.

En la era del ransomware se ha extendido a 3-2-1-1-0:

• 1 copia inmutable o air-gapped (no accesible para escritura desde la red de producción). Es la única que sobrevive a un ransomware que comprometa al administrador.
• 0 errores: la copia debe verificarse y restaurarse periódicamente con éxito.

Esta versión es la que se cita en las recomendaciones recientes de INCIBE-CERT, CCN-CERT y entidades equivalentes europeas.

Backup vs disaster recovery vs archivado: no son lo mismo

Tres conceptos distintos que en empresa pequeña se mezclan y en empresa mediana ya hay que separar.

Backup

Recupera datos. Su objetivo es volver a tener los archivos, las bases de datos, las configuraciones y los buzones tal como estaban en un punto del tiempo. Las métricas que importan: RPO (Recovery Point Objective, cuánta pérdida de datos asumes) y RTO (Recovery Time Objective, cuánto tardas en estar operativo).

Disaster Recovery

Recupera la capacidad de operar, no solo los datos. Implica infraestructura alternativa lista o reconstruible, procedimientos para levantar servicios en otra ubicación, equipos preparados para ejecutarlos y comunicación a clientes. El DR usa los backups, pero no es solo backups: incluye redes, identidades, servidores, integraciones y personas.

Archivado

Guarda datos a largo plazo por motivos legales, regulatorios o de negocio. Está pensado para consulta esporádica, no para recuperación operativa rápida. Cumple obligaciones (RGPD, normativa contable, retención de logs en NIS2) pero no sustituye al backup operativo.

Mezclar estos tres conceptos es uno de los errores más caros que vemos en respuestas a incidentes: el cliente dice "tenemos backup" cuando lo que tiene es replicación, o "tenemos DR" cuando lo que tiene es una copia fuera de sede sin procedimiento ni infraestructura para levantar nada.

Cómo diseñar una estrategia de backup en empresa

Una estrategia razonable de backup empresarial responde a seis preguntas en este orden.

1. Qué hay que proteger

Inventario realista: servidores físicos, máquinas virtuales, bases de datos, buzones de correo (Microsoft 365, Google Workspace), repositorios de código, datos en SaaS (Salesforce, Notion, Jira), configuraciones de infraestructura cloud (plantillas CloudFormation, Terraform), endpoints críticos. Lo que no está en el inventario no se respalda.

2. Qué pérdida es aceptable (RPO)

¿Cuánta información perderías sin que el negocio se rompa? En sistemas críticos B2B, el RPO suele ser minutos, lo que exige replicación más backups frecuentes. En sistemas internos no críticos, 24 horas suele ser suficiente. Esta cifra determina la frecuencia del backup.

3. Cuánto tardas en volver (RTO)

¿Cuánto puedes estar parado? Define la tecnología que necesitas: para RTOs bajos hace falta backup con restauración instantánea (montar la copia como disco operativo), virtualización en caliente, plan de DR ejecutable. Para RTOs altos (días), una restauración estándar desde cloud es suficiente.

4. Cuánto tiempo guardas las copias

La política de retención depende de tres cosas: obligaciones legales, ciclos de auditoría y patrón de ataque. Un esquema habitual en PYME:

• Backups diarios: 14 a 30 días.
• Backups semanales: 3 a 6 meses.
• Backups mensuales: 1 a 7 años (según sector regulado).

5. Dónde se guardan

Cumpliendo 3-2-1-1-0: producción más al menos dos copias en soportes y ubicaciones distintas, con al menos una inmutable. Las opciones habituales:

• NAS local para restauraciones rápidas.
• Cinta o disco offline para inmutabilidad real.
• Cloud con bloqueo de objeto (object lock) para inmutabilidad gestionada.
• Sede secundaria o proveedor de DR para resistencia geográfica.

6. Quién prueba que funciona

La responsabilidad debe estar nombrada y la prueba debe ejecutarse periódicamente (al menos trimestral en sistemas críticos, semestral en el resto). Sin prueba documentada, el plan no existe en la práctica.

Por qué muchas empresas con backup no pudieron restaurar

Patrones que aparecen una y otra vez en respuesta a incidentes de ransomware:

1. El backup estaba en una unidad de red accesible. El ransomware lo cifró junto a producción. Sin copia inmutable, no había nada que restaurar.
2. Los backups eran replicación, no copias independientes. Cuando se borraron archivos críticos, el espejo replicó el borrado.
3. Las credenciales de administración de backup estaban en Active Directory comprometido. El atacante accedió a la consola y borró los puntos de restauración antes de ejecutar el cifrado.
4. Nadie probaba restaurar. La copia existía, pero llevaba meses sin ser verificada. En el momento del incidente, descubrieron que llevaba meses fallando en silencio.
5. El RTO real era 5 veces el RTO en papel. La organización dimensionó la red, los servidores y la capacidad humana para una restauración pequeña; cuando tocó restaurar 30 servidores y 200 endpoints a la vez, el plan se vino abajo.
6. Las claves de cifrado de los backups se habían perdido o estaban en el mismo dominio comprometido. Backup cifrado sin clave no es un backup.

Estos seis fallos resumen casi todos los incidentes de respuesta DFIR en los que vemos a empresas con copias paralizadas durante semanas.

Backup en cloud, on-premise e híbrido

Cada modelo tiene un perfil distinto.

Backup on-premise

Almacenamiento en la propia infraestructura del cliente. Ventaja: restauración rápida en red local, control total. Desventaja: vulnerable a desastre físico y a compromisos de red interna. Necesita copia adicional fuera de sede para cumplir 3-2-1.

Backup en cloud

Almacenamiento en un proveedor cloud (AWS S3, Azure Blob, Google Cloud Storage, Backblaze B2 o soluciones especializadas como Veeam Cloud Connect, Acronis, Datto). Ventaja: ubicación remota nativa, escalabilidad, modelos de inmutabilidad gestionados (object lock). Desventaja: coste de salida (egress) si toca restaurar volúmenes grandes, dependencia del proveedor, latencia en RTO bajos.

Backup híbrido

Combina copias locales (para RTOs bajos) con copias en cloud (para resistencia geográfica e inmutabilidad). Es el modelo más común en empresas medianas a 2026.

SaaS backup

Los datos en SaaS (Microsoft 365, Google Workspace, Salesforce) necesitan backup independiente del propio proveedor. El modelo de responsabilidad compartida deja la recuperación de datos borrados o cifrados como responsabilidad del cliente, no del SaaS. Herramientas como Veeam para M365, Druva, Spanning Backup (Kaseya) o AvePoint cubren este caso. Ignorarlo es un fallo común.

Inmutabilidad: la pieza que cambia el juego frente al ransomware

Una copia inmutable es una copia que no se puede modificar ni borrar durante un periodo definido, ni siquiera por el administrador del sistema. Es la única defensa real cuando el atacante consigue privilegios de administrador en producción y va a por los backups antes de cifrar.

Tres formas habituales de conseguirla:

1. Cintas físicas en custodia externa: el clásico, sigue siendo robusto.
2. Cloud con object lock en modo compliance: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage retention policies. Configurados en modo compliance, ni el propietario puede borrarlos antes del vencimiento.
3. Appliances de backup con inmutabilidad nativa: Veeam Hardened Repository, Rubrik, Cohesity, Datto SIRIS y similares ofrecen modelos de inmutabilidad gestionados.

La inmutabilidad es lenta de configurar y dolorosa cuando hay que mover datos, pero es la diferencia entre recuperar y no recuperar tras un ataque serio.

Probar las copias: el paso que casi nadie ejecuta

Probar significa restaurar de verdad, en un entorno de pruebas, sin atajos, y validar que los datos restaurados funcionan. Mínimos razonables:

• Restauración de archivo aislado mensual: bajar un archivo cualquiera del backup y comprobar que se abre.
• Restauración de máquina completa trimestral: levantar una VM o un servidor desde backup en entorno aislado y comprobar que arranca y opera.
• Simulacro de desastre anual: ensayar la recuperación de un servicio crítico al completo, midiendo RTO real y comparándolo con el RTO en papel.

Un backup que no se prueba no es estrategia: nadie sabe si funciona hasta el día en que se necesita, y ese día es tarde para descubrirlo.

Errores frecuentes y cómo evitarlos

Patrones que aparecen en auditorías y revisiones:

1. Backup en la misma red, sin segmentación ni MFA. Sumar al sistema de backup la MFA, el aislamiento de red de gestión y cuentas dedicadas independientes del directorio principal.
2. Logs y telemetría de backup no monitorizados. Si nadie ve los fallos, los fallos se acumulan en silencio. Integrar la plataforma de backup en el SIEM y en el SOC.
3. Sin estrategia de bases de datos. Backups de archivos sobre carpetas que contienen ficheros de base de datos abiertos no producen copias coherentes. Usar el agente o el método de la base de datos (SQL Server Backup, pg_dump, mysqldump consistente, Oracle RMAN, etcétera).
4. Sin retención de versiones para SaaS. Microsoft 365 conserva borrados típicamente 30-93 días según licencia; pasado ese tiempo, sin backup independiente, el dato se pierde.
5. Sin documentación. El procedimiento de restauración debe estar escrito, accesible offline y probado por personas distintas a quien lo escribió.

Preguntas frecuentes

¿Qué es un backup y para qué sirve?

Un backup es una copia independiente de los datos que permite recuperarlos si los originales se pierden por fallo de hardware, error humano, desastre físico, ataque (especialmente ransomware) o corrupción lógica. Es la última capa de defensa de la seguridad de la información: cuando todo lo demás falla, el backup es lo que separa el incidente molesto de la crisis existencial.

¿Cuál es la diferencia entre backup completo, incremental y diferencial?

El completo copia todos los datos cada vez; el incremental copia solo lo cambiado desde la última copia (sea completa o incremental); el diferencial copia lo cambiado desde la última copia completa. El completo ocupa más y tarda más; el incremental va rápido pero exige cadena íntegra para restaurar; el diferencial está en el medio.

¿Qué es la regla 3-2-1 de backup?

3 copias de los datos (original más dos backups), en 2 soportes distintos, con 1 copia fuera de la ubicación principal. Es el estándar mínimo desde hace décadas. La extensión moderna 3-2-1-1-0 añade 1 copia inmutable y 0 errores verificados en restauraciones de prueba.

¿Cada cuánto hay que hacer backup?

Depende del RPO que el negocio acepte. En sistemas críticos B2B, el RPO suele ser minutos, lo que exige backups muy frecuentes o replicación con snapshots. En sistemas internos no críticos, 24 horas suele ser suficiente. Es una decisión de negocio antes que técnica.

¿Es suficiente con tener backup para protegerse del ransomware?

No. El backup es la última capa, no la única. Protege contra ransomware si y solo si los backups son inmutables o están aislados de la red, las credenciales de gestión son independientes, la telemetría se monitoriza y se prueba la restauración periódicamente. Sin esas condiciones, el atacante moderno borra o cifra los backups antes de pedir rescate.

¿Microsoft 365 ya hace backups automáticos?

Microsoft 365 mantiene retención y papelera, pero no es un servicio de backup independiente. Los datos borrados se recuperan dentro de la ventana de retención (típicamente 30-93 días según licencia); pasado ese plazo, sin backup independiente de terceros, los datos se pierden. La misma lógica aplica a Google Workspace y a la mayoría de SaaS críticos.

¿Es legal restaurar datos personales tras un incidente?

Sí, y en algunos casos es obligado por el principio de integridad y disponibilidad del RGPD y por las normativas de continuidad de servicios esenciales (NIS2, DORA). Lo que cambia es la notificación del incidente a la autoridad y, si procede, a los afectados. El procedimiento de restauración debe estar documentado y trazado para auditorías posteriores.

Recursos relacionados

• Qué es un ransomware
• Tipos de malware
• Qué es un SOC
• Qué es EDR
• NIS2 España: cómo cumplir
• DFIR: respuesta a incidentes

---

Un backup bien diseñado no se nota hasta el día que salva una empresa. En Secra revisamos planes de backup desde la óptica del atacante: cómo intentaríamos comprometerlos, qué se nos resistiría y qué cambiaríamos para que la siguiente respuesta a incidente sea cuestión de horas en vez de semanas. Cuéntanos qué tienes hoy y vemos qué falta.