Casi todas las empresas tienen backup. Casi ninguna tiene un ensayo de recuperación con fecha en el calendario. La diferencia entre ambas cosas solo aparece el día en que alguien necesita el archivo de vuelta — y entonces ya no es un ejercicio.

El motivo del aplazamiento no es pereza. Es que el backup emite una señal de éxito todos los días, y el restore no pide nada. El job termina, el panel queda verde, el informe llega por correo. Todo el sistema fue construido para informar que la escritura salió bien. Nadie construyó nada que informe que la lectura va a salir bien.

Qué demuestra realmente un "backup completado"

Demuestra que los bytes salieron del origen y llegaron al destino. Nada más.

No demuestra que el índice que mapea archivo a objeto esté consistente. No demuestra que la clave de cifrado guardada en la bóveda sea la clave correcta. No demuestra que la cuenta que hará la recuperación tenga permiso de lectura en el bucket. No demuestra que alguien conozca el orden de arranque de los servicios. Y no demuestra lo que más duele: cuánto tiempo tarda.

Cada uno de estos es un modo de fallo independiente. Backup en verde y restore imposible conviven sin contradicción.

Las cuatro cosas que se prueban

Integridad. ¿El archivo que vuelve es idéntico al que subió? La verificación honesta es comparar el checksum del original con el del restaurado, no abrir el archivo y ver que parece correcto. En bases de datos, integridad significa restaurar el dump y ejecutar la verificación de consistencia del propio SGBD. Un dump que se descarga completo y no importa es un archivo íntegro e inútil.

Tiempo. Cronometrado con reloj, desde la solicitud hasta el dato utilizable. Ese número es tu RTO real. El RTO que figura en el documento es una intención. La distancia entre ambos suele ser grande, y es mayor cuando el almacenamiento es de clase de archivado (Glacier Flexible Retrieval, Deep Archive, Azure Archive): en esas clases existe una etapa de rehidratación antes de la descarga, con su propio plazo, que varía según el nivel elegido. Las clases de acceso infrecuente y Glacier Instant Retrieval no pasan por rehidratación — el objeto sale en acceso directo. La documentación de AWS sobre restauración de objetos archivados y la descripción general de rehidratación de Azure Blob describen los niveles disponibles en cada plataforma. Si tu backup está en clase de archivado, ese tiempo no es un detalle: es la mayor parte del reloj. Escribimos sobre ese comportamiento en Deep Archive en la práctica.

Permisos. La prueba tiene que ejecutarse con la identidad que va a existir el día malo. Es tentador recuperar con la credencial de administrador que está en tu máquina — y es justamente esa la que puede no existir durante el incidente, porque el incidente puede ser la pérdida de la máquina, la rotación forzada de credenciales o el compromiso de la cuenta. Prueba con la cuenta de recuperación, desde un host que no sea el servidor de backup.

Orden de dependencia. Un sistema no vuelve archivo por archivo. Vuelve en capas: red, secretos, base de datos, cola, aplicación, DNS. Restaurar la aplicación antes de la base de datos produce una aplicación que arranca, responde al healthcheck y sirve errores. El orden tiene que estar escrito, y el ensayo es lo que revela el elemento olvidado — casi siempre un secreto, un certificado o una variable de entorno que nunca entró en el alcance del backup.

Un ejercicio que cabe en una mañana

No intentes ensayar el desastre completo la primera vez. Un ensayo demasiado grande es un ensayo que nunca ocurre. Empieza con un alcance pequeño y cerrado.

Elige el objetivo el día anterior. Un directorio real, una base de datos pequeña, un volumen de máquina virtual. Algo que importe, pero cuya indisponibilidad no detenga a nadie.
Escribe la hipótesis antes. "Espero recuperar 8 GB en menos de dos horas, usando la cuenta restore-ops, sin necesitar a nadie del equipo de infraestructura." Una hipótesis escrita convierte el ensayo en medición. Sin ella, el resultado siempre es "salió bien".
Restaura en un destino aislado. Bucket aparte, host aparte, base de datos aparte. Nunca encima de producción. Un restore de ensayo que sobrescribe datos buenos es un incidente creado por el propio ejercicio.
Cronometra en tres hitos. Solicitud hecha; dato disponible para descarga; dato utilizable por la aplicación. Los tres números cuentan historias diferentes, y el tercero es el único que el negocio entiende.
Verifica con checksum. sha256sum en el origen y en el destino, comparación automática. El muestreo sirve para volúmenes grandes, siempre que la muestra sea aleatoria y no los primeros archivos de la lista.
Anota lo que faltó. Todo primer ensayo descubre algo ausente. Es el producto principal del ejercicio, no un fracaso.
Cierra con el registro. Fecha, alcance, tiempos, quién lo ejecutó, qué se rompió, qué cambió en el runbook. Una página. Sin eso, el siguiente ensayo empieza de cero.

Ensayar cuesta dinero, y el costo tiene una forma conocida

Esta es la objeción real, y merece una respuesta honesta. Recuperar no es gratis. El cobro suele tener cuatro componentes, y todos los grandes proveedores usan alguna combinación de ellos:

Solicitudes. Se cobran por operación. Recuperar un millón de archivos pequeños genera un millón de operaciones, y esa cuenta a veces supera la del almacenamiento del mes.
Salida de datos. Sacar datos de la nube suele tener precio por gigabyte en la mayoría de los proveedores. Restaurar hacia un host dentro de la misma región suele ser bastante más barato que restaurar hacia la oficina.
Recuperación de datos archivados. En archivado, además del almacenamiento pagas por el volumen recuperado, con precio distinto según el nivel de urgencia.
Mínimo de retención y penalización por eliminación anticipada. Las clases frías cobran un período mínimo. Borrar la copia del ensayo antes de ese plazo puede generar un cargo por el resto.

No pongo valores aquí porque cambian y varían según la región. Abre la tabla de precios actual de tu proveedor, para tu región y tu clase, y calcula el costo del ensayo antes de ejecutarlo. Dos decisiones reducen ese costo sin falsear la prueba: restaurar una muestra en lugar del conjunto completo, y restaurar dentro de la misma región. La muestra mide integridad y permisos de forma suficiente para el ensayo. Lo único que no mide es el tiempo total — para eso, una vez al año, vale la pena pagar el ensayo grande.

Una cadencia que funciona

Mensual, pequeño y automatizado: un objetivo rotativo, restaurado por script, con checksum comparado y resultado registrado. Trimestral, mediano: un servicio entero, con el orden de dependencia ejercitado y con distintas personas de guardia conduciéndolo. Anual, grande: el escenario de pérdida total, con el tiempo medido de punta a punta.

El criterio de rotación es simple: ensaya primero lo que más miedo te da perder y menos costumbre tienes de tocar.

Lo que este artículo no demuestra

No traigo aquí ninguna medición, y es deliberado: tu reloj depende del volumen, de la clase de almacenamiento, de la región y del disco de destino. El número de la prueba de otro no es una promesa sobre tu caso — mide el tuyo.

Hay situaciones en las que el consejo anterior es malo. Si tu backup está en una clase fría con un mínimo de retención largo y el presupuesto es ajustado, el ensayo mensual del conjunto completo es un desperdicio: usa una muestra y reserva la prueba completa para una vez al año. Si la base contiene datos personales sensibles, restaurar en un entorno de prueba puede violar tu propia política — en ese caso el ensayo exige anonimización o un entorno con el mismo control que producción, y eso cambia el esfuerzo. Y si tu operación es de un solo servidor, con una sola persona, el ritual de tres cadencias es burocracia: un ensayo semestral bien registrado ya resuelve.

Este texto tampoco cubre la recuperación de sistemas distribuidos con estado replicado, donde el orden de dependencia es bastante más complejo de lo que la lista anterior sugiere. Y no trata de quién tiene la clave, que es un problema aparte y tan grave como este — está en quién puede abrir tu backup.

Lo que queda es la parte que vale para todo el mundo: un restore no probado es una hipótesis. La hipótesis cuesta una mañana para convertirse en hecho.

NubliVault es el producto de backup de Nublify: empaqueta millones de archivos pequeños y los guarda en una nube distinta a la de origen. Cómo funciona · Seguridad