Ja neesat to atjaunojuši, tā nav rezerves kopija

Gandrīz katram uzņēmumam ir datubāzu rezerves kopijas. Daudz mazāk ir to, kuri nesen kādu no tām atjaunojuši, nomērījuši laiku un pārbaudījuši, vai rezultāts ir pilnīgs. Rezerves kopijas sabojājas klusi — pilns disks, beidzies piekļuves atslēgas derīgums, mainīts ceļš —, un kļūme parasti atklājas vissliktākajā brīdī: incidenta laikā, kad kopijas ir vajadzīgas.

Sāciet ar atjaunošanas mērķiem, nevis rīkiem

Visu risinājumu jānosaka diviem skaitļiem:

• RPO (atjaunošanas punkta mērķis) — cik daudz datu varat atļauties zaudēt. "Līdz 24 stundām" un "mazāk par minūti" nozīmē pilnīgi atšķirīgus risinājumus.
• RTO (atjaunošanas laika mērķis) — cik ilgi datubāze drīkst būt nepieejama atjaunošanas laikā.

Saskaņojiet abus ar biznesu katrai sistēmai atsevišķi. Ikvakara izgāztuve var būt pilnīgi pietiekama iekšējam rīkam un nepieņemama pasūtījumu datubāzei.

Loģiskās un fiziskās rezerves kopijas

Loģiskās rezerves kopijas — pg_dump, mysqldump — eksportē datus kā SQL vai arhīvu. Tās ir pārnesamas starp versijām un ērtas atsevišķām tabulām, bet lielām datubāzēm atjaunojas lēni un atspoguļo tikai izveides brīdi.

Fiziskās rezerves kopijas kopē pašus datu failus. PostgreSQL vidē tādi rīki kā pgBackRest, WAL-G vai Barman apvieno periodiskas bāzes kopijas ar nepārtrauktu darbību žurnāla (WAL) arhivēšanu. MySQL vidē to pašu dara Percona XtraBackup kopā ar binārajiem žurnāliem. Šī kombinācija ļauj atjaunot datus uz konkrētu laika punktu.

Atjaunošana uz laika punktu

Lielākā daļa datu zudumu nav aparatūras kļūmes — tas ir DELETE bez WHERE, slikta migrācija vai kļūdaina izlaide. Ikvakara kopija liek izvēlēties starp dienas datu zaudēšanu un bojājuma paturēšanu. Ar atjaunošanu uz laika punktu atjaunojat pēdējo bāzes kopiju un atskaņojat žurnālu līdz minūtei pirms kļūdas.

Klusās kļūmes

Šīs ir problēmas, ko visbiežāk atrodam rezerves kopiju pārskatos — neviena no tām pēc noklusējuma nerada trauksmi:

• Žurnālu arhivēšana, kas klusi neizdodas. PostgreSQL skatā pg_stat_archiver redzami failed_count un last_failed_time; ja tiem neviens neseko, atjaunošana uz laika punktu, iespējams, nav bijusi iespējama jau nedēļām.
• Glabāšanas politika, kas dzēš par daudz. Arhivēts WAL, kas izdzēsts, kamēr vecākā bāzes kopija to vēl prasa, padara šo kopiju nederīgu atjaunošanai uz laika punktu.
• Rezerves kopijas ar tām pašām piekļuves tiesībām kā produkcija. Ikviens — vai jebkurš izspiedējvīruss —, kas var izdzēst datubāzi, tad var izdzēst arī kopijas. Glabājiet vismaz vienu kopiju ārpus vietnes un nemaināmu, piemēram, objektu krātuvē ar objektu bloķēšanu.
• Šifrēšanas atslēgas, kas glabājas tikai dublējamajā serverī. Šifrēta kopija bez atslēgas nav rezerves kopija.
• Kopijas no replikas, kas pārstājusi replicēties. Tās katru nakti veiksmīgi izpildās — ar trīs nedēļas veciem datiem.

Automatizējiet atjaunošanas testus

Vienīgais pierādījums, ka rezerves kopija strādā, ir veiksmīga atjaunošana. Automatizējiet to: pēc grafika — kritiskām sistēmām reizi nedēļā — atjaunojiet jaunāko kopiju izolētā vidē, atjaunojiet līdz nesenam laika punktam un pārbaudiet rezultātu:

1. Pārbaudiet, vai datubāze startē un atjaunošana sasniedza gaidīto laika punktu.
2. Salīdziniet galveno tabulu rindu skaitu ar produkciju.
3. Palaidiet integritātes pārbaudes — PostgreSQL vidē pg_amcheck var pārbaudīt tabulas un B-koka indeksus.
4. Palaidiet īsu lietotnes pamatfunkciju testu pret atjaunoto kopiju.
5. Pierakstiet, cik ilgi aizņēma visa atjaunošana, un salīdziniet ar RTO.

Par neizdevušos atjaunošanas testu ziņojiet tieši tāpat kā par neizdevušos rezerves kopiju.

Uzrakstiet instrukciju pirms incidenta

Incidenta laikā nevienam nevajadzētu pirmo reizi lasīt rīka dokumentāciju. Uzrakstiet soli pa solim atjaunošanas instrukciju ar reālām komandām, ceļiem un norādēm, kur glabājas piekļuves dati, un lieciet kādam, kas nav tās autors, to izpildīt testa laikā. Katra vieta, kur viņš iestrēgst, ir vieta, kur iestrēgtu arī īsta atjaunošana.