Backup doméstico seguro con Linux, cifrado y ZFS (IV): Elección de sistema operativo y configuración
Antes de continuar lee Backup doméstico seguro con Linux, cifrado y ZFS (IV): Equipo nuevo.
Moviendo mi backup a una máquina dedicada me permite reevaluar mi elección de sistema operativo, tecnología y configuración.
Reparticionar los discos de datos no es una opción, porque están en producción. Meter un disco duro pequeño para el sistema operativo supone un coste adicional, la ocupación de una bahía SATA y un incremento del consumo eléctrico.
Tengo a mano dos tarjetas microSD viejas, pequeñas y lentas, de 1GB y 4GB. Son pequeñas para un uso serio pero perfectas para esto. Son tarjetas lentas pero la idea es que la actividad en la microSD sea mínima tras el arranque del sistema y que el tráfico se concentre en los discos duros.
Otro detalle que hay que saber es que dentro de la LAN de mi padre hay una RaspberryPI funcionando 24x7.
Mi valoración es la siguiente:
-
Arranque PXE:
El nuevo servidor puede arrancar por PXE. Esto permitiría un arranque remoto con un sistema arbitrario, sin necesidad de tener nada instalado en el servidor. Por ejemplo, podría descargar la imagen a arrancar desde la RaspberryPI.
La idea es buena pero tiene tres problemas:
- Un arranque PXE requiere la colaboración del servidor DHCP. En este caso el servidor DHCP es el router instalado por el ISP. Aunque podría usar la RaspberryPI como servidor DHCP, mi padre acostumbra a cambiar de router con frecuencia y cualquier configuración local no estándar es problemática. Al fin y al cabo yo no vivo ahí.
- Perder la RaspberryPI sería un problema serio. Perdería tanto el servidor de backup como mi acceso remoto a la LAN.
- Hay que confiar en la LAN. Con todo lo que hay pinchado ahí prefiero no hacerlo.
-
Partición de arranque en la microSD y disco raíz en NFS:
La tarjeta microSD del servidor podría contener la partición de arranque exclusivamente, que solo se usa al reiniciar, y todo el sistema operativo en sí puede estar albergado en la RaspberryPI y ser accesible por NFS.
Esta idea es interesante porque la microSD de 1GB solo para el arranque iría sobrada y su rendimiento no sería un problema. Tampoco lo sería para el tráfico de escritura.
Algunos problemas son:
-
La RaspberryPI necesita una IP fija. Es factible usando, por ejemplo, una segunda IP tipo 192.168.230.x (la red controlada por el router que no controlamos es la 192.168.0.x).
-
Perder la RaspberryPI sería un problema serio. Perdería tanto el servidor de backup como mi acceso remoto a la LAN.
-
Hay que confiar en la LAN. Con todo lo que hay pinchado ahí prefiero no hacerlo.
Una opción es que el tráfico NFS viaje cifrado y autenticado. Se podría usar una VPN o emplear IPsec. Sería problemático porque la RaspberryPI tiene una CPU anémica.
En todo caso, complejidad.
La ventaja fundamental de este sistema es poder usar la tarjeta microSD de 1GB.
-
-
SmartOS u otros sistemas operativos basados en Illumos:
SmartOS es el hipervisor de Joyent, basado en Illumos (a su vez basado en el sistema operativo Solaris, de Sun Microsystems). Se trata de un sistema operativo tremendamente capaz, ideal para esta situación. La gestión ZFS es nativa y más fiable y moderna que la implementación ZFS en Linux.
El hipervisor es bastante ligero, menos de 300MB. Podría arrancar desde la tarjeta microSD de 1GB y aún habría algo de sitio para una zona Solaris que pudiera recibir y activar la clave que descifra los discos duros. El resto de la zona o zonas Solaris podrían residir en datasets en los discos duros de datos, sin tener que reparticionarlos.
La actualización de SmartOS es trivial: reemplazar un fichero por otro.
El problema es que SmartOS no tiene una implementación de cifrado propia y los discos duros actuales están cifrados usando LUKS. SmartOS no lo soporta de forma nativa.
Implementar un driver LUKS para Illumos y derivados sería un proyecto interesante. Tal vez en el futuro...
-
Migrar el sistema operativo actual a la máquina nueva:
Descartadas las opciones anteriores lo evidente es mover el sistema operativo que está funcionando actualmente en la máquina virtual del Microsoft Windows 8 de mi padre. El disco duro virtual configurado en el VirtualBox mide 50 gigabytes. Examinándolo veo que el sistema operativo en sí mide 1.8 gigabytes y que hay 4 gigabytes de swap.
Reducir o eliminar la partición de swap permitiría acomodar el sistema operativo entero en la tarjeta microSD de 4GB. No sería mal final para una tarjeta anticuada.
Con todas estas valoraciones decido aprovechar el sistema operativo que ya tengo funcionando para esta tarea, con todas sus configuraciones, VPN, claves, etc. La instalación se hará en una tarjeta microSD de 4GB y clase 4. La velocidad de escritura es ridícula: 2.8MB/s. La lectura está mejor: 12.7MB/s. De todas formas esto es poco importante en este caso: una vez que el ordenador ha arrancado el acceso a la microSD debería ser reducido. El mayor problema es cuando hago un apt-get update, que es bastante intensivo en actividad de disco.
Habría que valorar la desactivación del swap. Rendimiento y tráfico de escritura en la microSD en una mano y muerte por el "Out of Memory" Killer de Linux en la otra. Decisiones, decisiones...
El problema de la degradación de la tarjeta se soluciona extrayéndola una o dos veces al año y copiándola sector a sector. Guardar un fichero de 4GB en algún sitio no es problema y en caso de que la tarjeta empezase a fallar se podría grabar una nueva de forma trivial y en minutos. Algo que mi padre podría hacer, seguramente, con mi asistencia remota.
Actualización 20150102: Backup doméstico seguro con Linux, cifrado y ZFS (IV): Traspaso del sistema operativo a una microSD de 4GB.