Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

Yn y byd heriol o weinyddu cronfeydd data a pheirianneg dibynadwyedd safleoedd, mae axiom adnabyddus: Backup Schrödinger. Mae cyflwr unrhyw gopi wrth gefn yn anhysbys nes i chi geisio ei adfer. Hyd at y foment honno, mae’n bodoli mewn cyflwr cwantwm o fod yn berffaith hyfyw ac wedi’i lygru’n llwyr.

I beirianwyr DevOps a gweinyddwyr cronfeydd data (DBAs), darganfod bod copi wrth gefn hanfodol wedi’i lygru yn ystod digwyddiad gweithredol yw’r senario hunllefus eithaf. Mae’n trawsnewid gweithrediad adfer arferol yn ddigwyddiad colli data trychinebus. Mae’r “llofrudd tawel” hwn o gyfanrwydd data yn aml yn mynd heb i neb sylwi oherwydd bydd swyddi copi wrth gefn yn aml yn adrodd Exit Code 0 llwyddiannus hyd yn oed pan fo’r llwyth tâl sylfaenol wedi’i beryglu.

Yn y canllaw cynhwysfawr hwn, byddwn yn dadansoddi anatomeg llygredd copi wrth gefn, yn archwilio technegau dilysu penodol i gronfeydd data, ac yn dangos sut i adeiladu piblinellau adfer awtomataidd, gwrth-fwled ar gyfer amgylcheddau cynhyrchu.

Anatomeg Llygredd Copi Wrth Gefn

Er mwyn canfod llygredd, rhaid i chi ddeall yn gyntaf sut mae’n digwydd. Mae llygredd copi wrth gefn fel arfer yn disgyn i ddau gategori: corfforol (lefel seilwaith) a rhesymegol (lefel cais).

Llygredd Corfforol

Mae llygredd corfforol yn digwydd pan fydd y didau gwirioneddol ar y cyfrwng storio yn cael eu newid. Gall hyn ddigwydd yn ystod y broses ddarllen o’r ddisg ffynhonnell, yn ystod cludiant rhwydwaith, neu wrth orffwys ar y storfa darged.
* Pydredd Didau (Bit Rot): Gall diraddio graddol cyfryngau storio fflipio didau yn dawel.
* **Gwallau Cludiant:** Er bod gan TCP swm gwirio (checksums), maent yn adnabyddus am fod yn wan (16-bit). Gall amgylcheddau trwybwn uchel brofi llygredd data tawel dros y wifren na all TCP ei ddal.
* Ffyltau Rheolwr Storio: Gall chwilod caledwedd mewn rheolwyr RAID neu ffabrigau SAN ysgrifennu data sbwriel wrth adrodd llwyddiant i’r OS.

Llygredd Rhesymegol

Mae llygredd rhesymegol yn ddadleuol yn fwy peryglus oherwydd bod y ffeil copi wrth gefn ei hun yn gyfan, ond mae’r data y tu mewn iddo wedi torri.
* Sbwriel i Mewn, Sbwriel Allan (GIGO): Os oes gan eich cronfa ddata fyw fynegai wedi’i lygru neu dudalen wedi’i rhwygo, efallai y bydd eich offeryn copi wrth gefn yn copïo’r dudalen lygredig honno yn ffyddlon. Mae’r swydd copi wrth gefn yn llwyddo, ond bydd yr adferiad yn methu neu’n cynhyrchu cronfa ddata wedi torri.
* Trafodion Anghyflawn: Mae cipluniau lefel system ffeiliau a gymerir heb rewi I/O y gronfa ddata yn iawn (e.e., heb ddefnyddio FLUSH TABLES WITH READ LOCK yn MySQL) yn arwain at dudalennau wedi’u rhwygo a chyflyrau na ellir eu hadfer.

Canfod Rhagweithiol: Swm Gwirio a Hashio Cryptograffig

Y llinell amddiffyn gyntaf yn erbyn llygredd corfforol yw dilysu cryptograffig. Nid yw dibynnu ar feintiau ffeiliau neu ddyddiadau addasu yn ddigonol.

Galluogi Swm Gwirio Lefel Cronfa Ddata

Mae systemau rheoli cronfeydd data perthynol modern (RDBMS) yn cefnogi swm gwirio lefel tudalen. Pan gaiff ei alluogi, mae’r gronfa ddata yn cyfrifo swm gwirio ar gyfer pob tudalen cyn ei ysgrifennu i’r ddisg. Pan ddarllenir y dudalen (naill ai gan ymholiad neu broses copi wrth gefn), dilysir y swm gwirio.

Ar gyfer PostgreSQL, gallwch alluogi swm gwirio data yn ystod cychwyn y clwstwr:

# Cychwyn clwstwr PostgreSQL newydd gyda swm gwirio wedi'i alluogi
initdb --data-checksums -D /var/lib/postgresql/data

Nodyn: Os oes gennych glwstwr PostgreSQL presennol, gallwch ddefnyddio’r cyfleustod pg_checksums i’w galluogi all-lein.

Ar gyfer Microsoft SQL Server, sicrhewch fod PAGE_VERIFY wedi’i osod i CHECKSUM (y rhagosodiad mewn fersiynau modern, ond mae’n werth ei wirio ar systemau hŷn):

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

Dilysu Copïau Wrth Gefn wrth Orffwys

Unwaith y bydd y copi wrth gefn yn glanio ar eich targed storio, rhaid dilysu ei gyfanrwydd yn cryptograffig. Mae llwyfannau copi wrth gefn menter fel CloudSave yn cyfrifo ac yn dilysu hashiau SHA-256 o flociau copi wrth gefn yn awtomatig wrth gludo ac wrth orffwys. Os ydych chi’n rheoli sgriptiau personol, rhaid i chi weithredu hyn â llaw:

# Cynhyrchu hash SHA-256 ar ôl creu copi wrth gefn
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# Dilysu'r hash ar y gweinydd storio
sha256sum -c prod_db_backup.tar.gz.sha256

Technegau Dilysu Penodol i Gronfa Ddata

Mae gwahanol beiriannau cronfa ddata yn cynnig offer brodorol i wirio cyfanrwydd eu arteffactau copi wrth gefn.

PostgreSQL: pg_verifybackup

Wedi’i gyflwyno yn PostgreSQL 13, mae pg_verifybackup yn newidiwr gêm ar gyfer copïau wrth gefn corfforol a gymerwyd gyda pg_basebackup. Mae’n darllen y ffeil backup_manifest a gynhyrchwyd yn ystod y copi wrth gefn ac yn dilysu bod yr holl ffeiliau’n bresennol a bod eu swm gwirio yn cyfateb.

# Rhedeg dilysiad yn erbyn cyfeiriadur copi wrth gefn sylfaenol corfforol
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

Os yw un did wedi fflipio yn unrhyw un o’r ffeiliau data, bydd pg_verifybackup yn taflu gwall angheuol, gan ganiatáu i’ch systemau monitro rybuddio’r tîm DBA ar unwaith.

Microsoft SQL Server: RESTORE VERIFYONLY

Mae SQL Server yn darparu gorchymyn brodorol i wirio cyfanrwydd corfforol ffeil copi wrth gefn heb ei adfer mewn gwirionedd. Mae’n gwirio’r penawdau copi wrth gefn ac yn dilysu swm gwirio’r dudalen (os cawsant eu galluogi yn ystod y copi wrth gefn).

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

Rhybudd: Mae RESTORE VERIFYONLY ond yn cadarnhau bod y ffeil copi wrth gefn yn ddarllenadwy a bod y swm gwirio corfforol yn cyfateb. Nid yw’n gwarantu cyfanrwydd rhesymegol. Er mwyn sicrhau cyfanrwydd rhesymegol, rhaid i chi berfformio adferiad llawn a rhedeg DBCC CHECKDB.

MySQL / InnoDB: Percona XtraBackup

Ar gyfer amgylcheddau MySQL, mae copïau wrth gefn corfforol yn aml yn cael eu trin gan Percona XtraBackup. Mae’r broses copi wrth gefn yn cynnwys copïo ffeiliau, ond nid yw’r copi wrth gefn yn gyson nes bod y logiau trafodion (redo logs) yn cael eu cymhwyso. Mae’r cam --prepare yn gweithredu fel gwiriad cyfanrwydd adeiledig.

# Mae paratoi'r copi wrth gefn yn cymhwyso'r redo logs. 
# Os yw'r copi wrth gefn wedi'i lygru, bydd y cam hwn yn methu.
xtrabackup --prepare --target-dir=/data/backups/mysql/

Y Safon Aur: Profi Adfer Awtomataidd

Mae swm gwirio a gorchmynion dilysu yn angenrheidiol, ond nid ydynt yn ddigonol. Yr unig ffordd i brofi’n bendant bod copi wrth gefn yn hyfyw yw ei adfer. Mewn amgylcheddau DevOps modern, rhaid i’r broses hon gael ei awtomeiddio’n llwyr.

Trwy drin copïau wrth gefn fel cod, gallwch adeiladu piblinell CI/CD ar gyfer eich adferiadau cronfa ddata. Dylai’r biblinell hon ddarparu seilwaith dros dro, gweithredu’r adferiad, rhedeg ymholiadau dilysu, a chymryd yr amgylchedd i lawr.

Adeiladu Piblinell Adfer Awtomataidd

Isod mae enghraifft o sgript Bash y gellid ei sbarduno’n ddyddiol gan swydd cron neu redeg CI (fel GitLab CI neu GitHub Actions) i ddilysu dympiad rhesymegol PostgreSQL.

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] Yn dechrau Prawf Adfer Awtomataidd..."

# 1. Cychwyn cynhwysydd PostgreSQL dros dro
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# Aros i PostgreSQL fod yn barod
echo "[INFO] Yn aros i'r gronfa ddata gychwyn..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. Creu'r gronfa ddata darged
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. Gweithredu'r adferiad
echo "[INFO] Yn adfer copi wrth gefn..."
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. Rhedeg Ymholiadau Dilysu Rhesymegol
echo "[INFO] Yn rhedeg ymholiadau dilysu..."
# Gwirio a oes gan y tabl defnyddwyr fwy na 10,000 o gofnodion
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] Methodd y dilysiad rhesymegol. Disgwyliwyd >10000 o ddefnyddwyr, cafwyd $USER_COUNT"
    # Sbarduno rhybudd PagerDuty / Slack yma
    exit 1
else
    echo "[SUCCESS] Pasiodd y dilysiad rhesymegol. Cyfrif defnyddwyr: $USER_COUNT"
fi

# 5. Cymryd yr amgylchedd dros dro i lawr
echo "[INFO] Yn glanhau..."
docker rm -f $CONTAINER_NAME

echo "[INFO] Prawf Adfer Awtomataidd wedi'i Gwblhau'n Llwyddiannus."

Beth ddylech chi ei ddilysu?

Wrth berfformio profion adfer awtomataidd, peidiwch â gwirio dim ond a yw’r gronfa ddata yn cychwyn. Rhedeg ymholiadau dilysu penodol i’r cais:
1. Cyfrif Rhesi: Sicrhewch fod gan dablau craidd gyfrif rhesi disgwyliedig (e.e., ni ddylai’r tabl users fod yn wag).
2. Data Diweddar: Ymholwch am gofnodion a grëwyd yn y 24 awr ddiwethaf i sicrhau nad yw’r copi wrth gefn yn hen.
3. Cyfanrwydd Cyfeiriol: Rhedeg sgriptiau i wirio am allweddi tramor amddifad, sy’n dynodi llygredd rhesymegol.

Monitro a Rhybuddio am Anomaleddau Copi Wrth Gefn

Mae canfod llygredd cyn i drychineb daro yn gofyn am arsylwadwyedd cadarn. Y tu hwnt i gyflyrau llwyddiant/methiant deuaidd, dylech fonitro metadata eich swyddi copi wrth gefn i ganfod anomaleddau.

Monitro Heuristaidd

Integreiddiwch eich metadata copi wrth gefn i Prometheus a’i ddelweddu gyda Grafana. Gosodwch rybuddion ar gyfer y heuristegau canlynol:
* Gostyngiadau Maint Sydyn: Os yw’ch copi wrth gefn dyddiol yn 500GB yn gyson, a bod copi wrth gefn heddiw yn 50MB, efallai bod y swydd wedi’i chwblhau’n llwyddiannus (Exit Code 0), ond mae’n debygol ei fod wedi copïo sgema wag.
* Anomaleddau Hyd: Os yw copi wrth gefn sydd fel arfer yn cymryd 2 awr yn gorffen mewn 5 munud, cafodd rhywbeth ei hepgor. I’r gwrthwyneb, os yw’n cymryd 10 awr, efallai bod gennych ddiraddiad I/O disg a allai arwain at lygredd.
* Cronni WAL/Log Archif: Os yw’ch cronfa ddata yn cynhyrchu Logiau Write-Ahead (WAL) ond nad yw’r system copi wrth gefn yn eu harchifo’n ddigon cyflym, rydych chi mewn perygl o gael bwlch yn eich cadwyn Adferiad Pwynt-mewn-Amser (PITR).

Gweithredu’r Rheol 3-2-1 gyda Gwiriadau Cyfanrwydd

Mae rheol copi wrth gefn 3-2-1 safonol y diwydiant (3 chopi o ddata, 2 gyfrwng gwahanol, 1 oddi ar y safle) ond yn effeithiol os yw’r holl gopïau wedi’u dilysu.

Dyma lle mae defnyddio datrysiad menter fel CloudSave yn lleihau gorbenion gweithredol yn sylweddol. Yn lle ysgrifennu a chynnal sgriptiau bash cymhleth ar gyfer pob nod cronfa ddata, mae CloudSave yn integreiddio’n uniongyrchol â’ch seilwaith i awtomeiddio cylch bywyd 3-2-1. Mae’n darparu storfa annewidiol—gan amddiffyn rhag ransomware—ac yn cynnwys amserlenni dilysu adfer awtomataidd adeiledig. Gall CloudSave gychwyn amgylcheddau blwch tywod ynysig yn awtomatig, mowntio’r copi wrth gefn, rhedeg eich sgriptiau dilysu SQL personol, ac adrodd statws iechyd yn ôl i’ch dangosfwrdd canolog.

Casgliad

Mae copïau wrth gefn cronfa ddata wedi’u llygru yn llofrudd tawel a all ddinistrio busnesau. Mae dibynnu’n llwyr ar Exit Code 0 sgript copi wrth gefn yn gambl peryglus.

Er mwyn amddiffyn eich amgylcheddau cynhyrchu yn wirioneddol, rhaid i chi fabwysiadu strategaeth amddiffyn-mewn-dyfnder:
1. Galluogi swm gwirio lefel tudalen o fewn eich peiriant cronfa ddata.
2. Defnyddio offer dilysu brodorol (pg_verifybackup, RESTORE VERIFYONLY) yn syth ar ôl creu copi wrth gefn.
3. Monitro metadata copi wrth gefn (maint, hyd) ar gyfer anomaleddau heuristaidd.
4. Gweithredu profion adfer awtomataidd, dros dro fel rhan o’ch piblinell weithredol ddyddiol.

Trwy symud o feddylfryd copi wrth gefn goddefol “tân ac anghofio” i fodel “dilysu adferiad parhaus” gweithredol, rydych chi’n sicrhau, pan fydd trychineb yn taro’n anochel, bod eich data yn barod, yn ddibynadwy, ac yn gwbl adferadwy.

Categorïau