Într-o echipă mică, recuperarea după dezastru se rezumă de obicei la un singur rând dintr-un document pe care nu l-a deschis nimeni: backupurile sunt activate. Afirmația este adevărată și nu este un răspuns, pentru că nu spune nimic despre cât de vechi ar fi datele recuperate, cât durează o restaurare sau dacă a dus cineva vreodată una până la capăt.

În spațiul dintre a avea backupuri și a ști să restaurezi se transformă majoritatea întreruperilor în incidente. Un backup care există, care este la zi și care nu a fost niciodată restaurat rămâne o ipoteză, iar momentul în care o verifici este cel mai prost moment posibil pentru a descoperi că era greșită.

Două cifre transformă o opinie într-un plan. Câte date îți poți permite să pierzi și cât timp îți poți permite să stai oprit? Acestea sunt obiectivul tău de punct de recuperare și obiectivul tău de timp de recuperare. Până când nu le rostește cineva din zona de business, orice dispută tehnică despre frecvența backupurilor rămâne fără soluție, pentru că lipsește criteriul față de care se poate argumenta.

RPO și RTO pe înțelesul tuturor

Recovery point objective, adică RPO, este cantitatea de date pe care ți-o poți permite să o pierzi. Backupurile de noapte înseamnă un RPO de 24 de ore: o cădere la ora 17 duce cu ea tot ce s-a produs de la noaptea precedentă. Dacă acest lucru este inacceptabil, atunci programul de backup este greșit, iar oricâtă grijă ai avea în altă parte nu compensează.

Recovery time objective, adică RTO, este durata în care îți poți permite să stai oprit. Include tot: să observi, să decizi, să provizionezi, să restaurezi, să verifici și să comuți traficul înapoi. Echipele estimează pasul de restaurare și uită de celelalte cinci, exact de aceea recuperările reale durează de câteva ori mai mult decât se aștepta cineva.

Ambele sunt decizii de business și nu decizii tehnice, iar ambele costă bani pe măsură ce se strâng. Un RPO de cinci minute cere replicare continuă. Un RTO de o oră cere o infrastructură care se poate reconstrui automat, pentru că sub presiune nimeni nu configurează manual un server într-o oră.

Discuția productivă este despre compromis. Spune-i business-ului cât costă fiecare nivel și lasă-l să aleagă, în loc să fixezi o cifră în inginerie și să speri că se potrivește cu așteptări pe care nu le-a formulat nimeni.

Un backup netestat nu este un backup

Eșecurile care dor rar sunt absența backupurilor. Sunt backupurile care se dovedesc inutilizabile exact în momentul în care ai nevoie de ele.

Cauzele obișnuite, toate vizibile abia la restaurare: jobul eșuează în tăcere de săptămâni întregi pentru că nimeni nu urmărește succesul la fel de atent ca eșecul. Dumpul a capturat schema, dar nu și datele, sau doar un subset de tabele pe care cineva le-a trecut cândva pe o listă de excluderi. Fișierul este criptat cu o cheie păstrată chiar pe mașina care a murit. Backupul stă în același cont sau în aceeași regiune cu lucrul pe care ar trebui să îl protejeze.

Ultimul punct cântărește mai mult decât cântărea odinioară. Un backup aflat în același mediu cu producția este protejat împotriva defecțiunilor hardware și împotriva a nimic altceva. Nu supraviețuiește compromiterii contului, unei ștergeri accidentale la nivel de cont sau unui ransomware care ajunge la tot ce pot atinge aceleași credențiale.

Singura modalitate de a ști că un backup funcționează este să îl restaurezi. Pune-l în calendar, fă-o cel puțin trimestrial și cronometreaz-o. Cronometrul acela este RTO-ul tău real, spre deosebire de cel scris în document.

Ce trebuie să acopere recuperarea după dezastru

Datele sunt partea evidentă și rareori partea lentă. Ceea ce lungește recuperările sunt aproape întotdeauna lucrurile pe care nu le-a trecut nimeni pe listă.

Baza de date, de care își amintește toată lumea. Fișierele încărcate de utilizatori, care stau altundeva și de multe ori nu au niciun backup. Configurația și secretele, care există frecvent doar pe mașina aflată în funcțiune. DNS-ul și certificatele, care nu se recreează rapid dacă tocmai contul care le găzduiește este cel pierdut. Infrastructura în sine, adică serverele, rețelele și regulile, rapidă de reconstruit dacă este definită ca și cod și chinuitor de lentă dacă a fost făcută din clicuri.

Și cunoașterea felului în care se leagă totul, care într-o echipă mică este de departe cel mai important factor al timpului de recuperare. Un sistem pe care o singură persoană îl poate reconstrui din memorie are un timp de recuperare egal cu disponibilitatea acelei persoane, iar asta nu este un plan.

Scrie inventarul înainte de plan. Majoritatea echipelor descoperă, chiar în timp ce fac lista, cel puțin o componentă fără niciun backup, iar descoperirea pe această cale costă considerabil mai puțin decât alternativa.

Un plan care încape pe o pagină

Documentele lungi nu se citesc în timpul unui incident. Țintește ceva ce un om obosit poate urma la trei noaptea, fără să fie nevoit să gândească.

Trebuie să conțină: cine decide că recuperarea a început, pentru că ezitarea în privința întrebării dacă situația se califică drept dezastru este o sursă foarte frecventă de întârziere. Unde sunt backupurile și cum ajungi la ele, inclusiv credențiale care nu depind de sistemul căzut. Pașii de restaurare în ordine, suficient de exacți încât să fie urmați fără improvizație. Cum verifici că a funcționat, adică o verificare concretă și nu impresia că se încarcă site-ul. Și pe cine anunți, intern și extern.

Păstrează-l undeva unde supraviețuiește căderii. Un plan de recuperare stocat exclusiv în sistemul pe care ar trebui să îl recupereze este o greșeală recurentă și complet evitabilă.

Același raționament este valabil pentru accese. Dacă o singură persoană deține credențialele contului de găzduire, timpul tău de recuperare este limitat de faptul că răspunde sau nu la telefon. Ghidul nostru de securizare a serverului Linux acoperă controalele de acces de care depinde tot acest lucru.

Proporțional, nu perfect

O echipă mică nu are nevoie de un hot standby într-o a doua regiune. Costul este real, iar complexitatea aduce propriile ei moduri de eșec.

Ceea ce le trebuie majorității echipelor mici costă considerabil mai puțin: backupuri într-un cont separat, cu credențiale pe care producția nu le poate folosi, o restaurare testată și cronometrată după un calendar, o infrastructură definită ca și cod pentru a putea fi recreată fără arheologie și un plan de o pagină pe care l-a citit cineva.

Setul acesta acoperă defecțiunea hardware, ștergerea accidentală, compromiterea contului și ransomware-ul, adică mare parte din ce se întâmplă în realitate. Tot ce trece dincolo de el este o decizie despre cât valorează o reducere suplimentară a timpului de nefuncționare, iar aceasta este o întrebare pentru business și nu pentru inginerie.

Mecanik analizează și construiește exact asta ca parte a serviciului nostru de analiză securitate server . Prima întrebare este mereu aceeași și nu ține de tehnologie: cât timp poți sta oprit și cine a decis asta?

Articole similare: SLA-uri de uptime care înseamnă ceva , Securitatea lanțului de aprovizionare software pentru echipe mici , Agenți IA în afaceri: costuri și puncte de eșec și Dezvoltare software fintech în UK: FCA, rails și costuri .

Întrebări frecvente

Ce înseamnă RPO și RTO? Recovery point objective este cantitatea de date pe care ți-o poți permite să o pierzi, așa că backupurile de noapte implică un RPO de 24 de ore. Recovery time objective este durata în care îți poți permite să stai oprit, incluzând observarea, decizia, provizionarea, restaurarea, verificarea și comutarea traficului înapoi. Ambele sunt decizii de business și ambele costă mai mult pe măsură ce se strâng.

De ce un backup netestat nu este un backup? Pentru că modurile de eșec sunt vizibile abia la restaurare. Joburile eșuează în tăcere săptămâni întregi când nimeni nu urmărește succesul la fel ca eșecul, dumpurile capturează schema fără date sau omit tabelele excluse, cheile de criptare stau pe mașina care a murit, iar copiile se află în același cont cu lucrul pe care îl protejează. Restaurează trimestrial și cronometrează.

Unde ar trebui păstrate backupurile? Într-un cont sau într-o regiune separată, cu credențiale pe care producția nu le poate folosi. Un backup aflat în același mediu protejează împotriva defecțiunilor hardware și a nimic altceva: nu supraviețuiește compromiterii contului, unei ștergeri la nivel de cont sau unui ransomware care ajunge la tot ce pot atinge aceleași credențiale.

Ce uită oamenii să includă în recuperarea după dezastru? Fișierele încărcate și păstrate separat de baza de date, configurația și secretele care există doar pe mașina aflată în funcțiune, DNS-ul și certificatele ținute într-un cont care poate fi el însuși pierdut, infrastructura făcută din clicuri în loc să fie definită ca și cod și cunoașterea felului în care se leagă totul, atunci când o are o singură persoană.

Are nevoie o echipă mică de un hot standby? De regulă nu. Costul este real, iar complexitatea adăugată aduce propriile moduri de eșec. Backupurile într-un cont separat, o restaurare testată și cronometrată, o infrastructură definită ca și cod și un plan de o pagină pe care l-a citit cineva vor acoperi defecțiunea hardware, ștergerea accidentală, compromiterea contului și ransomware-ul, adică mare parte din ce se întâmplă.