Tocho: suverena, ĉifrita persona stokado, replikita inter du lokoj

1. Enkonduko

Tocho estas persona projekto kiun prizorgas Ismael Ripoll kaj mi, Raúl, kun la celo disponi pri sistemo de amasa stokado, racie fidinda, ĉifrita kaj replikita inter du malsamaj fizikaj lokoj.

La komenca ideo estis simpla: ĉiu el ni havus po unu Raspberry Pi kun 16-TB-a SATA-malmola disko. Ĉiu disko servus por konservi la proprajn datumojn kaj, samtempe, ĉifritan kopion de la datumoj de la alia. Tiamaniere, ĉiu disponus pri ekstera repliko en alia hejmo.

Kun la tempo, la projekto evoluis. Ĝi jam ne estas nur “hejmfarita NAS kun fora kopio”, sed persona infrastrukturo kiu kombinas:

• amasan stokadon;
• krucajn kopiojn;
• ĉifradon;
• nativan aliron el Linukso;
• monitoradon;
• protekton kontraŭ paneoj;
• partan protekton kontraŭ elaĉetomalvaro (ransomware);
• versiitajn kopiojn per Borg;
• kaj klaran filozofion de teknika suvereneco.

Ĝi ne estas entreprena sistemo nek pretendas anstataŭigi profesian infrastrukturon. Sed ĝi ja provizas tre gravan plibonigon kompare al havi unusolan lokan kopion, aŭ eĉ pli malbone, al havi neniun sisteman kopistrategion.

2. Motivado

La ĉefa motivado estas tre praktika: la personaj datumoj okupas ĉiam pli da spaco kaj ne ĉiam bone akordiĝas kun la komercaj nubaj servoj. Fotoj, videoj, deponejoj, dokumentoj, diskbildoj, kopioj de maŝinoj, personaj projektoj kaj historiaj arkivoj povas facile atingi plurajn terabajtojn.

La komercaj servoj tre bone solvas multajn problemojn, sed ankaŭ trudas limigojn:

• ripetiĝanta monata kosto;
• dependo de provizanto;
• malegala integriĝo kun Linukso;
• manko de reala kontrolo super protokoloj kaj aŭtomatismoj;
• spaclimoj;
• ŝanĝiĝantaj politikoj;
• kaj, ofte, interfaco pensita pli por ĝeneralaj uzantoj ol por teknikaj fluoj.

Tocho naskiĝas el malsama ideo: se ni havas sufiĉan teknikan scion, ni povas konstrui propran infrastrukturon, kompreni ĝin, ripari ĝin kaj adapti ĝin al niaj bezonoj.

Tamen, unu el la lecionoj de la projekto estas ĝuste ke tio ne estas senpaga. Kvankam oni ne pagas monatan kotizon, oni devas pagi por diskoj, adaptiloj, elektroprovizo, malvarmigo, administra tempo, testoj, monitorado kaj prizorgado. La komerca nubo povas ŝajni multekosta ĝis vi enkalkulas ĉion kion implicas funkciigi mem racie fidindan infrastrukturon.

3. Celoj de la projekto

La ĉefaj celoj de Tocho estas:

1. Disponi pri multe da stokspaco je akceptebla kosto.
2. Konservi foran replikon de la gravaj datumoj.
3. Protekti la konfidencecon de la datumoj gastigitaj en la servilo de la alia.
4. Redukti la riskon de perdo pro paneoj, ŝteloj, incendioj aŭ aliaj lokaj incidentoj.
5. Uzi normajn ilojn de Linukso.
6. Permesi nativan aliron al la dosieroj, sen dependi de proprieta aplikaĵo.
7. Fari versiitajn kaj seripetigitajn kopiojn.
8. Redukti la riskon ke elaĉetomalvaro aŭ homa eraro detruu ĉiujn kopiojn.
9. Konservi la sistemon komprenebla kaj riparebla de la du administrantoj.

La filozofio estas ke la fidindeco ne dependas nur de la aĉeto de multekosta aparataro, sed de la kombino de bonaj praktikoj: replikoj, ĉifrado, monitorado, periodaj kontroloj, disigo de privilegioj kaj reala kapablo restaŭri.

4. Ĝenerala arkitekturo

Ĉiu partoprenanto havas similan instalaĵon:

• Raspberry Pi kiu funkcias kiel servilo;
• 16-TB-a SATA-malmola disko;
• USB-SATA-adaptilo kongrua kun grandaj diskoj;
• propra elektroprovizo por la disko;
• fizika ŝranko aŭ rako;
• ventolado;
• aliro per SSH kun publikaj ŝlosiloj;
• loka eksporto de dosieroj, en mia kazo ankaŭ per NFS;
• ĉifritaj spacoj;
• kaj planitaj taskoj de kopiado kaj kontrolado.

La koncepta skemo estas jena:

Figura 1

Ĉiu servilo havas duoblan funkcion:

• ĉefa servilo de lokaj datumoj;
• fora celo de la ĉifrita kopio de la alia.

5. Modelo de kruca repliko

La baza modelo de repliko estas intence simpla. La datumoj kopiiĝas periode, normale dum la nokto, per rsync.

En la kutima kazo:

1. La loka servilo enhavas la ĉefajn datumojn.
2. Antaŭ la kopiado, oni kontrolas la staton de la disko.
3. Se la disko ŝajnas esti en bona stato, oni komencas la sinkronigon.
4. La datumoj de la alia konserviĝas ĉifritaj.
5. La fizika posedanto de la fora servilo ne povas legi la realan enhavon.

Figura 2

Eblas ankaŭ devigi manan sinkronigon post la kopiado de multaj datumoj. Tio reduktas la riskofenestron inter la momento kiam nova datumo aperas en la loka servilo kaj la momento kiam ĝi estas replikita fore.

rsync permesas facile limigi la kapaciton de la konekto (--bwlimit), sed praktike ni ne faras tion: ĉiu nodo disponas pri 1 Gbps kaj la kopioj lanĉiĝas nokte, do ni neniam rimarkis perdon de rendimento, nek en la hejma reto nek en la konekto inter la du hejmoj. Se iam tio ŝanĝiĝus, aktivigi la limon estus bagatela.

6. RPO: kiom da datumoj ni povas perdi

En la nuna stato, la sistemo havas proksimuman RPO-on de unu tago por la datumoj kiuj sinkroniĝas nur dum la nokto.

RPO signifas Recovery Point Objective (celo de restaŭra punkto): la maksimuma periodo de datumoj kiun oni supozas eble perdota en katastrofo. Se la kopio fariĝas ĉiun nokton, la kutima maksimuma perdo estas tio kio modifiĝis ekde la lasta korekta kopio.

Praktike:

• se la nokta kopio bone funkciis, mi povas perdi maksimume la datumojn de la sama tago;
• se post la kopiado de multaj datumoj mi ekzekutas mane sinkronigon, mi reduktas tiun fenestron;
• se la kopio malsukcesas kaj mi ne rimarkas tion, la reala RPO malboniĝas.

Tio igas la monitoradon ne flanka detalo. Ne sufiĉas “havi kopiojn”: necesas scii ke la lastaj kopioj finiĝis korekte.

7. Ĉifrado per GoCryptFS

Esenca punkto de la projekto estas ke ĉiu partoprenanto gastigas datumojn de la alia, sed ne devas povi legi ilin.

Tial parto de la foraj datumoj konserviĝas ĉifrita per GoCryptFS. Tiu sistemo permesas havi ĉifritan reprezenton de la dosieroj sur la disko, dum la posedanto povas munti ilin travideble kiam li bezonas aliri ilin.

Tio alportas plurajn avantaĝojn:

• la disko povas esti forprenita, anstataŭigita aŭ detruita sen elmeti la datumojn;
• la fizika posedanto de la servilo ne povas inspekti la realan enhavon de la kopio de la alia;
• la kopio povas fariĝi per normaj iloj, ĉar fine kopiiĝas normalaj ĉifritaj dosieroj;
• la muntado povas fariĝi loke en la Raspberry Pi aŭ fore el alia komputilo.

Figura 3

Praktike, estas utile povi fari la muntadon el pli potenca komputilo. La Raspberry Pi estas efika maŝino, sed la ĉifrado povas ŝarĝi la procesoron. Se la procezo uzas malmultajn fadenojn aŭ la kopio estas intensa, delegi parton de la kriptografia laboro al pli potenca komputilo povas plibonigi la rendimenton.

8. NAS, sed ne nur NAS

Parto de Tocho funkcias kiel NAS: dosierservilo alirebla el la loka reto. En mia kazo, mi povas munti la dosierojn per NFS kaj labori kun ili nature el Linukso.

Tio estas tre komforta, sed ankaŭ enkondukas riskon: se mia komputilo havas plenan aliron al la dosiersistemo, eraro mia, difekta skripto aŭ elaĉetomalvaro povus modifi aŭ forviŝi datumojn rekte.

Tial gravas distingi du funkciojn:

1. Labora NAS, pensita por komforte aliri dosierojn.
2. Sekurkopia sistemo, pensita por konservi versiojn kaj rezisti erarojn aŭ atakojn.

NAS ne estas aŭtomate sekurkopio. Se ĝi estas konstante muntita kun skribpermesoj, ĝi apartenas al la sama risksurfaco kiel la komputilo.

9. Borg-kopioj: seripetigo, ĉifrado kaj versioj

Por plifortigi la kopian parton, mi komencis uzi BorgBackup. Borg estas sekurkopia ilo kun seripetigo, kunpremo kaj aŭtentikigita ĉifrado. Ĝi estas pensita por fari efikajn kopiojn, ĉar post la unua ĝi bezonas konservi nur la blokojn kiuj ŝanĝiĝis.

Tiu parto estas aparte grava ĉar ĝi enkondukas konceptan diferencon kompare al la klasika uzo de NAS.

Per NFS, mi laboras rekte sur videblaj dosieroj. Per Borg, la klientaj komputiloj kreas versiitajn kopioarkivojn ene de deponejo. Tio permesas konservi multajn versiojn sen lineare multobligi la uzitan spacon.

Borg alportas tri tre valorajn ecojn:

• ĉifradon;
• seripetigon;
• logikajn momentfotojn (snapshots).

Tio igas ĝin multe pli taŭga por historia kopio ol simpla repliko per rsync.

10. SSH-ŝlosiloj limigitaj laŭ komputilo

Ĉiu komputilo kiu faras kopiojn al la servilo havas propran SSH-ŝlosilon, kreitan specife por tiu funkcio.

Tiuj ŝlosiloj ne devus doni ĝeneralan aliron al la servilo, nek permesi malfermi interaktivan ŝelon, nek administri la sistemon. La ideo estas ke ĉiu ŝlosilo permesu nur ekzekuti la servon necesan por aldoni kopiojn al la respektiva Borg-deponejo.

Borg subtenas la uzon de borg serve kun devigitaj ordonoj per SSH, kio estas ĝuste la taŭga modelo por tiu tipo de agordo.

Konkrete, tio atingiĝas limigante ĉiun ŝlosilon al difinita ordono ene de la dosiero authorized_keys. Se oni antaŭmetas command="<rajtigita ordono>" antaŭ la publika ŝlosilo, la servilo nur ekzekutos tiun ordonon kiam iu konektiĝas per la ŝlosilo, eĉ se la kliento provas lanĉi alian. Tiamaniere, ŝlosilo pensita por fari kopiojn ne povas malfermi interaktivan ŝelon, trairi la dosiersistemon nek forviŝi datumojn arbitre. Ĝi estas ŝlosila ero por redukti la riskon de elaĉetomalvaro kaj aliaj atakscenaroj.

La skemo estas proksimume jena:

Figura 4

Tio multe reduktas la riskon en kazo ke tekokomputilo, komputilo aŭ alia klienta maŝino estas kompromitita. Se atakanto akiras la ŝlosilon de tiu maŝino, li ne devus povi libere eniri la servilon nek forviŝi ion ajn.

11. Append-only-reĝimo kaj defendo kontraŭ elaĉetomalvaro

Unu el la lastatempaj motivadoj de la projekto estas plibonigi la protekton kontraŭ elaĉetomalvaro.

La problemo de tradicia NAS estas ke, se la dosieroj estas muntitaj kun skribpermesoj el la ĉefa komputilo, elaĉetomalvaro povus ĉifri aŭ detrui ankaŭ la datumojn de la NAS. En tiu kazo, la NAS ĉesus esti reala sekurkopio kaj fariĝus vundebla etendo de la sama komputilo.

Por redukti tiun riskon, la Borg-deponejoj povas esti agorditaj en append-only-reĝimo (nuraldona). La dokumentado de Borg klarigas ke tiu reĝimo estas utila kiam klienta maŝino faras forajn kopiojn al servilo per borg serve, ĉar kompromitita klienta maŝino ne povas permanente elimini la kopiojn de la servilo.

La disigo estas ŝlosila:

• la klientoj povas aldoni kopiojn;
• la klientoj ne devus povi detrui la historion;
• la pritranĉo de malnovaj versioj devas esti aparta operacio;
• atako el klienta komputilo ne devus povi elimini ĉiujn bonajn kopiojn.

Tio ne forigas ĉiujn riskojn. Atakanto povus aldoni malbonajn aŭ ĉifritajn kopiojn, kaj necesus detekti la problemon antaŭ ol fari detruan pritranĉon. Sed ĝi estas tre grava plibonigo kompare al havi NFS-dosierujon konstante muntitan kun plena aliro.

12. Disigo inter vivantaj datumoj kaj sekurkopioj

Estonta ideo estas redukti la uzon de la servilo kiel deponejon de rekte manipuleblaj dosieroj kaj konverti ĝin ĉiam pli en deponejon de Borg-kopioj.

Tio implicas distingi inter:

1. Vivantaj datumoj, kiujn oni povas malfermi, redakti, movi aŭ forviŝi el la normala komputilo.
2. Sekurkopioj, kiuj nur aldoniĝas al la deponejo kaj ne estas rekte modifeblaj de la kutima uzantokonto.

Tiu disigo estas tre sana. La vivantaj datumoj povas esti en lokaj diskoj, ekzemple en 4-TB-a disko aŭ en interna 2-TB-a disko. La Tocho-servilo, male, povas dediĉiĝi precipe al la konservado de ĉifritaj kaj seripetigitaj Borg-versioj.

La celo estas pasi de tiu modelo:

Figura 5

al tiu alia:

Figura 6

Se la normala konto de la uzanto faras eraron, ekzekutas tro vastan rm aŭ estas kompromitita, ĝi ne devus havi rektan aliron por detrui ĉiujn historiajn kopiojn.

13. Kreskaj kopioj kaj parta sinkronigo

Malferma demando estas ĉu eblas fari kreskajn kopiojn sen devi trairi la tutan dosierarbon ĉiufoje.

Per rsync, la normala modelo estas kompari fonton kaj celon por decidi kio ŝanĝiĝis. Tio estas fortika, sed povas esti multekosta se estas tre multaj dosieroj.

Ekzistas pluraj eblaj strategioj:

• lanĉi manajn sinkronigojn de konkretaj dosierujoj post gravaj ŝanĝoj;
• fari Borg-kopiojn de la vere gravaj datumaroj;
• uzi listojn de lastatempe modifitaj dosieroj per find, kvankam tio estas pli fragila;
• pli bone disigi la datumojn laŭ ŝanĝfrekvenco: malvarmaj arkivoj, aktivaj datumoj kaj kritikaj kopioj;
• konsideri sistemojn kun nativaj momentfotoj se estonte oni uzas Btrfs aŭ ZFS.

Ĝenerale, por versiita sekurkopio, Borg estas pli taŭga ol simpla repliko per rsync. Por repliko de navigebla dosierarbo, rsync daŭre estas tre simpla kaj praktika.

14. Nativa aliro el Linukso kaj suvereneco super la dosieroj

Unu el la plej gravaj avantaĝoj de Tocho estas ke ĝi permesas al mi labori kun miaj dosieroj native en Linukso.

Malsame al kelkaj komercaj nubaj servoj, la sistemo ne devigas min trapasi retan interfacon, proprietan aplikaĵon aŭ fremdan integrigan tavolon. Mi povas munti dosiersistemojn per normaj iloj, aliri ilin per NFS, SSHFS, GoCryptFS aŭ Borg, aŭtomatigi taskojn per skriptoj kaj decidi ekzakte kiel mi volas organizi la datumojn.

Tio havas grandegan praktikan valoron. Por uzanto de Linukso, la dosiersistemo ne estas nur loko kie lasi dokumentojn: ĝi estas universala interfaco. La samaj iloj kiujn mi uzas por programi, indeksi, serĉi, kompari, versii aŭ transformi datumojn povas operacii rekte sur miaj dosieroj.

Google Drive estas bona kontraŭekzemplo. Malgraŭ esti tre populara servo, Google ne ofertas kompletan oficialan klienton de Google Drive por Linukso. Fakte, ekzistas paĝo prizorgata de la komunumo, How long since Google said a Google Drive Linux client is coming?, kiu kalkulas la tempon pasintan ekde la 24-a de aprilo 2012, kiam Google sugestis ke alvenos subteno por Linukso per la mesaĝo “hang tight”.

Tiu manko devigas la uzantojn de Linukso dependi de neoficialaj iloj aŭ de partaj solvoj. Iuj funkcias tre bone, kiel rclone, sed ili ja restas alternativaj tavoloj ĉirkaŭ servo kiu ne estas pensita ĉefe por mia laborfluo.

Per Tocho, male, la situacio estas la kontraŭa: mi kontrolas la servilon, la protokolon, la dosiersistemon, la ĉifradon, la permesojn kaj la aŭtomatismojn. Mi ne dependas de tio ke entrepreno decidu ĉu Linukso meritas aŭ ne unuaklasan integriĝon.

Tio estas konkreta formo de teknika suvereneco: ne nur posedi la datumojn, sed povi decidi kiel oni aliras ilin.

15. Tio kion ni ankoraŭ ne havas: nativa administrado de fotoj

Tamen, tiu suvereneco ankoraŭ ne estas kompleta en ĉiuj kampoj.

Pendanta punkto estas la administrado de fotoj. La komercaj servoj tre bone solvis la parton de uzantsperto: aŭtomata alŝuto el la poŝtelefono, kunhavataj albumoj, etbildoj, templinio, rekono de duplikatoj, simpla kunhavigo kaj komforta aliro el iu ajn aparato.

Tocho ankoraŭ ne ofertas propran alternativon al tio. Ĝi povas konservi fotojn kiel dosierojn, kompreneble, sed ĝi ankoraŭ ne provizas sperton kompareblan al Google Photos, iCloud Photos aŭ similaj servoj.

Interesa estonta paŝo estus disfaldi propran solvon por fotografio, kapablan:

• ricevi aŭtomatajn kopiojn el la poŝtelefono;
• generi etbildojn;
• organizi albumojn;
• kunhavigi fotojn kaj albumojn facile kun amikoj kaj familianoj, kontrolite;
• konservi la bildojn ene de la propra infrastrukturo;
• integriĝi kun la jam ekzistanta sistemo de kopioj kaj replikoj.

Tiu parto estus natura evoluo de la projekto: pasi de “mi havas la dosierojn konservitaj” al “mi havas ankaŭ personajn servojn super miaj dosieroj”.

16. Uzata aparataro

Ĉiu instalaĵo konsistas proksimume el:

• Raspberry Pi;
• 16-TB-a SATA-malmola disko;
• USB-SATA-adaptilo kongrua kun grandaj diskoj;
• elektroprovizilo taŭga por la disko;
• kesto, rako aŭ fizika subteno;
• aldona ventolado;
• hejma retkonekto kun fibro.

Grava detalo estas ke ne ĉiuj USB-SATA-adaptiloj funkcias korekte kun grandkapacitaj diskoj. En kelkaj kazoj povas esti limigoj de la blato, de la mikroprogramaro, de la tipo de USB-SATA-ponto, de la UASP-subteno, de la administrado de grandaj sektoroj aŭ simple kongruecaj problemoj kun modernaj plurterabajtaj diskoj.

Tial necesis elekti pli fidindan adaptilon, eĉ se ĝi estis pli multekosta.

17. Malvarmigo, bruo kaj fizika stabileco

La temperaturo de la disko estas grava faktoro por la longvivo kaj la stabileco de la sistemo.

En mia kazo, la disko estas muntita ene de metala strukturo pensita por pluraj diskoj, kvankam nuntempe mi uzas nur unu. Tio provizas pli da metala maso kaj, tial, pli da disipa kapablo.

Krome, la rako disponas pri ventolilo kontrolata per PWM el la Raspberry Pi. Tio permesas alĝustigi la rapidon de la ventolilo, redukti la bruon kaj teni la diskon je racia temperaturo.

Figura 7

La celo ne estas agreseme malvarmigi, sed eviti ke la disko laboru varma dum multaj horoj. Disko kiu restas tepida kaj stabila estas preferinda al disko submetita al termikaj pintoj aŭ al manka ventolado.

18. La kazo de la ventolilo: kiam la “plug and play” ne estas tia

Alia leciono de la projekto estas ke la hejma aparataro malofte estas tiel “plug and play” kiel ĝi promesas.

En mia kazo, mi aĉetis ŝrankon aŭ rakon kiu teorie jam venis preta, kun ventolilo inkluzivita. La ideo estis simpla: munti la diskon, konekti ĉion kaj lasi la sistemon funkcii.

Sed la ventolilo kiu venis serie havis klare difektan konduton: tio kio varmiĝis estis la ventolilo mem, ne la disko kiun ĝi devis malvarmigi. Senŝarĝe, sen reala ŝarĝo kiu pravigus tion, la ventolilo atingis proksimume 70 °C en kelkaj sekundoj. Tio estas, ne estis la disko kiu estis je 70 °C, sed la ventolilo mem, kio estis nek akceptebla nek sekura.

Profitante ke necesis anstataŭigi ĝin, mi ŝanĝis la originan ventolilon, de proksimume unu centimetro da dikeco, per alia de du centimetroj. La pli dikaj ventoliloj povas movi aeron kun malpli da peno kaj, ĝenerale, povas esti pli silentaj por sama debito. Tio gravis ĉar la servilo estas instalita en la salono, kie la bruo estas reala faktoro.

La ŝanĝo ankaŭ ne estis tuja. Mi devis uzi la 3D-presilon por fabriki cilindrojn aŭ adaptajn distancigilojn kiuj permesis korekte munti la novan ventolilon en la ekzistanta ŝranko.

Tiu epizodo tre bone resumas la karakteron de la projekto: sur la papero, ĝi ŝajnas nur “Raspberry Pi kun disko”. Praktike, aperas multaj etaj sed gravaj detaloj:

• kongrueco de la USB-SATA-adaptilo;
• elektroprovizo de la disko;
• temperaturo;
• bruo;
• vibradoj;
• fizika muntado;
• aerfluo;
• adaptitaj pecoj;
• PWM-kontrolo;
• loko ene de la hejmo.

Ĉiu detalo povas ŝajni malgrava, sed ĉiuj kune apartigas improvizitan muntaĵon de racie fidinda sistemo.

19. Monitorado kaj kontroloj

La sistemo enhavas plurajn periodajn kontrolojn.

Antaŭ ol komenci gravan kopion, oni konsultas la staton de la disko per smartctl. Se la disko raportas problemecan aŭ antaŭpanean staton, la kopio povas esti preterlasita por eviti skribi sur eble difektitan subtenon aŭ pliakrigi delikatan situacion.

Krome, estas hora kontrolo kiu konfirmas ke la maŝino estas alirebla kaj ke la disko daŭre estas muntita aŭ disponebla. Tiu kontrolo konsultas ankaŭ la liberan spacon per df.

Unufoje tage, ĉirkaŭ la 7-a matene, oni sendas mesaĝon per Telegram kun la ĝenerala stato. Tiamaniere, la gravaj problemoj ne restas silentaj dum semajnoj.

Ĝis nun, Telegram neniam fiaskis al ni. Krome, ĉi tiu ĉiutaga mesaĝo funkcias kiel ia mortintula ŝaltilo: ni rigardas ĝin ĉiun matenon je la 7-a, do se iun tagon ĝi ne alvenus, la foresto mem estus la alarmo kaj ni tuj maltrankviliĝus.

Figura 8

Punkto kiun necesas plifortigi estas la kutima revizio de la stato de la kopioj. Ne sufiĉas generi protokolojn: necesas ke la fina stato estu videbla.

Klara plibonigo estus enkonduki en la ĉiutagan Telegram-mesaĝon informojn kiel jenajn:

• lasta korekta kopio de ĉiu maŝino;
• daŭro de ĉiu kopio;
• kvanto de aldonitaj datumoj;
• nombro de prilaboritaj dosieroj;
• stato de la Borg-deponejo;
• rezulto de la lasta borg check, se ĝi estas ekzekutata periode;
• restanta libera spaco;
• SMART-stato kaj temperaturo de la disko;
• la horan diferencon inter la nodoj (ĉiuj agordas sian horloĝon per NTP, sed kontroli ĝin periode helpas detekti horloĝajn problemojn);
• eksplicita averto se kopio jam pasigis pli ol X tagojn sen kompletiĝi.

Tio konvertus la monitoradon en realan fidoinstrumenton, ne nur en supraĵan kontrolon de disponebleco.

20. Administrado de la diskripozo

La malmolaj diskoj povas endormiĝi post mallonga periodo de neaktiveco. Tio reduktas konsumon, bruon kaj mekanikan eluzon, sed ankaŭ enkondukas streĉon inter du celoj:

• ne veki la diskon senbezone;
• detekti problemojn sufiĉe rapide.

Tial konvenas grupigi pezajn operaciojn en konkretajn horfaskojn, precipe la noktajn kopiojn. Necesas ankaŭ eviti tro entrudemajn kontrolojn ĉiun horon se tio devigas la diskon konstante turniĝi.

La praktika regulo estas ke la oftaj kontroloj devus esti malpezaj, kaj la operacioj kiuj klare vekas la diskon devus esti pravigitaj.

21. Git-deponejoj ĉifritaj per git-crypt

En la kazo de Ismael, alia interesa linio estis la uzo de Git-deponejoj kun enhavo ĉifrita per git-crypt.

git-crypt estas ilo kiu permesas travideble ĉifri difinitajn dosierojn ene de Git-deponejo. La dosieroj agorditaj kiel sentemaj konserviĝas ĉifritaj en la deponejo, sed la rajtigitaj uzantoj vidas ilin malĉifritaj en sia laborarbo. La oficiala priskribo de la projekto estas ĝuste “transparent file encryption in git”.

Tio estas utila kiam oni volas konservi normalan Git-deponejon, sed sen elmeti sekretojn, privatajn agordojn, ŝlosilojn, personajn datumojn aŭ dosierojn kiuj ne devus esti en klara teksto.

Figura 9

Tio bone akordiĝas kun la ĝenerala filozofio de Tocho: ne fidi nur la perimetron de la sistemo, sed ĉifri ankaŭ la datumojn laŭ ilia konkreta uzo.

Alivorte, ekzistas pluraj protektotavoloj:

• GoCryptFS por ĉifritaj dosierarboj;
• Borg por versiitaj, seripetigitaj kaj ĉifritaj kopioj;
• git-crypt por sekretoj aŭ sentemaj dosieroj ene de Git-deponejoj;
• SSH kun limigitaj ŝlosiloj por limigi kion povas fari ĉiu maŝino;
• disigo inter vivantaj datumoj kaj historiaj kopioj.

La komuna modelo estas klara: ĉiu ilo protektas malsaman parton de la problemo.

22. Kovritaj riskoj

Tocho sufiĉe bone kovras plurajn riskoscenarojn.

Paneo de disko

Se disko paneas, ankoraŭ ekzistas repliko en la alia loko. En tiu kazo, necesas aĉeti novan diskon kaj rekonstrui la kopion.

Ŝtelo

Se oni ŝtelas unu el la aparatoj, la datumoj de la alia daŭre estas en alia hejmo. Krome, la datumoj gastigitaj en la ŝtelita disko estas ĉifritaj.

Incendio aŭ loka fizika damaĝo

Katastrofo kiu trafas unusolan lokon ne devus detrui ĉiujn kopiojn.

Parta homa eraro

Se oni hazarde forviŝas ion kaj la kopio ankoraŭ ne sinkroniĝis, eble eblas restaŭri ĝin el la antaŭa repliko. Tamen, tiu protekto estas limigita se la forviŝo aŭ korupto jam disvastiĝis per rsync.

Kompromito de klienta maŝino

Per Borg append-only kaj limigitaj SSH-ŝlosiloj, kompromitita klienta maŝino ne devus povi permanente elimini ĉiujn historiajn kopiojn.

23. Ne tute solvitaj riskoj

La nuna sistemo ankoraŭ havas gravajn malfortajn punktojn.

Silenta korupto

Se dosiero koruptiĝas kaj poste replikiĝas, la fora kopio povas fini enhavanta ankaŭ la koruptan version. rsync ne estas, per si mem, sistemo de historia kontrolo de la integreco.

Elaĉetomalvaro sur vivantaj datumoj

Se klienta maŝino amase ĉifras aŭ modifas la videblajn dosierojn, kaj poste oni ekzekutas sinkronigon, la damaĝo povas disvastiĝi al la repliko.

Parta manko de historio

Simpla repliko protektas kontraŭ la perdo de disko, sed ne ĉiam kontraŭ logikaj eraroj. Por tio necesas momentfotoj, malnovaj versioj aŭ neŝanĝeblaj kopioj dum periodo.

Vundeblofenestro

Inter loka modifo kaj la fora kopio estas tempa fenestro en kiu la novaj datumoj ankoraŭ ekzistas nur en unu loko.

Malrapida rekonstruo

En kazo de perdo de kompleta disko, rekonstrui 16 TB povas esti malrapida. Je 100 MB/s daŭre, kopii 16 TB daŭras proksimume 44 horojn. Praktike, ĝi povas esti pli, ĉar la reala rendimento dependas de la disko, de la reto, de la ĉifrado, de la protokolo kaj de la kvanto de dosieroj.

Tial, en kompleta rekonstruo povas esti pli racie porti fizike la diskon al la alia hejmo kaj fari la unuan kopion loke aŭ per rapida loka reto.

24. Restaŭro post katastrofo

En kazo de kompleta paneo de disko, la ĝenerala procedo estus:

1. Detekti la paneon per SMART, EN/EL-eraroj aŭ manko de la disko.
2. Marki la trafitan nodon kiel nefidindan.
3. Halti la aŭtomatajn sinkronigojn al tiu disko.
4. Aĉeti aŭ instali novan diskon.
5. Pravalorizi la dosiersistemon.
6. Restaŭri la kopion el la alia servilo.
7. Kontroli integrecon kaj muntadon de la ĉifrita sistemo.
8. Reaktivigi la noktajn kopiojn.

Dum la rekonstruo, la sistemo restas en pli delikata momento, ĉar provizore povas esti unusola kompleta kopio. Tial necesas minimumigi la rekonstrutempon kaj eviti riskajn operaciojn ĝis la redundo estas restaŭrita.

25. Eblaj plibonigoj

La projekto jam estas utila en sia nuna formo, sed ekzistas pluraj eblaj plibonigoj.

Persista stato de “suspektinda disko”

Se smartctl detektas antaŭpanean situacion, ne sufiĉas preterlasi konkretan kopion. Estus konvene lasi la diskon en persista stato de “blokita”, “suspektinda” aŭ “bezonas manan intervenon”.

Tio evitus ke posta ekzekuto denove provu kopii aŭtomate ĝis iu revizias la problemon.

Periodaj aktivaj SMART-testoj

Nuntempe oni nur legas la SMART-atributojn antaŭ ĉiu kopio, sed oni ne lanĉas aktivajn testojn. Estus bona ideo plani longan teston (smartctl -t long) unufoje monate: ĝi trairas la tutan surfacon de la disko kaj povas detekti difektajn sektorojn antaŭ ol ili kaŭzas problemojn. Ĉar ĝi estas malrapida operacio kiu tenas la diskon vekita, konvenas lanĉi ĝin en nokta tempofasko kaj registri la rezulton en la ĉiutaga averto.

Momentfotoj aŭ versioj

Por pli bone protekti kontraŭ elaĉetomalvaro, hazardaj forviŝoj aŭ logika korupto, estus interese aldoni iun mekanismon de versioj.

Iuj opcioj estus:

• momentfotoj per Btrfs aŭ ZFS;
• kopioj per rsnapshot;
• deponejoj de BorgBackup aŭ Restic;
• malmolaj ligiloj kun strategioj de tipo rsync --link-dest;
• retenado de ĉiutagaj, ĉiusemajnaj kaj ĉiumonataj versioj.

Kontrolo de integreco

Estus ankaŭ utile disponi pri katalogo de haŝoj aŭ pri sistemo de perioda kontrolo kiu permesu detekti silentan korupton.

La defio estas fari tion sen konstante veki la diskon nek konverti la kontrolon en tro multekostan taskon.

Detekto de suspektindaj ŝanĝoj

Alia interesa ideo estus sistemo kiu aŭtomate detektus suspektindajn ŝanĝojn en la dosieroj antaŭ ol propagi ilin al la repliko. Ekzemple, se dosiero ŝanĝas tipon —kiel identigus ĝin la ilo file—, tio povus esti signo de korupto aŭ de ĉifrado per ransomware: dokumento kiu subite fariĝas opaka binaro, aŭ amaso da dosieroj kiuj ŝanĝas tipon samtempe, estas nenormala ŝablono. Detekti tion ebligus paŭzigi la sinkronigon kaj averti antaŭ ol la damaĝo atingas la foran kopion.

Restaŭrtestoj

Sekurkopio kiu neniam estis restaŭrita estas nur hipotezo. Tial estus sane fari periodajn restaŭrtestojn, eĉ se ili estas partaj.

Ekzemple:

• restaŭri hazardan dosierujon;
• kontroli ke GoCryptFS munteblas el alia maŝino;
• kontroli ke Borg povas restaŭri malnovajn arkivojn;
• dokumenti la restaŭrpaŝojn;
• konfirmi ke la necesaj ŝlosiloj estas disponeblaj.

26. Lernitaj lecionoj

Unu el la plej gravaj lecionoj de la projekto estas ke konstrui propran alternativon al nubaj servoj ne estas senpaga, eĉ se oni ne pagas monatan kotizon.

La kosto ne estas nur la disko. Necesas ankaŭ konsideri:

• la prezon de la grandaj diskoj;
• kongruajn kaj fidindajn USB-SATA-adaptilojn;
• elektroprovizilojn;
• kestojn, rakojn aŭ fizikajn subtenojn;
• malvarmigon;
• bruon;
• elektran konsumon;
• administran tempon;
• monitoradon;
• restaŭrtestojn;
• administradon de ŝlosiloj;
• dokumentadon;
• respondon al incidentoj.

Tial, esti kontraŭ pagi por nuba servo nur ĉar “mi povas fari ĝin mem senpage” estas danĝera simpligo. La realo estas ke fari ĝin bone postulas monon, tempon kaj scion.

La konkludo ne estas ke la nubo estas ĉiam pli bona. La konkludo estas pli nuancita: la komerca nubo povas ŝajni multekosta ĝis vi enkalkulas ĉion kion implicas funkciigi mem fidindan infrastrukturon.

En nia kazo, Tocho havas sencon ĉar ni lernas, ni kontrolas la datumojn, ni havas teknikan kapablon kaj la procezo interesas nin. Sed ĝi ne estas magia nek senpaga solvo. Ĝi estas reala infrastrukturo, eĉ se ĝi estas hejmfarita.

27. Estonta direkto de la projekto

La natura direkto de Tocho estas evolui de replikita NAS al hibrida sistemo:

• NAS por grandaj dosieroj kaj komforta aliro;
• Borg por versiitaj kopioj;
• SSH-ŝlosiloj limigitaj laŭ maŝino;
• append-only por redukti la riskon de fora detruo;
• kontrolata pritranĉo el la servilo;
• vere agebla ĉiutaga monitorado;
• disigo inter vivantaj datumoj kaj historiaj kopioj;
• personaj servoj super la dosieroj, kiel estonta propra administrado de fotoj.

Tiu evoluo igas la sistemon pli rezista ne nur kontraŭ fizikaj paneoj, sed ankaŭ kontraŭ homaj eraroj, difektaj skriptoj kaj elaĉetomalvaraj atakoj.

28. Resumo: paŝoj por konstrui vian propran Tocho

Se iu volas reprodukti similan agordon, jen la bazaj paŝoj, en proksimuma ordo:

29. Fina vida resumo

Figura 10

30. Konkludo

Tocho estas hejma sistemo de stokado kaj distribuita sekurkopio kiu kombinas NAS, foran replikon, ĉifradon kaj versiitajn kopiojn.

Ĝia valoro ne estas nur en la disponeblaj terabajtoj. Ĝi estas en la kontrolo: kontrolo super kie estas la datumoj, kiu povas legi ilin, kiel ili muntiĝas, kiel ili kopiiĝas, kiel ili monitoriĝas kaj kiel ili restaŭriĝas.

Ĝia natura evoluo estas redukti la rektan aliron al la kritikaj dosieroj kaj pliigi la pezon de append-only-deponejoj, pli rezistaj kontraŭ homaj eraroj kaj elaĉetomalvaro.

Resume, Tocho estas persona infrastrukturo de teknika suvereneco: ne perfekta, ne senpaga kaj ne triviala, sed komprenebla, riparebla kaj adaptita al nia reala maniero labori.