La retención de copias de seguridad define durante cuánto tiempo y en qué cantidad se conservan las versiones históricas de los datos. Es uno de los aspectos más críticos —y a la vez más mal definidos— en muchas empresas. Tener backups sin una política clara de retención suele generar dos problemas opuestos: o no hay versiones útiles cuando ocurre un incidente, o se acumulan copias sin sentido que complican la recuperación.
Definir bien la retención no es una decisión técnica aislada, sino una decisión operativa ligada al riesgo real del negocio.
Qué significa realmente “retener copias”
La retención responde a tres preguntas básicas:
- cuántas versiones distintas se conservan
- durante cuánto tiempo se guardan
- cuándo y cómo se eliminan
No se trata solo de almacenamiento, sino de capacidad real de volver atrás en el tiempo cuando algo falla.
El error más común: pensar solo en el último backup
Muchas empresas confían en:
- una copia diaria
- unas pocas copias recientes
- el “backup de anoche”
Este enfoque falla en escenarios muy habituales:
- errores humanos detectados días después
- bases de datos que se corrompen de forma progresiva
- ransomware que actúa sin ser detectado
- cambios incorrectos que pasan desapercibidos
Cuando se identifica el problema, todas las copias disponibles ya contienen el error.
El otro extremo: guardar versiones sin límite
Conservar copias indefinidamente tampoco es una buena estrategia.
Los efectos habituales son:
- crecimiento descontrolado del almacenamiento
- aumento innecesario de costes
- dificultad para identificar la versión correcta
- restauraciones lentas y confusas
Retener sin criterio no mejora la protección; reduce la operatividad.
Qué factores deben definir cuántas versiones guardar
No existe un número universal válido. La política debe adaptarse a la realidad de cada empresa.
Frecuencia de cambio de los datos
Cuanto más cambian los datos, más sentido tiene conservar versiones frecuentes.
Ejemplos de alta rotación:
- bases de datos operativas
- sistemas de facturación
- aplicaciones internas
- información de clientes
En estos casos, perder horas puede ser tan grave como perder días.
Tiempo de detección de errores
Un punto clave es cuándo se suele detectar que algo ha ido mal.
- si los errores se detectan el mismo día, bastan pocas versiones
- si se detectan semanas después, se necesitan copias más antiguas
La retención debe cubrir el tiempo de detección, no solo el tiempo técnico del backup.
Riesgo de ataques y fallos silenciosos
El ransomware y otros incidentes modernos no siempre se manifiestan de inmediato.
Puede ocurrir que:
- el cifrado sea progresivo
- las copias recientes ya estén afectadas
- el problema solo se detecte días después
Sin versiones suficientemente antiguas, la recuperación puede ser imposible.
Requisitos legales y operativos
Algunas empresas necesitan:
- conservar datos durante periodos mínimos
- poder recuperar información histórica
- cumplir auditorías o normativas
La retención debe alinearse también con estas exigencias, no solo con criterios técnicos.
Esquemas habituales de retención
Aunque cada caso es distinto, existen modelos habituales que sirven como base.
Retención corta (operativa)
Pensada para incidencias recientes y errores cotidianos.
Suele incluir:
- copias horarias de las últimas 24–48 horas
- copias diarias de los últimos 7–14 días
Retención media (seguridad)
Pensada para incidentes detectados con retraso.
Puede incluir:
- copias diarias de varias semanas
- copias semanales de varios meses
Retención larga (histórica)
Pensada para necesidades legales, auditorías o recuperaciones puntuales.
Normalmente:
- copias mensuales
- conservación durante periodos largos
- acceso poco frecuente
Versiones y retención no son lo mismo
Es importante diferenciar:
- versiones: cuántos puntos distintos de recuperación existen
- retención: cuánto tiempo se conserva cada punto
Un sistema puede tener muchas versiones que se eliminan rápido, o pocas versiones conservadas durante mucho tiempo. Ambos conceptos deben definirse de forma coherente.
Impacto de la retención en la recuperación
Una política mal definida puede:
- dificultar encontrar el punto correcto
- alargar tiempos de recuperación
- aumentar errores en situaciones de presión
En una incidencia real, la claridad de la política es tan importante como la tecnología usada.
Documentar y revisar la política
La retención no debe quedar “por defecto”.
Es fundamental:
- documentar qué se guarda y durante cuánto
- saber quién puede modificar la política
- revisarla periódicamente
- ajustarla cuando cambian los sistemas o el negocio
Una política válida hoy puede no serlo dentro de un año.
Retener con intención, no por acumulación
Una buena política de retención no busca guardar más copias, sino guardar las correctas durante el tiempo necesario.
Cuando se define con criterio, la retención convierte el backup en una herramienta real de recuperación, preparada para errores humanos, fallos técnicos y escenarios de seguridad complejos, sin generar costes ni complejidad innecesarios.