Sigurnosna kopija koju nikad niste vratili nije sigurnosna kopija

Najgori trenutak za otkriti da sigurnosna kopija ne funkcionira jest trenutak kada vam je potrebna. Ipak, najčešći obrazac izgleda upravo tako: sigurnosne kopije jednom su konfigurirane, na nadzornoj ploči osamnaest mjeseci stoji zelena kvačica, a zatim vraćanje podataka proizvede praznu bazu podataka.

Testiranje vraćanja sigurnosne kopije baze podataka nije najbolja praksa u smislu u kojem je većina najboljih praksi opcionalna. Sigurnosna kopija predstavlja tvrdnju, a dok je ne vratite, ta je tvrdnja neprovjerena.

Evo kako sigurnosne kopije zakazuju i što provjera zaista mora obuhvatiti.

Četiri načina na koja sigurnosna kopija može neprimjetno postati beskorisna

1. Prazna je i nitko to nije provjerio

pg_dump koji ne uspije do kraja i dalje može proizvesti datoteku. Dump pokrenut nad pogrešnim nazivom baze podataka proizvodi valjanu, ispravnu, praznu datoteku. I jedno i drugo izgleda kao uspjeh svemu što provjerava samo izlazni kod različit od nule ili postojanje datoteke.

Najjeftinija provjera na svijetu: pogledajte veličinu i usporedite je s jučerašnjom. Sigurnosna kopija veličine 400 bajtova, dok je jučerašnja imala 40 MB, govori vam sve što trebate znati. Sigurnosna kopija koja šest mjeseci ima 400 bajtova cijelo vas je vrijeme upozoravala.

2. Sadrži podatke, ali ne i sve što ih okružuje

pg_dump jedne baze podataka ne uključuje uloge ni druge baze podataka. Vratite je na novi poslužitelj i tablice će se pojaviti, dok će svaki GRANT upućivati na ulogu koja ne postoji. Vaša se aplikacija poveže i za sve dobije poruku o nedopuštenom pristupu.

Isto vrijedi za ekstenzije. Ako vaša shema ovisi o pgcrypto ili uuid-ossp, a odredišni sustav ih nema, vraćanje podataka neće uspjeti do kraja i ostat ćete s dijelom tablica.

3. Zastavice nisu odgovarale vraćanju podataka koje vam je potrebno

pg_dump proizvodi različite rezultate ovisno o formatu, a pogreška se obično otkrije pod pritiskom:

• Plain SQL vraća se pomoću psql i čitljiv je ljudima. Ne može se vraćati selektivno i spor je za velike baze podataka.
• Custom format (-Fc) vraća se pomoću pg_restore, podržava paralelno i selektivno vraćanje podataka te je ono što želite za sve što je imalo veći opseg.

Izraditi sigurnosnu kopiju u plain formatu zato što je tako učinjeno u uputama, a zatim tijekom incidenta otkriti da ne možete vratiti jednu tablicu, posebna je i potpuno izbježiva vrsta lošeg dana.

4. Ne možete je dešifrirati

Ako su sigurnosne kopije šifrirane — a trebale bi biti — ključ je dio sigurnosne kopije. Ključ koji se nalazi samo na izgubljenom računalu ili samo u varijabli okruženja nedostupne usluge nije ključ koji imate kad vam je najpotrebniji.

Kako izgleda prava provjera

Provjera nije pitanje „postoji li datoteka”. Vratite je negdje drugdje i postavite joj pitanje.

# 1. Restore into a scratch database, not the live one
createdb verify_$(date +%Y%m%d)
pg_restore -d verify_$(date +%Y%m%d) --no-owner --no-privileges latest.dump

# 2. Ask it something only real data can answer
psql -d verify_$(date +%Y%m%d) -c "
  select
    (select count(*) from users)            as users,
    (select count(*) from orders)           as orders,
    (select max(created_at) from orders)    as newest_order;
"

# 3. Drop it
dropdb verify_$(date +%Y%m%d)

Korak 2 cijela je poanta. Vraćanje podataka koje završi bez pogreške i dalje vam ne govori ništa o tome jesu li podaci prisutni. Broj redaka i provjera ažurnosti to mogu pokazati.

Vrijedi provjeriti tri stvari:

• Broj redaka je približno očekivan. Ne mora biti točan — podaci se mijenjaju — ali tablica koja je imala 200.000 redaka, a sada ih ima 12, nije uspješno vraćena.
• Najnoviji zapis je nedavan. Ako je najnovija narudžba u vašoj „noćnoj” sigurnosnoj kopiji iz ožujka, posao izrade sigurnosne kopije prestao je raditi u ožujku.
• Aplikacija se zaista može povezati. Usmjerite staging instancu na vraćenu bazu podataka i učitajte jednu stranicu.

Radite to prema rasporedu, a ne kad se sjetite

Realna je učestalost jednom mjesečno, automatizirano, uz rezultat na mjestu na kojem ćete ga primijetiti. Podsjetnik u kalendaru da „testirate sigurnosne kopije” samo je podsjetnik koji ćete odgoditi.

Da bi se postupak održao, pogreška mora biti jasno vidljiva: ako upit za provjeru vrati manje redaka od zadanog praga, to bi trebalo poslati obavijest odgovornoj osobi na isti način kao pogreška u produkciji. Sustav sigurnosnog kopiranja koji neprimjetno prestane raditi ne razlikuje se od nepostojanja sustava sigurnosnog kopiranja — sve dok ne postane važan.

Kako Dockup to rješava

Tri odluke, od kojih je svaka usmjerena na jednu od prethodno navedenih pogrešaka.

Sigurnosne kopije spremaju se na drugu lokaciju. Sigurnosna kopija na istom disku kao i baza podataka nije sigurnosna kopija — to je kopija koja nestaje zajedno s diskom. Dockup izravno šalje sigurnosne kopije baza podataka u object storage dok nastaju, pa datoteka nikad ne ovisi o računalu na kojem je izrađena.

Šifrirane su, a ključ nije na tom računalu. Sigurnosne se kopije šifriraju pomoću AES-256-GCM dok se šalju. Za oporavak je važno to što ključ čuva platforma, umjesto da se nalazi u okruženju usluge čija se sigurnosna kopija izrađuje.

Sigurnosna kopija iz koje ništa nije proizvedeno ne bilježi se kao sigurnosna kopija. Time se izravno rješava problem prazne datoteke: ako dump završi s izlaznim kodom različitim od nule ili proizvede nula bajtova, prijenos se briše, a sigurnosna se kopija bilježi kao neuspješna. Nećete završiti s popisom zelenih zapisa među kojima je jedan datoteka od 400 bajtova.

dockup db backup my-project/main-db --json     # take one now
dockup db backups my-project/main-db --json    # list them with sizes

Veličine u tom popisu najjeftinija su provjera ispravnosti koju imate. Pratite kako se mijenjaju.

Neugodno pitanje

Kad bi vaša produkcijska baza podataka bila uništena u sljedećih deset minuta, koliko bi vam trebalo da je vratite i koliko biste podataka izgubili?

Ako ne možete odgovoriti na oba pitanja, nemate strategiju sigurnosnog kopiranja — imate datoteke sigurnosnih kopija. Razlika je isključivo u tome je li itko ikad izvršio vraćanje podataka.

Često postavljana pitanja

Koliko često trebam testirati vraćanje podataka? Jednom mjesečno razumna je početna vrijednost, i to automatizirano, a ne ručno. Važno je da se pogreška jasno prijavi, a ne da učestalost bude što veća.

Zašto je vraćanje podataka završilo, ali nije proizvelo podatke? Najčešće je dump izrađen nad pogrešnom bazom podataka ili nije uspio do kraja, iako se datoteka i dalje zapisivala. Usporedite veličine sigurnosnih kopija tijekom vremena — prazan dump očit je iz trenda veličine, a nevidljiv u stupcu statusa.

Trebaju li sigurnosne kopije biti šifrirane? Da, a ključ mora biti na mjestu koje preživljava gubitak računala. Šifrirana sigurnosna kopija čiji se ključ nalazio na izgubljenom poslužitelju ne može se oporaviti.

Je li snapshot isto što i sigurnosna kopija? Nije. Snapshot volumena bilježi disk, uključujući stanje u kojem se baza podataka nalazila u tom trenutku. Logički dump po konstrukciji je konzistentan. Većina timova želi oboje, zbog različitih vrsta kvarova.