Políticas de retención y frecuencia son las reglas que indican qué copias guardar y por cuánto tiempo. Funcionan combinando frecuencia de copia, tipo de backup y reglas de rotación para cubrir RPO y RTO. Sirven a administradores y responsables de TI para reducir pérdidas, costes y cumplir normativas.
Los factores clave para decidir
En el contexto de las políticas de retención y frecuencia, la decisión parte de cuatro variables claras. RPO define cuánto dato se puede perder. RTO mide cuánto tiempo tarda la organización en volver a servir. Coste, velocidad de cambio del sitio, cumplimiento legal y capacidad de almacenamiento completan la lista.
- RPO y RTO se traducen a frecuencias y ventanas de retención.
- Tipo de copia afecta espacio y tiempo de restauración.
- Patrón de cambios del sitio define retención por objetos.
Si el sitio cambia poco, conviene priorizar snapshots diarios y backups completos semanales para ahorrar espacio.
No usar una misma política para todos los sitios. Segmentar por criticidad y cumplimiento evita costes innecesarios.
Cómo definir políticas de retención y frecuencia
La diferencia principal entre elegir frecuencia y retención es que la frecuencia controla la ventana de pérdida y la retención cubre la preservación histórica. Para definir políticas, siga este flujo simple:
- Identificar criticidad del sitio y datos prioritarios.
- Fijar RPO y RTO aceptables.
- Elegir tipo de backup y rotación.
- Automatizar, etiquetar y probar restauraciones.
Un ejemplo práctico: RPO 1 hora implica hacer backups incrementales cada 30 a 60 minutos y un snapshot completo diario. Para RTO 2 horas, la organización debe poder restaurar y verificar en entorno staging en menos de 120 minutos.
Retención de backups reglas según tipo de contenido
En el contexto de contenidos, no todos los datos requieren la misma retención. Bases de datos transaccionales necesitan RPO bajos y retenciones cortas con muchas versiones. Contenido estático de marketing admite RPO altos y retención más corta.
- Bases de datos y pedidos de eCommerce: versiones horarias durante 7 días, diarias durante 30 días, mensuales 6 meses.
- Contenido editorial y CMS: copias diarias durante 14 días, semanales 3 meses.
- Logs y auditoría: retención según regulación sectorial.
Elegir frecuencia de copias diaria, semanal o mensual
La elección entre diaria, semanal o mensual depende del RPO acordado y de la tasa de cambio del sitio. Para sitios con cambios frecuentes, es recomendable elegir copias horarias o cada 30 minutos. Para sitios estáticos, con copias diarias o semanales suele ser suficiente.
Matriz simple de traducción RPO a frecuencia:
- RPO 15 minutos: backups incrementales cada 5-15 minutos y snapshot por hora.
- RPO 1 hora: incrementales cada 30–60 minutos y snapshot diario.
- RPO 24 horas: snapshot diario y copia completa semanal.
Según el sector, el rango habitual para sitios WordPress gestionados va de backups cada 15 minutos a copias diarias, dependiendo de la criticidad.
Políticas de retención y cumplimiento legal para empresas
La diferencia principal entre retención técnica y legal es que la legal obliga a conservar ciertos datos por periodos mínimos. GDPR obliga a justificar plazos y minimizar datos retenidos. Sectores financieros y salud suelen exigir retenciones superiores y garantías de integridad.
- Para facturación, guardar facturas y registros al menos 6 años según normativa fiscal española.
- Para datos sanitarios, seguir la normativa autonómica y registros de consentimiento.
Para referencia legal sobre protección de datos ver gdpr.eu.
Almacenamiento y rotación conservar snapshots y versiones
La elección entre GFS, FIFO y retención basada en tags cambia los costes y la complejidad. GFS (Abuelo-Padre-Hijo) funciona bien para versiones históricas. FIFO reduce costes manteniendo solo N versiones.
- Snapshots incrementales reducen espacio frente a copias completas.
- Objetos S3 con versionado permiten retención por etiqueta y ciclo de vida.
| Criterio |
On‑premise |
Cloud objetos S3 |
Cuándo elegir |
| Coste inicial |
Alto por hardware |
Bajo inicial, pago por uso |
Si control total y cumplimiento local |
| Escalado |
Limitado |
Autoescalado |
Si crecimiento variable elegir cloud |
| Flexibilidad retención |
Media |
Alta, políticas lifecycle |
Si se necesita retención por tag elegir cloud |
| Velocidad de restore |
Alta en LAN |
Variable según capa de objetos |
Si prioridad es velocidad elegir on‑premise |
En la mayoría de pymes, el cloud de objetos con snapshots incrementales es la opción más coste‑eficiente. Para entornos regulados, on‑premise puede ser necesario.
Proceso: definir frecuencia → etiquetar → rotación → probar restauración
Se desarrolla a continuación una sección práctica que contrasta implementaciones on‑premise y cloud con pasos operativos concretos. En cloud (objetos/S3) conviene aprovechar versioning, reglas lifecycle para mover objetos a capas de bajo coste, Object Lock o WORM para requisitos regulatorios y replicación cross‑region para disponibilidad. Es importante considerar los costes de egress y las latencias de restore según la clase de almacenamiento (Standard, Infrequent Access, Glacier/Archive).
Para on‑premise, priorice snapshots locales para restores rápidos en LAN, incluya mantenimientos periódicos de discos y pruebas de reconstrucción de LUNs/volúmenes. Planifique retenciones fuera del sitio (copias fuera de la instalación física) para recuperación por desastres y documente procedimientos de reconstrucción.
Estrategia híbrida recomendada:
- Copias locales para RTO bajos (restores rápidos en red local).
- Replicación incremental a cloud para retención a largo plazo y redundancia geográfica.
- Uso de snapshots de bloque (EBS/similar) cuando se necesite restitución rápida del estado de máquinas/volúmenes; usar backups a nivel de fichero para restauraciones más granulares y portabilidad.
- Automatizar políticas de lifecycle y etiquetas con herramientas de infraestructura como código (por ejemplo Terraform) y configuración/operaciones (por ejemplo Ansible) para aplicar lifecycle y etiquetas de retención como código.
Calcular RTO y RPO para tu estrategia de backups
RPO se refiere al punto en el tiempo al que se recuperan los datos. RTO se refiere al tiempo para restaurar servicios. Ambos deben mapearse a frecuencia de copias, tipo de copia y SLA interno.
Fórmula simple para estimar almacenamiento real:
- Espacio estimado = Tamaño base + (Tasa de cambio diaria × Tamaño base × Retención en días), ajustado por factores reales como deduplicación y compresión, overhead de metadatos y versiones, y añadiendo el espacio de copias completas periódicas o snapshots de sistema. Por ejemplo, si hay deduplicación efectiva del 40% reduzca la cifra resultante en ese factor; si planifica copias completas semanales añada 6×Tamaño base al mes.
Ejemplo numérico: sitio 10 GB, tasa de cambio 5% diaria, retención 30 días.
- Espacio incremental aproximado = 10 GB + (0.05 × 10 GB × 30) = 10 + 15 = 25 GB.
Esto muestra cuándo compensan snapshots incrementales frente a copias completas.
Según el informe de IBM 2023, el coste medio de una brecha de datos subió a 4.45 millones USD en la actualidad; en el sector, el rango habitual para RPO operativo suele estar entre 15 minutos y 24 horas. Muchos proveedores gestionados ofrecen SLA con RTO entre 1 y 6 horas.
A continuación se incorpora una calculadora práctica y ejemplos numéricos comparativos para visualizar el trade‑off coste ↔ espacio ↔ ventana de recuperación. Ejemplo: sitio de 100 GB con tasa de cambio diaria del 2% y retención de 30 días. Si usa incrementales diarios aproximados: espacio ≈ 100 GB + (0,02 × 100 × 30) = 160 GB. Si en vez de incrementales hace copias completas diarias: 100 GB × 30 = 3.000 GB. Usando un precio de ejemplo S3 Standard de 0,023 USD/GB‑mes, coste mensual aproximado sería: incremental → 160 × 0,023 = 3,68 USD; copias completas diarias → 3.000 × 0,023 = 69 USD.
Es útil añadir variantes con almacenamiento en frío (ej. Glacier/Archive) y considerar los costes de egress/operaciones para restauración; presentar estos cálculos en una pequeña tabla o en una hoja de cálculo permite al lector ajustar tamaños, tasa de cambio y precios a su entorno.
Checklist de implementación y pruebas de restauración
- Definir RPO y RTO por segmento de sitio.
- Configurar backups automáticos con etiquetado por entorno y cliente.
- Implementar rotación GFS o FIFO según necesidad.
- Programar pruebas de restauración trimestrales y documentarlas.
Prueba mínima: restaurar una copia en staging, verificar integridad y tiempos. Registrar tiempo total y fallos. Medir RTO real.
Errores al tomar esta decisión
Elegir una frecuencia arbitraria sin mapear RPO y RTO produce ventanas de pérdida inaceptables. Confiar solo en backups automatizados sin pruebas los vuelve inútiles. Aplicar la misma política a todos los sitios puede disparar costes y crear riesgos legales.
Comprobar restauraciones cada 3 meses y automatizar reportes. Las copias sin prueba no valen para auditoría.
Políticas de retención y frecuencia
A continuación preguntas frecuentes y respuestas claras para aplicar la política.
¿Cuáles son los 3 tipos de backup?
Respuesta breve: copia completa, diferencial e incremental. Una copia completa guarda todo. Diferencial guarda cambios desde la última completa. Incremental guarda los cambios desde la última copia (completa o incremental): cada backup incremental contiene solo las diferencias respecto al backup anterior, por lo que para restaurar una versión completa normalmente se aplica la última copia completa más la secuencia de incrementales posteriores. Esto implica más pasos en la restauración y la necesidad de comprobar la cadena de incrementales durante las pruebas.
Desarrollo: la copia completa facilita restauraciones rápidas. Las diferenciales consumen más espacio que incrementales, pero restauran más rápido. Las incrementales son eficientes en espacio y requieren más pasos al restaurar.
¿Qué es una política de retención de copias de seguridad?
Respuesta breve: regla que define cuánto tiempo se guardan las copias. Incluye frecuencia, rotación y criterios de eliminación.
Desarrollo: una política documenta retenciones por tipo de dato. Debe incluir responsables, SLAs y pruebas de restauración. Debe revisarse tras cambios de regulación o negocio.
¿Qué son las políticas de retención de datos?
Respuesta breve: normas sobre conservación y eliminación de datos. Van más allá del backup e implican cumplimiento legal.
Desarrollo: incluyen plazos fiscales, obligaciones sectoriales y minimización de datos. Deben alinearse con GDPR y políticas internas. Se documentan y auditan.
¿Cada cuánto se debe hacer un backup?
Respuesta breve: según RPO definido. Puede variar de cada 5 minutos a diario.
Desarrollo: para RPO bajo, hacer incrementales frecuentes y snapshots diarios. Para RPO alto, copias diarias o semanales son suficientes. El coste y la capacidad guían la elección.
¿Cómo calcular el coste de almacenamiento?
Respuesta breve: usar la fórmula Tamaño base + (tasa de cambio × días de retención).
Desarrollo: incluir overhead de metadatos y versiones. Si se usa S3, estimar coste por GB/mes y operaciones. Comparar precios entre capas de almacenamiento.
¿Cada cuánto probar restauraciones?
Respuesta breve: mínimo cada 3 meses y tras cambios mayores. Registrar resultados.
Desarrollo: las pruebas deben incluir restauración completa y parcial. Medir RTO real y documentar incidencias. Ajustar políticas si los tiempos no cumplen SLAs.
¿Qué diferencia hay entre snapshots y copias completas?
Respuesta breve: snapshot captura estado del sistema; copia completa duplica todos los ficheros.
Desarrollo: snapshots son rápidos y eficientes en disco. Copias completas son más portables. En cloud conviene combinar snapshots incrementales y copias completas periódicas.
Recursos prácticos para implementar ya
- Plantilla de política: definir RPO, RTO, responsable, retenciones por tipo.
- Tabla calendario: ejemplo para eCommerce, blog y web corporativa.
- Calculadora coste/espacio: aplicar la fórmula de espacio y multiplicar por coste GB/mes.
Ejemplo anónimo real: un comercio electrónico migró a backups incrementales cada 30 minutos, retención horaria 48 horas y retención diaria 30 días. Redujo coste en almacenamiento un 40% y cumplió RTO 90 minutos.
Para facilitar la adopción inmediata, se propone una plantilla de política de retención en formato editable (.docx/.md) con campos claros: alcance y alcance técnico, responsable y aprobado por, clasificación de datos (crítico/alto/medio/bajo), RPO/RTO por clase, calendario de retención (horaria/diaria/semanal/mensual/anual), esquema de rotación (GFS/FIFO/retención por etiquetas), procedimientos paso a paso para restauración (parámetros, entorno de prueba, comprobaciones de integridad), frecuencia y alcance de pruebas de restauración, requisitos legales y referencias normativas, y un registro de cambios y auditoría. Un bloque de ejemplo que puede incluirse en la plantilla: Clase: Transaccional | RPO: 1h | RTO: 2h | Retenciones: horarias 7d / diarias 30d / mensuales 12m | Rotación: GFS | Responsable: DBA. Añadir esta plantilla permite que equipos de TI adapten políticas en horas, no semanas.
Conclusión
Las Políticas de retención y frecuencia deben mapear RPO y RTO con tipos de copia, rotación y pruebas. Automatizar etiquetado y restauraciones y revisar compliance. Empezar con una política segmentada y medir resultados.
