/srv/tramontana/backups porta setmanes creixent. Cada matinada, a les 4:20, copia_tramontana.sh hi deixa una còpia nova sense que ningú hagi calculat quant hi cap, i el disc arrel de 23 GB va pel 30 %. La pregunta no és si s'omplirà, sinó quan — i què passarà amb l'aplicació quan passi, perquè una / plena no és «va lent»: és una màquina que no pot ni escriure un registre ni completar una transacció. En aquesta lliçó baixes per fi al maquinari: veuràs la pila completa des del disc físic fins al punt de muntatge, particionaràs, formataràs, entendràs /etc/fstab camp a camp (i per què una línia mal escrita impedeix arrencar), i muntaràs LVM, que és el que fa servir un servidor de debò. Al final, /srv/tramontana/backups viurà al seu propi volum lògic ampliable en calent.

1. La pila d'emmagatzematge, de dalt a baix
2. Identificar el maquinari: lsblk, blkid, fdisk -l
3. Taules de particions: MBR enfront de GPT
4. Particionar amb fdisk i parted
5. Sistemes de fitxers comparats, i els inodes revisitats
6. Muntar: mount, opcions, bind i findmnt
7. /etc/fstab camp a camp i la xarxa de seguretat
8. Espai: df, du, i el fitxer esborrat que no l'allibera
9. Intercanvi: partició, fitxer i quant en cal
10. LVM: PV, VG, LV, ampliar en calent i instantànies
11. RAID per programari amb mdadm
12. Quotes de disc
13. Cas Tramontana: un disc nou per a les còpies

Entre el plat (o la cel·la NAND) i el cat fitxer.txt que escrius hi ha cinc o sis capes. Confondre-les és la causa del 90 % dels errors d'emmagatzematge.

Les capes d'LVM són opcionals —sense elles la partició es formata directament—, però resolen el pitjor problema de tots: una partició no es pot ampliar si l'espai lliure no és just al darrere; un volum lògic sí, encara que l'espai sigui en un altre disc.

lsblk -f és l'ordre que faràs servir més vegades: diu el tipus de sistema de fitxers, l'etiqueta, l'UUID i l'ús real.

I el detall crític: aquests noms poden canviar entre arrencades. N'hi ha prou d'afegir un disc, canviar l'ordre dels controladors o que el nucli detecti els dispositius en un altre ordre perquè el sdb d'avui sigui el sdc de demà. Per això mai no es munta per nom de dispositiu a fstab: es munta per UUID o per LABEL, que viatgen dins del sistema de fitxers mateix.

Per a qualsevol disc nou avui: GPT, sense excepcions que mereixin discussió. La partició d'1 MiB que veus a sda1 és precisament la bios_grub que GRUB necessita en un GPT arrencat per BIOS heretada; el seu paper s'explica a 07-01.

fdisk és interactiu i còmode; parted admet ordres en una línia, cosa que el fa apte per a scripts. Preparem /dev/sdb amb una única partició que ocupi el disc sencer:

L'1MiB d'inici no és un caprici: alinea la partició amb els blocs físics i evita una penalització de rendiment notable en SSD i en cabines.

A fdisk la sessió equivalent seria g (crear GPT), n (nova partició), Retorn tres vegades, t i 31 (tipus Linux LVM) i w per escriure. Res no s'escriu fins a la w: q et treu sense tocar res, i aquesta és la xarxa de seguretat de fdisk.

Si el nucli no s'assabenta de la taula nova —típic quan el disc té alguna partició muntada—, sudo partprobe /dev/sdb la torna a llegir, i lsblk /dev/sdb confirma que hi apareix sdb1.

Regla pràctica per a un servidor Ubuntu convencional: ext4 sobre LVM. Tens redimensionament, instantànies (les de l'LVM) i el sistema de fitxers més provat que existeix.

tune2fs permet canviar l'etiqueta (-L), l'interval de comprovació (-i) i, molt útil en un volum de dades, el 5 % reservat per a root: sudo tune2fs -m 1 /dev/vg-dades/lv-backups recupera uns 600 MiB en 15 GiB. Aquell 5 % té sentit a / —evita que un disc ple impedeixi a root arreglar la situació—, però en un volum dedicat a còpies és espai llençat.

A 02-06 vas veure que l'inode guarda les metadades i que el nom és només una entrada de directori. Aquí arriba la conseqüència operativa: el nombre d'inodes es fixa en formatar i no creix. Un directori amb milions de fitxers diminuts els pot esgotar amb el disc mig buit, i l'error és desconcertant:

43 % d'espai lliure i No space left on device en crear un fitxer. Davant d'aquest error, df -i és la segona comprovació obligatòria. La solució passa per esborrar fitxers petits o reformatar amb més inodes (mkfs.ext4 -i 8192).

Si umount respon «target is busy», reprèn lsof i fuser de 03-06:

Algú —tu, probablement— hi té el seu directori de treball. umount -l (lazy) desmunta quan s'alliberi, però és un pedaç.

findmnt és infinitament més llegible que mount sense arguments, i findmnt --verify valida el fstab sense muntar res. Un muntatge bind (sudo mount --bind /srv/tramontana/backups/enviaments /opt/tramontana/sortida) fa aparèixer un directori existent en un altre punt de l'arbre sense copiar res: és la manera neta d'exposar una carpeta a un servei confinat, i a 05-05 veuràs que systemd fa el mateix amb BindPaths.

En l'arrencada, systemd converteix cada línia de fstab en una unitat .mount i les fa dependència de local-fs.target. Si un dispositiu no apareix, l'arrencada espera 90 segons i després cau a mode d'emergència demanant la contrasenya de root — que a Ubuntu està bloquejada. Un servidor remot en aquest estat és un servidor perdut fins que algú obri la consola.

Per això hi ha dues regles innegociables:

mount -a abans de reiniciar no és opcional. Si falla, ho arregles amb el servidor dret; si no l'executes, ho descobriràs amb el servidor caigut. I afegeix nofail a tot el que no sigui /: converteix una fallada d'arrencada en un avís al registre.

ncdu fa el mateix de manera interactiva i és el que faràs servir quan busquis el culpable amb pressa. Recorda de 02-03 que du mesura espai ocupat en blocs i ls -l la mida lògica: no tenen per què coincidir.

Falten gigues que ningú no veu. L'explicació connecta directament amb els inodes de 02-06: quan esborres un fitxer que un procés té obert, desapareix el nom del directori, però l'inode i els seus blocs continuen vius fins que l'últim descriptor es tanqui. Algú va fer rm sobre un registre gegant i el procés continua escrivint en un fitxer sense nom.

NLINK 0 i (deleted) són la signatura del problema. Les dues sortides: reiniciar el procés (systemctl restart, que veurem a 05-05) o, si no pots, truncar el fitxer pel seu descriptor amb sudo truncate -s 0 /proc/1284/fd/3, que allibera l'espai sense matar-lo.

I la lliçó de fons: un registre no s'esborra, es rota — que és exactament el que muntarem a 05-06.

L'intercanvi (swap) és espai de disc que el nucli fa servir per descarregar pàgines de memòria poc utilitzades. Avui es prefereix un fitxer d'intercanvi a una partició: es redimensiona sense tocar la taula de particions.

Amb la seva línia a fstab (/swapfile none swap sw 0 0). El chmod 600 és obligatori: el contingut de l'intercanvi inclou trossos de memòria de processos, i això inclou secrets.

vm.swappiness (0–200, per defecte 60) decideix quanta pressa es dona el nucli a fer-lo servir; baixar-lo a 10 és l'habitual en un servidor d'aplicació. L'ajust fi d'aquest i altres paràmetres del nucli és matèria de 07-03. Quant d'intercanvi? Amb 3,8 GB de RAM, entre 2 i 4 GB és raonable: no com a substitut de memòria —si el servidor fa intercanvi constantment, anirà molt lent igualment—, sinó com a coixí que evita que l'OOM killer mati l'aplicació davant d'un pic puntual.

LVM introdueix tres nivells: els PV (particions o discs sencers lliurats a LVM), el VG (una bossa d'espai formada per un o diversos PV) i els LV (els «discs virtuals» que es formaten i es munten). El VG es divideix en extents de 4 MiB, i un LV és simplement un conjunt d'extents, que no han de ser contigus ni ser al mateix disc. D'aquí ve tot el poder d'LVM.

Fixa't que hem deixat 5 GiB lliures al VG expressament: són el marge per ampliar el volum i, sobretot, per poder crear una instantània. Un VG al 100 % és un VG sense maniobra.

Ampliar en calent, amb el volum muntat i en ús:

L'opció -r (--resizefs) és la clau: amplia l'LV i el sistema de fitxers de sobre en un sol pas. Sense ella tindries un volum més gran i un df idèntic, que és l'error més freqüent de qui comença amb LVM. lvextend -l +100%FREE -r es menja tot l'espai lliure del VG.

Reduir és una altra història. Cal fer-ho al revés (primer el sistema de fitxers, després l'LV), amb el volum desmuntat, i XFS directament no es pot reduir. Un error d'ordre aquí destrueix dades. Regla: crea els LV petits i amplia'ls quan calgui; mai al revés.

Una instantània és un LV que guarda les diferències respecte a l'original des de l'instant de la seva creació. Es crea en segons i permet copiar un volum en un estat congelat i coherent mentre l'aplicació continua escrivint:

Dos advertiments imprescindibles: la instantània s'omple si l'original canvia més del que la seva mida permet, i quan s'omple s'invalida i es perd. I no és una còpia de seguretat: viu al mateix VG, al mateix disc. És una eina de coherència, i així la farem servir a 05-08.

[UU] significa els dos discs sans; un [U_] és un disc caigut i cal actuar avui, no la setmana que ve. Sobre /dev/md0 s'hi posa després un PV d'LVM, i així es combinen redundància i flexibilitat.

RAID no és una còpia de seguretat. RAID protegeix que un disc es trenqui. No protegeix d'un rm -rf (es replica a l'instant al mirall), ni d'un xifratge per ransomware, ni d'una fallada del controlador que corrompi tots dos discs, ni d'un incendi a la sala. La còpia de seguretat és 05-08, i són coses diferents i complementàries.

Quan diversos usuaris comparteixen un volum, les quotes limiten quant ocupa cadascun. S'activen amb usrquota,grpquota a fstab, s'inicialitzen amb quotacheck -cug i es fixen amb edquota -u usuari o sense interacció: sudo setquota -u luis 5G 6G 0 0 /srv/tramontana/backups (tou 5G, dur 6G), i sudo repquota -s /srv/tramontana/backups dona l'informe d'ús. El límit tou es pot superar durant un període de gràcia; el dur no se supera mai. En un servidor d'aplicació amb un únic usuari de servei són poc útils; en un de compartit són la diferència entre un incident i una trucada a les tres de la matinada.

La Marta aprova afegir un disc de 20 GiB a la VM. L'objectiu: que /srv/tramontana/backups deixi de competir per l'espai de /, sense perdre ni un byte de les còpies existents i sense que copia_tramontana.sh se n'assabenti.

Pas 1 — Afegir el disc. Amb la VM apagada, VirtualBox → Emmagatzematge → disc de 20 GiB. En arrencar, lsblk ha de mostrar sdb sense particions.

Pas 2 — Partició, PV, VG i LV: les ordres dels apartats 4 i 10, ja executades. Resultat: vg-dades de 20 GiB amb lv-backups de 15 GiB i 5 GiB de marge.

Pas 3 — Formatar i muntar en un punt temporal.

Pas 4 — Copiar preservant-ho tot. rsync -aHAX no és luxe: -a conserva permisos i propietaris (l'operador:tramontana de 05-01), -H els enllaços durs, -A les ACL de 05-02 i -X els atributs estesos.

(Abans de copiar, comenta la línia de cron de la còpia perquè no n'entri una a mitja feina.)

Pas 5 — Intercanviar, amb xarxa de seguretat. No esborrem l'original: el reanomenem, i així la reversió és instantània. sudo umount /mnt/nou && sudo mv /srv/tramontana/backups /srv/tramontana/backups.vell && sudo mkdir /srv/tramontana/backups.

Pas 6 — fstab, amb les tres proteccions.

nosuid i nodev perquè en un volum de còpies no hi ha d'haver mai un binari SUID ni un fitxer de dispositiu; nofail perquè una fallada d'aquest disc no pot impedir que arrenqui el servidor.

Pas 7 — Restaurar la propietat, verificar i netejar.

Només quan una còpia real hagi funcionat i se n'hagi verificat el sha256sum s'esborra /srv/tramontana/backups.vell, i s'anota tot:

• Muntar per /dev/sdb1 a fstab. El dia que l'ordre de detecció canviï, arrencarà el disc equivocat o cap. UUID o LABEL, sempre.
• Reiniciar sense mount -a. És la causa número u de servidors que no tornen. I nofail a tot el que no sigui /.
• lvextend sense -r. El volum creix, df no canvia i perds mitja hora. Amb -r, el sistema de fitxers creix amb ell. I no omplis el VG al 100 %: sense espai lliure no hi ha instantània ni marge per ampliar.
• Confiar en RAID com a còpia de seguretat. No ho és, i descobrir-ho el dia de l'esborrat accidental és car.
• rm sobre un registre en ús. L'espai no s'allibera fins que el procés tanqui el descriptor: lsof +L1 el delata. Els registres es roten (05-06).
• Copiar dades amb cp -r en comptes de rsync -aHAX: perds propietaris, enllaços durs, ACL i atributs, i després els permisos de 05-01 no quadren.
• Consell: guarda lsblk -f, vgs, lvs i una còpia del fstab al costat de l'HISTORIAL. Reconstruir de memòria la disposició de discs, amb el servidor caigut, no és un pla.

1. Diagnòstic de disc ple. df -h / marca 100 %, però du -sh / suma bastant menys. Enumera les tres causes possibles en ordre de probabilitat i l'ordre que confirma cadascuna.
2. Ampliar en calent. lv-backups (15 GiB) s'ha quedat curt i el VG té 5 GiB lliures. Amplia'l 3 GiB sense desmuntar, verifica que l'espai és visible per a df i explica què hauria passat sense -r.
3. Entrada de fstab segura. Escriu la línia de fstab per a un volum de pujades d'usuaris muntat a /opt/tramontana/shared/uploads, amb les opcions que un directori on escriuen tercers ha de tenir, i descriu com la validaries abans de reiniciar.

1. Per ordre de probabilitat:

La tercera és la més traïdora: si algú va escriure a /srv/tramontana/backups abans de muntar-hi el volum a sobre, aquells fitxers continuen ocupant espai a / però són invisibles perquè el muntatge els tapa. El bind mount de / en un altre punt els deixa a la vista. És el risc del pas 5 del cas Tramontana, i per això creem el directori buit en lloc de reutilitzar el que tenia dades.

2.

Sense -r, lvs mostraria 18 GiB i df continuaria dient 15 GiB: el sistema de fitxers ext4 no sap que el dispositiu de sota ha crescut fins que se li diu amb resize2fs. L'operació és segura en calent perquè ext4 admet créixer muntat; reduir exigiria desmuntar i fer-ho en l'ordre invers.

3.

noexec és l'afegit clau respecte al volum de còpies: en un directori on escriuen tercers, impedir l'execució de binaris talla en sec que una pujada maliciosa es converteixi en codi en marxa. nodev i nosuid tanquen les altres dues vies, i nofail evita que un problema amb aquest volum impedeixi arrencar. Validació abans de reiniciar:

Fixa't que findmnt al final mostra les opcions efectives: és l'única prova que el que vas escriure és el que el nucli va aplicar.

Ja no hi ha una capa opaca entre els teus fitxers i el maquinari. Recorres la pila sencera —disc, taula de particions, partició, PV, VG, LV, sistema de fitxers, punt de muntatge— i saps quin problema resol cada esglaó; identifiques el maquinari amb lsblk -f, blkid i fdisk -l, i saps per què els noms /dev/sdX no són de fiar i l'UUID sí; tries GPT sense dubtar-ho, particiones amb parted en una línia i amb fdisk sabent que res no s'escriu fins a la w; compares ext4, XFS, Btrfs i ZFS amb criteri, ajustes amb tune2fs i reconeixes el desconcert d'un df -h amb lloc i un df -i al 100 %.

Muntes amb les opcions que un servidor necessita —noatime, nodev, nosuid, noexec, nofail—, llegeixes /etc/fstab camp a camp i saps que mount -a abans de reiniciar és la diferència entre un ajust i una nit perduda. Diagnostiques el disc ple en les seves tres variants, inclòs el fitxer esborrat que lsof +L1 delata. I domines LVM: crees PV, VG i LV, amplies en calent amb lvextend -r, saps per què reduir és perillós i fas servir instantànies per congelar un estat coherent. Coneixes mdadm i els seus nivells, i tens gravat que RAID no és una còpia de seguretat.

Sobretot, /srv/tramontana/backups viu ja al seu propi volum lògic de 15 GiB, ampliable en calent, muntat per UUID amb nofail, amb les còpies migrades byte a byte amb rsync -aHAX i verificades, i amb 5 GiB de marge al VG reservats per a instantànies.

I arribem al nucli del mòdul. Tens identitats, permisos, paquets i disc, però l'aplicació de Tramontana continua arrencant-se a mà: si el servidor es reinicia, no torna; si el procés mor, ningú no l'aixeca; desplegar.sh canvia l'enllaç simbòlic i continua sense reiniciar res; i la còpia de les 4:20 depèn d'una línia de cron sense control real de solapament ni registre decent. A systemd i la Gestió de Serveis s'acaba tot això: escriuràs tramontana.service des de zero i enfortit, entendràs la diferència real entre ordre i dependència, convertiràs copia_tramontana.sh en un .service amb el seu .timer i Persistent=true, i desplegar.sh farà per fi el systemctl restart que li faltava.