Tanquem el mòdul amb la lliçó que converteix Rutas Norte en una plataforma en què es pot confiar. Ja tenim les dades fora del contenidor, en un volum que sobreviu al pod, expandible i amb snapshots. Però la lliçó anterior va acabar amb un advertiment que ho relativitza tot: un snapshot viu al mateix sistema d'emmagatzematge que l'original, així que no sobreviu a la pèrdua d'una zona, a l'esborrat d'un compte ni a una corrupció descoberta tres setmanes tard. Una còpia de seguretat de veritat és una altra cosa: surt del clúster, va a un sistema independent, inclou també els objectes de l'API, es coordina amb l'aplicació per ser consistent, té retenció definida i —això és l'únic innegociable— es prova restaurant-la. En aquesta lliçó construiràs les dues peces que Rutas Norte necessita: el bolcat lògic programat de postgres-reserves i la còpia de la plataforma completa amb Velero, i faràs el simulacre de desastre esborrant un entorn sencer per recuperar-lo amb cronòmetre.

1. Què cal salvar realment en un clúster
2. Snapshot no és còpia de seguretat: la regla 3-2-1
3. RPO i RTO aplicats a Rutas Norte amb números
4. Còpia lògica: pg_dump des d'un Job programat
5. Compressió, xifratge i restauració del bolcat
6. Velero: què fa i com està construït
7. Instal·lació i primera còpia d'un namespace
8. Hooks pre i post: la còpia consistent
9. Còpies programades amb retenció
10. Restaurar en un altre namespace
11. El simulacre de desastre
12. Què no es restaura sol i el runbook mínim
13. Retenció, cost i dades personals

La primera pregunta no és "com faig còpies" sinó "de què". En un clúster de Kubernetes hi ha tres coses diferents, i cadascuna necessita una tècnica diferent:

Tres observacions que orienten tota la resta. Git no basta: els manifests permeten recrear la forma de la plataforma, però no contenen els Secrets (que vam deixar deliberadament fora de Git a 03-02), ni els certificats emesos per cert-manager (04-05), ni per descomptat les dades. La còpia d'etcd és cosa de l'administrador del clúster, no de l'equip d'aplicació, i en un clúster gestionat ni tan sols tens accés a etcd: per això l'enfocament pràctic per a Rutas Norte és copiar objectes de l'API per namespace, que a més és portable entre clústers. I el que és veritablement irreemplaçable són les dades: un Deployment es recrea en segons; una reserva venuda i cobrada, no.

Reprenem l'advertiment de 05-05 i li donem forma operativa amb la regla clàssica, que continua sent el millor resum. 3-2-1: almenys 3 còpies de les dades, en 2 suports o sistemes diferents, amb 1 d'elles fora de l'emplaçament principal. Aplicada a Rutas Norte:

La quarta fila és la que converteix el conjunt en una estratègia: sense ella, tota la resta desapareix juntament amb la infraestructura que protegeix. Dos reforços que avui es consideren obligatoris: la immutabilitat —el magatzem d'objectes en mode bloqueig (Object Lock / WORM), perquè ni tan sols unes credencials robades puguin esborrar o xifrar les còpies— i la separació de credencials: el compte que escriu les còpies no ha de poder esborrar-les, i el destí ha d'estar en un altre compte o subscripció.

Dues sigles que cal separar bé perquè es confonen constantment:

I ara els números, que és el que converteix la conversa en una cosa útil. Rutas Norte ven unes 60 reserves per hora en dia laborable normal, i unes 400 en pont o inici de vacances, amb pics de 700.

Cada fila implica una conversa de negoci, no tècnica: quant costa perdre 9.600 reserves? No és només l'import; és reconstruir a mà, atendre reclamacions, clients que es presenten a l'estació sense bitllet i dany reputacional en plena temporada alta.

Decisió de Rutas Norte:

L'RTO mesurat a l'exercici de 05-05 —de l'ordre de dos minuts en local— era el de restaurar un volum. L'RTO real d'un desastre inclou detectar, decidir, restaurar, verificar i reobrir el servei. Per això cal mesurar-lo amb un simulacre (apartat 11), no estimar-lo.

La còpia lògica és un fitxer amb les instruccions necessàries per reconstruir la base de dades. Els seus avantatges davant d'un snapshot de blocs són decisius:

No competeixen: es complementen. El snapshot és ràpid per desfer; el bolcat és la còpia que de veritat demostra que les dades estan bé.

Primer, el volum on s'escriuen els bolcats: k8s/base/copies-postgres-pvc.yaml, un PVC anomenat copies-postgres de 50 GiB, ReadWriteOnce, amb les etiquetes habituals més app.kubernetes.io/component: copies-de-seguretat. Va a la classe rutasnorte-rapida (amb Retain) perquè si es perden les còpies, la xarxa de seguretat desapareix.

I ara el CronJob. Nota: l'objecte CronJob s'estudia a fons a 06-03; aquí el fem servir com a eina, quedant-nos amb l'imprescindible per llegir-lo.

Les decisions que hi ha a dins, una a una:

• concurrencyPolicy: Forbid: si un bolcat triga més d'una hora, el següent no arrenca. Dos pg_dump simultanis duplicarien la càrrega sobre la base de dades just quan ja va lenta.
• set -euo pipefail i la verificació amb pg_restore --list: sense el primer, un pg_dump fallit pot deixar un fitxer truncat i el Job acabar en Completed, donant-te còpies que no valen; el segon comprova que el bolcat és almenys llegible. La verificació de veritat és restaurar-lo (apartat 11).
• --no-owner --no-privileges: el bolcat no arrossega propietaris ni permisos, cosa que permet restaurar-lo en un altre clúster amb un altre usuari. I amb la ServiceAccount pròpia (03-06) el pod només té el que necessita, mentre que la retenció local de 72 h converteix el PVC en la còpia calenta per restaurar ràpid; la retenció llarga viu fora del clúster.

I cal recordar les NetworkPolicies de 04-06: el pod del CronJob és nou al namespace i el deny-all el bloquejarà. Cal autoritzar explícitament la seva conversa:

Verificació:

El format -Fc comprimeix però no xifra. I aquest fitxer conté el nom, el DNI, el telèfon i el correu de tots els clients de Rutas Norte: és exactament el tipus d'artefacte que no pot quedar en clar en cap suport. La solució pràctica és xifrar amb una clau pública la clau privada de la qual no és al clúster:

La variable CLAU_PUBLICA_COPIES arriba per secretKeyRef des d'un Secret copies-clau-publica. I aquí hi ha el punt important: al clúster només hi viu la clau pública, així que qui comprometi el clúster pot escriure còpies però no pot llegir-les. La clau privada es custodia fora (gestor de secrets corporatiu, caixa forta), i el seu procediment d'accés ha d'estar documentat, perquè una còpia que ningú no pot desxifrar el dia del desastre no és una còpia.

Es llança un pod auxiliar amb la imatge postgres:16.4 que munti el PVC copies-postgres a /copies (amb kubectl run ... --overrides o un Job d'un sol ús), i des de dins:

Restaura sempre a una base de dades nova i verifica abans de substituir. Restaurar directament sobre la base de producció amb --clean és la forma més ràpida de convertir un incident recuperable en un d'irreversible.

Opcions de pg_restore que estalvien temps el dia dolent:

--jobs=4 restaura en paral·lel i redueix molt l'RTO en bases grans; --table=reserves restaura una sola taula, que és el cas més comú (algú ha esborrat una taula); --schema-only i --data-only separen estructura i dades; i --list amb --use-list permeten inspeccionar el contingut i restaurar només una part.

El bolcat lògic protegeix les dades de la base. No protegeix els Secrets, ni els PVC, ni els Ingress, ni els certificats, ni la resta d'objectes del namespace. Per a això hi ha Velero, l'eina estàndard de còpia i migració de recursos de Kubernetes.

Velero fa tres coses. Copia els objectes de l'API d'un namespace (o del clúster sencer), filtrats per etiquetes o per tipus, a un magatzem d'objectes (S3, Azure Blob, GCS, MinIO). Copia les dades dels volums per dues vies: demanant snapshots al driver CSI, o copiant fitxer a fitxer amb Kopia/Restic al mateix magatzem d'objectes, que és el que de veritat treu les dades del sistema d'emmagatzematge. I restaura tot això, al mateix clúster o en un altre, amb reassignació de namespaces i filtres.

La distinció que cal tenir clara des del principi:

Per a Rutas Norte: snapshots CSI per al dia a dia (ràpid, per desfer) i còpia al magatzem d'objectes per a la còpia setmanal de retenció llarga, que és la que compleix l'"1" de la regla 3-2-1.

Per practicar a minikube farem servir MinIO com a magatzem d'objectes compatible amb S3, desplegat al mateix clúster. En producció seria un bucket real en una altra regió i un altre compte.

La primera còpia, del namespace de preproducció:

Fixa't en el que ha capturat: els Secrets, que no són a Git; els PVC; les NetworkPolicies; els ServiceAccounts. I les dades del volum, 18,4 GB copiats fitxer a fitxer al magatzem d'objectes.

Les dues variants de volums són --snapshot-volumes=false (només objectes de l'API: rapidíssim, però sense dades) i --snapshot-volumes=true (snapshots CSI: ràpid, però les dades es queden al mateix sistema d'emmagatzematge).

Aquí resolem el problema de consistència que vam deixar obert a 05-05. Els hooks de Velero executen una ordre dins del contenidor abans i després de copiar el volum, cosa que permet deixar la base de dades en un estat coherent.

Es declaren com a anotacions al pod, o al mateix backup. La forma declarativa, al podTemplate del Deployment:

Què fa cadascun. pg_backup_start (nom a partir de PostgreSQL 15; abans era pg_start_backup) posa el servidor en mode còpia: força un checkpoint i garanteix que els fitxers del directori de dades formin un conjunt restaurable, encara que continuïn arribant escriptures. I pg_backup_stop tanca aquest mode: és imprescindible que s'executi sempre, perquè una base de dades que es queda en mode còpia acumula WAL sense alliberar i acaba omplint el disc; per això el hook post s'executa encara que la còpia falli.

Alternativa més simple i sovint preferible per a bases mitjanes: el hook pre fa directament un pg_dump a un emptyDir que Velero també copia. Sacrifica una mica de temps a canvi d'una còpia lògica verificable.

Una còpia manual serveix per aprendre; el que protegeix és una programació amb retenció automàtica, que Velero resol amb Schedule i el TTL, que esborra la còpia i les seves dades en expirar.

El calendari resultant de Rutas Norte:

Només la fila pro-setmanal compleix l'"1" de la regla 3-2-1. Les altres són comoditat i velocitat.

Vigilància obligatòria: una còpia que falla en silenci és pitjor que no tenir còpies, perquè genera confiança infundada. Es detecta amb velero backup get | grep -v Completed i s'investiga amb velero backup describe <nom> --details i velero backup logs <nom> | grep -i error. Aquesta comprovació ha de ser una alerta automàtica, no una revisió manual; es munta amb les eines de 07-04.

Restaurar sobre el namespace original en producció és l'operació més delicada. La pràctica correcta és restaurar primer en un altre lloc i verificar:

Opcions de restauració que es fan servir cada dia:

I l'avís que estalvia un ensurt: per defecte Velero NO sobreescriu els objectes que ja existeixen. Si restaures sobre un namespace viu, veuràs un munt d'avisos "already exists" i creuràs que la restauració ha fallat, quan el que ha fet és protegir-te. Per a una recuperació real, el namespace destí ha d'estar buit o cal fer servir --existing-resource-policy=update conscientment.

Una còpia no provada no és una còpia. Aquesta és la pràctica obligatòria del mòdul, i a Rutas Norte s'executa cada trimestre sobre rutas-norte-pre, amb cronòmetre i amb acta.

L'acta del simulacre ha de recollir, com a mínim: data i responsable, còpia utilitzada, RTO mesurat, RPO efectiu (el temps transcorregut entre la còpia i el desastre), què no va tornar sol, incidències i accions derivades. Al segon exercici la redactaràs sencera.

L'apartat "què no va tornar sol" és el més valuós de l'acta. És literalment impossible de conèixer sense fer el simulacre, i és el que converteix una recuperació teòrica en una recuperació real.

Un document curt, al repositori, que algú de guàrdia a les tres de la matinada pugui seguir sense pensar:

Les còpies costen diners, i sense retenció automàtica la despesa creix sense fre. Amb postgres-reserves en uns 20 GiB, els 72 bolcats horaris ocupen uns 30 GiB (comprimeixen a ~410 MB cadascun), els 7 snapshots diaris uns 25 GiB per ser incrementals, i les 13 còpies setmanals uns 260 GiB al magatzem d'objectes. Palanques per ajustar-ho: fer servir classes d'emmagatzematge fredes per al que és antic, aprofitar la deduplicació de Kopia, i no copiar el que es pot regenerar (redis-cache no entra en cap còpia, pel que es va decidir a 05-03).

I aquí hi ha el que no pot quedar com un detall tècnic. Les còpies de seguretat de Rutas Norte contenen dades personals de clients: nom, DNI, telèfon i correu de cada persona que ha comprat un bitllet. Això significa que cada còpia és un tractament de dades personals amb els mateixos deures que el sistema original, i en alguns aspectes més exigents, perquè les còpies es multipliquen, es repliquen i s'obliden.

Els requisits mínims que Rutas Norte aplica:

ADVERTIMENT DE COMPLIMENT NORMATIU

Tot l'anterior és arquitectura tècnica, no assessorament legal. Els terminis de retenció, la ubicació geogràfica de les còpies, el tractament del dret de supressió sobre dades ja copiades, la base legal del tractament i les obligacions davant d'una bretxa de seguretat han de ser revisats i aprovats pel responsable de compliment normatiu i de protecció de dades de l'organització abans de posar en marxa aquesta configuració en producció. Els valors d'aquest curs (72 hores, 7 dies, 90 dies) són exemples didàctics triats per il·lustrar la mecànica de la retenció, no recomanacions legals: el termini correcte depèn de la normativa aplicable, del sector i de la finalitat declarada de cada tractament, i conservar dades personals més temps del necessari és tan incompliment com no protegir-les.

Consells:

1. Automatitza la verificació, no només la còpia. Un Job setmanal que restauri l'últim bolcat en un namespace de proves i compari el recompte de files converteix "creiem que tenim còpies" en "sabem que tenim còpies".
2. Documenta l'RPO i l'RTO reals, no els desitjats, i revisa'ls després de cada simulacre. Són la dada que necessita el negoci per decidir quant invertir.
3. La còpia ha de poder restaurar-se sense la persona que la va configurar. Si el procediment viu al cap d'algú, no existeix: escriu-lo al runbook, al repositori. I quan dubtis entre gastar en còpies o en qualsevol altra cosa, gasta en còpies: és l'únic component de la plataforma l'absència del qual no es nota fins que és massa tard.

A rutas-norte-dev, munta la cadena completa de còpia lògica:

1. Crea el PVC copies-postgres de 5 GiB a la classe rutasnorte-rapida.
2. Adapta el CronJob de l'apartat 4 a dev, amb schedule: "*/10 * * * *" per no esperar una hora.
3. Llança una execució manual i comprova als registres que el bolcat s'ha creat i verificat.
4. Esborra la taula reserves i restaura-la a una base de dades nova des del bolcat, sense tocar l'original.
5. Comprova que les dades coincideixen i explica per què és important restaurar a una base nova.

Executa el simulacre complet de l'apartat 11 sobre rutas-norte-pre (crea'l amb els cinc components si no el tens) i redacta l'acta amb: inventari previ, còpia usada, RTO mesurat, RPO efectiu, què no va tornar sol, incidències i accions derivades.

Compara després l'RTO mesurat amb l'objectiu de 8 hores fixat per a pre a l'apartat 3 i raona si la política és adequada o cal canviar-la.

El comitè de direcció de Rutas Norte pregunta: "si demà perdem el centre de dades sencer, quant trigarem a tornar a vendre i quantes reserves perdem?". Prepara la resposta en forma de document breu:

• A. Taula de què es copia, amb quin mètode, freqüència, retenció i de què protegeix cada còpia.
• B. RPO i RTO compromesos, amb el nombre de reserves perdudes en el pitjor cas (pont, 400 reserves/hora).
• C. Els tres elements que no es restauren sols i qui és responsable de cadascun.
• D. Un apartat sobre dades personals que inclogui què contenen les còpies, com es protegeixen i què ha de validar el responsable de compliment normatiu.

Exercici 1

Per què a una base nova. Tres raons. Primera, si el bolcat estigués corrupte o incomplet, restaurar a sobre amb --clean hauria destruït el que quedava: et quedaries sense el que està danyat i sense la còpia. Segona, la base danyada és l'evidència per al post-mortem: sense ella no sabràs què va passar ni des de quan. I tercera, permet comparar abans de tallar: recompte de files, data màxima, integritat referencial. La substitució final és un canvi de nom de dos segons, així que l'estalvi de temps de restaurar a sobre és menyspreable davant del risc.

Exercici 2

Acta tipus:

Valoració de la política: l'RTO objectiu de pre era de 8 hores i el mesurat és de 23 minuts, així que es compleix amb un marge enorme. Però la conclusió útil és una altra: el mateix procediment aplicat a producció no donaria 23 minuts, perquè a pro el volum és deu vegades més gran, cal actualitzar el DNS amb la seva propagació, regenerar secrets externs i verificar el negoci d'extrem a extrem. L'acció correcta és repetir el simulacre sobre una còpia de producció restaurada en un namespace a part, que és el que dona el número real de les 2 hores compromeses.

Exercici 3

A. Què es copia:

B. Compromisos:

L'última fila és la resposta a la pregunta del comitè, i és incòmoda a propòsit: la còpia que sobreviu a perdre el centre de dades és la setmanal, de manera que en el pitjor cas es perdrien fins a set dies de reserves. Si això no és acceptable —i no hauria de ser-ho—, hi ha dues inversions que ho arreglen: passar la còpia externa a diària (RPO de 24 h) i, sobretot, arxivar el WAL de PostgreSQL de forma contínua a un magatzem d'objectes extern, que portaria l'RPO a minuts. És la millora prioritària del pla.

C. El que no es restaura sol:

D. Dades personals:

Les còpies contenen nom, DNI, telèfon i correu de tots els clients que han comprat un bitllet, a més de l'historial complet de reserves. Proteccions aplicades: xifratge en repòs dels bolcats amb clau pública (privada custodiada fora del clúster), xifratge del bucket, xifratge en trànsit, credencials de només escriptura per al procés de còpia, accés a la restauració limitat per RBAC i registrat, retenció automàtica per TTL i anonimització obligatòria de qualsevol clon destinat a entorns no productius.

El que ha de validar el responsable de compliment normatiu, abans de posar res d'això en producció:

1. Que els terminis de retenció (72 h, 7 dies, 90 dies) són els legalment correctes per a aquesta finalitat, ni més ni menys.
2. Que la regió del magatzem de còpies és dins de l'àmbit geogràfic permès i declarat.
3. El procediment davant del dret de supressió: què es fa amb les còpies que ja contenen les dades de qui l'exerceix, i com es documenta.
4. La base legal del tractament i el seu reflex al registre d'activitats, incloent-hi les còpies com a tractament.
5. El protocol de notificació de bretxes si una còpia es veu compromesa.
6. Les condicions de l'encarregat del tractament amb el proveïdor del núvol que allotja les còpies.

Aquest document és una proposta tècnica i no substitueix aquesta revisió.

Rutas Norte ja és una plataforma en què es pot confiar. Saps què cal salvar —els manifests, que ja són a Git; l'estat de l'API, amb els Secrets i els PVC que Git no conté; i les dades dels volums, l'única cosa veritablement irreemplaçable— i que cadascun exigeix una tècnica diferent. Tens interioritzada la regla 3-2-1 i saps que, de totes les còpies de Rutas Norte, només la setmanal al magatzem d'objectes d'una altra regió compleix l'"1"; les altres són comoditat i velocitat. I manegues RPO i RTO amb números concrets: a 400 reserves per hora en un pont, una còpia diària significa perdre fins a 9.600 reserves, i això converteix una discussió tècnica en una decisió de negoci que algú ha de prendre i signar.

Has construït les dues peces. La còpia lògica: un CronJob horari que executa pg_dump -Fc, verifica el bolcat amb pg_restore --list, el xifra amb una clau pública la privada de la qual no viu al clúster, aplica retenció local i —detall que s'oblida sempre— té la seva pròpia NetworkPolicy per travessar el deny-all de producció. I la còpia de la plataforma amb Velero: la seva arquitectura de controlador, node-agent i plugins; les dues vies per als volums, amb la diferència decisiva que només la còpia al magatzem d'objectes treu de veritat les dades del sistema d'emmagatzematge; els hooks pre i post amb pg_backup_start/pg_backup_stop que resolen la consistència que vam deixar oberta a 05-05, i l'advertiment que el post s'ha d'executar sempre so pena d'omplir el disc de WAL; els Schedule amb TTL que fan la retenció automàtica; i la restauració amb --namespace-mappings per verificar abans de tocar res real.

I has fet el que separa una còpia d'una còpia útil: el simulacre. Esborrar rutas-norte-pre sencer i recuperar-lo amb cronòmetre, mesurant un RTO real i descobrint la llista del que no torna sol —el certificat, la IP del LoadBalancer, el DNS, els secrets externs, els recursos de clúster—, que és literalment impossible de conèixer sense executar-lo. D'aquí surt el runbook que algú de guàrdia pot seguir a les tres de la matinada. Al costat de tot això queda l'advertiment que no és tècnic: les còpies contenen dades personals de clients, s'han de xifrar, tenir termini d'esborrat, no sortir de l'àmbit legal previst, i la política de retenció i el tractament d'aquestes dades han de ser revisats i aprovats pel responsable de compliment normatiu abans de portar res d'això a producció.

Amb això acaba el mòdul 5. El deute que arrossegàvem des del mòdul 2 està saldat del tot: postgres-reserves guarda les seves dades en un volum que sobreviu al pod, aprovisionat dinàmicament per una StorageClass amb Retain, expandible en calent, amb snapshots abans de cada canvi arriscat i amb còpies verificades dins i fora del clúster.

Queda un sostre que hem trobat tres vegades i sempre hem ajornat amb la mateixa frase. A 05-03 vas descobrir que un Deployment té una sola plantilla, de manera que totes les seves rèpliques demanen el mateix PVC i per això postgres-reserves està condemnat a replicas: 1 amb strategy: Recreate. Una base de dades de producció necessita més: identitat estable, arrencada ordenada i un volum propi per rèplica. Això ho dona el volumeClaimTemplate dels StatefulSets, i amb ell arrenca el mòdul 6, Conceptes Avançats: StatefulSets, DaemonSets, Jobs i CronJobs —on per fi arriba informes-ocupacio, el sisè component de la plataforma—, init containers i sidecars, planificació amb afinitat i taints, recursos personalitzats i operadors. Comencem per StatefulSets.