Un plan de backup pentru serverul dumneavoastră

Modulul 8: Backupuri și monitorizare · Timp de citire: 11 minute

Obiectivul lecției: După această lecție veți putea face un plan de backup pentru propriul server: ce păstrați, unde, cât de des și cât timp, și cum vă asigurați că restaurarea funcționează.

Noțiuni cheie: regula 3-2-1, snapshot, backupul furnizorului, backup propriu în afara furnizorului, RPO, RTO, dump de bază de date (mariadb-dump, pg_dump), configurația din /etc, volume Docker, criptare, ransomware, append-only, test de restaurare

De ce un plan, și nu "doar există un backup"?

Aproape oricine a pierdut un server a crezut că există un backup. Apoi se dovedește că acesta conține doar sistemul de operare și nu baza de date, sau că se află pe același server care acum a dispărut, sau că a fost criptat de același ransomware, sau că nimeni nu știe parola. Un backup are valoare abia atunci când îl puteți restaura. De aceea începeți cu un plan și terminați cu un test.

Un plan răspunde la cinci întrebări:

1. Ce trebuie să poată fi restaurat?
2. Câte date vă permiteți să pierdeți? (RPO)
3. Cât de repede trebuie să funcționeze din nou? (RTO)
4. Unde se află copiile și câte sunt?
5. Cum știți că funcționează?

Ce trebuie să poată fi restaurat?

Un server este alcătuit din straturi. Nu fiecare strat trebuie inclus în backup:

Acordați o atenție deosebită bazelor de date. O bază de date care rulează scrie în permanență. Dacă copiați fișierele unui MariaDB sau PostgreSQL care rulează, puteți obține o copie deteriorată. De aceea faceți mai întâi un dump: o imagine consistentă la un moment dat, sub formă de fișier, pe care o includeți apoi în backup.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump se numea înainte mysqldump; de obicei și această comandă funcționează încă.) Dacă baza de date rulează într-un container, procedați la fel cu docker compose exec (lecția 9.4).

RPO și RTO: cât vă permiteți să pierdeți?

Două noțiuni din practica profesională vă ajută să faceți alegeri:

• RPO (recovery point objective): cât timp de date vă permiteți să pierdeți cel mult? Un backup zilnic la ora 03:00 înseamnă: dacă serverul cade la ora 22:00, ați pierdut aproape o zi. Pentru un magazin online cu comenzi este prea mult; pentru un blog care se schimbă o dată pe săptămână este în regulă.
• RTO (recovery time objective): cât timp poate dura până când totul funcționează din nou? Restaurarea unui backup complet al furnizorului poate dura câteva minute; construirea unui server nou și restaurarea manuală a tuturor datelor poate dura ore.

Notați-le pentru propriul server. Ele determină cât de des faceți un backup și cum îl păstrați.

Snapshot, backupul furnizorului, backup propriu

Pe un VPS aveți de obicei trei tipuri de plasă de siguranță. Seamănă între ele, dar vă protejează împotriva unor lucruri diferite.

1. Snapshotul. O imagine la un moment dat a întregului disc virtual, făcută în panoul furnizorului dumneavoastră. Se creează repede și se restaurează repede. Ideal chiar înainte de un upgrade (lecția 4.3). Dar: la majoritatea furnizorilor, un snapshot se află pe același spațiu de stocare ca serverul dumneavoastră. Dacă acel spațiu de stocare se defectează sau vă pierdeți contul, dispare și snapshotul. Iar un snapshot nu se păstrează mult timp: crește odată cu toate modificările ulterioare. Un snapshot nu este un backup.

2. Backupul furnizorului. Mulți furnizori fac (eventual ca opțiune) automat în fiecare zi o copie a întregului server, pe alt spațiu de stocare. La WebOké, de exemplu, acesta este un backup zilnic al întregului VPS, păstrat timp de șapte zile; la alți furnizori funcționează similar, cu propriile termene. Este un al doilea strat bun împotriva hardware-ului defect și a propriilor greșeli de ieri. Dar rămâne o singură parte: contul dumneavoastră, plata dumneavoastră, pana lor. Iar restaurarea se face de obicei pentru întregul server deodată.

3. Backupul dumneavoastră propriu, în afara furnizorului. O copie a datelor dumneavoastră la o altă parte sau într-un alt loc, pe care o faceți și o administrați dumneavoastră (lecția 8.2). Acesta este stratul care rămâne atunci când tot restul eșuează.

Regula 3-2-1

O regulă empirică uzuală:

• 3 copii ale datelor dumneavoastră (originalul plus două backupuri);
• pe 2 tipuri diferite de stocare sau sisteme;
• dintre care 1 într-o altă locație.

Pentru un VPS, aceasta poate însemna: datele de pe server, backupul zilnic al furnizorului și un backup propriu criptat cu restic către un spațiu de stocare la o altă parte. O completare modernă este ca cel puțin o copie să nu poată fi ștearsă de cel care preia controlul asupra serverului (offline sau append-only, lecția 8.2). Ransomware-ul de pe un server caută activ backupuri pentru a le cripta sau șterge și pe acestea. Un backup pe care serverul însuși îl poate șterge nu oferă protecție împotriva acestui lucru.

Criptarea și parola backupului dumneavoastră

Un backup aflat la o altă parte trebuie să fie criptat: conține date ale clienților, parole și chei. restic (lecția 8.2) criptează în mod implicit. Dar astfel apare un nou risc: parola backupului dumneavoastră. Dacă o pierdeți, backupul devine inutilizabil. La fel se întâmplă dacă parola se află doar pe serverul pe care l-ați pierdut.

De aceea păstrați parola și în afara serverului: în managerul de parole și, eventual, pe hârtie, într-un seif. Același lucru este valabil pentru datele de acces la spațiul de stocare unde se află backupul.

Testarea restaurării

Cea mai importantă parte a planului. Un test de restaurare înseamnă: restaurați efectiv un backup, într-un loc unde nu strică nimic, și verificați dacă rezultatul funcționează.

• Mic și des: restaurați un fișier sau un director în /tmp/terug și comparați (diff). De exemplu, lunar.
• Mare și din când în când: construiți din backup un server de test complet nou, importați baza de date, porniți site-ul. De exemplu, o dată pe an sau la fiecare modificare majoră. Acesta este totodată și exercițiul pentru situația în care chiar apare o problemă (lecția 10.3).

Notați cât a durat: acesta este RTO-ul dumneavoastră real.

Termene de păstrare

Nu păstrați doar ultimul backup. Dacă descoperiți abia după două săptămâni că un fișier a fost deteriorat sau șters, aveți nevoie de un backup de acum trei săptămâni. O schemă uzuală: șapte versiuni zilnice, patru săptămânale și șase lunare. restic se ocupă de aceasta cu forget (lecția 8.2). Gândiți-vă și la GDPR: datele cu caracter personal nu se păstrează mai mult decât este necesar, nici în backupuri. Stabiliți în scris termenele de păstrare.

În practică

Folosiți snapshotul furnizorului chiar înainte de modificări riscante și ștergeți-l după aceea; lăsați activat backupul zilnic al furnizorului, dacă există; și, pe lângă acestea, faceți un backup propriu criptat al datelor și al configurației către o altă parte. La WebOké, în ecranul VPS, acestea se numesc Snapshots și Backups; la alți furnizori denumirile și termenele diferă, dar principiul este același. Un pachet de găzduire sau un serviciu administrat are adesea alte condiții: verificați ce este prevăzut în cazul dumneavoastră.

Rezumat

• Un backup are valoare abia atunci când restaurarea funcționează; începeți cu un plan și terminați cu un test.
• Faceți backup mai ales la date și configurație: baze de date sub formă de dump, /etc, site-uri, volume Docker, fișiere compose.
• Stabiliți RPO (cât vă permiteți să pierdeți) și RTO (cât de repede trebuie să funcționeze).
• Snapshotul (același spațiu de stocare, pe termen scurt), backupul furnizorului (alt spațiu de stocare, aceeași parte) și un backup propriu în afara furnizorului sunt trei straturi diferite; urmați regula 3-2-1, cu cel puțin o copie pe care serverul însuși nu o poate șterge.
• Criptați, păstrați parola backupului în afara serverului și testați restaurarea: mic și des, mare din când în când.

Test (quiz)

Exercițiu

Exercițiul O8.1: Planul dumneavoastră de backup. Faceți pentru propriul server un plan de backup pe o singură pagină: ce trebuie să poată fi restaurat (pe straturi), RPO-ul și RTO-ul dumneavoastră, ce copii aveți (snapshot, furnizor, propriu) și unde, termenele de păstrare, unde se află parola backupului și când faceți un test de restaurare. Completați formularul; după trimitere veți vedea un plan model cu care vă puteți compara propriul plan.

Lecturi suplimentare

• Snapshoturi și backupuri pentru VPS-ul dumneavoastră
• Strategia de backup: regula 3-2-1 pentru propria dumneavoastră companie
• Curs gratuit Siguranță online pentru antreprenori 6.1: Regula 3-2-1 și ce anume trebuie să copiați de siguranță
• Curs gratuit Siguranță online pentru antreprenori 6.2: Copii de siguranță care supraviețuiesc ransomware-ului
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html
• VPS: de la prima autentificare la un server securizat 1.5: Snapshoturi: o plasă de siguranță pentru orice modificare importantă
• VPS: de la prima autentificare la un server securizat 1.6: Restaurarea backupurilor WebOké