Estrategia de copias de seguridad: de la regla 3-2-1 a una recuperación probada

Una copia por sí sola no restaura un proceso empresarial

El lunes falta una carpeta de proyecto, pero la sincronización ya ha propagado por todas partes el borrado del fin de semana. Otra empresa conserva sus datos, pero no puede reiniciar la gestión de inventario tras un fallo de servidor porque faltan el archivo de licencia, la configuración de la base de datos y el acceso de administrador. Ambos ejemplos muestran por qué una estrategia debe explicar algo más que dónde se guarda una copia.

El resultado consiste en que un proceso concreto vuelva a funcionar con un estado de datos aceptable dentro de un tiempo acordado. Una pequeña empresa de oficios puede necesitar un enfoque distinto del de un sistema de pedidos operativo las veinticuatro horas. La planificación económica empieza con esa distinción.

Elegir la pérdida aceptable antes del calendario de copias

El objetivo de punto de recuperación (RPO) limita en el tiempo la pérdida de datos aceptable. Un RPO de cuatro horas requiere un punto recuperable de no más de cuatro horas de antigüedad al producirse el fallo. El objetivo de tiempo de recuperación (RTO) describe el tiempo previsto hasta reanudar el servicio. Las copias nocturnas por sí solas no cumplen un RPO de cuatro horas y una descarga rápida no demuestra el RTO.

El equipo de negocio debe acordar estos objetivos. Volver a introducir pedidos a partir de correos puede compensar parte de los datos perdidos, pero sigue costando tiempo del personal. La espera del hardware, la disponibilidad del proveedor y la validación final de negocio cuentan para la interrupción real. Los ejemplos siguientes ilustran la planificación; no son recomendaciones universales.

• Documentos de proyecto: RPO de cuatro horas, RTO de un día laborable; varios puntos diarios y restauración selectiva de carpetas.
• Pedidos actuales: RPO de una hora, RTO de cuatro horas; protección de base de datos y entorno de recuperación inmediatamente disponible.
• Sitio web público: RPO de 24 horas, RTO de ocho horas; proteger conjuntamente contenido, aplicación, configuración y administración del dominio.

3-2-1 necesita copias realmente independientes

La regla clásica significa tres copias incluida la de producción, dos tipos de soporte y una copia externa. Examine también las causas de fallo compartidas. Dos directorios en un NAS no son protección independiente. Una segunda cuenta en la nube solo ayuda si el administrador principal no puede modificar también su conservación y sus datos.

Una combinación práctica es disponer de datos de producción, una copia local para restauraciones rápidas y una copia externa separada ante la pérdida de la sede. Una copia desconectada o temporalmente inmutable limita aún más los cambios no deseados. RAID puede soportar ciertos fallos de disco, pero no proporciona versiones históricas independientes.

La inmutabilidad tiene límites específicos de cada producto. S3 Object Lock protege versiones concretas de objetos durante un período definido, mientras que pueden seguir creándose versiones nuevas. Pruebe la conservación y ajústela al presupuesto de almacenamiento y al procedimiento de recuperación.

Archivos, bases de datos y servicios en la nube necesitan métodos diferentes

Los documentos suelen necesitar una versión anterior concreta. Una base de datos necesita que los cambios relacionados sean consistentes; copiar archivos abiertos en un instante arbitrario puede no conseguirlo. Las copias con conocimiento de la aplicación coordinan un punto de recuperación con una aplicación compatible. Compruebe la compatibilidad de la base de datos pertinente, en vez de suponer que la consistencia de aplicaciones es universal.

Para servicios en la nube, inventaríe cuentas, permisos, conservación y exportaciones. Las papeleras y el historial de versiones pueden ayudar, pero no son automáticamente copias independientes. Determine si los datos necesarios siguen disponibles tras perder la cuenta o caducar el historial. Una exportación solo es útil si el destino puede importarla.

Calcular el coste de toda la vía de recuperación

Incluya licencias, crecimiento, copias externas, capacidad de recuperación, supervisión y tiempo de ejercicios. Los proveedores pueden cobrar por recuperar datos, conservación mínima o transferencia. Una conservación larga no reduce el coste cuando llegan grandes cantidades de datos nuevos a diario. Mida deduplicación y compresión con datos reales, en lugar de suponer un descuento estándar.

Este cálculo de ancho de banda es ilustrativo: transferir 1 TB por una conexión de 100 Mbit/s utilizable al máximo de forma continua tarda aproximadamente 22.2 horas, con unidades decimales e ignorando la sobrecarga del protocolo. Desempaquetar, iniciar la base de datos y validar llevan más tiempo. Una recuperación en cuatro horas necesita un camino más rápido o copias ya cercanas al entorno de recuperación.

Una propuesta debe identificar sistemas protegidos y exclusiones, copias, conservación, objetivos, un contacto disponible, acceso documentado y la primera restauración correcta cronometrada. Acepte por separado la restauración de elementos individuales y el reinicio del servicio completo.

Realizar un ejercicio con un resultado verificable

Elija un proceso completo pero manejable, como la gestión de pedidos. Restaure un punto seleccionado en un entorno de pruebas aislado y verifique acceso, búsqueda de pedidos, recuperación de documentos y una transacción de prueba inocua. Evite que notificaciones o pedidos reales lleguen a sistemas externos. Registre el punto inicial, las dependencias y el resultado previsto antes de empezar.

Mida más que la copia: registre el comienzo del incidente simulado, la disponibilidad de credenciales, el arranque de la aplicación, la finalización de las comprobaciones de negocio y la fecha y hora de los datos recuperados. Compare tiempo real de recuperación y pérdida con RTO y RPO. Asigne a cada desviación un responsable y un plazo, en lugar de ajustar el informe para aparentar éxito. Repita las pruebas tras cambios importantes de base de datos, cifrado o alojamiento.

Una alerta debe conducir a una acción

Las tareas fallidas son solo una señal. También importan las copias ausentes, los conjuntos de datos inusualmente pequeños, el crecimiento sostenido y los puntos de recuperación más antiguos que la ventana acordada. Clasifique cada alerta y envíela a alguien capaz de actuar durante el horario de soporte contratado.

Un sistema crítico podría alertar cuando el último punto de recuperación confirmado alcance una antigüedad de aviso interna, dejando tiempo para investigar y comprobar copias alternativas antes de incumplir el RPO. Pruebe la vía de notificación y confirme que un sustituto recibe la misma información.

La entrega forma parte de la aceptación

El plan de recuperación debe seguir accesible sin el servidor averiado ni el conocimiento de una sola persona. Identifique contactos, productos y versiones, orden de dependencias y acceso seguro a claves y credenciales. Guarde las contraseñas en un gestor adecuado con acceso de emergencia controlado, no expuestas en un manual general.

Una segunda persona debería realizar una restauración delimitada utilizando solo la documentación. Registre cualquier carencia de conocimiento. La frecuencia de los ejercicios depende del ritmo de cambio y la criticidad: una revisión anual documentada puede ser un punto de partida, mientras que los sistemas centrales que cambian con frecuencia o los objetivos incumplidos exigen controles más próximos.