informe-diari.sh ja compleix les set propietats d'una tasca desatesa. Aplicarem aquesta tècnica a l'operació que més s'agraeix tenir automatitzada i pitjor es porta improvisar. Una còpia de seguretat té una particularitat incòmoda: és l'única tasca del servidor el valor de la qual només es comprova el dia que tota la resta ha fallat. Fins aquell dia, una còpia trencada i una de bona s'assemblen molt —totes dues generen fitxers, totes dues ocupen disc, totes dues escriuen «ok» al registre—. Aquesta lliçó va de què copiar, com copiar-ho sense gastar un disc sencer cada dia, com retenir les còpies i, sobretot, de la part que gairebé ningú no prova fins que la necessita: la restauració.

1. Què s'ha de copiar, la regla 3-2-1 i RPO/RTO
2. Completa, incremental i diferencial
3. tar: la còpia completa comprimida
4. rsync: l'eina central
5. --link-dest: incrementals que es restauren com a completes
6. Rotació i retenció
7. Verificació i restauració
8. Bases de dades, xifratge i espai en disc
9. Aplicació: neix copia.sh

El primer error d'una còpia de seguretat és voler copiar-ho tot. El sistema sencer produeix fitxers enormes, lents de generar i de restaurar, i majoritàriament reproduïbles: si el servidor crema, no restauraràs /usr/bin, instal·laràs Ubuntu 24.04 una altra vegada. El que cal copiar són les tres categories que no es poden reconstruir:

I el que no es copia: el sistema operatiu, els paquets, les memòries cau, els temporals, els registres antics i molt especialment el mateix directori de còpies (copiar-lo a dins duplica la mida a cada volta). Un criteri pràctic: pregunta't quant trigaries a tornar a tenir aquell fitxer si desaparegués. Si la resposta és «me'l torno a descarregar», no va a la còpia; si és «no puc», hi va el primer. La regla 3-2-1 és el consens del sector i es recorda sola: 3 còpies de les dades (l'original i dues còpies de seguretat), en 2 mitjans o sistemes diferents, amb 1 d'elles fora de l'emplaçament. Cada número respon a una manera de fallar real: dues còpies al mateix disc moren amb el disc; dues al mateix edifici moren amb l'incendi o amb el xifratge per ransomware que recorre la xarxa. La còpia remota és la que salva de la catàstrofe, i per això a 07-06 l'enviarem a srv-veloz-02 per SSH.

Els altres dos conceptes s'expliquen amb dues preguntes concretes, sense argot. RPO (Recovery Point Objective): quantes dades em puc permetre perdre? Determina cada quant faig la còpia. RTO (Recovery Time Objective): quant puc estar sense servei? Determina com la faig. Si Veloz Envíos accepta perdre com a màxim un dia de registres, l'RPO és de 24 hores i n'hi ha prou amb una còpia diària; si el negoci no pot estar més de dues hores aturat, aquell RTO descarta un format de còpia que trigui tres hores a restaurar-se. Aquests dos números es decideixen abans d'escriure l'script, perquè determinen el disseny sencer.

Amb una completa el diumenge i incrementals de dilluns a dissabte, restaurar l'estat del dissabte exigeix recuperar set peces en l'ordre correcte; si falta la de dimecres, la cadena es trenca. Amb diferencials n'hi ha prou amb dues peces, a canvi que cadascuna sigui més gran que l'anterior. L'estratègia clàssica és completa setmanal més incrementals diàries, però hi ha una quarta opció que avui és la millor per a fitxers i que veurem a l'apartat 5: rsync --link-dest dona còpies que es generen com a incrementals i es restauren com a completes.

Reprenent 05-01, tar empaqueta un arbre de directoris en un sol fitxer comprimible:

c crea, z comprimeix amb gzip, f dona el nom. El -C /srv/veloz/dades és important: canvia de directori abans d'empaquetar, així que dins de l'arxiu els camins són historic/2026/08/… i no srv/veloz/dades/historic/…. Camins relatius dins de l'arxiu vol dir poder restaurar on vulguis; amb camins absoluts t'arrisques a sobreescriure l'original en descomprimir. El nom amb data és obligatori per poder rotar, i sempre en format %F, que ordena alfabèticament igual que cronològicament —cosa que 03-08-2026 no fa—.

Les exclusions van en un fitxer versionat, un patró per línia (*.tmp, cache/, logs/*.gz), no incrustades a l'script: així es canvien sense tocar codi. Per a arxius grans, --zstd comprimeix semblant a gzip però molt més ràpid; -j (bzip2) i -J (xz) comprimeixen més a costa de CPU.

tar serveix per congelar un arbre en un fitxer. Per sincronitzar un directori amb la seva còpia, l'eina és rsync, i la seva virtut és que transfereix només el que ha canviat.

La barra final decideix el significat, i és l'error clàssic: rsync -a /srv/veloz/dades/ /copies/dades/ copia el contingut de dades, mentre que sense la barra de l'origen crea /copies/dades/dades/. Posa-la sempre i sigues consistent. I --delete mereix un advertiment seriós. Fa que el destí sigui un mirall exacte de l'origen, i això significa que un esborrat accidental a l'origen es propaga a la còpia a l'execució següent: si algú esborra enviaments.csv i a les 03:00 s'executa la còpia, la teva còpia també el perd. Dues regles: --delete només té sentit quan hi ha diverses còpies retingudes (apartat 6), de manera que la d'ahir conservi el que s'ha esborrat avui; i mai s'estrena sense veure-ho abans.

Si aquella llista d'esborrats et sorprèn, encara no estàs a punt per treure el --dry-run.

Aquest és el truc central de la còpia de seguretat moderna de fitxers. Un enllaç dur és un segon nom per a les mateixes dades en disc: dos camins, un sol contingut, ocupació d'una sola còpia. --link-dest DIR li diu a rsync: «en copiar, compara cada fitxer amb el que hi ha a DIR; si no ha canviat, en lloc de copiar-lo crea un enllaç dur».

El resultat és notable: /copies/2026-08-03/ sembla una còpia completa —té tots els fitxers, es restaura copiant i sense reconstruir cadenes, i pots esborrar qualsevol dia sense afectar els altres—, però en disc només ocupa el que va canviar respecte de l'anterior. Cada còpia «pesa» 2,1 GB per separat, i totes dues juntes ocupen 2,2 GB perquè els fitxers compartits es compten un cop. Trenta dies de còpies diàries poden ocupar poc més que una de sola.

Dos avisos. Els enllaços durs exigeixen que totes dues còpies siguin al mateix sistema de fitxers: entre discos diferents --link-dest no falla, simplement fa còpies completes i omple el disc. I com que els fitxers estan compartits, modificar un fitxer dins d'una còpia el modifica a totes les que el comparteixen: els directoris de còpia són de només lectura, es restauren copiant a fora i mai s'editen al lloc.

Sense retenció, el disc s'omple i la còpia deixa de funcionar justament quan més la necessites. La política habitual és GFS (grandfather-father-son): còpies amb densitat decreixent cap al passat —7 diàries (l'última setmana, dia a dia), 4 setmanals (l'últim mes) i 6 mensuals (l'últim mig any)—. Són 17 còpies en lloc de 180, i segueix permetent recuperar «com estava el 3 d'agost» o «com estava el març». La raó de conservar còpies antigues no és la fallada de disc —per a això n'hi ha prou amb la d'ahir— sinó el dany silenciós: un fitxer corrupte o esborrat que ningú no nota fins dos mesos després.

Al primer, -mindepth 1 evita que find consideri el mateix directori arrel, -maxdepth 1 no entra dins de cada còpia i -exec … + agrupa els esborrats. Però -mtime depèn de la data del sistema de fitxers, que és fràgil (un touch o una còpia mal feta l'altera); com que els noms porten data ISO, comptar per nom amb sort -r és més fiable. I fixa't en la salvaguarda de la línia del (( )): mai no sobra, perquè la pitjor fallada possible d'un script de retenció és esborrar-ho tot.

Un fitxer de 2 GB amb el nom correcte pot estar buit per dins, truncat per falta de disc o corrupte. Que l'script hagi acabat amb codi 0 no prova que la còpia serveixi. Hi ha tres nivells, de més barat a més car:

tar -t llista el contingut sense extreure i, en recórrer-lo sencer, gzip valida la seva suma interna: barat, i detecta truncaments i corrupció. El fitxer .sha256 permet comprovar molt després que l'arxiu no s'ha degradat i que va arribar íntegre a una altra màquina. Afegeix-hi una comprovació de sentit comú que detecta la fallada més freqüent: (( $(stat -c %s "$desti") > 1024 )), perquè una còpia que ahir ocupava 2 GB i avui 40 KB no és una còpia petita, és una còpia buida amb una fallada silenciosa al darrere.

El tercer nivell és l'únic que demostra alguna cosa. La pregunta que revela si un sistema de còpies funciona no és «es fan les còpies?», és «quan va ser l'última vegada que en vau restaurar una?». La restauració de prova es fa sempre a un directori temporal, mai sobre les dades vives: extreure sobre l'original és la manera més ràpida de convertir un incident en un desastre, perquè si la còpia estava corrupta acabes de destruir també el que quedava.

Per restaurar només una part s'afegeix el camí intern al final del tar xzf. I des d'una còpia feta amb rsync, restaurar és copiar en sentit contrari —sense --delete, per no esborrar al destí el que s'ha creat després—: rsync -a /copies/diaries/2026-08-03/dades/ /srv/veloz/dades/. El procediment ha d'estar escrit on es pugui llegir sense accés al servidor caigut: les ordres exactes, en quin ordre, quin servei aturar abans i com verificar després. Un runbook de restauració que només existeix al cap d'una persona no existeix.

Bases de dades. Copiar /var/lib/mysql amb el servei en marxa produeix una còpia inconsistent: mentre rsync recorre els fitxers, el motor està escrivint en diversos alhora, i acabes amb una foto on unes parts són de les 03:00:01 i altres de les 03:00:47. Pot semblar que funciona i fallar mesos després en restaurar. La manera correcta és demanar-li al motor una còpia consistent:

--single-transaction pren la instantània dins d'una transacció, sense bloquejar escriptures; -Fc genera un format comprimit que permet restaurar taules soltes. El bolcat és després un fitxer normal que ja pots comprimir, verificar, retenir i enviar fora. Les credencials van a ~/.my.cnf o ~/.pgpass amb permisos 600, mai a la línia d'ordres, que és visible a ps per a qualsevol usuari.

Xifratge. Una còpia que surt del servidor s'emporta dades de clients fora del teu control. Xifrar-la és una línia: gpg --batch --symmetric --cipher-algo AES256 --passphrase-file "$BASE/etc/copia.key" -o "$desti.gpg" "$desti". El --batch evita qualsevol pregunta interactiva (propietat 1 de 07-02). I aquí hi ha el parany: si perds la clau, perds la còpia. Desar-la només al servidor que copies és inútil —crema amb ell—; posar-la al costat de la còpia xifrada és pitjor que no xifrar. La clau va a un gestor de secrets o a un sobre físic, fora del sistema (08-03).

Espai en disc. Una còpia que es queda sense espai a mitges deixa un arxiu truncat que sembla vàlid. Comprova-ho abans, amb allò de 06-03:

df -P força el format POSIX d'una línia per sistema de fitxers, i evita que un nom llarg parteixi la sortida en dues. El marge del 20 % cobreix la variació entre origen i còpia. Si no hi cap, la reacció correcta és fallar abans de començar, no morir a mitges.

El tercer script del toolkit copia /srv/veloz/dades i ~/veloz-ops/etc amb rsync --link-dest, comprimeix l'històric amb tar, verifica amb sha256sum, aplica retenció i registra el resultat, complint les set propietats de 07-02:

Tres decisions mereixen comentari. umask 077 perquè una còpia amb dades de clients no ha de ser llegible per tothom. El --link-dest es construeix com a array (enllac=()) perquè, quan no hi hagi còpia prèvia, l'opció desaparegui per complet de l'ordre en lloc de quedar buida. I ${ARREL:?} al rm -rf és una salvaguarda essencial: si ARREL estigués buida per un error de configuració, rm -rf "/${copies[i]}" seria catastròfic; amb :? l'script mor abans.

Al crontab va a les 03:15 —no a les 03:00, per no coincidir amb tota la resta—, embolcallat en timeout 3600s i amb >> logs/copia.log 2>&1. És una versió funcional, no la definitiva: falta l'enviament fora del servidor (07-06), la comprovació que la còpia d'ahir a la nit existeix (07-04) i la restauració guiada. El projecte 09-03 la porta a la seva versió completa, amb menú de restauració, informe i proves.

• Copiar el directori de còpies. Duplica la mida a cada volta fins a omplir el disc. Exclou-lo sempre.
• La barra final de rsync. Amb barra copia el contingut; sense barra crea un nivell de més. Revisa-la abans de cada --delete.
• --delete sense retenció. Un esborrat accidental a l'origen destrueix també la còpia.
• --link-dest entre discos diferents, o editar dins d'una còpia. Els enllaços durs no travessen sistemes de fitxers (sense avisar, fa còpies completes i omple el disc); i on sí que funcionen, modificar un fitxer el modifica a totes les còpies que el comparteixen.
• Copiar fitxers de base de dades en calent. Produeix una còpia inconsistent que falla en restaurar. Fes servir mysqldump/pg_dump.
• No comprovar l'espai abans, o desar la clau de xifratge al costat de la còpia. Una còpia truncada per disc ple sembla vàlida fins que la necessites; i la clau al costat del fitxer xifrat equival a no xifrar.
• Restaurar sobre les dades originals per «provar». Si la còpia està malament, destrueixes també el que quedava. A un temporal.
• Consell: apunta al calendari una restauració de prova mensual i tracta-la com una tasca real. La còpia que mai s'ha restaurat té una probabilitat de funcionar sorprenentment baixa.

Exercici 1. Explica què fa malament cadascuna d'aquestes tres ordres i corregeix-les.

Exercici 2. Escriu una funció veloz_verifica_copia que rebi el camí d'un .tar.gz i comprovi tres coses: que existeix i supera una mida mínima, que l'arxiu es llegeix sencer, i que la seva suma sha256 coincideix amb el .sha256 que l'acompanya. Ha de retornar codis diferents per a cada fallada.

Solució 1.

La fallada més greu és la segona: una còpia sense data al nom és una còpia d'una sola generació, i el dia que el procés falli a mitges hauràs destruït la còpia bona d'ahir per deixar-ne una de corrupta d'avui.

Solució 2.

El sha256sum -c s'executa dins d'una subshell amb cd perquè el fitxer .sha256 desa el nom relatiu; sense aquell canvi de directori, la comprovació buscaria l'arxiu al directori actual i fallaria sempre. --status silencia la sortida perquè només parli el codi de sortida, que és el que necessita un script. I l'absència del .sha256 es registra com a avís però no invalida la còpia: no és el mateix «no verificat» que «verificat i malament».

Una còpia de seguretat comença per decidir què copiar: dades, configuració i estat, mai el sistema sencer ni el mateix directori de còpies. La regla 3-2-1 —tres còpies, dos mitjans, una fora— i les dues preguntes d'RPO i RTO fixen la freqüència i el disseny abans d'escriure una línia. De les estratègies, la completa és simple i cara, la incremental barata i fràgil en restaurar, la diferencial un punt mitjà; però per a fitxers la millor opció és rsync --link-dest, que genera còpies com a incrementals i les restaura com a completes gràcies als enllaços durs —amb la condició d'estar al mateix sistema de fitxers i de no editar mai dins d'una còpia—. De les eines: tar czf amb -C, nom amb %F i --exclude-from per congelar arbres; i rsync amb -a sempre, -z només per xarxa, --delete únicament quan hi ha diverses còpies retingudes i mai sense un --dry-run previ, vigilant la barra final de l'origen. Retén amb política decreixent (7 diàries, 4 setmanals, 6 mensuals) per nom ordenat o per find -mtime, amb la salvaguarda de no esborrar si hi ha menys còpies de les esperades. Verifica en tres nivells —mida mínima, tar -tzf i sha256sum -c—, perquè una còpia no verificada no és una còpia, i restaura de debò, a un directori temporal i mai sobre l'original. Per a bases de dades, mysqldump --single-transaction o pg_dump -Fc, perquè copiar-ne els fitxers en calent dona una foto inconsistent; i si la còpia surt del servidor, xifratge amb gpg i la clau desada fora del sistema.

copia.sh ja viu al toolkit i s'executa a les 03:15 amb pany, comprovació d'espai i retenció; el projecte 09-03 el portarà a la seva versió completa. Però ara tens tres tasques automàtiques escrivint en tres registres que creixen sense parar, i una pregunta sense resposta: qui se n'assabenta si una d'elles deixa de funcionar? A 07-04 ataquem les dues cares d'aquell problema: el registre —dissenyar un format de línia, una funció veloz_log amb nivells, logger cap al syslog, journalctl per consultar i logrotate perquè els fitxers no es mengin el disc— i el monitoratge —llindars, alertes sense soroll, comprovacions a l'estil dels connectors clàssics i avisos que sonen un sol cop—. Neix vigilant.sh.