Definiți pierderea și întreruperea acceptabile
Notați cel mai recent punct de recuperare acceptabil și timpul țintă pentru restaurarea unui serviciu util. Acestea sunt obiective ale aplicației, nu un SLA PrivacyNodes. Dacă pierderea unei ore de date este inacceptabilă, o singură copie zilnică nu poate îndeplini acest obiectiv. Alegeți o metodă de copiere de siguranță a bazei de date compatibilă cu volumul de lucru și versiunea dvs.
Obțineți o țintă de unică folosință, artefactul aplicației și acreditările de recuperare autorizate prin stocare protejată. Confirmați cine aprobă restaurarea datelor clienților și cum mediul de test împiedică traficul extern. Nu restaurați peste baza de date de producție în funcțiune sau peste un director existent.
Inventariați întreaga stare a aplicației
Pentru API-ul de raportare, enumerați PostgreSQL, încărcările, exporturile care nu pot fi reproduse, configurația, referințele la cheile de criptare, DNS și dependențele externe. Distingeți un cache de unică folosință de o coadă care conține munca clienților ce necesită reconciliere. O imagine de container descrie software-ul, nu toată starea persistentă.
| Înregistrare | Valoarea dvs. |
|---|---|
| Versiunea artefactului și a configurației | Identificatori exacți |
| Copie de siguranță a bazei de date și punct de recuperare | Arhiva aleasă și marcajul de timp |
| Instantaneu de încărcare și limită de consistență | Instantaneu, cale și plan de potrivire |
| Țintă de unică folosință | Mediu verificat și destinație goală |
| Acreditări și aprobator | Numai referințe protejate |
| Început, finalizare, pași lipsă | Rezultate observate, nu estimări |
Înțelegeți ce include copia de siguranță
PostgreSQL documentează dump-urile logice, copiile de siguranță ale sistemului de fișiere și arhivarea continuă ca strategii diferite. O pg_dump arhivă acoperă o singură bază de date; rolurile la nivel de cluster și tablespace-urile necesită o considerare separată. Clientul său nu poate face dump de pe un server cu versiune majoră mai nouă. Potriviți versiunile instrumentelor și strategia cu obiectivul; copierea unui director de date activ nu este automat consistentă.
Inspectați o arhivă înainte de restaurare. Selectarea unei tabele cu pg_restore nu include automat toate dependențele sale. Opțiunea sa --clean elimină obiectele existente; o restaurare într-o singură tranzacție nu poate fi combinată cu sarcini paralele. Examinați opțiunile pentru baza de date de test goală identificată în mod specific.
Referință tehnică: Copie de siguranță și restaurare PostgreSQL · PostgreSQL pg_dump · PostgreSQL pg_restore.
Verificați integritatea și restaurați independent
Verificările depozitului și restaurările funcționale răspund la întrebări diferite. Comanda obișnuită a restic check nu citește fiecare pachet de date stocat; check --read-data adaugă acele citiri și poate consuma o lățime de bandă substanțială. Niciuna nu dovedește că instantaneul conține tot ce are nevoie API-ul.
Selectați un instantaneu specific și un director țintă nou. O comandă necalificată latest într-un depozit partajat poate selecta alt volum de lucru. O restaurare poate suprascrie fișiere, iar întreruperea poate lăsa rezultate parțiale. Verificați mai întâi destinația, păstrând fișierele de producție și depozitul original neatinse.
Referință tehnică: verificări ale depozitului restic · ținte de restaurare restic.
Testați comportamentul restaurat în ordinea dependențelor
Recreeați mediul, restaurați baza de date și încărcările corespunzătoare, apoi porniți API-ul cu acreditări de staging. Mențineți workerii în pauză până când backlog-ul și efectele lor secundare sunt înțelese. Dezactivați e-mailul de producție, apelurile de plată și webhook-urile; folosiți o destinație de export de test și nu consumați niciodată coada de producție.
Folosiți un cont de test cunoscut pentru a citi o înregistrare, a deschide încărcarea acesteia, a verifica restricțiile de acces și a rula un export nou mic. Verificați că un alt cont de test nu poate citi datele sale. Comparați punctul de recuperare selectat cu cea mai recentă înregistrare așteptată. Înregistrați timpul real de restaurare după exercițiu; nu scrieți în avans un rezultat de succes inventat.
Rezolvați proprietatea asupra scrierii înainte de o tranziție reală
În timpul unui incident, decideți ce sistem poate accepta scrieri și cum sunt reconciliate modificările ulterioare. Două copii care permit scrierea pot diverge. Un exercițiu documentează această decizie fără a comuta traficul real. Eliminați datele de unică folosință conform regulilor dvs. de retenție la încheierea exercițiului.
Corectați acreditările, dependențele și pașii de validare lipsă după fiecare repetiție. Păstrați runbook-ul în afara gazdei originale și asigurați-vă că un alt maintainer autorizat îl poate găsi. Opțiunea de copiere de siguranță selectabilă este separată de acest proces de aplicație; confirmați domeniul de aplicare și procedurile de restaurare în faptele despre serviciu. Folosiți înregistrarea lansării pentru implementarea care urmează.
Referințe oficiale
Documentația a fost revizuită pentru acest articol. Exemplele sunt exerciții de planificare, nu comenzi testate pe un server PrivacyNodes. Verificați documentația pentru versiunea instalată.