Andmebaaside halduse ja süsteemide töökindluse (SRE) kõrgete panustega maailmas on tuntud aksioom: Schrödingeri varukoopia. Varukoopia seisukord on teadmata seni, kuni proovite seda taastada. Kuni selle hetkeni eksisteerib see kvantolekus, olles korraga nii täiesti toimiv kui ka täielikult rikutud.
DevOps-inseneride ja andmebaasiadministraatorite (DBA) jaoks on kriitilise andmebaasi varukoopia rikutuse avastamine aktiivse intsidenti ajal kõige hullem õudusunenägu. See muudab rutiinse taastamisoperatsiooni katastroofiliseks andmekao sündmuseks. See andmete terviklikkuse „vaikne tapja“ jääb sageli märkamata, kuna varundustööd teatavad sageli edukast Exit Code 0 isegi siis, kui aluseks olev andmekandja on kompromiteeritud.
Selles põhjalikus juhendis lahutame varukoopiate rikumise anatoomia, uurime andmebaasispetsiifilisi valideerimistehnikaid ja näitame, kuidas luua automatiseeritud, pommikindlaid taastamistorusid tootmiskeskkondade jaoks.
Varukoopia rikumise anatoomia
Rikumise tuvastamiseks peate esmalt mõistma, kuidas see tekib. Varukoopiate rikumine jaguneb üldiselt kahte kategooriasse: füüsiline (infrastruktuuri tasandil) ja loogiline (rakenduse tasandil).
Füüsiline rikumine
Füüsiline rikumine tekib siis, kui salvestusmeediumil olevad tegelikud bitid on muutunud. See võib juhtuda lähtekettalt lugemise ajal, võrguülekande ajal või sihtkoha salvestusruumis puhkeolekus.
* Bitimädanik (Bit Rot): Salvestusmeediumi järkjärguline degradeerumine võib bitte märkamatult ümber pöörata.
* Ülekandvead: Kuigi TCP-l on kontrollsummad, on need teatavasti nõrgad (16-bitised). Suure läbilaskevõimega keskkondades võib andmeedastusel tekkida vaikne andmete rikumine, mida TCP ei suuda tuvastada.
* Salvestuskontrolleri vead: RAID-kontrollerite või SAN-kangaste riistvaravead võivad kirjutada prügiandmeid, teatades samal ajal operatsioonisüsteemile õnnestumisest.
Loogiline rikumine
Loogiline rikumine on vaieldamatult ohtlikum, kuna varukoopia fail ise on täiesti terve, kuid selle sees olevad andmed on rikutud.
* Prügi sisse, prügi välja (GIGO): Kui teie reaalajas andmebaasis on rikutud indeks või katkine leht, võib teie varundustööriist selle rikutud lehe ustavalt kopeerida. Varundustöö õnnestub, kuid taastamine ebaõnnestub või annab tulemuseks rikutud andmebaasi.
* Lõpetamata tehingud: Failisüsteemi tasemel tehtud hetktõmmised, mis on tehtud ilma andmebaasi I/O-d korralikult külmutamata (nt MySQL-is FLUSH TABLES WITH READ LOCK kasutamata), põhjustavad katkiseid lehti ja taastamatuid olekuid.
Ennetav tuvastamine: kontrollsummad ja krüptograafiline räsistamine
Esimene kaitseliin füüsilise rikumise vastu on krüptograafiline valideerimine. Failisuurustele või muutmiskuupäevadele tuginemine on ebapiisav.
Andmebaasitaseme kontrollsummade lubamine
Kaasaegsed relatsioonilised andmebaaside haldussüsteemid (RDBMS) toetavad lehetaseme kontrollsummasid. Kui see on lubatud, arvutab andmebaas enne kettale kirjutamist iga lehe jaoks kontrollsumma. Kui lehte loetakse (kas päringu või varundusprotsessi kaudu), kontrollitakse kontrollsummat.
PostgreSQL puhul saate andmete kontrollsummad lubada klastri initsialiseerimise ajal:
# Initsialiseerige uus PostgreSQL-i klaster lubatud kontrollsummadega
initdb --data-checksums -D /var/lib/postgresql/data
Märkus: Kui teil on olemasolev PostgreSQL-i klaster, saate nende võrguühenduseta lubamiseks kasutada utiliiti pg_checksums.
Microsoft SQL Serveri puhul veenduge, et PAGE_VERIFY on seatud väärtusele CHECKSUM (kaasaegsetes versioonides vaikimisi, kuid pärandsüsteemides tasub kontrollida):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Varukoopiate valideerimine puhkeolekus
Kui varukoopia jõuab teie salvestussihtkohta, tuleb selle terviklikkust krüptograafiliselt kontrollida. Ettevõtte tasemel varundusplatvormid, nagu CloudSave, arvutavad ja kontrollivad automaatselt varukoopia plokkide SHA-256 räsisid ülekande ajal ja puhkeolekus. Kui haldate kohandatud skripte, peate seda käsitsi rakendama:
# Genereerige SHA-256 räsi pärast varukoopia loomist
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Kontrollige räsi salvestusserveris
sha256sum -c prod_db_backup.tar.gz.sha256
Andmebaasispetsiifilised valideerimistehnikad
Erinevad andmebaasimootorid pakuvad natiivseid tööriistu oma varukoopia artefaktide terviklikkuse kontrollimiseks.
PostgreSQL: pg_verifybackup
PostgreSQL 13-s kasutusele võetud pg_verifybackup on mängumuutja pg_basebackup-iga tehtud füüsiliste varukoopiate jaoks. See loeb varundamise ajal loodud backup_manifest faili ja kontrollib, kas kõik failid on olemas ja nende kontrollsummad klapivad.
# Käivitage kontrollimine füüsilise baasvarukoopia kataloogi vastu
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Kui mõnes andmefailis on kas või üks bitt muutunud, viskab pg_verifybackup fataalse vea, võimaldades teie seiresüsteemidel DBA-meeskonda viivitamatult teavitada.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server pakub natiivset käsku varukoopia faili füüsilise terviklikkuse kontrollimiseks ilma seda tegelikult taastamata. See kontrollib varukoopia päiseid ja valideerib lehtede kontrollsummad (kui need olid varundamise ajal lubatud).
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Hoiatus: RESTORE VERIFYONLY kinnitab ainult seda, et varukoopia fail on loetav ja füüsilised kontrollsummad klapivad. See ei taga loogilist terviklikkust. Loogilise terviklikkuse tagamiseks peate tegema täieliku taastamise ja käivitama DBCC CHECKDB.
MySQL / InnoDB: Percona XtraBackup
MySQL-i keskkondades tegeleb füüsiliste varukoopiatega sageli Percona XtraBackup. Varundusprotsess koosneb failide kopeerimisest, kuid varukoopia ei ole järjepidev enne, kui tehingulogid (redo logs) on rakendatud. --prepare faas toimib sisseehitatud terviklikkuse kontrollina.
# Varukoopia ettevalmistamine rakendab redo-logid.
# Kui varukoopia on rikutud, siis see samm ebaõnnestub.
xtrabackup --prepare --target-dir=/data/backups/mysql/
Kuldstandard: automatiseeritud taastamise testimine
Kontrollsummad ja kontrollkäsud on vajalikud, kuid neist ei piisa. Ainus viis lõplikult tõestada, et varukoopia on toimiv, on see taastada. Kaasaegsetes DevOps-keskkondades peab see protsess olema täielikult automatiseeritud.
Käsitledes varukoopiaid koodina, saate luua oma andmebaasi taastamiseks CI/CD-toru. See toru peaks eraldama efemeerse infrastruktuuri, teostama taastamise, käivitama valideerimispäringud ja keskkonna sulgema.
Automatiseeritud taastamistoru ehitamine
Allpool on näide Bash-skriptist, mida võib iga päev käivitada cron-töö või CI-käivitaja (nagu GitLab CI või GitHub Actions), et valideerida PostgreSQL-i loogilist dump-faili.
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Alustatakse automatiseeritud taastamise testi..."
# 1. Käivitage efemeerne PostgreSQL-i konteiner
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# Oodake, kuni PostgreSQL on valmis
echo "[INFO] Oodatakse andmebaasi initsialiseerimist..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Looge sihtandmebaas
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Teostage taastamine
echo "[INFO] Taastatakse varukoopiat..."
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. Käivitage loogilise valideerimise päringud
echo "[INFO] Käivitatakse valideerimispäringud..."
# Kontrollige, kas kasutajate tabelis on rohkem kui 10 000 kirjet
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] Loogiline valideerimine ebaõnnestus. Oodati >10000 kasutajat, leiti $USER_COUNT"
# Käivitage siin PagerDuty / Slacki teavitus
exit 1
else
echo "[SUCCESS] Loogiline valideerimine õnnestus. Kasutajate arv: $USER_COUNT"
fi
# 5. Sulgege efemeerne keskkond
echo "[INFO] Puhastatakse..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Automatiseeritud taastamise test lõpetati edukalt."
Mida peaksite valideerima?
Automatiseeritud taastamise testimisel ärge kontrollige ainult seda, kas andmebaas käivitub. Käivitage rakendusespetsiifilised valideerimispäringud:
1. Ridade arv: Veenduge, et põhitabelites on oodatud arv ridu (nt users tabel ei tohiks olla tühi).
2. Hiljutised andmed: Tehke päring viimase 24 tunni jooksul loodud kirjete kohta, et veenduda, et varukoopia pole aegunud.
3. Viiteline terviklikkus: Käivitage skriptid, et kontrollida orvuks jäänud välisvõtmeid, mis viitavad loogilisele rikumisele.
Varukoopia anomaaliate seire ja teavitamine
Rikumise tuvastamine enne katastroofi nõuab tugevat vaadeldavust. Lisaks binaarsetele õnnestumise/ebaõnnestumise olekutele peaksite anomaaliate tuvastamiseks jälgima oma varundustööde metaandmeid.
Heuristiline seire
Integreerige oma varunduse metaandmed Prometheusesse ja visualiseerige neid Grafanaga. Seadistage hoiatused järgmiste heuristikate jaoks:
* Äkiline suuruse vähenemine: Kui teie igapäevane varukoopia on järjepidevalt 500 GB ja tänane varukoopia on 50 MB, võis töö küll edukalt lõppeda (Exit Code 0), kuid tõenäoliselt varundati tühi skeem.
* Kestuse anomaaliad: Kui tavaliselt 2 tundi võttev varundus lõpeb 5 minutiga, jäi midagi vahele. Vastupidi, kui see võtab 10 tundi, võib teil olla ketta I/O degradeerumine, mis võib viia rikumiseni.
* WAL/arhiivilogide kuhjumine: Kui teie andmebaas genereerib Write-Ahead logisid (WAL), kuid varundussüsteem ei arhiveeri neid piisavalt kiiresti, riskite lüngaga oma ajapunkti taastamise (PITR) ahelas.
3-2-1 reegli rakendamine terviklikkuse kontrollidega
Tööstusharu standardne 3-2-1 varundusreegel (3 andmekoopiat, 2 erinevat meediumit, 1 väljaspool asukohta) on tõhus ainult siis, kui kõik koopiad on kontrollitud.
Siin vähendab ettevõtte lahenduse, nagu CloudSave, kasutamine drastiliselt operatiivset koormust. Selle asemel, et kirjutada ja hooldada keerulisi bash-skripte iga andmebaasisõlme jaoks, integreerub CloudSave otse teie infrastruktuuriga, et automatiseerida 3-2-1 elutsüklit. See pakub muutumatut salvestusruumi – kaitstes lunavara eest – ja sisaldab sisseehitatud automatiseeritud taastamise kontrollimise ajakavasid. CloudSave saab automaatselt käivitada isoleeritud liivakastikeskkonnad, ühendada varukoopia, käivitada teie kohandatud SQL-i valideerimisskriptid ja teatada tervislikust seisundist tagasi teie kesksele armatuurlauale.
Kokkuvõte
Rikutud andmebaasi varukoopiad on vaikne tapja, mis võib hävitada ettevõtteid. Ainult varundusskripti Exit Code 0-le tuginemine on ohtlik hasartmäng.
Oma tootmiskeskkondade tõeliseks kaitsmiseks peate kasutama süvakaitsestrateegiat:
1. Lubage oma andmebaasimootoris lehetaseme kontrollsummad.
2. Kasutage natiivseid kontrollimistööriistu (pg_verifybackup, RESTORE VERIFYONLY) kohe pärast varukoopia loomist.
3. Jälgige varunduse metaandmeid (suurus, kestus) heuristiliste anomaaliate suhtes.
4. Rakendage automatiseeritud efemeerne taastamise testimine osana oma igapäevasest operatiivtorust.
Liikudes passiivselt „seadista ja unusta“ varundusmentaliteedilt aktiivsele „pideva taastamise valideerimise“ mudelile, tagate, et kui katastroof vältimatult saabub, on teie andmed valmis, usaldusväärsed ja täielikult taastatavad.
