Copia de seguridad y recuperación ante desastres: estados, objetivos y reanudación

Un trabajo de copia de seguridad finalizado correctamente solo demuestra inicialmente que una herramienta ha escrito datos. Aún no indica si el punto de copia está completo, es coherente con la aplicación, está protegido frente al mismo fallo y puede restaurarse como servicio utilizable dentro del plazo acordado. Copia de seguridad designa la copia recuperable de un estado anterior; la recuperación ante desastres incluye además personas, prioridades, infraestructura de destino, dependencias, validación y el retorno controlado a la operación. Por ello, NIST distingue entre copia de seguridad, estrategia de restauración, procedimientos de recuperación, pruebas y mantenimiento continuo del plan (NIST SP 800-34 Rev. 1).

Para las plataformas de mensajería, «la base de datos» no es un objeto de protección completo. Un estado utilizable puede distribuirse entre almacenamiento de buzones o blobs, metadatos relacionales, colas de transporte, índices de búsqueda, configuraciones, reglas de enrutamiento, referencias de directorio, certificados, claves privadas, DNS, licencias y automatización. Algunas partes son autoritativas, otras solo proyecciones y otras estados efímeros. El plan de recuperación debe especificar para cada parte si se restaura, reconstruye, vuelve a emitir o se descarta deliberadamente. Además de los datos de usuario, NIST exige estado del sistema, software, inventario, licencias y documentación relevante para la seguridad; PostgreSQL, por ejemplo, señala expresamente que el archivado de WAL no guarda sus archivos de configuración (NIST SP 800-34 Rev. 1, CP-9, PostgreSQL: archivado continuo y PITR).

Por tanto, el criterio operativo de aceptación no es «backup montado», sino, por ejemplo: un remitente externo puede entregar un mensaje, se aplica la política correcta, el mensaje aparece en el buzón previsto, se puede buscar y responder, y el monitoreo y la auditoría registran el proceso. NIST menciona restauraciones correctas y puntuales, objetivos de recuperación alcanzados y usuarios o sistemas nuevamente disponibles como resultados medibles de recuperación (NIST SP 800-184, NIST SP 800-184, métricas de recuperación).

La explicación comienza con el proceso de negocio que debe volver a funcionar tras un fallo. De ello surgen RTO y RPO, después la cadena de copias adecuada; el resultado final no es el trabajo de copia de seguridad, sino una prueba de restauración medida.

Una copia de seguridad no es alta disponibilidad

La copia de seguridad, la instantánea, la replicación y la alta disponibilidad resuelven clases de error diferentes. Microsoft describe explícitamente la copia de seguridad y la replicación como complementarias: la replicación mantiene una copia actual para la operación continua, pero también reproduce eliminaciones lógicas o daños; una copia de seguridad con marca temporal permite volver a un estado anterior (Microsoft Azure Reliability: redundancia, replicación y copia de seguridad).

Una instantánea puede ser un componente de la copia de seguridad. Sin embargo, solo se convierte en una fuente de recuperación fiable mediante coherencia, exportación o replicación a un almacenamiento operado independientemente, retención, catálogo y procedimiento de restauración. La API de instantáneas de Kubernetes, por ejemplo, no garantiza por sí misma la coherencia de la aplicación; las aplicaciones deben prepararse adecuadamente antes de la instantánea. En Windows, VSS asume esta coordinación únicamente cuando requester, writer y provider interactúan correctamente (Kubernetes: instantáneas de volúmenes y coherencia de aplicaciones, Microsoft: Volume Shadow Copy Service).

MTD, RTO y RPO corresponden a funciones empresariales y del sistema

El Maximum Tolerable Downtime (MTD) es la interrupción más larga que el proceso de negocio en conjunto puede tolerar. El Recovery Time Objective (RTO) describe cuánto tiempo puede estar indisponible un recurso concreto del sistema antes de afectar de forma inaceptable a otros recursos, al proceso respaldado o a su MTD. El Recovery Point Objective (RPO) designa el momento anterior al evento hasta el que deben restaurarse los datos. Por regla general, el RTO debe ser menor que el MTD, ya que tras la reanudación técnica aún deben procesarse datos y verificarse funcionalmente el servicio (NIST SP 800-34 Rev. 1, sección 3.2).

Un único «RTO de correo» oculta diferencias relevantes. Una plataforma puede aceptar SMTP aunque el acceso de usuarios o la búsqueda todavía no estén disponibles. Una puerta de enlace puede almacenar mensajes en búfer aunque el servicio de buzones posterior esté caído. A la inversa, una interfaz web puede ser accesible mientras faltan claves, consultas de directorio o conectores salientes. Por ello, los objetivos deben definirse por función empresarial y dependencia.

Una vez definidos los objetivos, se debe inventariar el estado real de la plataforma. Una base de datos de buzones por sí sola no restaura ni enrutamiento, ni identidades, ni claves, ni índices de búsqueda.

Inventario de estados de una plataforma de mensajería

Una política de copias de seguridad comienza con un inventario de estados y dependencias, no con el catálogo de productos del fabricante de backup. Para cada estado se documentan la fuente autoritativa, el mecanismo de coherencia, RPO, retención, dominio de protección, método de restauración, orden y paso de verificación. El análisis de impacto en el negocio de NIST identifica procesos críticos, recursos y su prioridad de recuperación; NIST SP 800-184 añade escenarios realistas y dependencias descubiertas durante la recuperación (NIST SP 800-34 Rev. 1, NIST SP 800-184).

La recuperación de colas es un caso especial. SMTP exige ejecutar de forma fiable la responsabilidad aceptada, pero en caso de interrupciones de conexión permite situaciones en las que emisor y receptor evalúan de forma diferente la finalización. Por ello, un estado de cola restaurado puede volver a entregar mensajes. Los runbooks requieren una estrategia definida para duplicados, ID de cola, ventanas temporales y comunicación con destinatarios; copiar simplemente un directorio de spool no es una restauración conforme a norma (RFC 5321, colas y mensajes duplicados).

La coherencia se crea en la capa de aplicación

Un punto de copia coherente ante fallos contiene el estado que un sistema vería tras una pérdida repentina de alimentación. El sistema de archivos y los bloques individuales pueden ser coherentes internamente mientras que bases de datos, blobs y colas relacionados representan momentos diferentes. Un punto de copia coherente con la aplicación coordina búferes de escritura, registros de transacciones, puntos de comprobación y, cuando corresponde, varios volúmenes, de modo que la aplicación tenga una ruta de recuperación definida.

VSS muestra explícitamente esta arquitectura: el requester de backup solicita la copia, el writer específico de la aplicación prepara un conjunto de datos coherente y el provider crea la copia de sombra. Exchange proporciona para ello su propio VSS Writer; por eso, un backup compatible con Exchange es más que una instantánea de sus archivos de base de datos (Microsoft: Volume Shadow Copy Service, Microsoft: Windows Server Backup para Exchange).

PostgreSQL utiliza un modelo de recuperación diferente pero comparable. Un backup base proporciona la base inicial y una secuencia ininterrumpida de segmentos archivados de Write-Ahead Log la prolonga hasta el momento deseado. Un pg_dump es una exportación lógica y no sustituye la cadena de backup base/WAL necesaria para PITR. Los archivos de configuración como postgresql.conf y pg_hba.conf también quedan fuera de esta recuperación WAL y requieren una ruta de copia separada (PostgreSQL: archivado continuo y PITR).

Para productos distribuidos, la documentación del producto debe indicar si los backends se protegen de forma independiente, como grupo de coherencia o mediante funciones de exportación propias de la aplicación. Una instantánea de almacenamiento simultánea de varios volúmenes no constituye automáticamente un corte coherente de base de datos, almacenamiento de objetos, cola e índice de búsqueda. El administrador debe conocer la fuente de verdad y la ruta de reconstrucción permitida para cada proyección.

Inventariar la capacidad y los artefactos de copia de seguridad

Get-Volume | Sort-Object DriveLetter |
  Select-Object DriveLetter, FileSystemLabel, Size, SizeRemaining
Get-ChildItem \\backup.example.ch\mail -File -Recurse |
  Select-Object FullName, Length, LastWriteTime

df -hT
find /backup/mail -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %s %p\n'

Get-Volume y df muestran la capacidad utilizada y libre. Get-ChildItem y find inventarían artefactos y marcas temporales. Ninguno de los dos demuestra coherencia de la aplicación ni recuperabilidad; para ello se requieren evidencias de catálogo, logs y restauración.

Arquitectura de protección: separada, aislada y verificable

Una cadena de copia de seguridad fiable tiene al menos cuatro roles diferenciables:

1. Captura: la aplicación o función de exportación genera un estado definido.
2. Catálogo y manifiesto: ID de backup, fuente, momento, versión de software, logs necesarios, referencias de claves y sumas de verificación hacen que el conjunto sea localizable y verificable.
3. Almacenamiento de recuperación: las copias versionadas se encuentran fuera del dominio de fallo primario y, en lo posible, también del dominio administrativo.
4. Plano de control de recuperación: identidades separadas, runbooks, infraestructura de destino y aprobaciones permiten la restauración cuando la producción no es fiable.

CIS Control 11 exige datos de recuperación protegidos de forma equivalente, una instancia aislada, por ejemplo sin conexión, en la nube o fuera de la ubicación, así como pruebas de restauración periódicas. CISA recomienda para escenarios de ransomware copias de seguridad sin conexión o aisladas de otro modo, cifradas y probadas regularmente, además de imágenes limpias y un entorno de recuperación separado (CIS Control 11: recuperación de datos, CISA: guía StopRansomware).

La inmutabilidad y el aislamiento no son lo mismo. S3 Object Lock puede proteger determinadas versiones de objetos en el modelo WORM frente a eliminación y sobrescritura durante una retención o una retención legal. Los modos de gobernanza y cumplimiento ofrecen posibilidades de omisión diferentes. Esto protege las versiones almacenadas, pero no demuestra ni credenciales separadas ni un extremo de restauración limpio, una cadena de aplicación completa o claves de descifrado accesibles (Amazon S3: Object Lock).

Verificar sumas de comprobación y manifiesto

Get-FileHash .\mail-backup-2026-08-08.tar.zst -Algorithm SHA256
Get-FileHash .\mail-backup-2026-08-08.manifest.json -Algorithm SHA256

sha256sum mail-backup-2026-08-08.tar.zst
sha256sum mail-backup-2026-08-08.manifest.json

Get-FileHash y sha256sum detectan cambios en un artefacto si el hash esperado procede de una fuente fiable. Una suma de comprobación no sustituye la autenticación del manifiesto ni una prueba de restauración. NIST menciona hashes criptográficos y firmas digitales como mecanismos para proteger la integridad de la información de backup (NIST SP 800-34 Rev. 1, CP-9).

Las claves y los secretos requieren un plan de recuperación propio

«Hacer copia de todas las claves privadas» es tan erróneo como «los certificados se pueden volver a emitir». Lo decisivo es el propósito de uso:

• Una clave de servidor TLS perdida normalmente puede sustituirse mediante un nuevo par de claves y certificado; no obstante, la conmutación debe ajustarse al RTO y deben comprobarse las dependencias asociadas de confianza o pinning.
• Una clave de descifrado para datos S/MIME, OpenPGP o backups almacenados debe seguir disponible mientras el texto cifrado protegido deba poder leerse.
• Según NIST, la copia de seguridad de una clave privada de firma generalmente no es deseable, ya que su reutilización puede afectar el valor probatorio de la firma; las excepciones justificadas requieren una recuperación especialmente segura y una sustitución rápida.
• Una clave HSM/KMS no exportable necesita la vía de redundancia, backup o reprovisionamiento prevista por el sistema. Exportar un certificado sin clave privada no constituye una copia de seguridad de clave.
• La clave que cifra el backup no debe encontrarse exclusivamente dentro del backup cifrado ni del dominio de producción comprometido.

NIST exige una decisión según el tipo de clave, metadatos asociados, una política de recuperación de claves y controles de confidencialidad, integridad, disponibilidad y auditoría para el material de recuperación. Si se pierde una clave de descifrado, el texto cifrado ya no se puede convertir nuevamente en texto claro (NIST SP 800-57 Part 1 Rev. 5, NIST SP 800-57 Part 1 Rev. 5, recuperación de claves).

Comprobar el tiempo y la resolución de nombres antes de la restauración

w32tm /query /status
Resolve-DnsName -Type MX example.ch
Resolve-DnsName backup.example.ch

timedatectl status
dig +short MX example.ch
dig +short A backup.example.ch

w32tm y timedatectl comprueban la base temporal para certificados, Kerberos, logs y puntos de recuperación. Resolve-DnsName y dig muestran si los nombres MX, de servicio y de repositorio se resuelven según lo previsto en la zona de recuperación. La fuente de DNS y su autorización de modificación deben figurar por sí mismas en el inventario de dependencias.

Un backup coherente es solo la mitad del plan. Durante la restauración, la identidad, DNS, la base de datos, la cola, las claves y las aplicaciones deben volver en un orden justificado.

La reanudación sigue el grafo de dependencias

Un orden fijo de productos sería inventado. El orden fiable resulta del BIA, el inventario de recursos y las dependencias reales. NIST exige una lista priorizada de recursos del sistema y escenarios de prueba realistas; NIST SP 800-184 requiere incorporar a la documentación las dependencias recién identificadas durante la restauración (NIST SP 800-34 Rev. 1, prioridades de recuperación, NIST SP 800-184, ejecución de recuperación). Para una plataforma de mensajería típica, esto suele dar lugar a la siguiente cadena, que debe validarse localmente:

1. Delimitar el incidente: distinguir entre fallo o compromiso, preservar evidencias, determinar un punto de recuperación limpio conocido y la aprobación.
2. Establecer el plano de control de recuperación: proporcionar identidades de administrador separadas, MFA, runbooks, catálogo de copias y acceso al descifrado.
3. Validar servicios básicos: comprobar red, enrutamiento, DNS, tiempo, LDAP o Kerberos, PKI/KMS y balanceador de carga en la zona de destino.
4. Restaurar la persistencia: reconstruir almacenamiento de objetos/buzones, bases de datos y los logs de transacciones necesarios en un corte coherente.
5. Iniciar la aplicación y la política: aplicar imágenes aprobadas, configuración, secretos, conectores y roles; sin permitir todavía un flujo externo de correo no controlado.
6. Activar la cola y el enrutamiento de forma controlada: evaluar antigüedad, destinatarios, estado de reintentos y posibles duplicados; liberar por separado entrada y salida.
7. Regenerar proyecciones: crear índices de búsqueda, cachés e informes a partir de fuentes autoritativas y supervisar el retraso de reconstrucción.
8. Aceptar la transacción de negocio: probar entrega, acceso al buzón, búsqueda, TLS, cifrado, monitoreo y auditoría frente a criterios definidos.

Para un incidente de seguridad, «el sistema se inicia» expresamente no basta. NIST describe la reconstitución a un estado seguro conocido con parámetros seguros, parches, configuración, software fiable, backup limpio conocido y prueba completa. CIS formula el mismo objetivo como restauración a un «pre-incident and trusted state» (NIST SP 800-34 Rev. 1, CP-10, CIS Control 11: recuperación de datos).

Alcanzar los extremos de recuperación y TLS

Test-NetConnection backup.example.ch -Port 443 -InformationLevel Detailed
curl.exe --verbose https://backup.example.ch/health

nc -vz backup.example.ch 443
openssl s_client -connect backup.example.ch:443 \
  -servername backup.example.ch -verify_return_error

Test-NetConnection y nc comprueban la ruta TCP. curl y openssl s_client muestran el comportamiento de HTTP y TLS, respectivamente. Un extremo de estado accesible solo demuestra el plano de control, no la legibilidad de todos los conjuntos de backup.

La reanudación solo finaliza cuando un usuario o una contraparte puede utilizar realmente el servicio. Un medio de backup leído correctamente no es una prueba suficiente.

Las pruebas de restauración miden el servicio, no el medio

Una prueba completa se realiza en un entorno de destino aislado con punto de partida documentado, medición de tiempo y criterios de aceptación. Comprueba al menos:

• que el catálogo, las credenciales, las claves de descifrado y los artefactos son accesibles sin producción;
• que se puede proporcionar un sistema de destino compatible a partir de imágenes fiables;
• que el backup base, los logs de transacciones, el almacenamiento de blobs y la configuración producen el mismo estado funcional;
• que las colas se procesan de forma controlada y se detectan duplicados;
• que funcionan identidad, DNS, TLS, flujo de correo, acceso al buzón, búsqueda y monitoreo;
• que la pérdida de datos medida y el tiempo de reanudación medido cumplen RPO y RTO;
• que el servicio puede aprobarse como fiable tras incidentes de seguridad.

CIS Control 11.5 evalúa una muestra de backups restaurados y que después funcionan realmente. NIST SP 800-184 mide restauraciones correctas y puntuales y exige escenarios realistas, revisión posterior y mejora del plan (CIS Control 11: prueba de recuperación de datos, NIST SP 800-184). La frecuencia de las pruebas depende del riesgo, la tasa de cambios y los requisitos; una prueba completa anual puede complementarse con muestras automatizadas más frecuentes y restauraciones por componentes, pero no sustituirse por estadísticas exitosas de trabajos.

Listeners y estado de almacenamiento tras la restauración

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess
Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining

ss -lntup
df -hT

Get-NetTCPConnection y ss muestran los listeners locales y los procesos asociados. Get-Volume y df muestran el espacio libre. A continuación, la comprobación debe continuar en el nivel de protocolo: un listener en el puerto 25 todavía no es una transacción SMTP funcional.

Patrones de fallo y alcance de recuperación adecuado

Un fallo determina hasta dónde debe llegar una restauración. Por ello, la tabla vincula el evento observado con el alcance mínimo razonable de recuperación y el supuesto erróneo que se produce con especial frecuencia.

En caso de compromiso, el momento limpio conocido no tiene por qué ser el punto de copia más reciente. Los backups más nuevos pueden contener el estado del atacante; los más antiguos pueden traer vulnerabilidades conocidas o versiones de software incompatibles. Por tanto, la recuperación combina análisis forense, estado de parches, línea base de configuración, rotación de claves y restauración funcional de datos. CISA recomienda, entre otras medidas, «golden images» limpios, definiciones de infraestructura mantenidas sin conexión y una zona de red de recuperación para que los sistemas no vuelvan a infectarse durante la reconstrucción (CISA: guía StopRansomware).

Evolución técnica

La cinta magnética se introdujo a principios de la década de 1950 como medio rápido de almacenamiento de datos para ordenadores y sigue siendo un medio de backup debido a su coste, capacidad y separabilidad física (IBM: cinta magnética). Las arquitecturas de backup posteriores separaron cada vez más el punto lógico de copia del medio de destino: las bases de datos combinaron backups base con logs de transacciones y recuperación a un punto en el tiempo; los sistemas de almacenamiento permitieron instantáneas rápidas; la deduplicación y el almacenamiento de objetos cambiaron la transferencia y la retención.

Para las aplicaciones Windows en ejecución, Microsoft introdujo con VSS un modelo coordinado de requester, writer y provider; la tecnología apareció con Windows XP y Windows Server 2003, respectivamente. En plataformas distribuidas y en contenedores se estandarizaron APIs de instantáneas y orquestación, sin resolver automáticamente por ello la coherencia de las aplicaciones (Microsoft: Volume Shadow Copy Service, Kubernetes: instantáneas de volúmenes).

La recuperación cibernética volvió a desplazar el foco. El versionado y las copias externas no bastan si identidades con privilegios elevados pueden eliminar todos los destinos o si vuelven imágenes comprometidas. Instancias de recuperación aisladas, identidades separadas, versiones inmutables de objetos, infraestructura declarativa y zonas limpias de reanudación complementan los backups clásicos completos, incrementales y basados en logs. Amazon S3 Object Lock se introdujo en 2018 como protección WORM para versiones de objetos; esta función ilustra la transición, pero sigue sin sustituir ni la coherencia de aplicaciones ni las pruebas de restauración (AWS: introducción de S3 Object Lock, Amazon S3: Object Lock).

Lista de verificación para administradores

La planificación solo es fiable cuando los objetivos, las copias, los accesos y las pruebas se documentan conjuntamente. La lista de verificación resume estas dependencias para la revisión y los ejercicios de restauración.

• Los procesos de negocio, MTD, RTO y RPO por función del sistema están aprobados.
• Se han inventariado todos los estados autoritativos y derivados de la plataforma de mensajería.
• La coherencia de la aplicación, la cadena de logs y los grupos de coherencia están documentados de forma específica para el producto.
• Están regulados la restauración de colas, los posibles duplicados y la liberación de entrada y salida.
• La configuración, políticas, DNS, certificados, claves, secretos, licencias y runbooks están dentro del alcance.
• Al menos una copia de recuperación está separada de producción y de las cuentas administrativas principales.
• Se han evaluado por separado inmutabilidad, aislamiento, cifrado y acceso a claves.
• El plano de control de recuperación y la capacidad de destino funcionan sin la producción comprometida.
• El orden de reanudación sigue un grafo de dependencias mantenido.
• Las pruebas restauran una transacción empresarial completa de correo y miden RPO/RTO.
• Los resultados, las nuevas dependencias y las desviaciones se incorporan al runbook y a la arquitectura.

Fuentes

• NIST – SP 800-34 Rev. 1, guía de planificación de contingencias
• NIST – SP 800-34 Rev. 1, PDF
• PostgreSQL – archivado continuo y recuperación a un punto en el tiempo
• NIST – SP 800-184, guía para la recuperación de eventos de ciberseguridad
• NIST – SP 800-184, PDF
• Microsoft Azure Reliability – redundancia, replicación y copia de seguridad
• Kubernetes – instantáneas de volúmenes y coherencia de aplicaciones
• Microsoft Learn – Volume Shadow Copy Service
• IETF RFC 5321 – Simple Mail Transfer Protocol
• Microsoft Learn – Windows Server Backup para Exchange
• Microsoft Learn – Get-Volume
• GNU Coreutils – df
• Microsoft Learn – Get-ChildItem
• GNU Findutils – find
• CIS – Control 11: recuperación de datos
• CISA – guía StopRansomware
• Amazon S3 – Object Lock
• Microsoft Learn – Get-FileHash
• GNU Coreutils – sha256sum
• NIST – SP 800-57 Part 1 Rev. 5
• NIST – SP 800-57 Part 1 Rev. 5, PDF
• Microsoft Learn – w32tm
• systemd – timedatectl
• Microsoft Learn – Resolve-DnsName
• ISC BIND 9 – página de manual de dig
• Microsoft Learn – Test-NetConnection
• OpenBSD – página de manual de nc
• curl – página de manual de línea de comandos
• OpenSSL – s_client
• Microsoft Learn – Get-NetTCPConnection
• Linux man-pages – ss
• IBM – cinta magnética
• Kubernetes – instantáneas de volúmenes
• AWS – introducción de S3 Object Lock