No existeixen les còpies de seguretat; només existeixen les restauracions provades. Guarda't aquesta frase, perquè és l'única idea d'aquesta lliçó que no et pots permetre oblidar. A srv-tramontana hi ha còpies des de fa setmanes: copia_tramontana.sh les genera, en verifica els sha256sum, les deixa en un volum propi i un temporitzador de systemd el dispara cada matinada. Tot això sona molt bé i no demostra absolutament res, perquè ningú no n'ha restaurat mai cap. Una còpia que no s'ha restaurat és una hipòtesi, no una protecció. Aquesta lliçó tanca el mòdul convertint aquella hipòtesi en un procediment provat, amb RPO i RTO acordats, retenció per generacions, còpies incrementals que no creixen sense control, xifratge, verificació i un manual d'operació (runbook) que algú podria seguir encara que tu fossis de vacances.

1. Què es copia i què no: l'inventari de Tramontana
2. RPO i RTO: quant podem perdre i quant podem trigar
3. La regla 3-2-1 i la retenció per generacions
4. Completa, incremental i diferencial
5. Coherència: el fitxer que s'escriu mentre el copies
6. Eines: tar, rsync, dd i restic
7. Còpies del sistema enfront de reconstruir per codi
8. Xifratge, custòdia i obligacions legals
9. Verificació i la prova de restauració
10. Automatitzar i vigilar l'edat de l'última còpia
11. Restaurar: els tres escenaris de Tramontana
12. El manual d'operació de recuperació

La primera decisió no és tècnica: és decidir què mereix copiar-se. La regla és senzilla: es copia el que no es pot reconstruir.

L'inventari concret de Tramontana, que és el que es copiarà:

Dues sigles que cal acordar amb la Marta, no decidir en solitari:

• RPO (Recovery Point Objective): quantes dades ens podem permetre perdre, mesurat en temps. Si la còpia és diària a les 02:30 i el servidor mor a les 18:00, es perden 15,5 hores de reserves. És acceptable?
• RTO (Recovery Time Objective): quant pot estar caigut el servei mentre es restaura.

Traduït a Tramontana amb xifres reals: entren unes 25 reserves al dia, amb un import mitjà de 313,70 €. Perdre un dia complet són uns 7.842,50 € en reserves que caldria reconstruir a mà des dels correus de confirmació, amb el cost reputacional de trucar als hostes.

Aquell RPO de 4 hores per a la base de dades és la decisió que canvia el disseny: la còpia diària de les 02:30 no el compleix, i cal un abocament cada quatre hores. Cada millora d'RPO o RTO costa diners i complexitat; per això la decisió és del negoci, amb el teu assessorament tècnic.

La regla 3-2-1 resumeix dècades de desastres:

• 3 còpies de les dades (l'original i dues més).
• En 2 suports o sistemes diferents.
• 1 d'elles fora de l'emplaçament.

Avui a srv-tramontana tenim una còpia, al mateix servidor, al mateix edifici. Si el disc falla en un mode que s'endugui per davant el VG, o si algú xifra la màquina, o si s'incendia l'oficina, no hi ha còpia. /srv/tramontana/backups és una comoditat, no una protecció. La variant moderna hi afegeix un 1-0: almenys una còpia immutable o sense connexió, i zero errors a l'última verificació, perquè el ransomware modern busca i xifra les destinacions de còpia accessibles des del servidor.

Retenció GFS (Grandfather-Father-Son): no totes les còpies valen el mateix amb el temps.

Amb això, restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 deixa l'històric exacte que vas acordar, sense decisions improvisades.

El compromís clàssic: completa setmanal + incrementals diàries. La cadena incremental té un risc real que cal dir en veu alta: si es perd o es corromp una baula, tot el posterior és irrecuperable. Per això es verifiquen totes, no només l'última. Les eines modernes amb deduplicació (restic, borg) eliminen gairebé tot aquest dilema: cada còpia es comporta com a completa a l'hora de restaurar i ocupa com una incremental.

Copiar un fitxer mentre algú l'escriu produeix brossa: la primera meitat del fitxer és d'abans del canvi i la segona de després. En una base de dades, aquella barreja és una còpia que no es pot obrir. Tres solucions, en ordre de preferència:

La instantània a la pràctica, aplicant el de 05-04 i aprofitant els 5 GiB lliures que vam deixar al VG expressament:

La seqüència correcta i completa per a la base de dades de Tramontana combina les dues primeres: abocament lògic amb pg_dump (coherent per definició) i instantània per als fitxers d'uploads, que no tenen abocament propi.

El .snar és el cervell de l'operació: si el perds, la següent «incremental» serà una completa, i si el barreges entre cadenes, la còpia serà incoherent. Guarda'l amb les còpies i fes-ne una còpia a part. I la inspecció abans d'extreure, com mana la convenció del curs:

Aquí es tanca el cercle amb els enllaços durs de 02-06. --link-dest compara amb una còpia anterior i, per a cada fitxer que no ha canviat, crea un enllaç dur en lloc de copiar les dades. Resultat: cada còpia es veu i es restaura com una còpia completa, però al disc només ocupa el que ha canviat.

Aparenta 2,1 GiB —i en restaurar ho són—, però només consumeix 118 MiB de disc nou. Dos avisos: els enllaços durs no protegeixen de la corrupció d'un bloc (totes les còpies comparteixen el mateix inode i, per tant, el mateix dany), i esborrar la còpia base no trenca res, perquè l'inode sobreviu mentre quedi un enllaç.

dd copia bloc a bloc, sense entendre de fitxers. Serveix per clonar un disc sencer o el sector d'arrencada, i és l'ordre més perillosa d'aquesta lliçó: invertir if= i of= destrueix la destinació sense preguntar. Se l'anomena «disk destroyer» per alguna cosa.

Requereix el dispositiu desmuntat o congelat perquè la imatge sigui coherent, i copia també l'espai buit. Per a còpies regulars de dades, gairebé mai no és la resposta.

Deduplicació, xifratge de sèrie, verificació d'integritat i retenció declarativa. Ús real complet:

Fixa't en els 41.882 MiB afegits que n'ocupen 12.204 MiB de reals: això és deduplicació més compressió. borg és equivalent en prestacions; rsnapshot és la versió clàssica del truc del --link-dest, útil si prefereixes còpies navegables amb ls sense eina intermèdia.

Copiar el sistema sencer (imatge o tar de /) permet tornar exactament a l'estat anterior, però produeix còpies enormes i arrossega la brossa acumulada, inclòs qualsevol problema latent. L'alternativa moderna és reconstruir el servidor per codi: una màquina neta, un playbook que instal·li i configuri tot, i a sobre només les dades restaurades de la còpia.

Tramontana va camí del segon, i aquesta és la raó que l'inventari inclogui /etc/tramontana, les unitats de systemd i la llista de paquets: són l'entrada del futur playbook d'Ansible que veuràs a 07-06. Mentrestant, la llista de paquets és la teva assegurança:

Una còpia sense xifrar és una fuita esperant a passar. L'original viu en un servidor amb permisos, sudo, ACL i enfortiment de systemd; la còpia acaba en un disc USB, en un bucket o a casa d'algú, sense cap d'aquestes proteccions. I conté exactament les mateixes dades.

Xifra en origen, abans que la còpia surti del servidor: restic i borg ho fan de sèrie, i amb tar s'hi encadena gpg o age. La gestió de les claus —on viuen, qui les custodia, com es roten, què passa si es perden— és matèria de 06-05, i no és un detall menor: una còpia xifrada la clau de la qual s'ha perdut és exactament igual d'útil que no tenir còpia.

Advertiment de compliment (RGPD). reserves.csv i la base de dades contenen dades personals d'hostes (nom, contacte, dates d'estada). Les còpies hereten totes les obligacions de l'original: xifratge en repòs i en trànsit, control d'accés documentat, registre de qui hi accedeix, retenció limitada al temps necessari, i —el punt que gairebé sempre s'oblida— el dret de supressió arriba també a les còpies de seguretat, cosa que obliga a tenir una política escrita de com s'atén una sol·licitud d'esborrat quan la dada és en còpies immutables. Si a més la còpia surt cap a un proveïdor al núvol, hi entra en joc l'encarregat del tractament i la ubicació de les dades. Res d'això no ho decideixes tu: ho ha de definir i aprovar el responsable de protecció de dades o de compliment, i la teva feina és implementar-ho i poder demostrar-ho.

Una còpia no verificada és un fitxer de mida tranquil·litzadora. Hi ha tres nivells, i cal fer els tres:

Només el tercer demostra alguna cosa. Els dos primers s'automatitzen; el tercer s'agenda:

La prova de restauració periòdica és part del procediment, no un extra: una vegada al trimestre, restaurar en una VM neta, arrencar l'aplicació, comprovar que les 25 reserves hi són i que la suma d'imports dona 7.842,50 €, cronometrar quant s'ha trigat (compleix l'RTO de 8 h?) i anotar el resultat amb data i nom de qui la va fer. Una prova de restauració que ningú no ha cronometrat no permet prometre cap RTO.

Ja tens l'automatització de 05-05: tramontana-copia.service amb el seu temporitzador, Persistent=true i RequiresMountsFor. Falta la vigilància, i aquí hi ha l'error més comú del sector: vigilar que la feina es va executar en lloc de vigilar que hi ha una còpia recent i vàlida. Un script que falla en silenci i un temporitzador deshabilitat produeixen el mateix símptoma: res. La mètrica que de debò importa és l'edat de l'última còpia correcta.

Es dispara amb el seu propi temporitzador a les 08:00, després de la finestra de còpia, i només notifica quan hi ha alguna cosa a fer: és el principi de «silenci si tot va bé» aplicat a l'única mètrica que importa.

RPO 24 h, RTO 30 min. El Luis ha executat un mv desafortunat a les 11:40.

El pas 4 és el que separa una restauració d'un acte de fe: 26 línies i 7.842,50 € són les xifres conegudes del fitxer. Si no quadren, la còpia no serveix i cal anar a l'anterior.

RPO 0, RTO 15 min. És el cas de la 3.3.0, que pesa 99,2 MiB i no arrenca. desplegar.sh ja reverteix sol (05-05), però si la fallada es detecta més tard:

Aquí no intervé la còpia diària: la que salva el dia és la còpia prèvia al desplegament de /srv/tramontana/backups/pre-desplegament/, i l'enllaç simbòlic relatiu permet tornar enrere en un segon. Això és 02-06 i 05-05 treballant junts.

RPO 4 h, RTO 8 h. L'escenari que tothom evita pensar. Procediment complet:

1. Màquina nova: Ubuntu Server 24.04 LTS, mateix hostname, mateix esquema de particionat amb /var aïllada (01-04).
2. Identitats primer, i amb els mateixos números, o els permisos de la restauració no quadraran: groupadd -g 1002 tramontana, useradd -r -u 997 -g tramontana -s /usr/sbin/nologin svc-tramontana, més operador i luis (05-01).
3. Paquets: xargs -a paquets-2026-08-19.txt sudo apt install --no-install-recommends -y, amb el hold de la base de dades (05-03).
4. Discs: recrear PV, VG i LV, formatar i muntar /srv/tramontana/backups per UUID amb nofail, i mount -a abans de reiniciar (05-04).
5. Dades: restic restore <snapshot> --target /, i l'abocament de la base de dades amb psql < abocament.sql.
6. Configuració i serveis: restaurar /etc/tramontana, les unitats, sudoers.d, logrotate.d; systemctl daemon-reload; systemctl enable --now tramontana.service tramontana-copia.timer (05-05, 05-06).
7. Verificar: revisio_salut.sh, comptar les 25 reserves, comprovar la suma de 7.842,50 €, systemctl --failed buit, i provar una reserva real de cap a cap.
8. Cronometrar i anotar quant s'ha trigat. Aquell número és l'RTO real, i és el que pots prometre.

Fixa't que aquest procediment fa servir les vuit lliçons del mòdul. Aquest és el sentit del Mòdul 5.

Un manual d'operació és el document que permet que la recuperació la faci una altra persona, de matinada, amb pressa i sense tu. Ha de contenir:

• Inventari de què es copia, on va i amb quina freqüència.
• RPO i RTO acordats, amb qui els va aprovar i quan.
• On són les claus de xifratge i qui les custodia (no la clau: on és).
• Els procediments dels tres escenaris, amb ordres literals copiables.
• Contactes: qui decideix, qui executa, qui avisa els clients.
• Data i resultat de l'última prova de restauració, i qui la va fer.

I el més important: no es pot guardar només al servidor que perdràs. Còpia impresa, repositori git extern, gestor documental de l'empresa. Un manual d'operació que només existeix a /opt/tramontana/HISTORIAL és un manual que desapareix en l'escenari (c), justament quan el necessites.

• No haver restaurat mai. És l'error d'aquesta lliçó. Agenda la prova trimestral avui, amb data i responsable.
• La còpia al mateix servidor. Un incendi, un xifratge per ransomware o una fallada del VG s'endú original i còpia. 3-2-1, sense excuses.
• Perdre el fitxer .snar de tar --listed-incremental, o barrejar-lo entre cadenes: la còpia incremental deixa de ser recuperable.
• Copiar una base de dades en calent amb cp. Produeix un fitxer inservible. Abocament propi o instantània.
• Còpies sense xifrar que surten del servidor, o xifrades amb una clau que ningú no custodia. Totes dues coses són igual de greus.
• Vigilar la feina en comptes del resultat. El que importa és l'edat de l'última còpia correcta, no que l'script acabés.
• Restaurar directament a sobre de l'original. Restaura en un directori a part, verifica i després col·loca.
• Retenció infinita «per si de cas». Costa diners i xoca amb l'RGPD: la retenció s'acorda i es documenta.
• Consell: cronometra cada restauració de prova. L'RTO que pots prometre és el que has mesurat, no el que t'agradaria.

1. Dissenyar l'esquema. A partir de l'RPO de 4 h i l'RTO de 8 h acordats amb la Marta, descriu l'esquema complet de còpies de Tramontana: què es copia, amb quina freqüència, amb quina eina, on va cada còpia i quina retenció té. Justifica on falla avui la regla 3-2-1.
2. Verificar sense restaurar del tot. Escriu les ordres que comproven, sense tocar producció, que la còpia d'ahir a la nit conté reserves.csv amb les 25 reserves i que la seva suma d'imports és correcta. Explica per què això no substitueix una prova de restauració.
3. La baula perduda. Tens una completa del diumenge i sis incrementals de tar. La del dimecres està corrompuda. Fins a quin dia pots restaurar i per què? Què hauries fet diferent perquè aquest problema no existís?

1.

On falla avui la 3-2-1: hi ha una sola còpia (falla el «3»), al mateix servidor i el mateix disc lògic (falla el «2») i sense cap fora de l'emplaçament (falla l'«1»). El mínim acceptable és afegir una rèplica del dipòsit restic a una destinació remota amb credencials de només afegir, perquè un compromís del servidor no permeti esborrar l'històric.

2.

restic dump extreu un fitxer a stdout sense escriure res al disc, així que la comprovació no toca producció ni requereix espai.

Per què no substitueix una prova de restauració: això verifica un fitxer, no el conjunt; no comprova permisos, propietaris ni ACL; no valida que la base de dades restaurada arrenqui ni que l'aplicació funcioni amb aquelles dades; i, sobretot, no cronometra res, així que no permet afirmar que es compleix l'RTO. Verificar és necessari; restaurar és el que ho demostra.

3. Pots restaurar fins al dimarts: la completa del diumenge més les incrementals del dilluns i el dimarts. La del dimecres està corrompuda, i com que cada incremental de tar --listed-incremental conté només el que ha canviat des de l'anterior, les de dijous, divendres i dissabte depenen d'un estat que ja no pots reconstruir. Un fitxer modificat el dimecres i no tornat a tocar només existeix a la baula trencada.

Què hauria evitat el problema, per ordre d'eficàcia:

• Verificar cada còpia en crear-la (tar -tzf i sha256sum), no només l'última: el dimecres hauries sabut que calia repetir-la.
• Fer servir diferencials en comptes d'incrementals: cadascuna depèn només de la completa, així que una baula trencada costa un dia, no quatre.
• Millor encara, fer servir una eina amb deduplicació i verificació com restic, on cada instantània es restaura per si sola i restic check --read-data detecta la corrupció abans que la necessitis.

Has tancat el Mòdul 5, i amb ell la distància entre «tinc scripts» i «governo un servidor». Repassa el que ha canviat a srv-tramontana des que vas començar:

• 05-01 — Les identitats van deixar de ser màgia: el grup tramontana (gid 1002) i el compte de servei svc-tramontana (uid 997, sense shell ni contrasenya) existeixen de debò, amb operador i luis al grup i la propietat d'/opt/tramontana i /srv/tramontana/backups al seu lloc.
• 05-02 — sudo va deixar de ser una paraula màgica: hi ha una regla escrita, validada i documentada a /etc/sudoers.d/tramontana, més SGID als directoris compartits, ACL perquè el Luis llegeixi els registres sense entrar a adm, capacitats en lloc de SUID i chattr +i sobre app.conf.
• 05-03 — El programari té procedència: dipòsits deb822 amb claus a /etc/apt/keyrings/, la base de dades fixada amb hold i pinning, i actualitzacions de seguretat desateses que avisen sense reiniciar soles.
• 05-04 — Les còpies viuen al seu propi volum LVM ampliable en calent, muntat per UUID amb nofail, amb marge al VG per a instantànies i un fstab provat amb mount -a.
• 05-05 — L'aplicació és un servei de debò: tramontana.service enfortit, amb reinici automàtic i límits de cgroup, i la còpia nocturna convertida en tramontana-copia.service + .timer amb Persistent=true; desplegar.sh per fi reinicia.
• 05-06 — El servidor té memòria: journal persistent i acotat, /etc/logrotate.d/tramontana provat en simulació, els scripts escrivint al journal, i la resposta exacta a «què va passar ahir a la nit a les tres?».
• 05-07 — I té termòmetre: línia base amb llindars, sysstat guardant història, el mètode USE i un procediment d'onze passos que ja va resoldre la lentitud dels matins mesurant abans i després.
• 05-08 — I ara té xarxa de seguretat: RPO i RTO acordats amb la Marta, regla 3-2-1, retenció GFS, coherència amb abocament i instantània LVM, restic amb deduplicació i xifratge, verificació en tres nivells, vigilància de l'edat de l'última còpia correcta i tres procediments de restauració escrits, provats i cronometrats.

Res d'això no era «saber ordres». Era construir un sistema que se sosté quan tu no ets al davant, i aquesta és exactament la diferència entre fer servir Linux i administrar-lo.

I tanmateix, tot el que has aixecat en aquest mòdul té una porta oberta de bat a bat. srv-tramontana escolta al 8080 sense tallafoc, la configuració de xarxa continua sent la que va deixar l'instal·lador, SSH accepta contrasenyes i accessos de root sense que ningú hagi revisat sshd_config, la db_password és en clar dins d'app.conf, el trànsit de reserves —amb les dades personals dels hostes que tanta cura t'ha costat protegir a les còpies— viatja sense xifrar, i a /var/log/btmp ja hi ha quaranta-set intents d'accés des d'una IP que ningú no ha bloquejat. Al Mòdul 6: Xarxes i Seguretat tanques aquella porta: configuraràs la xarxa de manera persistent amb netplan, enfortiràs SSH amb claus i sense root, aixecaràs un tallafoc que només deixi passar l'imprescindible, detectaràs i frenaràs les intrusions, trauràs els secrets dels fitxers de configuració i posaràs TLS davant de l'aplicació, i acabaràs aplicant un enfortiment complet amb AppArmor i una política de contrasenyes que avui continua sent la de fàbrica. Has fet un servidor que funciona; toca fer-lo defensable. Actualitza la instantània de la teva VM, guarda el manual d'operació fora de la màquina i ens veiem al Mòdul 6.