"Teníamos backups, pero cuando los necesitamos no servían." Es la frase más dolorosa que escuchamos en consultoría de infraestructura. Tener backups sin una política documentada es como tener un extintor sin saber dónde está ni si funciona. Esta política de respaldos es un template listo para adaptar a tu empresa. Define qué se respalda, con qué frecuencia, dónde se almacena, cómo se verifica y cómo se restaura.
Estructura del documento de política
Sección 1: Objetivo y alcance
El objetivo de esta política es garantizar la protección, disponibilidad y recuperabilidad de la información crítica de la empresa mediante procesos de respaldo sistemáticos, verificados y documentados.
El alcance cubre todos los sistemas de información de la empresa, incluyendo servidores físicos y virtuales, bases de datos, archivos compartidos, configuraciones de red y sistemas, aplicaciones empresariales (ERP, CRM, correo), datos en servicios cloud (Google Workspace, Microsoft 365, SaaS) y repositorios de código fuente.
Esta política aplica a todo el personal de TI responsable de la administración de sistemas y a cualquier proveedor externo que gestione infraestructura de la empresa.
Sección 2: Definiciones
Para evitar ambigüedad, el documento debe definir los términos clave. Backup completo es una copia íntegra de todos los datos del sistema. Backup incremental es una copia que solo incluye los datos que cambiaron desde el último backup (completo o incremental). Backup diferencial es una copia que incluye todos los datos que cambiaron desde el último backup completo. RTO (Recovery Time Objective) es el tiempo máximo aceptable para restaurar un sistema después de un fallo. RPO (Recovery Point Objective) es la cantidad máxima de datos que se pueden perder, medida en tiempo. Retención es el periodo durante el cual se conserva una copia de backup antes de eliminarla. Backup inmutable es una copia que no puede ser modificada ni eliminada durante un periodo definido, como protección contra ransomware.
Sección 3: Clasificación de sistemas
Clasifica cada sistema por criticidad para definir la frecuencia y prioridad de respaldo.
| Sistema | Criticidad | RPO | RTO | Responsable |
|---|---|---|---|---|
| Base de datos ERP | Crítica | 1 hora | 4 horas | Admin. BD |
| Servidor de correo | Crítica | 0 (cloud) | 2 horas | Admin. Sistemas |
| File server | Alta | 4 horas | 8 horas | Admin. Sistemas |
| Servidor web | Alta | 24 horas | 4 horas | Admin. Sistemas |
| Servidor de desarrollo | Media | 24 horas | 24 horas | Dev Lead |
| Configuraciones de red | Media | Semanal | 4 horas | Admin. Redes |
Adapta la tabla a tu empresa
Esta clasificación es un ejemplo. Cada empresa tiene diferentes sistemas y diferentes tolerancias a la pérdida de datos. Reúne a los responsables de cada área para definir juntos el RPO y RTO de cada sistema — no lo decides TI solo.
Sección 4: Estrategia de respaldo
Regla 3-2-1-1
La política establece que se mantendrán al menos 3 copias de los datos, en 2 tipos de almacenamiento diferentes (por ejemplo: disco local y almacenamiento cloud), con 1 copia fuera del sitio principal y 1 copia inmutable (protegida contra modificación y eliminación).
Frecuencia por tipo de sistema
Sistemas críticos (RPO ≤ 1 hora):
- Backup continuo de transacciones (WAL archiving en PostgreSQL, binlog en MySQL)
- Backup completo diario a las 02:00 hrs
- Backup incremental cada hora durante horario laboral (08:00-20:00)
Sistemas de alta prioridad (RPO ≤ 4 horas):
- Backup completo diario a las 03:00 hrs
- Backup incremental cada 4 horas
Sistemas de prioridad media (RPO ≤ 24 horas):
- Backup completo diario a las 04:00 hrs
Configuraciones y código:
- Backup de configuraciones de red (routers, firewalls, switches) semanal
- Repositorios de código: protegidos por el sistema de control de versiones (Git), backup del servidor de repositorio diario
Retención
| Tipo de backup | Retención |
|---|---|
| Diarios | 30 días |
| Semanales (domingos) | 3 meses |
| Mensuales (último día del mes) | 1 año |
| Anuales (31 de diciembre) | 5 años |
La retención de 5 años para backups anuales cubre el periodo que el SAT puede solicitar información fiscal. Industrias reguladas pueden requerir retenciones más largas.
Sección 5: Almacenamiento de respaldos
Define dónde se almacena cada copia.
Copia 1 — Local: Servidor NAS o almacenamiento dedicado en el mismo sitio. Proporciona restauración rápida para incidentes menores (archivo borrado, fallo de disco). No protege contra desastres físicos.
Copia 2 — Cloud: Servicio de almacenamiento cloud (AWS S3, Azure Blob, Backblaze B2, o similar). Proporciona protección contra desastres físicos. Los datos deben transmitirse cifrados (TLS) y almacenarse cifrados (AES-256). Las credenciales de acceso al almacenamiento cloud deben estar documentadas en un vault seguro accesible sin depender de la infraestructura principal.
Copia 3 — Inmutable: Almacenamiento con Object Lock (S3 Object Lock, Azure Immutable Blob) o medio offline (disco externo desconectado, cinta). No puede ser modificado ni eliminado durante el periodo de retención. Es la última línea de defensa contra ransomware que cifra o elimina backups accesibles.
Sección 6: Cifrado
Todos los backups deben estar cifrados, tanto en tránsito como en reposo. El estándar mínimo es AES-256 para datos en reposo y TLS 1.2+ para datos en tránsito.
Las claves de cifrado deben almacenarse de forma separada a los backups. Si la clave está en el mismo servidor que los backups y pierdes ambos, los backups son irrecuperables. Documenta las claves en un vault de secretos con acceso restringido y mantén una copia offline en una ubicación segura (caja fuerte física, por ejemplo).
Sección 7: Verificación y pruebas
Esta es la sección más importante de toda la política. Un backup no verificado no es un backup.
Verificación automática diaria
El sistema de respaldos debe verificar automáticamente la integridad de cada backup completado: checksum de archivos, tamaño esperado vs real y registro de errores. Cualquier fallo en la verificación debe generar una alerta inmediata al equipo responsable.
Prueba de restauración trimestral
Cada trimestre, selecciona un sistema crítico y ejecuta una restauración completa en un entorno de prueba. Documenta: tiempo de restauración real (para validar el RTO), integridad de los datos restaurados (para validar el RPO), problemas encontrados durante la restauración y acciones correctivas si la prueba falla.
Si no pruebas, no tienes backups
En nuestra experiencia, más del 30% de los backups que nunca se han probado tienen algún problema: archivos corruptos, datos incompletos, credenciales de cifrado perdidas o procedimientos de restauración obsoletos. La prueba trimestral existe para descubrir estos problemas antes de que necesites el backup de verdad.
Prueba tabletop anual
Una vez al año, ejecuta una simulación donde el equipo recorre el procedimiento completo de restauración sin tocar sistemas reales: desde la detección del incidente, pasando por la decisión de qué restaurar primero, hasta la comunicación a usuarios y la validación post-restauración.
Sección 8: Roles y responsabilidades
| Rol | Responsabilidad |
|---|---|
| Administrador de sistemas | Configurar, ejecutar y monitorear los respaldos diarios. Atender alertas de fallos. |
| Administrador de base de datos | Configurar respaldos de bases de datos. Ejecutar pruebas de restauración de BD. |
| Director de TI | Aprobar la política. Asignar recursos. Revisar resultados de pruebas trimestrales. |
| Proveedor externo (si aplica) | Ejecutar respaldos según SLA. Reportar estado y problemas. Participar en pruebas. |
| Auditoría / Compliance | Verificar cumplimiento de la política. Revisar registros de pruebas. |
Sección 9: Procedimiento de restauración
Para cada sistema crítico, documenta el procedimiento paso a paso para restaurar desde backup. El procedimiento debe ser suficientemente detallado para que alguien que no configuró los backups pueda ejecutarlo.
Incluye: dónde están los backups (ruta exacta, credenciales de acceso), herramienta de restauración (comando exacto o software), orden de restauración si hay dependencias (primero la base de datos, después la aplicación), verificaciones post-restauración (qué revisar para confirmar que funciona) y contactos del equipo si hay problemas durante la restauración.
Documenta para el peor escenario
Asume que quien ejecute la restauración estará bajo presión, posiblemente a las 3 de la mañana, y que la persona que normalmente maneja los backups no está disponible. El procedimiento debe ser claro, paso a paso, sin suponer conocimiento previo.
Sección 10: Monitoreo y reportes
El sistema de respaldos debe generar reportes automáticos que incluyan: backups completados y fallidos en las últimas 24 horas, almacenamiento utilizado vs disponible, última prueba de restauración exitosa (fecha y sistema) y alertas activas sin resolver.
El director de TI debe recibir un resumen semanal. Las alertas de fallo deben llegar al administrador responsable en tiempo real (email + Slack/Teams/SMS).
Sección 11: Revisión y actualización
Esta política debe revisarse y actualizarse al menos anualmente, después de cada incidente de pérdida de datos o restauración, cuando se agrega o modifica un sistema crítico y cuando cambian los requisitos regulatorios.
Cada actualización debe documentar qué cambió, quién lo aprobó y la fecha de vigencia.
Checklist de implementación
Si estás creando tu política desde cero, esta es la secuencia recomendada:
Protege tus datos
¿Necesitas ayuda con tu estrategia de respaldos?
Diseñamos tu política, implementamos la automatización, configuramos almacenamiento seguro y ejecutamos pruebas de restauración.
