Product SiteDocumentation Site

9.10. Respaldo

Making backups is one of the main responsibilities of any administrator, but it is a complex subject, involving powerful tools which are often difficult to master. The importance of backups cannot be stressed enough, though. Backups are also not to be confused with the availability of data. Both can complement each other, but they are essentially different.
Many programs exist, such as amanda, bacula, or BackupPC. Those are client/server systems featuring many options, whose configuration is rather difficult. Some of them provide user-friendly web interfaces to mitigate this. For non-enterprise systems, administrators might want to check out rsnapshot or rdiff-backup. Users can easily create backups of their filesystems with timeshift, fsarchiver, duplicity, or even dd.
Debian contains dozens of other backup software covering all possible use cases, as you can easily confirm with apt-cache search backup.
En lugar de detallar algunos de ellos, esta sección presentará lo que pensaron los administradores de Falcot Corp cuando definieron su estrategia de respaldos.

GOING FURTHER Backup Strategies

The backup strategy for each company or person is different. It depends on many factors. A good starting point is the 3-2-1 rule, though. It is easy and logical. One should have at least three instances of the data, the original and two backups at least. The backups should be stored on at least two different media. And most importantly, one of the backups should be hosted externally (and actually, preferably offline). A fire, a compromise, or a technical quirk should be be able to destroy all backups.
En Falcot Corp los respaldos tiene dos objetivos: restaurar archivos eliminados por error y recuperar rápidamente cualquier equipo (servidor o de escritorio) en el que falle el disco duro.

9.10.1. Respaldos con rsync

Habiendo descartado los respaldos en cintas por ser lentos y costosos, se respaldarán los datos en discos duros en un servidor dedicado en el que utilizarán RAID por software (revise la Sección 12.1.1, “RAID por software”) que protegerá los datos contra errores de disco duro. No se respaldarán individualmente los equipos de escritorio, pero se le informa a los usuarios que se respaldará su cuenta personal en el servidor de archivos del departamento. Se utiliza diariamente el programa rsync (en el paquete del mismo nombre) para respaldar estos diferentes servidores.

VOLVER A LOS CIMIENTOS El enlace duro, un segundo nombre para el archivo

A diferencia de un enlace simbólico, no se puede diferenciar un enlace duro del archivo enlazado. Crear un enlace duro es esencialmente lo mismo que dar al archivo un segundo nombre. Es por esto que eliminar un enlace duro sólo elimina uno de los nombres asociados al archivo. Siempre que quede otro nombre asociado al archivo, los datos en él seguirán presentes en el sistema de archivos. Es interesante saber que, a diferencia de una copia, un enlace duro no ocupa espacio adicional en el disco duro.
Puede crear un enlace duro con ln objetivo enlace. El archivo enlace será un nuevo nombre para el archivo objetivo. Sólo puede crear enlaces duros en el mismo sistema de archivos, mientras que los enlaces simbólicos no tienen dicha restricción.
El espacio en disco disponible prohíbe la implementación de un respaldo diario completo. Por lo tanto, el programa rsync es precedido con una duplicación del contenido del respaldo anterior con enlaces duros, lo que evita utilizar demasiado espacio en disco. Luego, el proceso rsync sólo reemplazará los archivos que fueron modificados desde el último respaldo. Con este mecanismo, pueden mantener una gran cantidad de respaldos en un espacio pequeño. Debido a que todos los respaldos están disponibles inmediatamente (por ejemplo, en diferentes directorios de un recurso compartido en la red) puede realizar comparaciones entre dos fechas rápidamente.
Puede implementar fácilmente este mecanismo de respaldo con el programa dirvish. Utiliza un espacio de almacenamiento de respaldo («bank» — banco — en su vocabulario) en el que ubica copias con marcas temporales de conjuntos de archivos de respaldo (estos conjuntos son llamados «vaults» — bóvedas — en la documentación de dirvish).
La configuración principal se encuentra en el archivo /etc/dirvish/master.conf. Define la ubicación del espacio de almacenamiento de respaldos, la lista de «bóvedas» administradas y los valores predeterminados de expiración de los respaldos. El resto de la configuración está ubicada en los archivos banco/bóveda/dirvish/default.conf y contienen las configuraciones específicas a los conjuntos de archivos correspondientes.

Ejemplo 9.3. EL archivo /etc/dirvish/master.conf

bank:
    /backup
exclude:
    lost+found/
    core
    *~
Runall:
    root    22:00
expire-default: +15 days
expire-rule:
#   MIN HR    DOM MON       DOW  STRFTIME_FMT
    *   *     *   *         1    +3 months
    *   *     1-7 *         1    +1 year
    *   *     1-7 1,4,7,10  1
The bank setting indicates the directory in which the backups are stored. The exclude setting allows you to indicate files (or file types) to exclude from the backup. The Runall is a list of file sets to backup with a time-stamp for each set, which allows you to assign the correct date to the copy, in case the backup is not triggered at precisely the assigned time. You have to indicate a time just before the actual execution time (according to /etc/cron.d/dirvish). Finally, the expire-default and expire-rule settings define the expiration policy for backups. The above example keeps forever backups that are generated on the first Sunday of each quarter, deletes after one year those from the first Sunday of each month, and after 3 months those from other Sundays. Other daily backups are kept for 15 days. The order of the rules does matter, Dirvish uses the last matching rule, or the expire-default one if no other expire-rule matches.

EN LA PRÁCTICA Expiración programada

dirvish-expire no utiliza las reglas de expiración para realizar su trabajo. En realidad, se utilizan las reglas de expiración cuando se crea una nueva copia de respaldo para definir la fecha de expiración asociada con dicha copia. dirvish-expire simplemente examina las copias almacenadas y elimina aquellas cuyas fechas de expiración ya pasaron.

Ejemplo 9.4. El archivo /backup/root/dirvish/default.conf

client: rivendell.falcot.com
tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
exclude:
    /var/cache/apt/archives/*.deb
    /var/cache/man/**
    /tmp/**
    /var/tmp/**
    *.bak
El ejemplo anterior especifica el conjunto de archivos a respaldar: los archivos en la máquina rivendell.falcot.com (para respaldos de datos locales, simplemente especifique el nombre local del equipo según indica hostname), especialmente aquellos en el árbol raíz (tree: /), excepto aquellos enumerados en exclude. El respaldo estará limitado a los contenidos de un sistema de archivos (xdev: 1). No incluirá archivos de otros puntos de montaje. Generará un índice de los archivos almacenados (index: gzip) y el nombre de la imagen estará basado en la fecha actual (image-default: %Y%m%d).
There are many options available, all documented in the dirvish.conf(5) manual page. Once these configuration files are setup, you have to initialize each file set with the dirvish --vault vault --init command. From there on the daily invocation of dirvish-runall will automatically create a new backup copy just after having deleted those that expired.

EN LA PRÁCTICA Respaldos remotos sobre SSH

Cuando dirvish necesita guardar datos en una máquina remota, utilizará ssh para conectarse con ella, e iniciará rsync en modo servidor. Esto necesita que el usuario root pueda conectarse automáticamente. Las llaves de autenticación SSH permiten esto exactamente (revise la Sección 9.2.1.1, “Autenticación basada en llaves”).

9.10.2. Restauración de equipos sin repaldos

Desktop computers, which are not backed up, will be easy to reinstall from custom DVD-ROMs/USB sticks prepared with simple-cdd (see Sección 12.3.3, “Simple-CDD: la solución todo-en-uno”). Since this performs an installation from scratch, it loses any customization that can have been made after the initial installation. This is fine since the systems are all hooked to a central LDAP directory for accounts and most desktop applications are preconfigured thanks to dconf (see Sección 13.3.1, “GNOME” for more information about this).
Los administradores de Falcot Corp están al tanto de las limitaciones de sus políticas de respaldo. Debido a que no pueden proteger el servidor de respaldo tan bien como una cinta en una caja fuerte a prueba de fuego, lo instalaron en una habitación separada para que desastres como fuego en la sala de servidores no destruyan los respaldos junto con todo lo demás. Lo que es más, realizan un respaldo incremental en DVD-ROM una vez por semana — sólo se incluyen los archivos que fueron modificados desde el último respaldo.

YENDO MÁS ALLÁ Respaldo de servicios SQL y LDAP

No es posible hacer copia de seguridad de muchos servicios (como bases de datos SQL y LDAP) simplemente copiando sus archivos (a menos que sean detenidos apropiadamente mientras se crean estos respaldos, lo que frecuentemente es problemático ya que fueron pensados para estar disponibles todo el tiempo). Por lo tanto es necesario utilizar un mecanismo de «exportación» para crear un «volcado de datos» que pueda ser respaldado de forma segura. Generalmente son archivos grandes pero se comprimen fácilmente. Para reducir el espacio de almacenamiento necesario, se puede almacer únicamente un archivo de texto completo por semana y diferencias (diff) cada día, que puede crear utilizando una orden similar a diff archivo_de_ayer archivo_de_hoy. El programa xdelta produce diferencias incrementales de volcados binarios.

CULTURA TAR, el estándar para respaldos en cinta

Históricamente, la forma más sencilla de realizar un respaldo en Unix era almacenar un compendio TAR en una cinta. Inclusive el programa tar obtuvo su nombre de «compendio en cinta» («Tape ARchive»).