Estrategia de backups 3-2-1 para empresas

Los backups son el seguro de vida de cualquier empresa. Y como ocurre con los seguros, su valor solo se comprende completamente cuando se necesitan. La diferencia entre una empresa que sobrevive a un incidente grave (ransomware, fallo de hardware, error humano, desastre natural) y una que no lo hace está, en gran medida, en la calidad de su estrategia de backups. No en si tenía backups, sino en si eran correctos, recientes y restaurables.

La regla 3-2-1 de backups es el estándar de facto en la industria para definir una estrategia mínima de protección de datos. Enunciada originalmente por el fotógrafo Peter Krogh en el contexto de la fotografía digital, fue adoptada rápidamente por la industria de TI por su simplicidad y eficacia. La regla dice: mantén 3 copias de tus datos, en 2 tipos diferentes de medios de almacenamiento, con 1 copia fuera de las instalaciones (offsite). Esta regla, aparentemente simple, elimina los puntos únicos de fallo más comunes en las estrategias de backup.

Sin embargo, la regla 3-2-1 clásica tiene sus limitaciones frente a las amenazas modernas, especialmente el ransomware. Por eso han surgido extensiones como 3-2-1-1-0 (que añade 1 copia inmutable/air-gapped y verificación con 0 errores) y 4-3-2. En esta guía cubrimos tanto la implementación de la regla básica como sus extensiones más robustas, siempre con enfoque práctico y herramientas reales.

Qué significa exactamente la regla 3-2-1

El 3 de la regla significa que debes tener tres copias de tus datos: el original (los datos en producción) y dos copias de backup. Muchas empresas tienen una sola copia de backup y creen que están protegidas. No lo están: si el backup falla o está corrupto en el momento en que se necesita (algo que ocurre con más frecuencia de lo que se querría admitir), no hay alternativa. Tres copias proporcionan redundancia real.

El 2 significa que esas copias deben estar en 2 tipos diferentes de medios de almacenamiento. La razón es que los fallos de almacenamiento tienden a correlacionarse: si tienes dos copias en el mismo tipo de almacenamiento (por ejemplo, dos discos del mismo modelo comprados al mismo tiempo), es más probable que fallen de forma simultánea o correlacionada que si usas medios distintos. La combinación más común es disco duro local + cinta o disco duro externo + cloud.

El 1 significa que al menos una copia debe estar offsite, es decir, en una ubicación física diferente. Esto protege contra desastres que afectan a una ubicación completa: incendio, inundación, robo, corte de suministro eléctrico prolongado. Una copia en la nube cuenta como offsite. Una copia en un servidor en la sala de al lado, no.

La amenaza del ransomware y la extensión 3-2-1-1-0

El ransomware ha cambiado el escenario de los backups de forma fundamental. El ransomware moderno no solo cifra los ficheros del sistema en producción: activamente busca y destruye o cifra los backups antes de revelar su presencia. Un backup en una unidad de red accesible desde el servidor comprometido es tan vulnerable como los datos de producción. La regla 3-2-1 clásica es insuficiente frente a esta amenaza si no incluye copias inmutables.

La extensión 3-2-1-1-0 añade dos requisitos críticos: el primer 1 adicional significa que al menos una copia debe ser inmutable (immutable backup) o estar en air-gap (completamente desconectada de la red). Una copia inmutable es aquella que no puede ser modificada ni eliminada, ni siquiera por administradores con acceso root o Domain Admin, durante un periodo de tiempo definido. El 0 significa que la estrategia debe verificar que los backups tienen 0 errores, es decir, que se pueden restaurar correctamente.

Las principales plataformas de almacenamiento en nube (AWS S3, Azure Blob Storage, Backblaze B2) ofrecen funcionalidades de Object Lock con política WORM (Write Once, Read Many) que implementan la inmutabilidad a nivel de objetos. Una vez configurado, ni el propietario de la cuenta puede eliminar o modificar esos objetos antes de que expire el periodo de retención. Esta característica, combinada con una política de backups en la nube, proporciona protección efectiva contra ransomware.

Inventario y clasificación de datos: el primer paso obligatorio

Antes de diseñar una estrategia de backups, es imprescindible saber qué datos tienes y cuál es su criticidad. El inventario de datos debe identificar todos los sistemas que generan o almacenan datos importantes: servidores de ficheros, bases de datos, servidores de aplicaciones, sistemas de correo electrónico, sistemas ERP/CRM, equipos de usuario y cualquier servicio SaaS con datos propios.

Para cada sistema o conjunto de datos, deben definirse dos métricas clave: el RTO (Recovery Time Objective) y el RPO (Recovery Point Objective). El RTO define cuánto tiempo puede estar ese sistema no disponible antes de que el impacto en el negocio sea inaceptable. El RPO define cuánto dato se puede perder como máximo (cuánto tiempo atrás debe estar el último punto de restauración disponible). Sistemas diferentes tienen diferentes RTO y RPO, y la estrategia de backup debe adaptarse a esa variedad.

La clasificación de datos en niveles de criticidad (por ejemplo, Crítico, Alto, Medio, Bajo) simplifica la definición de políticas de backup: los datos críticos necesitan RPO de minutos o pocas horas y RTO de horas; los datos de archivo histórico pueden tener RPO de 24 horas y RTO de días. Esta clasificación también guía las decisiones de inversión en infraestructura de backup, concentrando los recursos donde el impacto sería mayor.

Tipos de backup: completo, incremental y diferencial

Los tres tipos fundamentales de backup tienen diferentes características en cuanto a tiempo de realización, espacio necesario y velocidad de restauración. El backup completo copia todos los datos cada vez: es el más lento de realizar y el que más espacio ocupa, pero el más rápido de restaurar porque todo está en un único conjunto. Es la base sobre la que se construyen las estrategias incrementales y diferenciales.

El backup incremental solo copia los datos que han cambiado desde el último backup (sea completo o incremental). Es el más rápido y eficiente en espacio de todos los tipos, pero la restauración requiere la cadena completa: el último completo más todos los incrementales hasta el punto deseado. Si algún incremental en la cadena está corrupto, la restauración puede fallar. La deduplicación y compresión modernas hacen que los incrementales sean la estrategia predominante en entornos empresariales actuales.

El backup diferencial copia los datos que han cambiado desde el último backup completo. Es más lento que el incremental (el diferencial crece con el tiempo hasta el próximo completo) pero más rápido de restaurar (solo necesitas el último completo y el último diferencial). Muchas organizaciones usan una estrategia combinada: backup completo semanal (generalmente el fin de semana) y diferenciales o incrementales cada noche.

Herramientas de backup para entornos empresariales

El mercado de herramientas de backup para empresas es amplio, con opciones para todos los tamaños y presupuestos. Veeam Backup & Replication es la solución más popular en entornos Windows y VMware/Hyper-V: su integración con las APIs de virtualización permite backups de VMs sin agente, snapshots consistentes con VSS (Volume Shadow Copy Service) y restauración granular de ficheros individuales o elementos de aplicación (correos de Exchange, objetos de AD, etc.).

Nakivo Backup & Replication es una alternativa a Veeam con una propuesta de valor similar a un precio más competitivo, especialmente atractiva para pequeñas y medianas empresas. Commvault es la opción enterprise de referencia para entornos heterogéneos muy complejos con múltiples sistemas operativos, bases de datos y plataformas en la nube. Bacula y Amanda son alternativas de código abierto que requieren mayor inversión en configuración pero ofrecen mucha flexibilidad sin coste de licencia.

Para entornos principalmente Linux, Restic y BorgBackup son herramientas de línea de comandos de código abierto con características modernas: deduplicación, compresión, cifrado de extremo a extremo y soporte para múltiples backends de almacenamiento (local, SFTP, S3, Azure, Google Cloud). Proxmox Backup Server, mencionado en el artículo sobre Proxmox, es específico pero excelente para entornos virtualizados en Proxmox. La clave es elegir la herramienta adecuada para el entorno y no intentar forzar una solución genérica donde se necesita integración específica.

Criterios para evaluar una herramienta de backup empresarial

• Compatibilidad con los sistemas que necesitas proteger (VMs, bases de datos, aplicaciones SaaS)
• Capacidades de backup consistente con aplicación (application-aware backup para Exchange, SQL, Oracle)
• Opciones de restauración granular: recuperar un fichero individual sin restaurar toda la VM
• Soporte para backups inmutables o integración con almacenamiento WORM
• Capacidades de replicación para DR (Disaster Recovery) y RTO bajo
• Alertas y reporting automatizados para detectar fallos de backup inmediatamente
• Cifrado de datos en tránsito y en reposo
• Coste total (licencias + almacenamiento + soporte) a 3 años

Almacenamiento de backups: opciones y consideraciones

La elección del almacenamiento de backups tiene implicaciones directas en la fiabilidad, el coste y la velocidad de restauración. El almacenamiento local en disco (NAS, DAS o SAN dedicada a backups) ofrece la mayor velocidad de restauración y control total, pero no protege contra desastres que afectan a las instalaciones. Las cintas magnéticas (LTO) ofrecen el coste por gigabyte más bajo para retenciones largas, capacidad de air-gap físico y una vida útil muy larga, pero la velocidad de restauración es menor y la gestión más compleja.

El almacenamiento en nube se ha convertido en el componente offsite de referencia para la mayoría de las empresas. AWS S3 Glacier Instant Retrieval, Azure Blob Storage Archive y Backblaze B2 ofrecen almacenamiento a costes muy reducidos (entre 0,001 y 0,004 dólares por GB al mes en las tiers de archivo) para retenciones largas. La clave es calcular correctamente el coste total incluyendo los cargos por transferencia de datos (egress), especialmente si se trata de restauraciones frecuentes.

Los appliances de backup dedicados (como los de Dell EMC, HPE StoreOnce o ExaGrid) combinan hardware optimizado con software de deduplicación en línea, ofreciendo ratios de reducción de datos de 10:1 a 30:1 para datos típicamente encontrados en entornos empresariales. Aunque la inversión inicial es significativa, el coste por GB efectivo puede ser menor que el almacenamiento en nube para grandes volúmenes con acceso frecuente. Los appliances modernos también pueden actuar como repositorios secundarios para herramientas como Veeam.

Backups de bases de datos: consideraciones especiales

Las bases de datos presentan desafíos específicos para los backups que no se resuelven con un simple backup de ficheros. Una base de datos activa puede tener transacciones en curso, datos en memoria no volcados al disco y estructuras internas que quedan inconsistentes si se copia a nivel de fichero sin los mecanismos adecuados. Un backup de base de datos tomado sin las herramientas adecuadas puede ser irrestauable.

Para SQL Server, la estrategia recomendada combina backups completos semanales, backups diferenciales diarios y backups del log de transacciones cada 15-60 minutos (dependiendo del RPO requerido). Esta estrategia permite restaurar hasta un punto específico en el tiempo (Point-in-Time Recovery, PITR), no solo al último backup completo. La herramienta nativa de SQL Server, junto con SQL Server Management Studio o PowerShell, es suficiente para implementar esta estrategia.

Para bases de datos PostgreSQL, pg_dump y pg_basebackup son las herramientas nativas de backup. pg_basebackup permite crear backups del clúster completo de forma consistente y pg_dump permite exportar bases de datos individuales en formato SQL o custom. Para PITR en PostgreSQL, la configuración de WAL archiving (archivado del Write-Ahead Log) es el equivalente al log de transacciones de SQL Server. Herramientas como Barman (Backup and Recovery Manager) automatizan la gestión de backups y PITR para PostgreSQL en entornos de producción.

Backups en la nube: SaaS y IaaS

Un error conceptual frecuente es asumir que los datos en la nube ya están protegidos por el proveedor. En el modelo de responsabilidad compartida de los proveedores cloud, el proveedor garantiza la disponibilidad de la infraestructura, pero la protección de los datos es responsabilidad del cliente. Esto aplica tanto a servicios SaaS como Microsoft 365, Salesforce o Google Workspace, como a IaaS como EC2 o Azure VMs.

Para Microsoft 365, el servicio incluye papelera de reciclaje y versionado de SharePoint, pero no proporciona backups en el sentido tradicional con retenciones largas ni restauración granular a un punto en el tiempo. Herramientas como Veeam Backup for Microsoft 365, Acronis Cyber Backup o AvePoint ofrecen backups completos de Exchange Online, SharePoint, OneDrive y Teams con retenciones configurables y restauración granular. Para la mayoría de las empresas con datos críticos en Microsoft 365, una solución de backup específica es imprescindible.

Para datos en IaaS (VMs en AWS, Azure o GCP), los snapshots nativos del proveedor son el punto de partida pero no deben ser la estrategia única. Los snapshots de EC2 o Azure VM son consistentes a nivel de disco pero pueden no ser consistentes a nivel de aplicación para bases de datos u otras aplicaciones que mantienen estado en memoria. Además, están en la misma cuenta cloud que los datos de producción, por lo que un compromiso de la cuenta puede afectarlos. Soluciones como AWS Backup (con cross-account copy), Veeam for AWS/Azure o Commvault proporcionan backups más robustos con opciones de inmutabilidad y copia a ubicaciones separadas.

Pruebas de restauración: el paso que todos omiten

Un backup que no se ha probado no es un backup: es una esperanza. Las pruebas de restauración son el componente más crítico y más frecuentemente omitido de cualquier estrategia de backup. Las razones habituales para no hacerlas son la falta de tiempo, el miedo a afectar al entorno de producción y la falsa seguridad de ver los jobs de backup completarse con éxito. Ninguna de estas razones es válida.

Las pruebas de restauración deben ser periódicas, documentadas y variadas en alcance. Como mínimo, deben incluir: restauración de ficheros individuales desde backups recientes (semanal), restauración de una base de datos a un entorno de pruebas (mensual) y simulacro completo de recuperación de desastre (anual o semestral). Los simulacros de DR son especialmente valiosos porque revelan dependencias ocultas, procedimientos incorrectos en los runbooks y problemas de acceso a credenciales bajo presión.

Las herramientas modernas de backup como Veeam incluyen funcionalidades de SureBackup que automatizan las pruebas de restauración: arrancan la VM restaurada en un entorno de red aislado, ejecutan pruebas de conectividad y de aplicación y generan un informe con el resultado. Esto permite verificar automáticamente que las VMs son restaurables sin impacto en producción ni esfuerzo manual significativo. La configuración de pruebas automáticas semanales debería ser estándar en cualquier entorno empresarial.

Cumplimiento normativo y backups: ENS, RGPD e ISO 27001

La mayoría de los marcos normativos aplicables a empresas españolas incluyen requisitos explícitos sobre backups y recuperación. El Esquema Nacional de Seguridad (ENS), de aplicación obligatoria en el sector público y recomendado en el privado, especifica controles de backup proporcionales al nivel de seguridad requerido. El RGPD exige medidas técnicas apropiadas para proteger los datos personales, lo que incluye la capacidad de recuperarlos ante incidentes.

ISO 27001 incluye en su Anexo A el control A.12.3.1 (Information backup) que requiere que se realicen copias de seguridad de la información, el software y las imágenes de sistema, y que se prueben regularmente de acuerdo con una política de copias de seguridad acordada. La política de backup documentada, los registros de ejecución, los informes de pruebas de restauración y los registros de incidentes relacionados con backups son evidencias necesarias en una auditoría ISO 27001.

El cifrado de backups es a la vez una buena práctica de seguridad y un requisito de cumplimiento cuando los backups contienen datos personales bajo el RGPD. El principio es claro: si un backup cifrado cae en manos equivocadas (por pérdida de un disco o acceso no autorizado a almacenamiento en nube), sin la clave de cifrado los datos son ilegibles. La gestión de las claves de cifrado de backups debe ser especialmente cuidadosa: perder la clave significa perder el acceso a los backups.

Documentación del plan de recuperación ante desastres

La estrategia de backups no es completa sin un Plan de Recuperación ante Desastres (DRP, Disaster Recovery Plan) documentado. El DRP describe los procedimientos paso a paso para recuperar cada sistema crítico ante diferentes escenarios de fallo. Sin documentación, la recuperación depende del conocimiento que esté en la cabeza de personas específicas que pueden no estar disponibles en el momento del desastre.

Los runbooks de recuperación deben ser lo suficientemente detallados para que alguien con conocimientos técnicos generales (pero no necesariamente experto en ese sistema específico) pueda seguirlos bajo presión. Deben incluir: el sistema afectado y su criticidad, el procedimiento de restauración paso a paso con comandos exactos, los tiempos estimados de cada paso, las credenciales de acceso necesarias (referencia al gestor de contraseñas, no las credenciales en texto claro), y los contactos de escalada.

El DRP debe revisarse y actualizarse cada vez que cambia la infraestructura (se añaden sistemas, cambian credenciales, se modifican procedimientos) y al menos anualmente aunque no haya cambios. Un DRP desactualizado puede ser peor que no tener ninguno: da falsa confianza y lleva a tomar decisiones incorrectas durante un incidente. La simulación periódica del DRP es la única forma de verificar que sigue siendo válido y que el equipo sabe cómo ejecutarlo.

Errores más comunes en estrategias de backup empresarial

• Nunca probar las restauraciones: descubrir que el backup es corrupto o irrestauable cuando lo necesitas
• Tener todas las copias en la misma red o cuenta, vulnerables al mismo ataque de ransomware
• No cifrar los backups que contienen datos personales o confidenciales
• No monitorizar los jobs de backup: fallos que pasan desapercibidos durante semanas
• Sobredimensionar el RPO: hacer backups diarios de sistemas que necesitan RPO de minutos
• Olvidar incluir en el backup los datos de configuración (firewalls, switches, servidores de aplicación)
• No actualizar el DRP cuando cambia la infraestructura
• Almacenar las claves de cifrado de los backups solo en los sistemas que se están protegiendo
• Confiar en que los snapshots del proveedor cloud son suficientes sin validar la política de retención

No tienes backups hasta que hayas probado que puedes restaurar. Todo lo anterior es simplemente esperanza comprimida y almacenada en algún disco.

Conclusión: la inversión en backups es la más rentable de TI

Implementar una estrategia de backups robusta basada en la regla 3-2-1 (y mejor aún, 3-2-1-1-0) no es el proyecto más glamuroso de TI, pero sí probablemente el más rentable en términos de riesgo mitigado por euro invertido. Un incidente de ransomware que destruye datos sin backup puede costar el cierre del negocio; el mismo incidente con backups inmutables y un DRP bien documentado se convierte en un problema de dos días de trabajo.

El camino para una estrategia de backups madura empieza por el inventario y la clasificación de datos, sigue con la elección de herramientas adecuadas y la implementación de copias en múltiples ubicaciones con al menos una inmutable, y se consolida con las pruebas periódicas de restauración y el mantenimiento del DRP actualizado. Ninguno de estos pasos es opcional; todos son necesarios para que la estrategia funcione cuando más se necesita.

En CiberForja tenemos artículos específicos sobre configuración de Veeam Backup & Replication, implementación de Restic para entornos Linux y configuración de backups inmutables en AWS S3 con Object Lock, que complementan esta guía conceptual con implementaciones concretas paso a paso.