O copie nerestaurată nu este o copie de siguranță

Toată lumea este de acord cu titlul. Tabloul de bord aproape al nimănui nu îl reflectă.

Motivul nu este lenea. Este că trei probe cu adevărat diferite sosesc prin aceeași conductă, se stochează în coloane alăturate și ajung să fie redate ca o singură bifă verde. Odată ce sunt o singură bifă, afirmația cea mai tare din grup împrumută în tăcere credibilitatea celei mai ieftine, iar un client citește „protejat” când ce s-a întâmplat de fapt a fost că o sarcină s-a încheiat cu zero.

Am petrecut o rundă separând acele trei lucruri în propria noastră schemă și o a doua rundă măsurând un Proxmox Backup Server real, ca să aflăm pe care dintre ele ni-l poate da cu adevărat. Iată unde am ajuns.

Trei dovezi, și nu sunt interschimbabile

Prima este cea mai ieftină și este cea pe care o arată orice produs. Valorează exact cât spune: un proces s-a terminat. Garanțiile din spatele fiecărui mod vzdump sunt despre ce putea și ce nu putea promite acel proces despre starea invitatului, iar niciuna dintre acele garanții nu supraviețuiește contactului ulterior cu un depozit de fragmente corupt.

A doua este o probă reală și este ușor de citit mai mult decât spune. Mai multe despre asta mai jos.

A treia este singura care răspunde la întrebarea pe care o pune de fapt un client și este singura care vă cere să construiți ceva, în loc să citiți ceva. Acea asimetrie este motivul pentru care de obicei lipsește.

Ce afirmă de fapt o verificare verde

Proxmox Backup Server poate verifica un instantaneu: recitește fragmentele și le compară cu manifestul. Când asta s-a întâmplat, listarea instantaneelor poartă un obiect verification cu o stare în el.

Este un lucru cu adevărat util de știut și este mai îngust decât pare. Spune că octeții de pe acel depozit de date sunt octeții care au fost scriși. Nu spune că mașina va porni. Nu spune că aplicația din ea va porni. Nu spune că baza de date era într-o stare consistentă în momentul instantaneului. Iar dacă copia este criptată de partea clientului, nu spune că mai are cineva cheia: o verificare de integritate pe text cifrat trece perfect și atunci când cheia a dispărut.

Așa că starea trăiește în propria ei coloană din schema noastră și este documentată în cod ca aparținând dovezii a doua, ca să nu fie niciodată amestecată cu „restaurare dovedită”. Dovada a treia își va primi propriul tabel în ziua în care o construiește cineva. Adăugarea unei a patra valori la un enum existent ar fi însemnat o jumătate de zi de lucru și o sursă permanentă de confuzie.

Un câmp lipsă nu este un eșec

Coloana noastră are trei valori: în regulă, eșuat și necunoscut. Cea din mijloc nu este cea interesantă.

Măsurat față de un Proxmox Backup Server 4.2 în funcțiune, cu instantanee reale pe el: un instantaneu care nu a trecut niciodată printr-o sarcină de verificare pur și simplu nu are cheia verification. Câmpul este absent. Acesta este alt lucru decât o verificare care a rulat și a eșuat, iar contopirea lor vă costă în ambele direcții. Puneți implicit „în regulă” și fiecare instantaneu neverificat devine unul verificat. Puneți implicit „eșuat” și fiecare instantaneu istoric din baza dumneavoastră de date ia dintr-odată foc. A treia valoare există ca să spună singurul lucru adevărat: nu se știe nimic.

O stocare Proxmox obișnuită nu completează deloc coloana, pentru că listarea ei de conținut nu poartă niciun concept de verificare. Aceea nu este o lipsă a integrării noastre. Acela este răspunsul.

Încă un detaliu cinstit, pentru că este genul care se rotunjește. Obiectul verification pe care l-am măsurat poartă o stare și un identificator de sarcină, și niciun moment de timp. Așadar, momentul „verificat la” pe care îl consemnăm este momentul în care noi am văzut prima dată acea stare, ceea ce este altă întrebare decât „când a verificat stocarea acest lucru”. El răspunde la „de când știm asta”. Dacă o versiune viitoare expune timpul real, coloana ar trebui să înceapă să îl poarte, iar comentariul care explică toate acestea ar trebui șters.

Gol trebuie să însemne gol

Iată cea mai ascuțită regulă din tot domeniul, iar ea nu are nimic de-a face cu verificarea.

Orice sistem care listează periodic puncte de restaurare ajunge să deducă ceva din absența unui instantaneu: era aici săptămâna trecută, nu este aici acum, deci a fost curățat sau șters. Acea deducție este portantă și este valabilă numai dacă o listare reușită și goală este cu adevărat goală.

Așa că am măsurat ce răspunde de fapt un server de copii când o listare merge prost, pentru că „un tablou gol” și „o eroare care arată ca un tablou gol” trebuie să fie de deosebit. Patru cazuri, toate măsurate față de aceeași instanță 4.2 în funcțiune:

• un spațiu de nume gol răspunde cu 200 și un tablou gol;
• un spațiu de nume care nu există răspunde cu 400 și o eroare de negăsit, nu cu o listă goală;
• un depozit de date pe care jetonul nu îl poate audita răspunde cu 403;
• un jeton greșit răspunde cu 401.

Trei dintre acele patru trebuie să devină erori specifice, nu rezultate. Dacă vreuneia dintre ele i se permite să ajungă la logica dumneavoastră de reconciliere ca „listarea a reușit și nu este nimic acolo”, atunci o singură greșeală de tastare într-un nume de spațiu de nume marchează drept dispărut întregul istoric de copii al unui client. Modul de eșec nu este o pană. Este un ecran care încetează în tăcere să mai pomenească faptul că există copii de siguranță.

Aceasta este aceeași clasă de capcană ca un hipervizor care răspunde cu 200 înainte ca lucrarea să înceapă: codul de răspuns este în regulă și nu este răspunsul la întrebarea dumneavoastră.

Datele de autentificare nu trebuie să poată strica nimic

Cea mai utilă decizie de securitate de aici este și cea mai plictisitoare.

Jetonul pe care îl creează un client pentru o țintă de copii de siguranță trebuie să citească instantanee și starea depozitului de date. Nu are nevoie să șteargă, să uite, să curețe sau să verifice. Acelea sunt operațiuni separate, care aparțin celui care deține stocarea, după propriul lui program, cu propria lui identitate.

Am construit integrarea fără nicio comandă de scriere, ceea ce face afirmația structurală în loc de aspirațională, și apoi am verificat-o din cealaltă parte: cu un jeton care are numai drepturi de audit, o ștergere pe un instantaneu răspunde cu 403. Aceasta este forma spre care să țintiți. O integrare numai-citire ale cărei date de autentificare pot curăța este o integrare numai-citire exact până când cineva scrie o buclă cu o eroare de o unitate în ea.

Există un corolar pe care furnizorii de găzduire îl greșesc în cealaltă direcție. Dacă platforma dumneavoastră șterge un server, întrebarea despre retenție este o decizie pe care trebuie să o ia clientul, nu o valoare implicită pe care o alege codul dumneavoastră. Înlăturarea singurei copii rămase a datelor cuiva ca efect secundar al ordonării unui rând este un lucru care li s-a întâmplat unor firme reale.

Ce trebuie să fie un test de restaurare, dacă îl construiți

Dovada a treia este locul unde se află munca și merită să scrieți constrângerile înainte de a scrie codul, pentru că cele mai multe dintre ele sunt despre a nu provoca un incident cu propriul dumneavoastră test.

Un test de restaurare are nevoie de un loc izolat în care să restaureze: o rețea fără rută către producție, identificatori temporari, adrese temporare, adrese hardware temporare. Niciodată adresa de producție și niciodată adresa hardware de producție, pentru că un duplicat într-o rețea vie este o pană pe care ați provocat-o chiar dumneavoastră în timp ce verificați că vă puteți reveni dintr-o pană. Are nevoie de cote stricte, pentru că restaurarea celei mai mari mașini dintr-o flotă într-un grup de test este un eveniment de capacitate. Are nevoie de un termen-limită și de o curățare garantată, fiindcă mașina va da uneori greș la pornire și tot trebuie ceva să o înlăture. Și are nevoie să nu trimită notificări, pentru că o alertă de monitorizare de la o copie de test care se dă drept sistemul real va trezi pe cineva.

Mai are nevoie și de o politică explicită de încheiere, iar aici își merită tot lucrul acesta numele. Pornit este un nivel. Accesibil este altul. Agentul de invitat răspunde este altul. Sistemele de fișiere montate este altul. O aplicație care răspunde la o verificare de sănătate definită de client este nivelul care se potrivește cu ce înțelege un client prin „recuperabil”. Alegeți unul, consemnați lângă rezultat pe care l-ați ales și nu lăsați niciodată un nivel mai jos să fie afișat cu eticheta unuia mai sus.

Abia atunci are voie un server să arate „restaurare dovedită”, iar afișarea trebuie să poarte data, punctul exact de restaurare, mediul în care a rulat, verificările trecute și cât timp se păstrează proba. Orice mai puțin și expresia este decorativă.

Ce am scrie

1. 01Numiți separat cele trei dovezi în schema dumneavoastră, înainte de a le avea pe toate trei. Ale noastre sunt coloane separate și un tabel care nu există încă, ceea ce se citește mai ușor decât o singură coloană cu un comentariu care își cere scuze.
2. 02Stocați „necunoscut” ca valoare adevărată. Orice valoare implicită care nu este „necunoscut” este o minciună despre cel puțin unul dintre rândurile dumneavoastră.
3. 03Puneți o listare goală să dovedească faptul că este goală și transformați orice alt răspuns într-o eroare distinctă înainte să ajungă la ceva care reconciliază.
4. 04Dați integrării date de autentificare care nu pot șterge și apoi verificați din exterior că nu pot.
5. 05Scrieți ce ar trebui să însemne „restaurare” pentru dumneavoastră, la ce nivel de încheiere, înainte ca cineva să pună o bifă verde lângă ea.

Starea noastră, spusă pe șleau: primele două dovezi sunt construite și măsurate, iar test de restaurare nu avem. Funcția de copii de siguranță stă în spatele unui comutator și nu este de vânzare. Aceasta este diferența dintre un plan și o afirmație și este aceeași diferență despre care este tot articolul.

Integrarea din spatele acestor măsurători a fost construită pentru Provibr. Întrebarea înrudită de sincronizare, ce se întâmplă când o copiere durează mai mult decât termenul pe care i l-ați dat, se află în un timeout nu este un buton de oprire; partea de containere a copiilor Proxmox se află în VM sau container pe Proxmox.