Didelių statymų duomenų bazių administravimo ir svetainių patikimumo inžinerijos pasaulyje egzistuoja gerai žinoma aksioma: Šriodingerio atsarginė kopija. Bet kurios atsarginės kopijos būklė yra nežinoma, kol nebandote jos atkurti. Iki tos akimirkos ji egzistuoja kvantinėje būsenoje – yra ir visiškai tinkama naudoti, ir visiškai sugadinta.
„DevOps“ inžinieriams ir duomenų bazių administratoriams (DBA) sužinoti, kad kritinė duomenų bazės atsarginė kopija yra sugadinta aktyvaus incidento metu, yra pats baisiausias scenarijus. Tai paverčia įprastą atkūrimo operaciją katastrofišku duomenų praradimo įvykiu. Šis „tylusis“ duomenų vientisumo žudikas dažnai lieka nepastebėtas, nes atsarginių kopijų kūrimo užduotys dažnai praneša apie sėkmingą Exit Code 0 net tada, kai pagrindinis turinys yra pažeistas.
Šiame išsamiame vadove išnagrinėsime atsarginių kopijų sugadinimo anatomiją, ištyrinėsime konkrečioms duomenų bazėms skirtus tikrinimo metodus ir parodysime, kaip sukurti automatizuotus, patikimus atkūrimo konvejerius gamybinėms aplinkoms.
Atsarginių kopijų sugadinimo anatomija
Norėdami aptikti sugadinimą, pirmiausia turite suprasti, kaip jis atsiranda. Atsarginių kopijų sugadinimas paprastai skirstomas į dvi kategorijas: fizinį (infrastruktūros lygio) ir loginį (programos lygio).
Fizinis sugadinimas
Fizinis sugadinimas įvyksta, kai pakeičiami tikrieji bitai saugojimo laikmenoje. Tai gali nutikti skaitant iš šaltinio disko, perduodant tinklu arba saugant tikslinėje saugykloje.
* Bitų irimas (Bit Rot): Laipsniškas saugojimo laikmenų degradavimas gali tyliai pakeisti bitus.
* Perdavimo klaidos: Nors TCP turi kontrolines sumas, jos yra itin silpnos (16 bitų). Didelio pralaidumo aplinkose gali įvykti tylus duomenų sugadinimas perduodant laidais, kurio TCP nepastebi.
* Saugojimo valdiklių gedimai: RAID valdiklių ar SAN audinių aparatinės įrangos klaidos gali įrašyti šiukšles, pranešdamos operacinei sistemai apie sėkmę.
Loginis sugadinimas
Loginis sugadinimas yra ginčytinai pavojingesnis, nes pati atsarginės kopijos byla yra visiškai nepažeista, tačiau joje esantys duomenys yra sugadinti.
* Šiukšlės įeina, šiukšlės išeina (GIGO): Jei jūsų veikiančioje duomenų bazėje yra sugadintas indeksas arba pažeistas puslapis, atsarginių kopijų kūrimo įrankis gali ištikimai nukopijuoti tą sugadintą puslapį. Atsarginės kopijos užduotis sėkmingai baigiasi, tačiau atkūrimas nepavyks arba sukurs sugadintą duomenų bazę.
* Nebaigti sandoriai: Failų sistemos lygio momentinės kopijos (snapshots), padarytos tinkamai neužšaldžius duomenų bazės įvesties/išvesties (pvz., nenaudojant FLUSH TABLES WITH READ LOCK MySQL), sukelia pažeistus puslapius ir neatkuriamas būsenas.
Proaktyvus aptikimas: kontrolinės sumos ir kriptografinis maišymas
Pirmoji gynybos linija nuo fizinio sugadinimo yra kriptografinis patvirtinimas. Pasikliauti failų dydžiais ar modifikavimo datomis nepakanka.
Duomenų bazės lygio kontrolinių sumų įjungimas
Šiuolaikinės reliacinių duomenų bazių valdymo sistemos (RDBMS) palaiko puslapio lygio kontrolines sumas. Kai jos įjungtos, duomenų bazė apskaičiuoja kontrolinę sumą kiekvienam puslapiui prieš įrašydama jį į diską. Kai puslapis nuskaitomas (užklausa arba atsarginės kopijos kūrimo procesu), kontrolinė suma patikrinama.
PostgreSQL atveju galite įjungti duomenų kontrolines sumas klasterio inicijavimo metu:
# Inicijuoti naują PostgreSQL klasterį su įjungtomis kontrolinėmis sumomis
initdb --data-checksums -D /var/lib/postgresql/data
Pastaba: Jei turite esamą PostgreSQL klasterį, galite naudoti pg_checksums įrankį, kad įjungtumėte jas neprisijungus (offline).
Microsoft SQL Server atveju įsitikinkite, kad PAGE_VERIFY nustatyta į CHECKSUM (tai numatytasis nustatymas šiuolaikinėse versijose, tačiau verta patikrinti senesnėse sistemose):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Atsarginių kopijų tikrinimas saugykloje
Kai atsarginė kopija patenka į jūsų saugyklą, jos vientisumas turi būti kriptografiškai patikrintas. Įmonių atsarginių kopijų platformos, tokios kaip „CloudSave“, automatiškai apskaičiuoja ir patikrina SHA-256 atsarginių kopijų blokų maišas (hashes) perdavimo metu ir saugykloje. Jei naudojate pasirinktinius scenarijus, turite tai įgyvendinti rankiniu būdu:
# Sugeneruoti SHA-256 maišą po atsarginės kopijos sukūrimo
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Patikrinti maišą saugojimo serveryje
sha256sum -c prod_db_backup.tar.gz.sha256
Konkrečioms duomenų bazėms skirti tikrinimo metodai
Skirtingi duomenų bazių varikliai siūlo vietinius įrankius savo atsarginių kopijų artefaktų vientisumui patikrinti.
PostgreSQL: pg_verifybackup
„PostgreSQL 13“ versijoje pristatytas pg_verifybackup yra esminis įrankis fizinėms atsarginėms kopijoms, sukurtoms naudojant pg_basebackup. Jis nuskaito backup_manifest failą, sugeneruotą atsarginės kopijos kūrimo metu, ir patikrina, ar visi failai yra vietoje ir ar jų kontrolinės sumos sutampa.
# Vykdyti patikrinimą fizinės bazinės atsarginės kopijos katalogui
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Jei bent vienas bitas pasikeitė bet kuriame duomenų faile, pg_verifybackup pateiks lemtingą klaidą, leisdamas jūsų stebėjimo sistemoms nedelsiant įspėti DBA komandą.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server suteikia vietinę komandą patikrinti atsarginės kopijos failo fizinį vientisumą jo faktiškai neatkuriant. Ji patikrina atsarginės kopijos antraštes ir patvirtina puslapių kontrolines sumas (jei jos buvo įjungtos atsarginės kopijos kūrimo metu).
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Įspėjimas: RESTORE VERIFYONLY tik patvirtina, kad atsarginės kopijos failas yra skaitomas ir fizinės kontrolinės sumos sutampa. Tai negarantuoja loginio vientisumo. Norėdami užtikrinti loginį vientisumą, turite atlikti pilną atkūrimą ir paleisti DBCC CHECKDB.
MySQL / InnoDB: Percona XtraBackup
MySQL aplinkose fizines atsargines kopijas dažnai tvarko „Percona XtraBackup“. Atsarginės kopijos kūrimo procesą sudaro failų kopijavimas, tačiau atsarginė kopija nėra nuosekli, kol nepritaikomi operacijų žurnalai (redo logs). --prepare fazė veikia kaip įmontuotas vientisumo patikrinimas.
# Atsarginės kopijos paruošimas pritaiko redo žurnalus.
# Jei atsarginė kopija sugadinta, šis žingsnis nepavyks.
xtrabackup --prepare --target-dir=/data/backups/mysql/
Aukso standartas: automatizuotas atkūrimo testavimas
Kontrolinės sumos ir tikrinimo komandos yra būtinos, tačiau jų nepakanka. Vienintelis būdas galutinai įrodyti, kad atsarginė kopija yra tinkama, yra ją atkurti. Šiuolaikinėse „DevOps“ aplinkose šis procesas turi būti visiškai automatizuotas.
Vertindami atsargines kopijas kaip kodą, galite sukurti CI/CD konvejerį savo duomenų bazių atkūrimui. Šis konvejeris turėtų paruošti laikiną infrastruktūrą, atlikti atkūrimą, paleisti patvirtinimo užklausas ir išjungti aplinką.
Automatizuoto atkūrimo konvejerio kūrimas
Žemiau pateiktas „Bash“ scenarijaus pavyzdys, kurį kasdien galėtų paleisti „cron“ užduotis arba CI vykdytojas (pvz., „GitLab CI“ arba „GitHub Actions“), kad patikrintų PostgreSQL loginį išrašą.
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Pradedamas automatizuotas atkūrimo testas..."
# 1. Paleisti laikiną PostgreSQL konteinerį
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# Palaukti, kol PostgreSQL bus paruoštas
echo "[INFO] Laukiama, kol duomenų bazė bus inicijuota..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Sukurti tikslinę duomenų bazę
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Atlikti atkūrimą
echo "[INFO] Atkuriama atsarginė kopija..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump
# 4. Vykdyti loginio patvirtinimo užklausas
echo "[INFO] Vykdomos patvirtinimo užklausos..."
# Patikrinti, ar vartotojų lentelėje yra daugiau nei 10 000 įrašų
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")
if [ "$USER_COUNT" -lt 10000 ]; then
echo "[ERROR] Loginis patvirtinimas nepavyko. Tikėtasi >10000 vartotojų, rasta $USER_COUNT"
# Čia suaktyvinti PagerDuty / Slack įspėjimą
exit 1
else
echo "[SUCCESS] Loginis patvirtinimas sėkmingas. Vartotojų skaičius: $USER_COUNT"
fi
# 5. Išjungti laikiną aplinką
echo "[INFO] Valoma..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Automatizuotas atkūrimo testas sėkmingai baigtas."
Ką turėtumėte patikrinti?
Atlikdami automatizuotą atkūrimo testavimą, ne tik patikrinkite, ar duomenų bazė pasileidžia. Vykdykite konkrečiai programai skirtas patvirtinimo užklausas:
1. Eilučių skaičius: Įsitikinkite, kad pagrindinės lentelės turi tikėtiną eilučių skaičių (pvz., users lentelė neturėtų būti tuščia).
2. Naujausi duomenys: Ieškokite per paskutines 24 valandas sukurtų įrašų, kad įsitikintumėte, jog atsarginė kopija nėra pasenusi.
3. Referencinis vientisumas: Vykdykite scenarijus, kad patikrintumėte, ar nėra našlaičių užsienio raktų (orphaned foreign keys), kurie rodo loginį sugadinimą.
Atsarginių kopijų anomalijų stebėjimas ir įspėjimas
Sugadinimo aptikimas prieš įvykstant nelaimei reikalauja patikimo stebėjimo. Be dvejetainių sėkmės/nesėkmės būsenų, turėtumėte stebėti savo atsarginių kopijų užduočių metaduomenis, kad aptiktumėte anomalijas.
Heuristinis stebėjimas
Integruokite savo atsarginių kopijų metaduomenis į „Prometheus“ ir vizualizuokite juos su „Grafana“. Nustatykite įspėjimus šioms euristikoms:
* Staigus dydžio sumažėjimas: Jei jūsų kasdienė atsarginė kopija nuolat yra 500 GB, o šiandienos – 50 MB, užduotis galėjo būti baigta sėkmingai (Exit Code 0), tačiau tikėtina, kad ji nukopijavo tuščią schemą.
* Trukmės anomalijos: Jei atsarginė kopija, kuri paprastai užtrunka 2 valandas, baigiama per 5 minutes, kažkas buvo praleista. Priešingai, jei tai užtrunka 10 valandų, galite turėti disko įvesties/išvesties degradaciją, kuri gali sukelti sugadinimą.
* WAL/archyvo žurnalų kaupimasis: Jei jūsų duomenų bazė generuoja „Write-Ahead Logs“ (WAL), bet atsarginių kopijų sistema jų archyvuoja nepakankamai greitai, rizikuojate prarasti savo atkūrimo iki tam tikro laiko (PITR) grandinę.
3-2-1 taisyklės įgyvendinimas su vientisumo patikrinimais
Pramonės standarto 3-2-1 atsarginių kopijų taisyklė (3 duomenų kopijos, 2 skirtingos laikmenos, 1 ne vietoje) yra veiksminga tik tada, jei visos kopijos yra patikrintos.
Štai kur „CloudSave“ tipo įmonės sprendimo panaudojimas drastiškai sumažina veiklos sąnaudas. Užuot rašę ir prižiūrėję sudėtingus „bash“ scenarijus kiekvienam duomenų bazės mazgui, „CloudSave“ tiesiogiai integruojasi su jūsų infrastruktūra, kad automatizuotų 3-2-1 gyvavimo ciklą. Ji suteikia nekintamą saugyklą – apsaugą nuo išpirkos reikalaujančių programų – ir turi įmontuotus, automatizuotus atkūrimo patikrinimo grafikus. „CloudSave“ gali automatiškai paleisti izoliuotas smėlio dėžės aplinkas, prijungti atsarginę kopiją, paleisti jūsų pasirinktinius SQL patvirtinimo scenarijus ir pranešti apie būklę į jūsų centrinį prietaisų skydelį.
Išvada
Sugadintos duomenų bazių atsarginės kopijos yra tylusis žudikas, galintis sunaikinti verslą. Pasikliauti vien tik atsarginės kopijos scenarijaus Exit Code 0 yra pavojingas lošimas.
Norėdami tikrai apsaugoti savo gamybines aplinkas, turite taikyti giliosios gynybos strategiją:
1. Įjunkite puslapio lygio kontrolines sumas savo duomenų bazės variklyje.
2. Nedelsdami po atsarginės kopijos sukūrimo naudokite vietinius tikrinimo įrankius (pg_verifybackup, RESTORE VERIFYONLY).
3. Stebėkite atsarginių kopijų metaduomenis (dydį, trukmę) dėl euristinių anomalijų.
4. Įgyvendinkite automatizuotą, laikiną atkūrimo testavimą kaip savo kasdienio operacinio konvejerio dalį.
Pereidami nuo pasyvaus „paleisk ir pamiršk“ atsarginių kopijų mentaliteto prie aktyvaus „nuolatinio atkūrimo patvirtinimo“ modelio, užtikrinate, kad kai neišvengiamai ištiks nelaimė, jūsų duomenys bus paruošti, patikimi ir visiškai atkuriami.
