¿Qué es una política de retención de backup?
Una política de retención de backup es un conjunto documentado de reglas que establece durante cuánto tiempo permanecen disponibles los puntos de recuperación. Por ejemplo, una directiva puede conservar siete copias diarias, cuatro semanales, doce mensuales y tres anuales. Cuando un punto de recuperación queda fuera de todas las ventanas de retención, la plataforma de backup puede depurarlo o darlo por caducado.
Una política completa documenta mucho más que un simple número de días. Cubre qué sistemas se incluyen, la frecuencia de las copias, los niveles de retención, los destinos de almacenamiento, los periodos de inmutabilidad, las autorizaciones de borrado, las pruebas de restauración y las responsabilidades.
Las directrices de seguridad de almacenamiento del NIST recomiendan gestionar las copias de datos y los backups mediante políticas documentadas de protección y retención a lo largo de todo su ciclo de vida.
Frecuencia y retención son conceptos distintos
La frecuencia de backup describe cada cuánto tiempo se genera un nuevo punto de recuperación. La retención describe cuánto tiempo se conserva ese punto.
Un sistema puede ejecutar copias de seguridad cada hora y conservar solo las últimas 24 horas. Otro puede hacer copias una vez al día y conservar cada una durante siete años. La frecuencia acota la pérdida potencial de datos, mientras que la retención determina hasta qué momento del pasado puedes volver. Una mayor retención también incrementa el gasto en almacenamiento físico o en la nube y la exposición en materia de privacidad, por lo que la directiva debe sopesar el valor de recuperación frente al coste y el riesgo.
Comienza por los requisitos de recuperación antes de elegir una plantilla
Para cada carga de trabajo, define su Objetivo de Punto de Recuperación y hasta dónde debe llegar el historial de versiones:
La cantidad máxima admisible de pérdida de datos, medida en tiempo. Un RPO de cuatro horas puede exigir copias o snapshots recuperables al menos cada cuatro horas.
Hasta qué momento en el pasado pueden necesitar restaurar los usuarios o administradores: un día para entornos de desarrollo temporales, treinta días para recuperación habitual de archivos o varios años para registros regulados.
Un calendario de retención práctico como punto de partida
Este ejemplo sirve como modelo de inicio. No constituye un estándar universal obligatorio.
Este calendario ofrece puntos recientes detallados conservando menos versiones a medida que envejecen. Una base de datos transaccional con muchos cambios puede requerir copias más frecuentes; un archivo estático de proyectos finalizados puede necesitar solo protección mensual o anual.
Retención abuelo, padre, hijo (GFS)
El modelo abuelo, padre, hijo, habitualmente abreviado como GFS (grandfather, father, son), clasifica los puntos de recuperación en distintas generaciones.
Microsoft define la retención GFS como una estructura de políticas que admite puntos de recuperación diarios, semanales, mensuales y anuales con diferentes periodos de conservación.
Imagina que las copias se ejecutan cada noche. Una política podría conservar las últimas siete copias diarias, una copia dominical durante ocho semanas, la última copia de cada mes durante doce meses y la última copia de cada año durante siete años. Esto no significa necesariamente almacenar 111 copias completas e independientes. Los sistemas de backup modernos utilizan datos incrementales, deduplicación o copias completas sintéticas; la política solo define qué puntos de recuperación permanecen direccionables, lo que dice poco sobre el espacio físico en disco requerido.
Retención por carga de trabajo
Una única directiva rara vez se ajusta a todos los sistemas.
Máquinas virtuales
Un esquema inicial puede conservar de 7 a 14 copias diarias, 8 semanales y de 6 a 12 mensuales. Las máquinas virtuales críticas pueden requerir puntos más frecuentes y mayor retención, mientras que los entornos de prueba temporales necesitan mucho menos.
Bases de datos
Las bases de datos suelen requerir una combinación de copias completas, incrementales o diferenciales junto con registros de transacciones. La política de retención debe conservar cada componente necesario para restaurar al punto exacto deseado. Conservar una copia completa sin su cadena de incrementales o registros asociados puede dejar inservibles algunos puntos de recuperación.
Servidores de archivos
Los servidores de archivos suelen beneficiarse de historiales de versiones más amplios, ya que los borrados o corrupciones pueden no detectarse de inmediato. Un punto de partida práctico: 30 versiones diarias, 12 versiones mensuales y archivos anuales seleccionados.
Sistemas de identidad
La retención debe ser suficiente para recuperarse de errores de configuración o intrusiones que hayan pasado inadvertidas durante un tiempo prolongado. La copia de seguridad debe incluir también la configuración y las credenciales necesarias para llevar a cabo la restauración.
Cargas de trabajo en Kubernetes
Una política de retención en Kubernetes debe contemplar datos de volúmenes persistentes, definiciones de recursos del clúster, manifiestos, Secrets, Custom Resources y cualquier base de datos externa o almacenamiento de objetos. Mantener únicamente snapshots de volúmenes persistentes puede no proporcionar una vía completa de restauración de la aplicación.
Datos personales y homelab
Una directiva sencilla puede conservar siete copias diarias, cuatro semanales, doce mensuales, un archivo anual y una copia offline de los datos críticos.
Retención en Proxmox Backup Server
Proxmox Backup Server permite fijar reglas de retención según la cantidad de snapshots recientes, horarios, diarios, semanales, mensuales y anuales a conservar. La depuración (prune) elimina las referencias a snapshots que ya no encajan en las reglas; la recolección de basura (garbage collection) libera después los datos no referenciados en el datastore.
Una copia puede satisfacer más de una categoría de retención. La copia más reciente puede coincidir con la copia diaria, y la última copia de la semana puede contar a la vez como punto diario y semanal. Revisa la retención según la lógica real de selección de la plataforma en lugar de sumar simplemente cada cifra configurada.
Proxmox recomienda restringir los permisos de borrado y ejecutar las tareas de depuración directamente en Proxmox Backup Server mediante trabajos controlados, lo que reduce las acciones destructivas accesibles desde los sistemas de producción o clientes de backup.
Retención, inmutabilidad y custodia legal
La retención y la inmutabilidad resuelven problemas diferentes. La retención determina cuánto tiempo debe guardarse un punto de recuperación; la inmutabilidad impide que ese punto se altere o elimine durante un plazo protegido.
Por ejemplo: una política de retención indica conservar copias mensuales durante doce meses, mientras que una directiva de inmutabilidad bloquea el borrado durante los primeros 90 días. Pasados los 90 días, la copia se mantiene según las reglas de retención pero deja de estar técnicamente bloqueada; tras doce meses, pasa a ser apta para su eliminación.
CISA recomienda mantener copias de seguridad offline o inmutables y verificar periódicamente su integridad y disponibilidad.
La retención de backup no es retención legal de documentos
Una política de retención de backup está pensada para la recuperación técnica. Una política de conservación de registros (records retention) responde a requisitos legales, regulatorios, contractuales y corporativos de custodia documental. Estas directivas pueden solaparse, pero una no puede sustituir a la otra. Una obligación legal de siete años no implica que cada backup completo del servidor deba guardarse siete años. Una arquitectura superior exporta los registros exigidos a un archivo gobernado mientras aplica una retención operativa más breve a las copias de seguridad de sistemas. Consulta a profesionales jurídicos o de cumplimiento antes de fijar periodos de conservación para datos regulados.
Diseña tu política: ocho pasos
Inventaria cargas de trabajo y datos
Haz una lista de cada sistema que requiera protección: responsable, tipo de datos, criticidad de negocio, tamaño, tasa de cambio diaria, RPO, RTO, historial necesario, requisitos legales y destino del backup. No apliques una directiva de retención a sistemas que nadie comprende.
Clasifica las cargas de trabajo
Crea un número reducido de clases de protección prácticas (crítica, importante, estándar, temporal, archivo), evitando crear tantas categorías que nadie pueda gestionarlas.
Define las ventanas de recuperación
Considera errores operativos inmediatos, borrados de usuarios detectados tras varios días, corrupciones detectadas tras semanas, incidentes de seguridad advertidos tras meses y exigencias de auditoría anuales o contractuales.
Selecciona los niveles de retención
Define una recuperación a corto plazo detallada y una cobertura a largo plazo progresivamente más espaciada; por ejemplo: horarios durante dos días, diarios durante treinta días, semanales durante doce semanas, mensuales durante doce meses y anuales durante siete años.
Estima los requisitos de almacenamiento
Evalúa el volumen inicial protegido, la tasa de cambio diaria, la compresión, la deduplicación, el trasiego de bases de datos, los datos borrados, el periodo inmutable, la tasa de crecimiento y un margen de seguridad. Un sistema de 10 TB con una tasa de cambio diaria alta puede consumir más espacio de backup que un conjunto de datos mucho más grande pero prácticamente estático.
10 TB de datos protegidos con una tasa de cambio diaria del 3%, copias diarias y 30 días de retención dan una estimación aproximada sin comprimir de 10 TB × 3% × 30 días = 9 TB solo para datos modificados. Eso excluye la copia completa inicial, los puntos mensuales, los metadatos y el margen de seguridad. Mide las ejecuciones reales siempre que sea posible en lugar de depender únicamente de la estimación teórica.
Fija los permisos de borrado
Documenta quién puede alterar la retención, eliminar puntos de recuperación individuales, desactivar tareas de backup, acortar la retención inmutable, eliminar un datastore o acceder a las claves de cifrado. Utiliza credenciales independientes de administración de backup y autenticación multifactor siempre que sea posible.
Prueba la recuperación a lo largo de toda la ventana de retención
Prueba algo más que la copia más reciente. Restaura desde ayer, la semana pasada, el mes pasado, un punto protegido antiguo, el repositorio externo y soportes de archivo o cinta. Esto confirma que las cadenas de backup antiguas, los soportes y las claves de cifrado continúan siendo válidos.
Revisa la política periódicamente
Revisa cuando cambie el ritmo de crecimiento de los datos, se incorporen nuevos sistemas, varíen los costes de la nube o las cintas, se modifiquen los objetivos de recuperación, cambie la normativa, se produzca un incidente o las pruebas de restauración revelen carencias.
Errores comunes en la retención de backups
La copia más nueva puede contener ya corrupciones, cifrado malicioso o borrados accidentales. Conserva versiones históricas.
La retención indefinida dispara los costes y complica la gobernanza de datos confidenciales. Establece reglas de caducidad aprobadas.
Las bases de datos críticas y las máquinas de prueba temporales no necesitan la misma protección. Clasifica las cargas de trabajo.
Ejecutar copias cada hora no garantiza que los puntos horarios sigan disponibles después. Configura ambos parámetros.
No elimines la copia mensual o anual anterior hasta que la nueva copia protegida haya finalizado y se haya verificado.
Las copias protegidas no pueden depurarse hasta que expira el bloqueo. Planifica la capacidad antes de activar retenciones largas.
Las restauraciones recientes pueden funcionar mientras cadenas antiguas, cintas o claves fallan. Prueba a lo largo de toda la ventana de retención.
Las copias de seguridad operativas no sustituyen a un archivo gobernado. Separa la retención técnica para recuperación de la custodia legal.
Una cuenta de producción comprometida no debería poder eliminar todos los puntos de recuperación. Restringe los permisos de borrado y los cambios en las políticas.
Un pequeño error de configuración puede eliminar más puntos de recuperación de los previstos. Utiliza primero funciones de vista previa, simulación o dry-run.
Lista de verificación de la política de retención
0 / 20Preguntas frecuentes
Una política de retención de backup define cuánto tiempo se conservan los puntos de recuperación, qué versiones sobreviven, dónde se almacenan y cuándo pueden eliminarse.
El periodo adecuado depende de las necesidades de recuperación, el tiempo medio de detección de incidentes, los requisitos del negocio, el coste de almacenamiento y las obligaciones legales. Un modelo habitual conserva puntos de recuperación diarios, semanales, mensuales y anuales durante periodos progresivamente más largos.
GFS corresponde a abuelo, padre, hijo (grandfather, father, son). Conserva copias recientes frecuentes y progresivamente menos puntos de recuperación semanales, mensuales o anuales a medida que las copias envejecen.
Treinta días pueden bastar para recuperar archivos habituales, pero pueden no cubrir corrupciones o incidentes de seguridad detectados tras varios meses. Los sistemas críticos suelen requerir versiones semanales, mensuales o anuales adicionales.
Conservar entre 7 y 30 copias diarias es un rango inicial habitual. El número exacto depende de con qué rapidez se detecten los problemas y del espacio de almacenamiento disponible.
Los snapshots pueden gestionarse mediante reglas de retención, pero los snapshots almacenados únicamente en el sistema de producción no deben considerarse copias de seguridad independientes.
No. La retención determina cuánto tiempo debe conservarse una copia. La inmutabilidad impide su borrado o alteración durante un plazo protegido.
Normalmente pasan a ser aptas para el borrado una vez expira el periodo de protección inmutable, conforme a las directivas de retención y las reglas de la plataforma de almacenamiento.
Solo si existe una justificación empresarial, legal o de archivado aprobada. La retención indefinida genera costes innecesarios y riesgos de privacidad y gobernanza.
Proxmox Backup Server conserva snapshots según reglas de últimos, horarios, diarios, semanales, mensuales y anuales. Las tareas de depuración (prune) eliminan las referencias a snapshots caducados, y la recolección de basura (garbage collection) libera después el espacio no referenciado en el datastore.
No necesariamente. La retención de copias de seguridad respalda la recuperación ante desastres. La retención documental legal responde a obligaciones de custodia aprobadas. Ambas deben coordinarse, pero pueden emplear sistemas y periodos distintos.
Conviene revisarla al menos una vez al año y siempre que cambien los requisitos de recuperación, el crecimiento del almacenamiento, la infraestructura, los riesgos de seguridad o las exigencias legales.
Conserva el historial necesario para recuperar con garantías
Una política de retención de copias de seguridad debe asegurar opciones de recuperación útiles sin permitir que los datos y los costes crezcan sin límite. Las copias recientes y detalladas resuelven los errores del día a día, mientras que los puntos semanales y mensuales ayudan cuando los daños se detectan más tarde. Las copias anuales respaldan requisitos aprobados a largo plazo, y la retención offline o inmutable te ofrece una vía alternativa cuando los sistemas habituales de backup sufren un ataque.
Comienza por los sistemas más importantes. Define sus requisitos de recuperación, establece niveles de retención diarios, semanales y mensuales, protege puntos seleccionados y comprueba copias antiguas antes de dar por buena la directiva.