Backups empresariales: política mínima recomendada para 2026

Políticas de respaldo para reducir riesgo operativo en infraestructura TI: regla 3-2-1, tipos de backup, periodicidad, verificación y recuperación ante desastres.

1. Por qué las empresas fallan en backups (y cómo evitarlo)

Las estadísticas son alarmantes:

• El 58% de las empresas que sufren ransomware pagan rescate, pero solo el 65% recupera todos sus datos.
• El 34% de las empresas nunca prueba sus backups hasta que es demasiado tarde.
• El 77% de las organizaciones han encontrado fallos en sus backups durante una recuperación real.

Los errores comunes incluyen: backups incompletos, falta de backups offline (vulnerables a ransomware), ausencia de verificación periódica, y confiar en un solo método o ubicación.

2. La regla 3-2-1: estándar mínimo indiscutible

La regla 3-2-1 es el fundamento de cualquier estrategia de backup seria:

• 3 copias de los datos (1 copia primaria + 2 backups).
• 2 medios diferentes (ej: disco local + almacenamiento en nube, o disco externo + cinta).
• 1 copia fuera del sitio (offsite), idealmente geográficamente separada y air-gapped (sin conexión permanente a la red).

Para empresas con datos críticos, se recomienda extender a 3-2-1-1-0: una copia adicional inmutable (WORM - Write Once Read Many) y cero errores verificados.

3. Frecuencias y retenciones: datos según criticidad

No todos los datos merecen la misma política. Clasificar:

• Críticos (misión crítica): Bases de datos transaccionales, ERP, CRM, correo corporativo. Backup diario (incremental) + semanal completo. Retención: 30-90 días.
• Importantes: Documentos de trabajo compartidos, configuraciones de sistemas. Backup diario o cada 12 horas. Retención: 30 días.
• Estándar: Archivos personales no críticos. Backup semanal. Retención: 14-30 días.
• Archivo histórico: Datos que deben conservarse por regulación (ej: facturas de 5 años). Backup mensual + retención anual.

Parámetros técnicos sugeridos: Retention policy: Full semanal + incrementales diarios. Punto de recuperación objetivo (RPO): según negocio (ej: 15 min para transacciones, 24h para archivos).

4. Tipos de backup: cuándo usar cada uno

• Full (completo): Copia todos los datos seleccionados. Lento, consume espacio, pero restauración rápida. Programar semanal o mensualmente.
• Incremental: Solo datos cambiados desde el último backup (full o incremental). Rápido, espacio reducido. Restauración requiere el último full + todos los incrementales.
• Diferencial: Datos cambiados desde el último full. Restauración más rápida que incremental (solo full + último diferencial), pero ocupa más espacio con el tiempo.
• Sintético completo: El software construye un full combinando el full anterior con incrementales, sin necesidad de leer datos originales. Útil para sistemas con grandes volúmenes.

Recomendación: Full semanal + incrementales diarios para la mayoría de entornos.

5. Inmutabilidad: la defensa contra ransomware

El ransomware moderno busca backups. Si el backup es modificable o borrable por el atacante (o por el malware con credenciales del administrador), no sirve.

• Backup inmutable (WORM): Una vez escritos, los datos no pueden ser modificados, cifrados ni eliminados durante un período fijo (ej: 7-30 días).
• Dónde implementar: En almacenamiento en nube (AWS S3 Object Lock, Azure Immutable Blob Storage, Google Cloud Bucket Lock) o en appliances de backup con funcionalidad inmutable (Veeam Hardened Repository, Synology con WORM).
• Backup offline / air-gapped: Discos o cintas que no están conectadas a la red. El malware no puede alcanzarlos.

6. Verificación de backups: probar antes de necesitar

Un backup que no se prueba no es un backup, es una esperanza.

• Verificación automática de integridad: La mayoría del software de backup puede validar checksums y estructura de archivos.
• Restauración de prueba (test restore): Restaurar archivos aleatorios periódicamente. Idealmente, realizar una restauración completa de un sistema no crítico cada trimestre.
• Ejercicios de recuperación ante desastres (DR): Simular un escenario donde se pierde el servidor primario y se debe restaurar desde backups en un entorno alternativo.
• Documentar resultados: Tiempo de restauración real (RTO - Recovery Time Objective). Si excede lo esperado, ajustar estrategia.

7. Casos específicos: bases de datos, VM y SaaS

Cada entorno tiene consideraciones especiales:

• Bases de datos (SQL, Oracle, PostgreSQL): Usar backup consistente con transacciones (VSS en Windows, pg_dump, mysqldump, o backup nativo del motor). Evitar copiar archivos .mdf/.ndf sin detener el servicio.
• Máquinas virtuales (VMware, Hyper-V): Backup a nivel de hipervisor (Veeam, Commvault, Nakivo) permite restauración completa de VM en minutos. Alternativa: backup agente dentro de la VM.
• SaaS (Office 365, Google Workspace, Salesforce): El proveedor no es responsable de los datos del cliente. Contratar un backup de terceros (ej: Veeam Backup for M365, Afi.ai, Backupify).

8. Backups y cumplimiento normativo

Dependiendo de la industria, pueden existir requisitos legales:

• Ley de Protección de Datos Personales (Perú - Ley 29733): Exige medidas de seguridad, incluyendo backups, y retención según fines.
• ISO 27001 (A.12.3): Requiere políticas de backup y pruebas periódicas.
• SOX (Ley Sarbanes-Oxley) / PCI-DSS: Retenciones específicas para registros financieros o de tarjetas.
• RGPD (Europa): Derecho al olvido: los backups deben permitir eliminar datos de personas si se solicita (desafío técnico).

Consultar con el área legal sobre los plazos de retención exigibles.

9. Automatización y monitoreo de backups

La gestión manual de backups falla inevitablemente. Implementar:

• Automatización completa: Programación automática de backups, sin intervención humana recurrente.
• Alertas y reporting: Notificar por correo o integración con sistemas de monitoreo (ej: correo si un backup falla, si no se ejecuta, si el espacio se agota).
• Dashboard centralizado: Ver estado de todos los backups (éxito/fallo, tamaño, duración) en un solo lugar.
• Revisión semanal: Un administrador revisa los logs de backup para detectar fallos intermitentes no alertados.

10. RTO y RPO: definiendo objetivos de recuperación

• RPO (Recovery Point Objective): ¿Cuántos datos se pueden perder? (ej: 4 horas = máximo perder 4 horas de cambios). Define la frecuencia de backup.
• RTO (Recovery Time Objective): ¿Cuánto tiempo máximo puede estar el sistema caído? (ej: 8 horas). Define la velocidad de restauración y los procedimientos.

Ejemplo: Sistema de ventas online: RPO 15 min, RTO 1 hora. Backup incremental cada 15 min, almacenamiento rápido, procedimiento de restauración automatizado.

Para empresas pequeñas: RPO 24h (backup diario), RTO 24-48h es aceptable para sistemas no críticos.

11. Plan de recuperación ante desastres (DRP) mínimo

Tener backups no es suficiente si no hay un plan documentado de cómo usarlos. El DRP debe incluir:

• Mapa de sistemas con sus respectivos RPO/RTO.
• Lista de contactos y roles (quién autoriza, quién restaura, quién comunica).
• Procedimiento paso a paso para restaurar backups en caso de desastre (fallo masivo, ransomware, incendio).
• Infraestructura alternativa (servidores de respaldo, nube, lugar físico alternativo).
• Prueba anual de recuperación completa.

El DRP no debe ser un documento extenso y teórico; debe ser práctico y accionable en minutos.

12. Backups en la nube: no es "automágico"

Muchas empresas creen que por tener datos en la nube (SaaS o IaaS) ya están protegidas. Falso.

• AWS/Azure/GCP: Ofrecen durabilidad, pero la responsabilidad de backup es compartida. El cliente debe configurar snapshots, copias entre regiones y retención.
• Office 365/Google Workspace: El proveedor protege su infraestructura, no los datos del cliente. Sin un backup externo, un empleado malintencionado o un error pueden borrar datos sin recuperación.
• Backup como servicio (BaaS): Soluciones como Druva, Backblaze, o Acronis Cloud simplifican la gestión.