Planificación de copias de seguridad y recuperación: protege tus archivos

Un plan de copia de seguridad y recuperación responde a dos preguntas numéricas: el RPO (cuántos datos puedes permitirte perder, medido en tiempo) y el RTO (cuánto tiempo puedes permitirte estar caído). Defínelos para cada carga de trabajo y luego diseña hacia atrás. Una base de datos con un RPO de 5 minutos necesita envío continuo de WAL; un informe semanal de marketing con un RPO de 24 horas necesita un trabajo nocturno. Combina con la regla 3-2-1 — tres copias, en dos tipos de medios, con una fuera de las instalaciones — y prueba las restauraciones cada trimestre. La mayoría de las historias de "tenemos copias de seguridad" terminan mal porque nadie practicó nunca la restauración.

RPO y RTO: los números de partida

RPO (Recovery Point Objective) = pérdida de datos máxima aceptable en tiempo. RTO (Recovery Time Objective) = tiempo de inactividad máximo aceptable.

Ejemplos por carga de trabajo:

• Base de datos de producción de un comercio electrónico: RPO 5 min, RTO 1 hora
• Cargas de ficheros de clientes: RPO 15 min, RTO 2 horas
• Servidor de ficheros interno: RPO 24 horas, RTO 8 horas
• Archivo de correo electrónico: RPO 24 horas, RTO 48 horas
• Analítica de marketing: RPO 24 horas, RTO 72 horas

Un RPO/RTO más ajustado cuesta más. Un RPO de 5 minutos implica replicación continua (infraestructura cara); un RPO de 24 horas implica un trabajo nocturno (barato). No sobre-ingenierices — no toda carga de trabajo necesita modo de espera en caliente.

La regla 3-2-1 sigue funcionando

Tres copias de los datos, en dos tipos de almacenamiento diferentes, con una fuera de las instalaciones. La regla 3-2-1 es anterior a la nube y sigue siendo válida:

• Principal: almacenamiento de producción (S3, EBS, disco de PostgreSQL)
• Secundaria: copia de seguridad en medios diferentes o en una región distinta (otro bucket S3 con replicación, Glacier)
• Terciaria: fuera de las instalaciones, idealmente proveedor diferente o aislada físicamente (Backblaze B2, cinta local, discos físicos en una caja fuerte)

El punto de diversidad de proveedores importa. Una cuenta root de AWS comprometida puede eliminar todas las copias de seguridad de AWS. Una copia secundaria en Backblaze, Wasabi o en instalaciones propias sobrevive a ese escenario. Para empresas con facturación inferior a 50 millones de euros, una copia en un segundo proveedor añade quizás 50-200 EUR/mes y protege contra problemas catastróficos a nivel de inquilino.

Completa, incremental y completa sintética

Tres estrategias de copia de seguridad:

• Completa: Copiar todo cada vez. Simple, la restauración es rápida (un solo fichero), el almacenamiento es pesado.
• Incremental: Copiar solo lo que ha cambiado desde la última copia de seguridad. Eficiente en almacenamiento, la restauración requiere la completa más todos los incrementales.
• Completa sintética: Fusión en el servidor de completa + incrementales en una nueva copia completa virtual. Restauración rápida desde cualquier punto.

Las herramientas modernas de copia de seguridad (Veeam, Rubrik, restic con prune, BorgBackup) usan incremental-para-siempre con completas sintéticas bajo el capó. El patrón: incremental nocturna, completa sintética semanal, retener 30 diarias + 12 mensuales + 7 anuales (rotación abuelo-padre-hijo).

Para un servidor de ficheros de 2 TB con una tasa de cambio diaria del 5%, el incremental-para-siempre almacena entre 3 y 5 TB en total para un año de retención — frente a más de 700 TB si se hacen copias completas cada noche.

Cifrado antes de que salga

Las copias de seguridad no deben viajar ni estar en reposo sin cifrar. El cifrado en el cliente con AES-256-GCM (el predeterminado en restic, Borg, Duplicacy, Veeam y otros) garantiza que el host de copia de seguridad nunca vea texto en claro.

La gestión de claves importa más que la elección del algoritmo. Una copia de seguridad cifrada con una clave almacenada en la misma cuenta de AWS que la copia de seguridad es teatro — un atacante con acceso IAM obtiene ambas. Almacena las claves en:

• AWS KMS con una clave de cuenta separada (descifrado entre cuentas)
• HashiCorp Vault en un entorno fuera de banda
• Un módulo de seguridad hardware (YubiKey, HSM) para la clave raíz
• Una copia impresa y sellada en papel para las claves verdaderamente críticas

Rota regularmente (anualmente), registra cada uso y prueba la recuperación con una clave rotada antes de que la rotación entre en vigor en producción.

Inmutabilidad: la respuesta al ransomware

Los ataques de ransomware en 2025 suelen apuntar primero a las copias de seguridad — cifran los datos de producción y luego eliminan o cifran las copias de seguridad para impedir la recuperación. Las copias de seguridad inmutables neutralizan esto.

Implementaciones:

• S3 Object Lock (modo Compliance): ni siquiera root puede eliminar durante el período de retención
• Azure Blob immutable storage: similar, aplicado a nivel de contenedor
• Veeam Hardened Linux Repository: solo escritura, solo SSH, sin API de eliminación
• Cinta física en una bóveda: el aislamiento máximo

Para datos críticos para el negocio, al menos una copia de seguridad debe ser inmutable durante el período de retención. El coste incremental suele ser cero — ibas a retenerla de todos modos. El valor cuando llega el ransomware es total.

Pruebas: la parte no opcional

Una copia de seguridad que nunca has restaurado no es una copia de seguridad; es esperanza. Calendario de pruebas por prioridad:

• Nivel 1 (misión crítica): simulacro completo de restauración trimestral, restauración de fichero aleatorio mensual
• Nivel 2 (importante para el negocio): simulacro completo de restauración semestral, restauración de fichero aleatorio trimestral
• Nivel 3 (estándar): simulacro completo de restauración anual, restauración de fichero aleatorio trimestral

Registra en la prueba:

1. Cuánto tardó la restauración (comparar con el RTO)
2. Si los datos coincidían con el estado de producción (sumas de verificación contra un punto conocido)
3. Si algún permiso o configuración no se restauró correctamente
4. Qué falló y cómo se corrigió

Las empresas que se saltan las pruebas descubren las copias de seguridad corruptas durante incidentes reales, que es el momento más caro para aprender cualquier cosa.

Las copias de seguridad de bases de datos necesitan su propio plan

Los ficheros y las bases de datos se respaldan de forma diferente. Un directorio .pgdata copiado a mitad de una transacción está corrupto. Usa las herramientas nativas:

• PostgreSQL: pg_basebackup + archivado de WAL para PITR, pg_dump para lógica
• MySQL: Percona XtraBackup para física en caliente, mysqldump para lógica
• MongoDB: mongodump, conjuntos de réplicas con secundarios retrasados
• Microsoft SQL Server: copia de seguridad nativa con BACKUP DATABASE, log shipping para PITR

Para una base de datos PostgreSQL de 500 GB con RPO de 5 minutos, copias de seguridad base nocturnas + archivado continuo de WAL a S3 ofrecen recuperación a un punto en el tiempo hasta cualquier segundo de los últimos 30 días. Tiempo de restauración: descargar la copia base (30 min), reproducir WAL hasta el momento objetivo (5-30 min). Un RTO ajustado implica tener una réplica en caliente lista para promover.

Instantáneas consistentes con la aplicación

Las instantáneas del sistema de ficheros (ZFS, Btrfs, AWS EBS, discos administrados de Azure, disco persistente de GCP) congelan un punto en el tiempo a nivel de bloque. Para las bases de datos, combina con la pausa de la aplicación:

1. pg_start_backup('label') (PostgreSQL) o FLUSH TABLES WITH READ LOCK (MySQL)
2. Tomar la instantánea
3. pg_stop_backup() o desbloquear

La instantánea es consistente con la aplicación — utilizable para restaurar sin recuperación de fallos. AWS Backup, Azure Backup y Google Cloud Backup automatizan este patrón para las bases de datos habituales.

Distribución de archivos de copia de seguridad a terceros

Cuando las copias de seguridad deben enviarse a partes externas — auditores, organismos reguladores, administradores sucesores — la transferencia en sí requiere cuidado. El FTP es obsoleto; los adjuntos de correo tienen límites de tamaño; entregar unidades USB es lento.

La transferencia de ficheros cifrada de extremo a extremo gestiona la distribución puntual de copias de seguridad de forma limpia. HexaTransfer mueve ficheros de hasta 10 GB con cifrado AES-256-GCM en el cliente y un enlace de un solo uso. Ideal para enviar una instantánea de base de datos a un auditor sin concederle acceso a tus buckets de S3.

La documentación es parte de la copia de seguridad

La mejor copia de seguridad del mundo es inútil si la persona que puede restaurarla está de vacaciones y nadie más sabe cómo. Documenta:

• Qué está respaldado y qué no (exclusiones explícitas)
• Calendario y retención por carga de trabajo
• Gestión de claves y acceso
• Runbooks de restauración con comandos paso a paso
• Lista de contactos (soporte del proveedor, guardia)
• Resultados de las pruebas y fechas

Imprime una copia. Guarda una copia en la caja fuerte física junto con las llaves de emergencia. Si el runbook de copia de seguridad solo existe en una página de Confluence servida desde la misma infraestructura que acaba de caerse, tienes un problema. El papel sigue funcionando cuando todo lo demás falla.

Define el RPO/RTO, implementa 3-2-1 con inmutabilidad, cifra en el cliente, prueba trimestralmente, documenta de forma obsesiva. El éxito de la copia de seguridad es un 10% de tecnología y un 90% de disciplina.

Pruébalo en hexatransfer.com — gratis, sin cuenta, máximo 10 GB.