Tips para diseñar sistemas de backup realmente útiles

El sistema de backup de una infraestructura compleja tiene que ser lo más simple posible: fácil de entender por alguien - un administrador - que no sea un especialista, y se haga cargo de la administración.

Fácil de usar para quienes no sean admins especialistas en backup, fácil para trabajar en una emergencia, cuando se necesita del backup y no se puede prestar atención a los detalles técnicos intrincados de un sistema de backup complejo; y finalmente fácil de restaurar a su funcionamiento normal cuando hay alguna falla interna.

Catálogos internos que se guardan en bases de datos propietarias, backends en bases de datos que pueden fallar, múltiples componentes distribuídos (que necesitan literalmente matemática combinatoria y grafos para llegar a conocer todos los posibles estados de error del sistema), etc. conspiran contra sistemas de backup simples y realmente manejables.

Los casos en que hace falta que un sistema de backup sea complejo e intrincado son escasos, muy raros. La mayoría de la infraestructura se puede diseñar y configurar de modo tal de disponer de "dropboxes" fácilmente recuperables: son directorios/carpetas donde se depositan o hacen disponibles los datos a resguardar.

Un ejemplo de "dropboxes" se da cuando se quiere backupear una base de datos y se guarda datos a un directorio que luego será backpeado:

- Con el clásico procedimiento de dumpear bases a backupear, o
- En un backup "raw", en crudo, bajando la base y backupeando limpiamente todos los directorios donde el software guarde y escriba datos. Lo que es posible en gral. y sin mucho problema en sistemas Linux y *Nix, y suele ser más complicado en Windows Server, debido a que muchos valores de configuración pueden estar guardados en el registro (hace falta crear un paso intermedio donde se "dumpea" todos los valores relevantes del registro a un archivo .reg que permita luego recuperar "crudamente" el software en un Windows "limpio").