Tocho: emmagatzematge personal sobirà, xifrat i replicat entre dues ubicacions

1. Introducció

Tocho és un projecte personal que mantenim Ismael Ripoll i jo, Raúl, amb l’objectiu de disposar d’un sistema d’emmagatzematge massiu, raonablement fiable, xifrat i replicat entre dues ubicacions físiques diferents.

La idea inicial era senzilla: cadascun de nosaltres tindria una Raspberry Pi amb un disc dur SATA de 16 TB. Cada disc serviria per a guardar les dades pròpies i, al mateix temps, una còpia xifrada de les dades de l’altre. D’aquesta manera, cada un disposaria d’una rèplica externa en una altra casa.

Amb el temps, el projecte ha anat evolucionant. Ja no és només “un NAS casolà amb una còpia remota”, sinó una infraestructura personal que combina:

• emmagatzematge massiu;
• còpies creuades;
• xifratge;
• accés natiu des de Linux;
• monitoratge;
• protecció davant d’avaries;
• protecció parcial davant de ransomware;
• còpies versionades amb Borg;
• i una filosofia clara de sobirania tècnica.

No és un sistema empresarial ni pretén substituir una infraestructura professional. Però sí que proporciona una millora molt important respecte a tindre una sola còpia local, o pitjor encara, a no tindre cap estratègia de còpia sistemàtica.

2. Motivació

La motivació principal és molt pràctica: les dades personals ocupen cada vegada més espai i no sempre encaixen bé en els serveis comercials de núvol. Fotos, vídeos, repositoris, documents, imatges de disc, còpies de màquines, projectes personals i arxius històrics poden arribar fàcilment a diversos terabytes.

Els serveis comercials resolen molt bé molts problemes, però també imposen limitacions:

• cost mensual recurrent;
• dependència d’un proveïdor;
• integració desigual amb Linux;
• absència de control real sobre protocols i automatismes;
• límits d’espai;
• polítiques canviants;
• i, sovint, una interfície pensada més per a usuaris generals que per a fluxos tècnics.

Tocho naix d’una idea diferent: si tenim coneixement tècnic suficient, podem construir una infraestructura pròpia, entendre-la, reparar-la i adaptar-la a les nostres necessitats.

Ara bé, una de les lliçons del projecte és precisament que això no és gratis. Encara que no es pague una quota mensual, cal pagar discos, adaptadors, alimentació, refrigeració, temps d’administració, proves, monitoratge i manteniment. La núvol comercial pot semblar cara fins que comptes tot el que implica operar tu mateix una infraestructura mínimament fiable.

3. Objectius del projecte

Els objectius principals de Tocho són:

1. Disposar de molt espai d’emmagatzematge a un cost assumible.
2. Mantindre una rèplica remota de les dades importants.
3. Protegir la confidencialitat de les dades allotjades en el servidor de l’altre.
4. Reduir el risc de pèrdua davant d’avaries, robatoris, incendis o altres incidències locals.
5. Usar eines estàndard de Linux.
6. Permetre accés natiu als fitxers, sense dependre d’una aplicació propietària.
7. Fer còpies versionades i deduplicades.
8. Reduir el risc que un ransomware o un error humà destruïsca totes les còpies.
9. Mantindre el sistema comprensible i reparable pels dos administradors.

La filosofia és que la fiabilitat no depén només de comprar maquinari car, sinó de combinar bones pràctiques: rèpliques, xifratge, monitoratge, comprovacions periòdiques, separació de privilegis i capacitat real de restauració.

4. Arquitectura general

Cada participant té una instal·lació semblant:

• una Raspberry Pi que actua com a servidor;
• un disc dur SATA de 16 TB;
• un adaptador USB-SATA compatible amb discos grans;
• alimentació pròpia per al disc;
• una carcassa o rack físic;
• ventilació;
• accés SSH amb claus públiques;
• exportació local de fitxers, en el meu cas també per NFS;
• espais xifrats;
• i tasques programades de còpia i verificació.

L’esquema conceptual és aquest:

Figura 1

Cada servidor té una doble funció:

• servidor principal de dades locals;
• destinació remota de la còpia xifrada de l’altre.

5. Model de rèplica creuada

El model bàsic de rèplica és deliberadament simple. Les dades es copien de manera periòdica, normalment durant la nit, mitjançant rsync.

En el cas habitual:

1. El servidor local conté les dades principals.
2. Abans de la còpia, es comprova l’estat del disc.
3. Si el disc sembla estar en bon estat, s’inicia la sincronització.
4. Les dades de l’altre es guarden xifrades.
5. El propietari físic del servidor remot no pot llegir el contingut real.

Figura 2

També és possible forçar una sincronització manual després de copiar moltes dades. Això redueix la finestra de risc entre el moment en què una dada nova apareix en el servidor local i el moment en què queda replicada remotament.

rsync permet limitar fàcilment l'amplada de banda (--bwlimit), però en la pràctica no ho fem: cada node disposa d'1 Gbps i les còpies es llancen de nit, així que mai hem notat pèrdua de rendiment ni en la xarxa domèstica ni en la connexió entre les dues cases. Si algun dia això canviara, activar el límit seria trivial.

6. RPO: quantes dades podem perdre

En l’estat actual, el sistema té un RPO aproximat d’un dia per a les dades que només se sincronitzen durant la nit.

RPO vol dir Recovery Point Objective: el màxim període de dades que s’assumeix que es podria perdre en un desastre. Si la còpia es fa cada nit, la pèrdua màxima habitual és el que s’ha modificat des de l’última còpia correcta.

En la pràctica:

• si la còpia nocturna ha anat bé, puc perdre com a màxim les dades del mateix dia;
• si després de copiar moltes dades execute manualment una sincronització, reduïsc eixa finestra;
• si la còpia falla i no ho detecte, el RPO real empitjora.

Això fa que el monitoratge no siga un detall secundari. No n’hi ha prou amb “tindre còpies”: cal saber que les últimes còpies han acabat correctament.

7. Xifratge amb GoCryptFS

Un punt essencial del projecte és que cada participant allotja dades de l’altre, però no ha de poder llegir-les.

Per això, una part de les dades remotes es guarda xifrada amb GoCryptFS. Aquest sistema permet tindre una representació xifrada dels fitxers en disc, mentre que el propietari pot muntar-los de manera transparent quan necessita accedir-hi.

Això aporta diversos avantatges:

• el disc es pot retirar, substituir o destruir sense exposar les dades;
• el propietari físic del servidor no pot inspeccionar el contingut real de la còpia de l’altre;
• la còpia es pot fer amb eines estàndard, perquè al final es copien fitxers xifrats normals;
• el muntatge pot fer-se localment en la Raspberry Pi o remotament des d’un altre ordinador.

Figura 3

En la pràctica, és útil poder fer el muntatge des d’un PC més potent. La Raspberry Pi és una màquina eficient, però el xifratge pot carregar la CPU. Si el procés usa pocs fils o la còpia és intensiva, delegar part del treball criptogràfic en un ordinador més potent pot millorar el rendiment.

8. NAS, però no només NAS

Una part de Tocho funciona com un NAS: un servidor de fitxers accessible des de la xarxa local. En el meu cas, puc muntar els fitxers per NFS i treballar amb ells de manera natural des de Linux.

Això és molt còmode, però també introdueix un risc: si el meu PC té accés complet al sistema de fitxers, un error meu, un script defectuós o un ransomware podria modificar o esborrar dades directament.

Per això és important distingir dues funcions:

1. NAS de treball, pensat per a accedir còmodament a fitxers.
2. Sistema de còpia de seguretat, pensat per a conservar versions i resistir errors o atacs.

Un NAS no és automàticament una còpia de seguretat. Si està muntat permanentment amb permisos d’escriptura, forma part de la mateixa superfície de risc que el PC.

9. Còpies Borg: deduplicació, xifratge i versions

Per reforçar la part de còpies, he començat a usar BorgBackup. Borg és una eina de còpia de seguretat amb deduplicació, compressió i xifratge autenticat. Està pensada per a fer còpies eficients, perquè després de la primera només necessita emmagatzemar els blocs que han canviat.

Aquesta part és especialment important perquè introdueix una diferència conceptual respecte a l’ús clàssic d’un NAS.

Amb NFS, treballe directament sobre fitxers visibles. Amb Borg, els ordinadors clients creen arxius de còpia versionats dins d’un repositori. Això permet conservar moltes versions sense multiplicar linealment l’espai usat.

Borg aporta tres propietats molt valuoses:

• xifratge;
• deduplicació;
• snapshots lògics.

Això fa que siga molt més adequat per a còpia històrica que una rèplica simple amb rsync.

10. Claus SSH restringides per ordinador

Cada ordinador que fa còpies cap al servidor té una clau SSH pròpia, creada específicament per a eixa funció.

Aquestes claus no haurien de donar accés general al servidor, ni permetre obrir una shell interactiva, ni administrar el sistema. La idea és que cada clau només permeta executar el servei necessari per a afegir còpies al repositori Borg corresponent.

Borg suporta l’ús de borg serve amb ordres forçades via SSH, que és precisament el patró adequat per a aquest tipus de configuració.

Concretament, açò s’aconsegueix limitant cada clau a una ordre concreta dins del fitxer authorized_keys. Si s’anteposa command="<ordre autoritzada>" davant de la clau pública, el servidor només executarà eixa ordre quan algú es connecte amb la clau, encara que el client n’intente llançar una altra. D’aquesta manera, una clau pensada per a fer còpies no pot obrir una shell interactiva, recórrer el sistema de fitxers ni esborrar dades de manera arbitrària. És una peça clau per a reduir el risc de ransomware i altres escenaris d’atac.

L’esquema és aproximadament aquest:

Figura 4

Això redueix molt el risc en cas que un portàtil, un PC o una altra màquina client quede compromesa. Si un atacant obté la clau d’eixa màquina, no hauria de poder entrar lliurement al servidor ni esborrar qualsevol cosa.

11. Mode append-only i defensa contra ransomware

Una de les motivacions recents del projecte és millorar la protecció davant de ransomware.

El problema d’un NAS tradicional és que, si els fitxers estan muntats amb permisos d’escriptura des del PC principal, un ransomware podria xifrar o destruir també les dades del NAS. En eixe cas, el NAS deixaria de ser una còpia de seguretat real i passaria a ser una extensió vulnerable del mateix ordinador.

Per reduir aquest risc, els repositoris Borg poden configurar-se en mode append-only. La documentació de Borg explica que aquest mode és útil quan una màquina client fa còpies remotes cap a un servidor amb borg serve, perquè una màquina client compromesa no pot eliminar permanentment les còpies del servidor.

La separació és clau:

• els clients poden afegir còpies;
• els clients no haurien de poder destruir l’històric;
• la poda de versions antigues ha de ser una operació separada;
• un atac des d’un ordinador client no hauria de poder eliminar totes les còpies bones.

Això no elimina tots els riscos. Un atacant podria afegir còpies dolentes o xifrades, i caldria detectar el problema abans de fer una poda destructiva. Però és una millora molt important respecte a tindre un directori NFS muntat permanentment amb accés complet.

12. Separació entre dades vives i còpies de seguretat

Una idea de futur és reduir l’ús del servidor com a magatzem de fitxers directament manipulables i convertir-lo cada vegada més en un magatzem de còpies Borg.

Això implica distingir entre:

1. Dades vives, que es poden obrir, editar, moure o esborrar des del PC normal.
2. Còpies de seguretat, que només s’afegeixen al repositori i no són modificables directament pel compte d’usuari habitual.

Aquesta separació és molt sana. Les dades vives poden estar en discos locals, per exemple en un disc de 4 TB o en un disc intern de 2 TB. El servidor Tocho, en canvi, pot dedicar-se sobretot a guardar versions Borg xifrades i deduplicades.

L’objectiu és passar d’aquest model:

Figura 5

a aquest altre:

Figura 6

Si el compte normal de l’usuari comet un error, executa un rm massa ampli o queda compromés, no hauria de tindre accés directe a destruir totes les còpies històriques.

13. Còpies incrementals i sincronització parcial

Una pregunta oberta és si es poden fer còpies incrementals sense haver de recórrer tot l’arbre de fitxers cada vegada.

Amb rsync, el model normal és comparar origen i destinació per decidir què ha canviat. Això és robust, però pot ser costós si hi ha moltíssims fitxers.

Hi ha diverses estratègies possibles:

• llançar sincronitzacions manuals de carpetes concretes després de canvis importants;
• fer còpies Borg dels conjunts de dades realment importants;
• usar llistes de fitxers modificats recentment amb find, encara que això és més fràgil;
• separar millor les dades per freqüència de canvi: arxius freds, dades actives i còpies crítiques;
• considerar sistemes amb snapshots natius si en el futur s’usa Btrfs o ZFS.

En general, per a còpia de seguretat versionada, Borg és més adequat que una rèplica simple amb rsync. Per a rèplica d’un arbre de fitxers navegable, rsync continua sent molt senzill i pràctic.

14. Accés natiu des de Linux i sobirania sobre els fitxers

Un dels avantatges més importants de Tocho és que em permet treballar amb els meus fitxers de manera nativa en Linux.

A diferència d’alguns serveis comercials de núvol, el sistema no m’obliga a passar per una interfície web, una aplicació propietària o una capa d’integració aliena. Puc muntar sistemes de fitxers amb eines estàndard, accedir-hi amb NFS, SSHFS, GoCryptFS o Borg, automatitzar tasques amb scripts i decidir exactament com vull organitzar les dades.

Això té un valor pràctic enorme. Per a un usuari de Linux, el sistema de fitxers no és només un lloc on deixar documents: és una interfície universal. Les mateixes eines que use per a programar, indexar, buscar, comparar, versionar o transformar dades poden operar directament sobre els meus fitxers.

Google Drive és un bon contraexemple. Malgrat ser un servei molt popular, Google no ofereix un client oficial complet de Google Drive per a Linux. De fet, hi ha una pàgina mantinguda per la comunitat, How long since Google said a Google Drive Linux client is coming?, que compta el temps transcorregut des del 24 d’abril de 2012, quan Google va donar a entendre que arribaria suport per a Linux amb el missatge “hang tight”.

Aquesta absència obliga els usuaris de Linux a dependre d’eines no oficials o de solucions parcials. Algunes funcionen molt bé, com rclone, però no deixen de ser capes alternatives al voltant d’un servei que no està pensat principalment per al meu flux de treball.

Amb Tocho, en canvi, la situació és la contrària: jo controle el servidor, el protocol, el sistema de fitxers, el xifratge, els permisos i els automatismes. No depenc que una empresa decidisca si Linux mereix o no una integració de primera classe.

Aquesta és una forma concreta de sobirania tècnica: no sols posseir les dades, sinó poder decidir com s’hi accedeix.

15. Allò que encara no tenim: gestió nativa de fotografies

Ara bé, aquesta sobirania encara no és completa en tots els àmbits.

Un punt pendent és la gestió de fotografies. Els serveis comercials han resolt molt bé la part d’experiència d’usuari: pujada automàtica des del mòbil, àlbums compartits, miniatures, línia temporal, reconeixement de duplicats, compartició senzilla i accés còmode des de qualsevol dispositiu.

Tocho encara no ofereix una alternativa pròpia a això. Pot guardar fotografies com a fitxers, naturalment, però no proporciona encara una experiència comparable a Google Photos, iCloud Photos o serveis semblants.

Un pas futur interessant seria desplegar una solució pròpia per a fotografia, capaç de:

• rebre còpies automàtiques des del mòbil;
• generar miniatures;
• organitzar àlbums;
• compartir fotos i àlbums fàcilment amb amics i familiars, de manera controlada;
• mantindre les imatges dins de la infraestructura pròpia;
• integrar-se amb el sistema de còpies i rèpliques ja existent.

Aquesta part seria una evolució natural del projecte: passar de “tinc els fitxers guardats” a “tinc també serveis personals damunt dels meus fitxers”.

16. Maquinari utilitzat

Cada instal·lació està formada aproximadament per:

• Raspberry Pi;
• disc dur SATA de 16 TB;
• adaptador USB-SATA compatible amb discos grans;
• font d’alimentació adequada per al disc;
• caixa, rack o suport físic;
• ventilació addicional;
• connexió de xarxa domèstica amb fibra.

Un detall important és que no tots els adaptadors USB-SATA funcionen correctament amb discos de gran capacitat. En alguns casos pot haver-hi limitacions del chipset, del firmware, del tipus de pont USB-SATA, del suport UASP, de la gestió de sectors grans o simplement problemes de compatibilitat amb discos moderns de molts terabytes.

Per això va ser necessari triar un adaptador més fiable, encara que fora més car.

17. Refrigeració, soroll i estabilitat física

La temperatura del disc és un factor important per a la longevitat i l’estabilitat del sistema.

En el meu cas, el disc està muntat dins d’una estructura metàl·lica pensada per a diversos discos, encara que actualment només n’utilitze un. Això proporciona més massa metàl·lica i, per tant, més capacitat de dissipació.

A més, el rack disposa d’un ventilador controlat per PWM des de la Raspberry Pi. Això permet ajustar la velocitat del ventilador, reduir el soroll i mantindre el disc a una temperatura raonable.

Figura 7

L’objectiu no és refredar agressivament, sinó evitar que el disc treballe calent durant moltes hores. Un disc que es manté tebi i estable és preferible a un disc sotmés a pics tèrmics o a ventilació deficient.

18. El cas del ventilador: quan el plug and play no ho és

Una altra lliçó del projecte és que el maquinari domèstic rarament és tan plug and play com promet.

En el meu cas, vaig comprar una carcassa o rack que teòricament ja venia preparat, amb ventilador inclòs. La idea era senzilla: muntar el disc, connectar-ho tot i deixar que el sistema funcionara.

Però el ventilador que venia de sèrie tenia un comportament clarament defectuós: el que s'escalfava era el mateix ventilador, no el disc que havia de refrigerar. En buit, sense cap càrrega real que ho justificara, el ventilador arribava a aproximadament 70 °C en pocs segons. És a dir, no era el disc el que estava a 70 °C, sinó el propi ventilador, cosa que no era ni acceptable ni segura.

Aprofitant que calia substituir-lo, vaig canviar el ventilador original, d’aproximadament un centímetre de gruix, per un altre de dos centímetres. Els ventiladors més gruixuts poden moure aire amb menys esforç i, en general, poden ser més silenciosos per a un mateix cabal. Això era important perquè el servidor està instal·lat al saló, on el soroll és un factor real.

El canvi tampoc va ser immediat. Vaig haver d’usar la impressora 3D per fabricar cilindres o separadors adaptadors que permeteren muntar correctament el ventilador nou en la carcassa existent.

Aquest episodi resumeix molt bé el caràcter del projecte: sobre el paper, sembla només “una Raspberry Pi amb un disc”. En la pràctica, apareixen molts detalls menuts però importants:

• compatibilitat de l’adaptador USB-SATA;
• alimentació del disc;
• temperatura;
• soroll;
• vibracions;
• muntatge físic;
• flux d’aire;
• peces adaptades;
• control PWM;
• ubicació dins de casa.

Cada detall pot semblar menor, però tots junts separen un muntatge improvisat d’un sistema raonablement fiable.

19. Monitoratge i comprovacions

El sistema incorpora diverses comprovacions periòdiques.

Abans d’iniciar una còpia important, es consulta l’estat del disc amb smartctl. Si el disc informa d’un estat problemàtic o de prefallada, la còpia es pot ometre per evitar escriure sobre un suport potencialment defectuós o agreujar una situació delicada.

A més, hi ha una comprovació horària que verifica que la màquina està accessible i que el disc continua muntat o disponible. Aquesta comprovació consulta també l’espai lliure mitjançant df.

Una vegada al dia, al voltant de les 7 del matí, s’envia un missatge per Telegram amb l’estat general. D’aquesta manera, els problemes importants no queden silenciosos durant setmanes.

De moment, Telegram no ens ha fallat mai. A més, este missatge diari funciona com una mena d’interruptor d’home mort: el mirem cada matí a les 7, així que, si algun dia no arribara, l’absència mateixa seria l’alarma i ens preocuparíem immediatament.

Figura 8

Un punt que cal reforçar és la revisió habitual de l’estat de les còpies. No n’hi ha prou amb generar logs: cal que l’estat final siga visible.

Una millora clara seria incorporar al missatge diari de Telegram informació com aquesta:

• última còpia correcta de cada màquina;
• duració de cada còpia;
• quantitat de dades afegides;
• nombre de fitxers processats;
• estat del repositori Borg;
• resultat de l’últim borg check, si s’executa periòdicament;
• espai lliure restant;
• estat SMART i temperatura del disc;
• el desfasament horari entre els nodes (tots es posen en hora per NTP, però comprovar-ho periòdicament ajuda a detectar problemes de rellotge);
• avís explícit si una còpia porta més de X dies sense completar-se.

Això convertiria el monitoratge en una eina de confiança real, no només en una comprovació superficial de disponibilitat.

20. Gestió del repòs del disc

Els discos durs es poden adormir després d’un període curt d’inactivitat. Això redueix consum, soroll i desgast mecànic, però també introdueix una tensió entre dos objectius:

• no despertar el disc innecessàriament;
• detectar problemes amb prou rapidesa.

Per aquest motiu, convé agrupar operacions pesades en franges horàries concretes, especialment les còpies nocturnes. També cal evitar comprovacions massa intrusives cada hora si això obliga el disc a girar constantment.

La regla pràctica és que les comprovacions freqüents haurien de ser lleugeres, i les operacions que desperten clarament el disc haurien d’estar justificades.

21. Repositoris Git xifrats amb git-crypt

En el cas d’Ismael, una altra línia interessant ha sigut l’ús de repositoris Git amb contingut xifrat mitjançant git-crypt.

git-crypt és una eina que permet xifrar de manera transparent determinats fitxers dins d’un repositori Git. Els fitxers configurats com a sensibles es guarden xifrats en el repositori, però els usuaris autoritzats els veuen desxifrats en el seu arbre de treball. La descripció oficial del projecte és precisament “transparent file encryption in git”.

Això és útil quan es vol mantindre un repositori Git normal, però sense exposar secrets, configuracions privades, claus, dades personals o fitxers que no haurien d’estar en clar.

Figura 9

Això encaixa bé amb la filosofia general de Tocho: no confiar només en el perímetre del sistema, sinó xifrar també les dades segons el seu ús concret.

En altres paraules, hi ha diverses capes de protecció:

• GoCryptFS per a arbres de fitxers xifrats;
• Borg per a còpies versionades, deduplicades i xifrades;
• git-crypt per a secrets o fitxers sensibles dins de repositoris Git;
• SSH amb claus restringides per limitar què pot fer cada màquina;
• separació entre dades vives i còpies històriques.

El patró comú és clar: cada eina protegeix una part diferent del problema.

22. Riscos coberts

Tocho cobreix bastant bé diversos escenaris de risc.

Avaria d’un disc

Si un disc falla, encara hi ha una rèplica en l’altra ubicació. En eixe cas, cal comprar un disc nou i reconstruir la còpia.

Robatori

Si roben un dels equips, les dades de l’altre continuen estant en una altra casa. A més, les dades allotjades en el disc robat estan xifrades.

Incendi o dany físic local

Una catàstrofe que afecte una sola ubicació no hauria de destruir totes les còpies.

Error humà parcial

Si s’esborra accidentalment alguna cosa i la còpia encara no s’ha sincronitzat, pot ser possible recuperar-la de la rèplica anterior. Ara bé, aquesta protecció és limitada si la supressió o corrupció ja s’ha propagat amb rsync.

Compromís d’una màquina client

Amb Borg append-only i claus SSH restringides, una màquina client compromesa no hauria de poder eliminar permanentment totes les còpies històriques.

23. Riscos no resolts completament

El sistema actual encara té punts febles importants.

Corrupció silenciosa

Si un fitxer es corromp i després es replica, la còpia remota pot acabar contenint també la versió corrupta. rsync no és, per si sol, un sistema de verificació històrica de la integritat.

Ransomware sobre dades vives

Si una màquina client xifra o modifica massivament els fitxers visibles, i després s’executa una sincronització, el dany es pot propagar a la rèplica.

Absència parcial d’històric

Una rèplica simple protegeix contra la pèrdua d’un disc, però no sempre contra errors lògics. Per a això fan falta snapshots, versions antigues o còpies immutables durant un període.

Finestra de vulnerabilitat

Entre una modificació local i la còpia remota hi ha una finestra temporal en què les dades noves encara només existeixen en un lloc.

Reconstrucció lenta

En cas de pèrdua d’un disc complet, reconstruir 16 TB pot ser lent. A 100 MB/s sostinguts, copiar 16 TB tarda aproximadament 44 hores. En la pràctica, pot ser més, perquè el rendiment real depén del disc, de la xarxa, del xifratge, del protocol i de la quantitat de fitxers.

Per això, en una reconstrucció completa pot ser més raonable portar físicament el disc a l’altra casa i fer la primera còpia en local o per xarxa local ràpida.

24. Recuperació davant d’un desastre

En cas de fallada completa d’un disc, el procediment general seria:

1. Detectar la fallada mitjançant SMART, errors d’E/S o absència del disc.
2. Marcar el node afectat com a no fiable.
3. Aturar les sincronitzacions automàtiques cap a eixe disc.
4. Comprar o instal·lar un disc nou.
5. Inicialitzar el sistema de fitxers.
6. Restaurar la còpia des de l’altre servidor.
7. Verificar integritat i muntatge del sistema xifrat.
8. Reactivar les còpies nocturnes.

Durant la reconstrucció, el sistema queda en un moment més delicat, perquè temporalment pot haver-hi una sola còpia completa. Per això cal minimitzar el temps de reconstrucció i evitar operacions arriscades fins que la redundància quede restaurada.

25. Millores possibles

El projecte ja és útil en la seua forma actual, però hi ha diverses millores possibles.

Estat persistent de “disc sospitós”

Si smartctl detecta una situació de prefallada, no n’hi ha prou amb ometre una còpia concreta. Seria convenient deixar el disc en un estat persistent de “bloquejat”, “sospitós” o “requereix intervenció manual”.

Això evitaria que una execució posterior tornara a intentar copiar automàticament fins que algú revisara el problema.

Tests SMART actius periòdics

Actualment només es llegeixen els atributs SMART abans de cada còpia, però no es llancen tests actius. Seria bona idea programar un test llarg (smartctl -t long) una vegada al mes: recorre tota la superfície del disc i pot detectar sectors defectuosos abans que causen problemes. Com que és una operació lenta que manté el disc despert, convé llançar-la en una franja nocturna i deixar constància del resultat en l'avís diari.

Snapshots o versions

Per protegir-se millor contra ransomware, esborrats accidentals o corrupció lògica, seria interessant afegir algun mecanisme de versions.

Algunes opcions serien:

• snapshots amb Btrfs o ZFS;
• còpies amb rsnapshot;
• repositoris BorgBackup o Restic;
• hard links amb estratègies tipus rsync --link-dest;
• retenció de versions diàries, setmanals i mensuals.

Verificació d’integritat

També seria útil disposar d’un catàleg de hashes o d’un sistema de verificació periòdica que permeta detectar corrupció silenciosa.

El repte és fer-ho sense despertar el disc contínuament ni convertir la verificació en una tasca massa costosa.

Detecció de canvis sospitosos

Una altra idea interessant seria un sistema que detectara automàticament canvis sospitosos en els fitxers abans de propagar-los a la rèplica. Per exemple, si un fitxer canvia de tipus —tal com ho identificaria la ferramenta file—, podria ser un senyal de corrupció o de xifratge per ransomware: un document que de sobte passa a ser un binari opac, o un munt de fitxers que canvien de tipus alhora, és un patró anòmal. Detectar-ho permetria pausar la sincronització i avisar abans que el dany arribe a la còpia remota.

Proves de restauració

Una còpia de seguretat que no s’ha restaurat mai és només una hipòtesi. Per això seria saludable fer proves periòdiques de restauració, encara que siguen parcials.

Per exemple:

• restaurar un directori aleatori;
• verificar que GoCryptFS es pot muntar des d’una altra màquina;
• verificar que Borg pot restaurar arxius antics;
• documentar els passos de recuperació;
• confirmar que les claus necessàries estan disponibles.

26. Lliçons apreses

Una de les lliçons més importants del projecte és que muntar una alternativa pròpia a serveis de núvol no és gratis, encara que no es pague una quota mensual.

El cost no és només el disc. També cal tindre en compte:

• el preu dels discos grans;
• adaptadors USB-SATA compatibles i fiables;
• fonts d’alimentació;
• caixes, racks o suports físics;
• refrigeració;
• soroll;
• consum elèctric;
• temps d’administració;
• monitoratge;
• proves de restauració;
• gestió de claus;
• documentació;
• resposta davant d’incidents.

Per això, estar en contra de pagar per un servei de núvol només perquè “ho puc fer jo gratis” és una simplificació perillosa. La realitat és que fer-ho bé exigeix diners, temps i coneixement.

La conclusió no és que la núvol siga sempre millor. La conclusió és més matisada: la núvol comercial pot semblar cara fins que comptes tot el que implica operar tu mateix una infraestructura fiable.

En el nostre cas, Tocho té sentit perquè aprenem, controlem les dades, tenim capacitat tècnica i ens interessa el procés. Però no és una solució màgica ni gratuïta. És infraestructura real, encara que estiga feta a casa.

27. Direcció futura del projecte

La direcció natural de Tocho és evolucionar des d’un NAS replicat cap a un sistema híbrid:

• NAS per a fitxers grans i accés còmode;
• Borg per a còpies versionades;
• claus SSH restringides per màquina;
• append-only per reduir el risc de destrucció remota;
• poda controlada des del servidor;
• monitoratge diari realment accionable;
• separació entre dades vives i còpies històriques;
• serveis personals damunt dels fitxers, com una futura gestió pròpia de fotografies.

Aquesta evolució fa que el sistema siga més resistent no sols davant d’avaries físiques, sinó també davant d’errors humans, scripts defectuosos i atacs de ransomware.

28. Resum: passos per a muntar el teu propi Tocho

Si algú vol replicar una configuració semblant, aquests són els passos bàsics, en ordre aproximat:

29. Resum visual final

Figura 10

30. Conclusió

Tocho és un sistema domèstic d’emmagatzematge i còpia de seguretat distribuïda que combina NAS, rèplica remota, xifratge i còpies versionades.

El seu valor no està només en els terabytes disponibles. Està en el control: control sobre on són les dades, qui pot llegir-les, com es munten, com es copien, com es monitoren i com es restauren.

La seua evolució natural és reduir l’accés directe als fitxers crítics i augmentar el pes de repositoris append-only, més resistents a errors humans i ransomware.

En resum, Tocho és una infraestructura personal de sobirania tècnica: no perfecta, no gratuïta i no trivial, però comprensible, reparable i adaptada a la nostra manera real de treballar.