Өгөгдлийн сангийн удирдлага болон сайтын найдвартай ажиллагааны (SRE) өндөр эрсдэлтэй ертөнцөд Шрёдингерийн нөөц хуулбар (Schrödinger’s Backup) хэмээх алдартай аксиом байдаг. Нөөц хуулбарын төлөв байдал нь түүнийг сэргээхийг оролдох хүртэл тодорхойгүй байдаг. Тэр мөч хүртэл нөөц хуулбар нь бүрэн бүтэн бөгөөд ашиглах боломжтой, эсвэл бүрэн гэмтсэн гэсэн квант төлөвт оршдог.
DevOps инженерүүд болон өгөгдлийн сангийн администраторуудын (DBA) хувьд чухал ач холбогдолтой нөөц хуулбар нь идэвхтэй ослын үед гэмтсэн болохыг олж мэдэх нь хамгийн аймшигтай хувилбар юм. Энэ нь ердийн сэргээх үйл ажиллагааг өгөгдөл алдах гамшигт үйл явдал болгон хувиргадаг. Өгөгдлийн бүрэн бүтэн байдлын энэхүү “чимээгүй алуурчин” нь ихэвчлэн анзаарагддаггүй, учир нь нөөц хуулбарын ажлууд нь үндсэн өгөгдөл нь гэмтсэн байсан ч Exit Code 0 (амжилттай) гэсэн төлөвийг байнга мэдээлдэг.
Энэхүү иж бүрэн гарын авлагад бид нөөц хуулбарын гэмтлийн анатомийг задлан шинжилж, өгөгдлийн санд тусгайлан зориулсан баталгаажуулалтын аргуудыг судалж, үйлдвэрлэлийн орчинд зориулсан автоматжуулсан, найдвартай сэргээх дамжуулах хоолойг (pipeline) хэрхэн бүтээхийг харуулах болно.
Нөөц хуулбарын гэмтлийн анатоми
Гэмтлийг илрүүлэхийн тулд та эхлээд энэ нь хэрхэн үүсдэгийг ойлгох хэрэгтэй. Нөөц хуулбарын гэмтэл нь ерөнхийдөө физик (дэд бүтцийн түвшин) болон логик (аппликейшний түвшин) гэсэн хоёр ангилалд хуваагддаг.
Физик гэмтэл
Физик гэмтэл нь хадгалах төхөөрөмж дээрх бодит битүүд өөрчлөгдөх үед үүсдэг. Энэ нь эх дискээс унших явцад, сүлжээгээр дамжих үед эсвэл зорилтот хадгалах төхөөрөмж дээр хадгалагдаж байх үед тохиолдож болно.
* Бит муудах (Bit Rot): Хадгалах төхөөрөмжийн аажмаар муудах нь битүүдийг чимээгүйгээр өөрчилж болно.
* Дамжуулалтын алдаа: TCP нь шалгах нийлбэр (checksum) ашигладаг ч тэдгээр нь маш сул (16-бит) байдаг. Өндөр ачаалалтай орчинд TCP-ийн илрүүлж чаддаггүй өгөгдлийн чимээгүй гэмтэл сүлжээгээр дамжих үед тохиолдож болно.
* Хадгалах хянагчийн гэмтэл: RAID хянагч эсвэл SAN сүлжээний техник хангамжийн алдаанууд нь үйлдлийн системд амжилттай болсон гэж мэдээлэхийн зэрэгцээ хог өгөгдлийг бичиж болно.
Логик гэмтэл
Логик гэмтэл нь илүү аюултай, учир нь нөөц хуулбарын файл өөрөө бүрэн бүтэн боловч доторх өгөгдөл нь эвдэрсэн байдаг.
* Хог орвол хог гарна (GIGO): Хэрэв таны ажиллаж байгаа өгөгдлийн санд гэмтсэн индекс эсвэл эвдэрсэн хуудас (torn page) байгаа бол таны нөөц хуулбарын хэрэгсэл тэрхүү гэмтсэн хуудсыг үнэнчээр хуулбарлаж болно. Нөөц хуулбарын ажил амжилттай болсон ч сэргээх үед алдаа гарах эсвэл эвдэрсэн өгөгдлийн сан үүсэх болно.
* Дуусаагүй гүйлгээ: Өгөгдлийн сангийн I/O-г зөв царцаахгүйгээр (жишээ нь, MySQL-д FLUSH TABLES WITH READ LOCK ашиглахгүйгээр) авсан файлын системийн түвшний агшин зуурын хуулбарууд (snapshots) нь эвдэрсэн хуудас болон сэргээх боломжгүй төлөвүүдийг үүсгэдэг.
Идэвхтэй илрүүлэлт: Шалгах нийлбэр ба криптограф хашинг
Физик гэмтлийн эсрэг хамгаалалтын эхний шугам бол криптограф баталгаажуулалт юм. Файлын хэмжээ эсвэл өөрчлөгдсөн огноонд найдах нь хангалтгүй.
Өгөгдлийн сангийн түвшний шалгах нийлбэрийг идэвхжүүлэх
Орчин үеийн харилцаатай өгөгдлийн сангийн удирдлагын системүүд (RDBMS) хуудасны түвшний шалгах нийлбэрийг дэмждэг. Идэвхжүүлсэн үед өгөгдлийн сан нь хуудас бүрийг дискэнд бичихээс өмнө шалгах нийлбэрийг тооцдог. Хуудсыг унших үед (асуулга эсвэл нөөц хуулбарын процессоор) шалгах нийлбэр нь баталгааждаг.
PostgreSQL-ийн хувьд та кластерыг эхлүүлэх явцад өгөгдлийн шалгах нийлбэрийг идэвхжүүлж болно:
# Шалгах нийлбэрийг идэвхжүүлсэн шинэ PostgreSQL кластерыг эхлүүлэх
initdb --data-checksums -D /var/lib/postgresql/data
Тэмдэглэл: Хэрэв танд одоо байгаа PostgreSQL кластер байгаа бол pg_checksums хэрэгслийг ашиглан офлайн байдлаар идэвхжүүлж болно.
Microsoft SQL Server-ийн хувьд PAGE_VERIFY нь CHECKSUM гэж тохируулагдсан эсэхийг шалгаарай (орчин үеийн хувилбаруудад анхдагчаар ийм байдаг ч хуучин системүүд дээр шалгах нь зүйтэй):
ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO
Хадгалагдсан нөөц хуулбарыг баталгаажуулах
Нөөц хуулбар таны хадгалах төхөөрөмж дээр очсоны дараа түүний бүрэн бүтэн байдлыг криптографын аргаар баталгаажуулах ёстой. CloudSave зэрэг байгууллагын түвшний нөөц хуулбарын платформууд нь дамжуулах болон хадгалах явцад нөөц хуулбарын блокуудын SHA-256 хашийг автоматаар тооцоолж, баталгаажуулдаг. Хэрэв та өөрөө скрипт удирдаж байгаа бол үүнийг гараар хэрэгжүүлэх ёстой:
# Нөөц хуулбар үүсгэсний дараа SHA-256 хаш үүсгэх
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256
# Хадгалах сервер дээр хашийг баталгаажуулах
sha256sum -c prod_db_backup.tar.gz.sha256
Өгөгдлийн санд тусгайлан зориулсан баталгаажуулалтын аргууд
Өөр өөр өгөгдлийн сангийн хөдөлгүүрүүд нь нөөц хуулбарын артефактуудын бүрэн бүтэн байдлыг шалгах өөрийн хэрэгслүүдийг санал болгодог.
PostgreSQL: pg_verifybackup
PostgreSQL 13-д нэвтрүүлсэн pg_verifybackup нь pg_basebackup-аар авсан физик нөөц хуулбаруудын хувьд томоохон өөрчлөлт юм. Энэ нь нөөц хуулбар авах явцад үүсгэгдсэн backup_manifest файлыг уншиж, бүх файл байгаа эсэх болон тэдгээрийн шалгах нийлбэр таарч байгаа эсэхийг баталгаажуулдаг.
# Физик нөөц хуулбарын лавлахад баталгаажуулалт хийх
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/
Хэрэв өгөгдлийн файлуудын аль нэгэнд нь ганц бит ч гэсэн өөрчлөгдсөн бол pg_verifybackup нь ноцтой алдаа гаргаж, таны хяналтын системүүд DBA багт нэн даруй мэдэгдэх боломжийг олгоно.
Microsoft SQL Server: RESTORE VERIFYONLY
SQL Server нь нөөц хуулбарын файлыг бодитоор сэргээхгүйгээр түүний физик бүрэн бүтэн байдлыг шалгах үндсэн командыг өгдөг. Энэ нь нөөц хуулбарын толгой хэсгийг шалгаж, хуудасны шалгах нийлбэрийг (хэрэв нөөц хуулбар авах үед идэвхжүүлсэн бол) баталгаажуулдаг.
RESTORE VERIFYONLY
FROM DISK = 'Z:BackupsProdDB_Full.bak'
WITH CHECKSUM;
Анхааруулга: RESTORE VERIFYONLY нь зөвхөн нөөц хуулбарын файл уншигдах боломжтой бөгөөд физик шалгах нийлбэрүүд таарч байгааг л баталгаажуулдаг. Энэ нь логик бүрэн бүтэн байдлыг баталгаажуулдаггүй. Логик бүрэн бүтэн байдлыг хангахын тулд та бүрэн сэргээлт хийж, DBCC CHECKDB-г ажиллуулах ёстой.
MySQL / InnoDB: Percona XtraBackup
MySQL орчны хувьд физик нөөц хуулбарыг ихэвчлэн Percona XtraBackup-аар зохицуулдаг. Нөөц хуулбарын процесс нь файлуудыг хуулахаас бүрддэг боловч гүйлгээний бүртгэлүүд (redo logs) хэрэглэгдэх хүртэл нөөц хуулбар нь тогтвортой байдаггүй. --prepare үе шат нь суурилуулсан бүрэн бүтэн байдлын шалгалтын үүрэг гүйцэтгэдэг.
# Нөөц хуулбарыг бэлтгэх нь redo logs-ийг хэрэглэдэг.
# Хэрэв нөөц хуулбар гэмтсэн бол энэ алхам амжилтгүй болно.
xtrabackup --prepare --target-dir=/data/backups/mysql/
Алтан стандарт: Автоматжуулсан сэргээлтийн тест
Шалгах нийлбэр болон баталгаажуулах командууд шаардлагатай боловч хангалтгүй юм. Нөөц хуулбар ашиглах боломжтой гэдгийг батлах цорын ганц арга бол түүнийг сэргээх явдал юм. Орчин үеийн DevOps орчинд энэ процессыг бүрэн автоматжуулах ёстой.
Нөөц хуулбарыг код гэж үзсэнээр та өгөгдлийн сангийн сэргээлтэд зориулсан CI/CD дамжуулах хоолойг бүтээх боломжтой. Энэхүү дамжуулах хоолой нь түр зуурын дэд бүтцийг бэлтгэх, сэргээлтийг гүйцэтгэх, баталгаажуулах асуулгуудыг ажиллуулах, орчныг устгах ёстой.
Автоматжуулсан сэргээлтийн дамжуулах хоолойг бүтээх
Доорх нь PostgreSQL логик дампыг баталгаажуулахын тулд cron job эсвэл CI runner (GitLab CI эсвэл GitHub Actions гэх мэт)-ээр өдөр бүр ажиллуулж болох Bash скриптийн жишээ юм.
#!/bin/bash
set -e
BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"
echo "[INFO] Автоматжуулсан сэргээлтийн тестийг эхлүүлж байна..."
# 1. Түр зуурын PostgreSQL контейнерийг ажиллуулах
docker run --name $CONTAINER_NAME
-e POSTGRES_PASSWORD=testpass
-d postgres:15
# PostgreSQL бэлэн болохыг хүлээх
echo "[INFO] Өгөгдлийн сан эхлэхийг хүлээж байна..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
sleep 2
done
# 2. Зорилтот өгөгдлийн санг үүсгэх
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"
# 3. Сэргээлтийг гүйцэтгэх
echo "[INFO] Нөөц хуулбарыг сэргээж байна..."
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. Логик баталгаажуулалтын асуулгуудыг ажиллуулах
echo "[INFO] Баталгаажуулалтын асуулгуудыг ажиллуулж байна..."
# Хэрэглэгчдийн хүснэгтэд 10,000-аас дээш бичлэг байгаа эсэхийг шалгах
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] Логик баталгаажуулалт амжилтгүй боллоо. 10000-аас дээш хэрэглэгч хүлээгдэж байсан ч $USER_COUNT олдлоо"
# Энд PagerDuty / Slack сэрэмжлүүлгийг идэвхжүүлэх
exit 1
else
echo "[SUCCESS] Логик баталгаажуулалт амжилттай. Хэрэглэгчийн тоо: $USER_COUNT"
fi
# 5. Түр зуурын орчныг устгах
echo "[INFO] Цэвэрлэж байна..."
docker rm -f $CONTAINER_NAME
echo "[INFO] Автоматжуулсан сэргээлтийн тест амжилттай дууслаа."
Та юуг баталгаажуулах ёстой вэ?
Автоматжуулсан сэргээлтийн тест хийхдээ зөвхөн өгөгдлийн сан ажиллаж байгаа эсэхийг шалгах хэрэггүй. Аппликейшнд зориулсан баталгаажуулалтын асуулгуудыг ажиллуул:
1. Мөрийн тоо: Үндсэн хүснэгтүүд хүлээгдэж буй мөрийн тоотой байгаа эсэхийг шалга (жишээ нь, users хүснэгт хоосон байх ёсгүй).
2. Сүүлийн үеийн өгөгдөл: Нөөц хуулбар хуучирсан эсэхийг шалгахын тулд сүүлийн 24 цагт үүсгэгдсэн бичлэгүүдийг хайх.
3. Лавлагааны бүрэн бүтэн байдал (Referential Integrity): Логик гэмтлийг илтгэх өнчин гадаад түлхүүрүүдийг (orphaned foreign keys) шалгах скриптүүдийг ажиллуулах.
Нөөц хуулбарын гажигт зориулсан хяналт ба сэрэмжлүүлэг
Гамшиг тохиолдохоос өмнө гэмтлийг илрүүлэхийн тулд бат бөх ажиглалт хийх шаардлагатай. Хоёртын амжилт/амжилтгүй төлөвөөс гадна та гажигийг илрүүлэхийн тулд нөөц хуулбарын ажлынхаа мета өгөгдлийг хянах хэрэгтэй.
Эвристик хяналт
Нөөц хуулбарын мета өгөгдлөө Prometheus-д нэгтгэж, Grafana-аар дүрслэн харуул. Дараах эвристикүүдэд сэрэмжлүүлэг тохируул:
* Хэмжээ гэнэт багасах: Хэрэв таны өдөр тутмын нөөц хуулбар тогтмол 500GB байдаг бол өнөөдрийнх 50MB байвал ажил амжилттай дууссан (Exit Code 0) байж болох ч хоосон схем нөөцөлсөн байх магадлалтай.
* Үргэлжлэх хугацааны гажиг: Хэрэв ихэвчлэн 2 цаг зарцуулдаг нөөц хуулбар 5 минутад дуусвал ямар нэг зүйл алгасагдсан байна. Эсрэгээрээ, хэрэв 10 цаг зарцуулбал дискний I/O муудсан байж болзошгүй бөгөөд энэ нь гэмтэлд хүргэж болзошгүй.
* WAL/Archive Log хуримтлал: Хэрэв таны өгөгдлийн сан Write-Ahead Logs (WAL) үүсгэж байгаа боловч нөөц хуулбарын систем тэдгээрийг хангалттай хурдан архивлаж чадахгүй бол та Point-in-Time Recovery (PITR) гинжин хэлхээндээ цоорхой үүсгэх эрсдэлтэй.
3-2-1 дүрмийг бүрэн бүтэн байдлын шалгалттай хэрэгжүүлэх
Салбарын стандарт болох 3-2-1 нөөц хуулбарын дүрэм (өгөгдлийн 3 хуулбар, 2 өөр зөөвөрлөгч, 1 гаднах байршил) нь бүх хуулбарыг баталгаажуулсан тохиолдолд л үр дүнтэй байдаг.
Энд CloudSave зэрэг байгууллагын шийдлийг ашиглах нь үйл ажиллагааны ачааллыг эрс бууруулдаг. Өгөгдлийн сангийн зангилаа бүрт зориулж нарийн төвөгтэй bash скрипт бичиж, засварлахын оронд CloudSave нь 3-2-1 амьдралын мөчлөгийг автоматжуулахын тулд таны дэд бүтэцтэй шууд нэгддэг. Энэ нь ransomware-аас хамгаалах хувиршгүй хадгалах сангаар хангаж, нөөц хуулбарыг сэргээх автоматжуулсан баталгаажуулалтын хуваарийг багтаасан болно. CloudSave нь тусгаарлагдсан sandbox орчныг автоматаар үүсгэж, нөөц хуулбарыг холбож, таны SQL баталгаажуулалтын скриптүүдийг ажиллуулж, эрүүл мэндийн төлөвийг таны төв хяналтын самбар руу буцааж мэдээлэх боломжтой.
Дүгнэлт
Гэмтсэн өгөгдлийн сангийн нөөц хуулбар нь бизнесийг сүйрүүлж чадах чимээгүй алуурчин юм. Нөөц хуулбарын скриптийн Exit Code 0-д дангаар найдах нь аюултай бооцоо юм.
Үйлдвэрлэлийн орчноо жинхэнэ утгаар нь хамгаалахын тулд та гүнзгийрүүлсэн хамгаалалтын стратегийг баримтлах ёстой:
1. Өгөгдлийн сангийн хөдөлгүүртээ хуудасны түвшний шалгах нийлбэрийг идэвхжүүл.
2. Нөөц хуулбар үүсгэсний дараа үндсэн баталгаажуулалтын хэрэгслүүдийг (pg_verifybackup, RESTORE VERIFYONLY) нэн даруй ашигла.
3. Нөөц хуулбарын мета өгөгдлийг (хэмжээ, үргэлжлэх хугацаа) эвристик гажигт хяна.
4. Өдөр тутмын үйл ажиллагааны дамжуулах хоолойнхоо нэг хэсэг болгон автоматжуулсан, түр зуурын сэргээлтийн тестийг хэрэгжүүл.
Идэвхгүй “хийгээд мартах” нөөц хуулбарын сэтгэлгээнээс идэвхтэй “тасралтгүй сэргээлтийн баталгаажуулалт” загвар руу шилжсэнээр та гамшиг тохиолдоход таны өгөгдөл бэлэн, найдвартай, бүрэн сэргээгдэх боломжтой гэдгийг баталгаажуулна.
