Backup doméstico seguro con Linux, cifrado y ZFS (III)
Hace un año publiqué un par de artículos interesantes:
- Backup doméstico seguro con Linux, cifrado y ZFS.
- Backup doméstico seguro con Linux, cifrado y ZFS (II).
El sistema sigue en producción y bien. No hay incidentes reseñables más allá de la virtualización sobre un Windows 8 doméstico (detalle anecdótico de mi configuración particular).
El proceso es simple y rutinario: el sistema de backup tiene configurado un mirror formado por dos discos. Uno de los discos está enchufado y funcionando, pero el otro está offline y, de hecho, guardado bajo llave en una localización remota.
En las vacaciones recojo el disco duro offline y lo enchufo al sistema de backup. Esto hace que el mirror resincronice los discos con todos los cambios. Una vez que ambos discos están al día, entonces procedo a realizar una revisión completa de ambos discos duros. Comprobado que todo está OK, desenchufo el disco duro original y dejo conectado el que estaba offline, básicamente alternando los dos discos duros.
Este esquema me protege de catástrofes graves como incendios, inundaciones o robos. O de fuentes de alimentación que fallan y se llevan los discos por delante, o bugs del sistema operativo. También te proteje de meteduras de pata, como borrar algo importante por error. La alternancia de los discos duros los desgasta por igual. Los discos duros en sí están cifrados, así que almacenarlos por ahí no es problema.
En caso de corrupciones puntuales con el disco duro activo, ZFS lo detectará perfectamente. Si la corrupción está en los metadatos, típicamente lo solucionará de forma automática:
En caso de corrupción en los datos en sí, ZFS lo detecta pero no puede corregir el problema porque el otro componente del mirror está offline. Si los datos son antiguos y están en espejo, el problema se solucionará solo en las siguientes vacaciones, cuando conecte ambos discos duros. Si los datos son recientes y no están en el disco mirror desconectado, lo mejor es que borremos ese fichero y lo volvamos a copiar de la fuente original. Recordemos que estamos hablando de un sistema de backup. Los datos originales o están en otro sitio (la fuente original) o se han borrado pero son antiguos y deberían estar en ambos discos del mirror.
Recomiendo leer los artículos originales enlazados al principio, que explican todo esto con detalle.
Este verano toca nueva rotación de disco duro. Veámoslo:
Primero vemos el estado actual del sistema de backup:
root@csi:/datos# zpool status
pool: datos
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: scrub repaired 0 in 16h23m with 0 errors on Tue Jan 7 07:35:16 2014
config:
NAME STATE READ WRITE CKSUM
datos DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
segundodisco ONLINE 0 0 0
primerdisco OFFLINE 0 0 0
errors: No known data errors
Aquí puede verse que solo tenemos un disco duro enchufado. Bien.
Conectamos el disco duro que falta y le decimos al sistema que ya está disponible y que puede usarlo (podemos enchufarlo y no permitir su uso, por eso hay que hacerlo explícito):
root@csi:/datos# zpool online datos primerdisco
root@csi:/datos# zpool status
pool: datos
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Aug 10 15:53:13 2014
37.9M scanned out of 1.49T at 1.58M/s, 274h43m to go
37.1M resilvered, 0.00% done
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
segundodisco ONLINE 0 0 0
primerdisco ONLINE 0 0 0 (resilvering)
errors: No known data errors
Aquí ZFS empieza a copiar los datos nuevos en el disco duro que estaba desconectado. Es de señalar que el tiempo empleado es proporcional a los datos que hayan cambiado, no al volumen de datos en total. El tiempo indicado no es realista porque la velocidad de operación varía mucho a lo largo del proceso.
Si la máquina se reiniciase, etc, el resilvering continuaría donde iba, así que el progreso es constante. Es cuestión de esperar a que termine.
Podemos ir viendo la actividad de disco de forma simple:
root@csi:/datos# zpool iostat -v 10 99999
[...]
capacity operations bandwidth
pool alloc free read write read write
---------------- ----- ----- ----- ----- ----- -----
datos 1.49T 332G 428 70 3.77M 180K
mirror 1.49T 332G 428 70 3.77M 180K
segundodisco - - 119 13 4.81M 154K
primerdisco - - 0 165 0 4.74M
---------------- ----- ----- ----- ----- ----- -----
[...]
Aquí se ve claramente el proceso de copia de datos nuevos de segundodisco a primerdisco.
Una vez que la sincronización del mirror se completa, vemos algo así:
root@csi:~# zpool status
pool: datos
state: ONLINE
scan: resilvered 30.3G in 2h5m with 0 errors on Sun Aug 10 17:58:23 2014
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
segundodisco ONLINE 0 0 0
primerdisco ONLINE 0 0 0
errors: No known data errors
Vemos que la sincronización supuso mover 30.3 Gigabytes, en 2 horas y cinco minutos. Esto nos da una velocidad media de 4.14MB/s. Es un poco lento debido a los movimientos constantes del cabezal del disco duro. Esto es bastante más lento que la velocidad posible de los discos duros el modo lineal. Hay que valorar la velocidad lineal de un RAID normal, pero que sincroniza el disco duro entero o la velocidad seek de ZFS sincronizando solo los cambios. Obviamente cuando el almacenamiento sea SSD, el seek no será un problema.
Hasta aquí sabemos que los datos nuevos están correctamente en los dos discos duros. Pero yo quiero estar seguro de que TODOS los datos están correctos. En ZFS podemos revisar ambos discos duros, detectar cualquier corrupción y corregirla aprovechando la información almacenada en el otro disco duro:
root@csi:/datos# zpool scrub datos
[...]
root@csi:/datos# zpool status
pool: datos
state: ONLINE
scan: scrub in progress since Mon Aug 11 11:09:47 2014
570G scanned out of 1.49T at 27.1M/s, 10h0m to go
0 repaired, 37.40% done
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
segundodisco ONLINE 0 0 0
primerdisco ONLINE 0 0 0
errors: No known data errors
root@csi:~# zpool iostat 10 99999
[...]
datos 1.49T 332G 210 17 24.3M 44.2K
datos 1.49T 332G 218 34 24.7M 87.6K
datos 1.49T 332G 185 17 21.3M 43.8K
datos 1.49T 332G 191 46 22.0M 232K
datos 1.49T 332G 202 17 24.0M 44.1K
[...]
root@csi:/datos# zpool status
pool: datos
state: ONLINE
scan: scrub in progress since Mon Aug 11 11:09:47 2014
1.43T scanned out of 1.49T at 24.0M/s, 0h40m to go
0 repaired, 96.29% done
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
segundodisco ONLINE 0 0 0
primerdisco ONLINE 0 0 0
errors: No known data errors
[...]
root@csi:~# zpool iostat 10 99999
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
[...]
datos 1.49T 332G 336 18 8.11M 48.9K
datos 1.49T 332G 1.63K 36 2.21M 98.1K
datos 1.49T 332G 651 34 9.94M 91.5K
datos 1.49T 332G 561 17 3.90M 45.7K
[...]
root@csi:/datos# zpool status
pool: datos
state: ONLINE
scan: scrub repaired 0 in 17h59m with 0 errors on Tue Aug 12 05:09:37 2014
config:
NAME STATE READ WRITE CKSUM
datos ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
segundodisco ONLINE 0 0 0
primerdisco ONLINE 0 0 0
errors: No known data errors
Aquí lanzamos un scrub que revisa todos los datos y metadatos de ambos discos duros, aprovechando que en este momento el mirror está completo para corregir cualquier problema que se detecte. El proceso se completó en 18 horas sin detectar ningún problema. Sale una velocidad media de 24MB/s, que es bastante razonable teniendo en cuenta que el tráfico real es el doble (24MB/s para cada uno de los dos discos duros) y que estamos bajo máquina virtual. Si hubiéramos reiniciado el ordenador el scrub continuaría donde se hubiera quedado; el progreso es constante.
Ahora que sabemos que el mirror está perfectamente sincronizado y que todos los datos son correctos, procedemos a desactivar y extraer el disco duro "antiguo":
root@csi:/datos# zpool offline datos segundodisco
root@csi:/datos# zpool status
pool: datos
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: scrub repaired 0 in 17h59m with 0 errors on Tue Aug 12 05:09:37 2014
config:
NAME STATE READ WRITE CKSUM
datos DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
segundodisco OFFLINE 0 0 0
primerdisco ONLINE 0 0 0
errors: No known data errors
Empaquetamos el disco duro reemplazado (recordemos que el disco está cifrado) y lo enviamos a la localización remota para su almacenaje hasta las próximas vacaciones, en navidad.
Asunto finiquitado.