Cómo probar un restore, no solo un backup

Cualquier consola de backup del mundo puede mostrarle una columna de marcas verdes. Ninguna puede decirle si su negocio volverá a funcionar a la hora de comer tras una mala noche. Solo un restore puede decírselo, y el único restore en el que puede confiar es uno que ya ha hecho. Así se prueban los restores para que el resultado signifique algo.

Qué demuestra realmente una tarea en verde

Una tarea de backup con éxito demuestra que una tarea se ejecutó, leyó algunos datos y los escribió en algún sitio sin un error que el software reconociera. No demuestra que los datos estén completos, que la máquina que le importa estuviera en la tarea, que la copia pueda leerse de vuelta, ni que la aplicación arranque desde ella.

Hay tres cosas que probar: la cobertura (¿se está haciendo backup de todo lo que debería?), la recuperabilidad (¿puede la copia leerse y arrancarse?) y el tiempo (¿cuánto tarda realmente una recuperación?). La mayoría de las organizaciones no prueban ninguna de las tres con una periodicidad.

Paso uno: compruebe la cobertura frente a la realidad

Las tareas de backup se definen en un momento dado. La infraestructura sigue cambiando. Una máquina virtual nueva creada junto a las antiguas, una base de datos movida a un host nuevo, un servidor renombrado: cada uno puede quedar fuera de todas las tareas sin que se levante un solo error.

Así que compare la lista de lo que existe con la lista de lo que está protegido. Exporte el inventario desde el lugar que sabe qué está funcionando, el hipervisor, la plataforma cloud o el DCIM, y la lista de objetos protegidos desde el sistema de backup, y compárelas:

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

La primera lista es la peligrosa. La segunda es ruido que la esconde. Cada entrada de la primera lista necesita una decisión: añadirla a una tarea, o dejar por escrito que deliberadamente no tiene backup y por qué.

Paso dos: restaure en más de un nivel

La recuperabilidad tiene niveles, y cada nivel detecta problemas que el anterior pasa por alto.

Nivel de fichero. Restaure una muestra de ficheros en una ubicación alternativa y compárelos con sumas de comprobación contra el origen o una copia conocida como buena. Esto detecta medios ilegibles y cadenas rotas de backups incrementales.

Nivel de máquina. Arranque un servidor o una máquina virtual completos desde el backup. Esto detecta volúmenes de arranque ausentes, drivers y el disco que quedó excluido de la tarea sin hacer ruido. La mayoría de las plataformas de backup enterprise, Veeam entre ellas, pueden arrancar una máquina directamente desde el repositorio de backup en un laboratorio aislado precisamente para esto.

Nivel de aplicación. Demuestre que la aplicación funciona desde la copia restaurada. Para una base de datos, eso significa que arranca, pasa su propia comprobación de consistencia, y contiene los registros más recientes que espera para el momento del backup:

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Para las herramientas de backup a nivel de fichero hay comprobaciones de integridad que leen de vuelta los datos almacenados, por ejemplo borg check --verify-data en un repositorio Borg.

Paso tres: restaure en un laboratorio, no en producción

Una máquina restaurada es una copia de producción, con las direcciones, las credenciales, las tareas programadas y el correo saliente de producción. Levántela en la red real y puede responder peticiones destinadas al servidor en vivo, enviar a los clientes un lote de correos duplicados, o ejecutar por segunda vez la facturación de anoche.

Las pruebas de restore pertenecen por tanto a una red aislada sin ruta a producción y sin ruta a internet. Antes de arrancar cualquier aplicación en ese laboratorio, deshabilite el planificador y el correo saliente en la copia restaurada. Conviértalo en un paso escrito de la prueba, para que nadie tenga que acordarse.

Paso cuatro: cronométrelo

El tiempo de recuperación sobre el papel es una estimación. El que cuenta es el medido: desde el momento en que alguien decide restaurar, pasando por encontrar el punto de restauración correcto, mover los datos, arrancar los servicios y comprobar la aplicación, hasta la primera transacción real con éxito. Los restores grandes suelen estar limitados por un caudal que nadie midió, o por un paso que solo una persona sabe hacer. Cronometrar la secuencia completa encuentra ambas cosas.

Paso cinco: escríbalo

Guarde una entrada corta por cada uno:

• Fecha, y quién lo ejecutó.
• Qué se restauró, desde qué punto de restauración.
• Qué nivel se probó: fichero, máquina o aplicación.
• Tiempo empleado, de principio a fin.
• Cualquier cosa que fallara, le sorprendiera o necesitara conocimiento que no está escrito.
• Qué se cambió como resultado.

El diseño de debajo también importa

Las pruebas demuestran que los backups existen y funcionan hoy. El diseño decide si seguirán existiendo tras un mal día. La regla que más importa es que los backups se extraen (pull). El sistema de backup llega hasta producción y toma lo que necesita; producción no tiene ninguna ruta de red hacia el sistema de backup ni credenciales para él. Así, un intruso que se adueña de un servidor de producción no puede llegar a los propios backups de ese servidor para borrarlos. El acceso append-only para las herramientas a nivel de fichero añade una segunda cerradura, y el historial en el repositorio significa que sigue existiendo una copia anterior al problema.

Cómo lo hacemos nosotros

Nuestros backups son pull-only por diseño e impuestos en los appliances de firewall, con solo la red de gestión capaz de llegar a los sistemas de backup y recuperación. Usamos Veeam para máquinas virtuales, servidores físicos y servidores SQL, y un hub de backup con deduplicación que extrae datos de ficheros y bases de datos Linux usando claves restringidas y append-only. La cobertura se comprueba contra el inventario en vivo, las planificaciones se fijan a partir de tiempos de ejecución medidos, y los restores completos se ejecutan hasta semanalmente.

Si nunca ha cronometrado un restore completo de su sistema más importante, ese es el que debe empezar, y con gusto le ayudamos a planificarlo.

CTA

Hable con un ingeniero

Related

Relacionado: Disaster recovery y réplicas entre sedes · Replicación de storage entre Atenas y Ámsterdam · Servicios de ficheros NAS, NFS y SMB