VPS y BTRFS.

El VPS que estoy utilizando, y es, el de Hetzner (sigue funcionando muy, muy bien), tiene actualmente varias imágenes de distribuciones de Linux para montar y arrancar en ellos. Da igual: ArchLinux; Debian; CloneZilla;... Hay varias distribuciones en sus sistemas para lo que haga falta. No hay problema.

Bien. El problema que hay ahora es, que al tener 80 GBytes de espacio de disco que tengo habilitado, tengo que usar a la fuerza el famoso sistema de ficheros BTRFS, que esto lo haré con la imagen Live de CloneZilla (de momento, a estas horas caído por problema del certificado de la web, pero esto ya lo hará la persona administradora que lo mantiene. Aunque lo hay en SourceForge). Estoy seguro que no tendré problemas para hacer la migración de EXT4 a BTRFS. Solo se puede hacer la migración entre 2 sistemas de ficheros: EXT4 y ReiserFS.

Esto es tan fácil como para hacerlo con btrfs-convert, que es tan fácil de hacer dicha conversión en medio minuto, más o menos. Luego es el traspaso de la información a subvolúmenes (esto se hace en 5 minutos, más o menos, según lo que se haga en HDD o SSD. Puede tardar más de 5 minutos. Esto que digo, se hace con rsync), para hacerlos más transparentes y llevarlos todos allí y dejarlos tal como a uno le guste que funcione.

¿Porqué me decanto por BTRFS? Pues por la velocidad, por la sencillez de hacerlo más limpia la conversión, y sobre todo, no te miente en la capacidad de disco duro. No te engaña como lo está haciendo el EXT4 (pero bueno). Lo digo, por la sencilla razón: que el EXT4 es bueno, sí. Pero tiene una pega: en discos duros grandes, te roba gigas que no merecen ser robados para nada. Sobre todo, en el fsck, que es mucho más rápido y limpio que EXT4.

Tanto es así, que el BTRFS te da ventajas de tener en una misma partición varios subvolúmenes como si fueran particiones, pero totalmente separados y, sobre todo, la información se puede tratar de una manera que, sencillamente, si haces las cosas con bases de datos, puedes habilitar la implementación NoDataCow. Es, una funcionalidad que, te permite no tener tanta degradación a la hora de desfragmentar dicha información integrada y, que te permite no hacer tantas escrituras todo el tiempo.

Estas cosas se hacen con cabeza para hacer funcionar decentemente un sistema que se necesita que funcione como uno quiere, como le guste que esté funcionando. Y sobre todo, que nos dure.

Yo tengo BTRFS (escrito por mí, aquí en mi página, de un disco duro a otro y convertir de EXT4 a BTRFS y viceversa, que lo he explicado muy, muy bien el cómo hacerlo) desde hace tiempo, que lo pasé de EXT4 a BTRFS. No me quita el sueño, pues me funciona tan estupendamente bien, que no necesito tanta historia, ni tantos rodeos en lo que van haciendo los discos duros con dicho sistema de ficheros que tengo actualmente.

Debian, en su instalador nos permite hacer una instalación limpia, pero con distintos sistemas de ficheros. Una de ellas, es el de BTRFS, que también se le pueden poner varias opciones, crearse (no recuerdo si lo hace) varios subvolúmenes y otras cosas que se le puede aplicar.

Yo, actualmente, al tenerlo en un NVME, le tengo puesto Debian, al completo. No tengo ningún problema. Puedo, hasta separar los directorios en subvolúmenes, si quiero en el futuro. Se pueden poner tantas como se quiera, que hay un límite, pero en sistemas normales es un número grande para eso. Nadie alcanza a esa cifra hoy en día. El número es hasta 2⁶⁴ subvolúmenes. Es una cantidad íntegramente alta, como para meter tantas y tantas cosas que se puede hacer en el BTRFS. Así que, actualmente no hay mucho límite hoy en día. Sea el /var, el /var/log, o lo que se quiera, si vamos a poner bases de datos, si vamos a poner una web, etc, etc, etc. Se pueden poner tantas como gusten.

Muchos servidores siguen manteniendo EXT3/EXT4, pero que nunca han probado (o eso creo), o hecho una migración sustanciosa para probar en producción dicho cambio de sistema de ficheros.

Mi experiencia dice que, al tratarse de un sistema de ficheros, como el BTRFS, es mucho más fiable para servidores, que, de manera ventajosa te ofrece la oportunidad de que no se estropeen los datos del servidor en caídas abruptas y desastrosas. O que dejen de funcionar los discos duros.

En el caso de Facebook, actualmente en sus servidores, tienen ya funcionando el sistema de ficheros BTRFS, y han comentado que les funciona básicamente bien, a la hora, pues que les ahorra bastante dinero en discos duros. Les está funcionando muy bien en este tema. Ya no pierden tanto dinero como antes.

Yo no sé actualmente qué sistema de ficheros utilizan, tanto aquí, en Blogger, como en otros grandes servidores. Pero tengo la certeza que están usando EXT3/EXT4. ¿Por qué que no lo prueban? ¿No lo han probado, o sí? ¿Hicieron pruebas en máquinas de prueba antes de lanzarlas a producción con el BTRFS? De ellos, que lo probaba. Quedarían satisfechos en mantenerlos en sus discos duros.

Yo, hasta ahora, toco madera. Pues funciona muy bien, no te escribe tanto en el disco duro. Que hoy en día, los vigilo duramente con smartmontools, que no viene mal en hacer estas cosas.

POR cierto... Hablando de smartmontools... También se puede hacer esto de manera automática, para que haga estas cosas que nos lo haga, pero que no estemos delante del PC o del servidor (disco duro real, no emulado) y, se puede hacer sin problema la monitorización por, si da problemas en algún momento, se haga el cambio «en caliente» (en servidores) o, que te fuerce que tengas que cambiar de disco duro antes de que falle. Pues se puede hacer estas cosas en el fichero /etc/smartd.conf. PERO OJO: hay que comentar esta línea:

DEVICESCAN d- removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

Pues porque, de hecho, esta línea, NO nos va a funcionar la monitorización del disco duro. Hay que hacerlo bien para que funcione y no tenga que darte la tabarra por cada cierto tiempo (cada semana, mejor) y no tener estos problemas.

Comentemos así:

# DEVICESCAN d- removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner 

Pues bien. Si tenemos un SSD/NVME, o un disco duro, lo que debemos hacer es, poner estas líneas (tengo dos discos duros, por supuesto):

/dev/nvme0n1 -d nvme -a -s (L/../../3/02)
/dev/sda -d sat -a -s (L/../../3/03)

Luego, ya hecho:

systemctl restart smartd

Ahí, ya con ello, me funciona estupendamente la monitorización semana tras semana. no tengo que estar pendiente de hacer tanta y tanta tontería toda junta. Tenía siempre que hacer semana tras semana con el comando smartctl para eso. Así que eso, ya me es pasado). Tal como se detalla arriba mismo, a las 2 y 3 de la madrugada de todos los miércoles, lo hace de manera automática. Luego es ver y revisar con smartctl -a /dev/nvme0n1 o con smartctl -a /dev/sda (también se puede ver con -x y otros parámetros). Ya no tengo que estar pendiente semana tras semana estas cosas con: smartctl -t long /dev/nvme0n1, o con smartctl -t long /dev/sda. No. Ya no, con que haga lo que dije más atrás de este párrafo ya vale y de sobra. No tengo que estar pendiente para hacer la monitorización cuando ya no esté delante del PC.

¿Porqué se ha de hacer así, si tenemos un disco o 2 o más discos duros, por ejemplo? Pues por la sencilla razón, que así, y de esta manera, en el log de journalctl si va haciendo el trabajo deseado para la monitorización del disco duro. Uso mucho el systemd. Pues nos da muchísimas ventajas a la hora de monitorizar, de funcionar el Linux a nuestro gusto y...sobre todo, no nos va a dejar tirados en lo que haga en cada momento.

¿Porqué digo todo esto?: para salvar nuestros discos duros. Pues han de durar mucho tiempo sin estropear nada, y seguir funcionando como hasta ahora. Se pueden hacer muchísimas cosas hoy en día.

A ver si me da tiempo (va a ser un tocho largo, con montón de líneas, de cosas y más), os explico el cómo tengo montado el FreshRSS, con nginx, con PHP, con PostgreSQL (tengo pensado dejarlo con SQLite pero se hará. Si hay tiempo) y con Let's Encrypt. Que al principio no fue nada fácil...pero ahora que lo tengo, funciona como me gusta que funcione. Y no falla nada. Como digo...al gusto de la persona que mantiene el servidor VPS.

Un saludito.