Las cintas no mueren, pero matan.

En la empresa para la que trabajo como administrador de copias de seguridad, Atos, realizamos copias de seguridad en cinta para nuestros clientes, como casi en todas partes. Tanto de clientes enormes como de pequeñas sedes remotas.

En una de estas sedes remotas utilizamos un tipo de cintas que es un estándar empresarial, las Linear Tape-Open Ultrium, si bien de cuarta generación (LTO-4, no es necesario especificar Ultrium ya que nunca se produjeron comercialmente las Accelis), introducidas en 2007, con una capacidad nativa de 800GB.

Y los 800GB son la única medida real del tamaño de la cinta. HP las publicita como cintas de 1,6TB, suponiendo que darán una compresión de 2:1 pero IBM indica realmente que son cintas de 800GB que dan 1,6TB con compresión (suponiendo otra vez 2:1).

Y la realidad es que la capacidad de las cintas depende mucho del tipo de datos que se meta en ellas. Para hacer backups de máquinas completas, con su Sistema Operativo lleno de ficheros binarios, un factor de compresión de 2:1 es excesivamente optimista. En esa sede remota de la que hablo, las cintas de 800GB están cargando entre 970GB y 1020GB (de 1,21:1 a 1,27:1, muy lejos de 2:1), con lo cual los backups completos semanales de 1140GB de esa sede que, según la publicidad, deberían caber en un cartucho, necesitan dos.

Siempre, siempre, un administrador de backup debe trabajar a partir de datos históricos de compresibilidad, y no fiarse de la versión edulcorada de los fabricantes de los cartuchos.

Los puntos de vista expresados en esta entrada son propios, y no representan necesariamente los puntos de vista de Atos SE, Atos España o ninguna de sus filiales.

Los backups incrementales y diferenciales

Una de las cosas con las que se enfrenta, con un poco de miedo, cualquier administrador de copias de seguridad es al backup diferencial.

¿Qué es un backup diferencial? La verdad es que ni siquiera los programas de backup lo tienen claro.

Para empezar, todos tienen claro lo que es un backup Full o completo: se copia todo lo que haya que copiar. Pero no se puede hacer backup de todo todos los días, sería un gasto enorme e inútil de recursos.

Entonces, se puede copiar cada día solamente lo que haya cambiado desde el día anterior. O solamente lo que haya cambiado desde que se hizo el backup Full.

Estas dos estrategias son interesantemente diferentes: si se copia solamente lo que haya cambiado desde el día anterior, todos esos backups serán pequeños, pero a la hora de restaurar (no perdamos de vista que los backups no son el objetivo: su propósito es poder restaurar) son necesarios tanto el backup completo inicial como todos estos backups parciales. En cambio, si se copia todo lo que haya cambiado desde el backup Full, estos backups parciales serán pequeños, sí, pero cada vez más grandes, sin embargo para restaurar solamente serán necesarios el backup completo inicial el el backup parcial en cuestión.

Estas dos estrategias, además, se pueden combinar de varias maneras. Y el problema es que reciben diferentes nombres allá donde se usen.

Uno de los grandes contendientes en la arena empresarial es EMC NetWorker. Para este programa la estrategia de copiar "lo que haya cambiado desde el día anterior" es llamada comúnmente backup incremental, y la de copiar "lo que haya cambiado desde el backup completo" es llamada normalmente backup diferencial. Aunque no es exactamente así: NetWorker tiene 9 niveles de backup diferencial. Así, un backup diferencial de nivel 1 es realmente "lo que haya cambiado desde el backup completo", uno de nivel 2 es "lo que haya cambiado desde el backup completo o desde el backup de nivel 1", etc., permitiendo un control fino de la estrategia de copia, mientras que un backup incremental es realmente "lo que haya cambiado desde el backup anterior". Nótese, por cierto, que en determinadas aplicaciones, como en el módulo de NetWorker para Microsoft SQL Server, el backup "incremental" tiene un uso especial (en MSSQL hace copia de los Transaction Logs), con lo cual no queda disponible para su uso regular. Para el control de lo que se ha copiado en cada uno de estos niveles, NetWorker maneja índices de ficheros.

Otro de los grandes programas es Veritas NetBackup. Para este programa, o su primo Veritas Backup Exec, la estrategia de copiar "lo que haya cambiado desde el día anterior" es llamada "Cumulative incremental" o más comúnmente incremental, y la de copiar "lo que haya cambiado desde el backup completo" es llamada "Differential Incremental" o más amigablemente backup diferencial, pero aquí no trabajan en base a índices de ficheros, sino que el backup incremental copia los ficheros que tengan el bit de Archivo en ON (los nuevos o que hayan sido modificados) y pone dicho bit a OFF, mientras que el backup diferencial copia los ficheros que tengan el bit de archivo a ON pero no modifica dicho bit. El comportamiento de ambos tipos de backups es el esperado, pero la interacción entre ambos es exactamente la contraria que en EMC NetWorker: los backups diferenciales de Veritas NetBackup o Veritas BackupExec "se apoyan", es decir, necesitan a la hora de una restauración, de un backup incremental previo si lo hubiera, mientras que en EMC NetWorker es exactamente al contrario.

El más importante de los programas de backup Open Source, Bacula, usa unas definiciones parecidas: un Incremental es exactamente lo que haya cambiado desde que comenzó el último backup de cualquier tipo, mientras que un Differential es exactamente lo que haya cambiado desde que comenzó (y es importante el detalle "desde que comenzó", ya que puede que no haya acabado) el último backup Full. De este modo, a la hora de la restauración se comportan igual que los de EMC NetWorker.

Para el no iniciado, pensar en términos de completo, diferencial e incremental puede suponer un esfuerzo mental extra. Es más sencillo trabajar solamente con el completo y el incremental, e introducir el diferencial a medida que se coge expericncia con el programa específico con el que se ha de trabajar.

No perder datos ni tiempo

En el mundo empresarial los datos son dinero, y el tiempo también. Un estudio de arquitectura, por ejemplo, que pierda sus datos (planos, informes, fotografías, etc.) irá a la ruina o, como mínimo, pasará un muy mal trago. Así que hay que asegurarse de que los datos no se pierden, para lo que tenemos soluciones como RAID 1 para los fallos de los discos.

Pero los fallos de los discos no son la única causa de que se pierdan datos. De hecho, ni siquiera son la principal. Un error del usuario al borrar un fichero, o un fallo del programa, o cualquier otra causa que vaya al sistema RAID y corrompa el sistema de ficheros puede suponer un desastre casi tan grave, y mucho más probable. Así que hay que asegurarse de que los datos están en más de un sitio a la vez. RAID 1 solamente nos permite seguir trabajando si un disco se estropea mientras llega su recambio. Para las copias de seguridad, tenemos el maravilloso rsync y su intefaz dirvish.

Y como comentaba arriba, no se puede tampoco perder tiempo, así que los datos no solamente deben estar a salvo en la copia de seguridad, sino que en caso de que falle la máquina deben poder ser utilizados inmediatamente mientras el servidor de ficheros es reparado, con lo que las copias de seguridad deben realizarse en un disco externo que pueda enchufarse, provisionalmente, a otra máquina.

Este es el sistema que he montado para una empresa semejante a la que ponía de ejemplo: Un servidor dedicado, con dos discos duros iguales (pero de distintos lotes, para evitar que puedan tener los mismos microdefectos de fabricación que puedan causar su mortalidad infantil o senil a la vez) en RAID 1, salvo el sector de arranque y la partición /boot, que son idénticos en ambos. La zona RAID particionada a su vez mediante LVM, con una parte para el sistema y otra separada para los datos de los usuarios, que se sirven mediante SAMBA. Y finalmente, un disco duro externo, identificado mediante su número de serie, con formato FAT, donde se realizan las copias de seguridad mediante dirvish, que es montada justo antes de copiar y desmontada justo al terminar.

Este disco externo pueden los usuarios desenchufarlo en cualquier momento (aunque les recomiendo que no lo hagan a las horas de las copias ;) ) para disponer de las copias de seguridad en otra máquina, aunque debido a su formato se pierda una de las mejores características de dirvish, los enlaces duros entre copias de distintas fechas, y haya (además) habido que desactivar las opciones de copia de permisos y propietarios.

Así, sea cual sea el incidente (salvo un desastre mayor de la máquina, como un incendio), los usuarios podrán acceder a sus datos de trabajo.

Para alguien que levanta España, no los vamos a dejar sin trabajar, ¿no?

Instalar Lenny

Con las copias de seguridad hechas (gracias a mi bienamado dirvish), voy a hacer una instalación desde cero de Debian 5.0 (antes conocida como Lenny). Ya después haré otras cosas feas como pasarme a testing (Squeeze) o incluso a unstable (Sid), con tal de que no se suban a la parra de KDE 4, que no quiero ni ver (al menos por ahora), pero quiero disfrutar de uno o dos días de estabilidad con mi portátil antes de lanzarme.

Disco duro externo

Finalmente me he comprado un nuevo disco duro externo. En realidad no ha sido un disco externo, sino un disco normal y corriente y una de esas cajas externas para meter el disco dentro.

La caja es la que se ve en la foto: una «MADE IN CHINA» de padre desconocido cuya página web soy incapaz de encontrar. El disco, en cambio, es un Seagate Barracuda (el ST3 500 41 8AS), un disco con interfaz SATA en el que creo que puedo confiar.

Ya les iré contando. De momento, voy a ponerme a configurar el dirvish.

Estas cosas pasan

Lo mejor de tener un disco de copias de seguridad es que, si se te muere el disco duro, no pierdes la información.

Esto es cierto incluso si se muere el disco de las copias de seguridad, que es lo que me acaba de pasar. Hace un par de semanas vi que uno de mis discos externos de LaCie no funcionaba. Precisamente el disco de mis copias de seguridad.

Bueno, pues abrí la caja y vi que el disco interno era un Barracuda SATA de Seagate. No es en absoluto lo que entiendo por un mal disco.

Hoy he comprobado, enchufando el disco directamente a otro ordenador con SATA, que lo puedo dar por difunto. Pero en fin, no he perdido nada: todo lo que había eran copias de seguridad, así que lo único que me queda es rezar para que no se me estropee el disco de sistema antes de comprar otro disco externo para volver a empezar a hacer copias.