Categories
Database Backup

** Discover the hidden dangers of DIY database backup scripts. Learn why custom Bash scripts fail in production, the risks of logical dumps, and how to secure your data with enterprise solutions.

Өгөгдлийн сангийн администратор (DBA) болон Системийн инженер бүр карьерынхаа аль нэг үед өгөгдлийн санг нөөцлөхийн тулд өөрөө тусгай shell скрипт бичиж үзсэн байдаг. Энэ бол бараг л нэг ёсны зан үйл юм. Төслийн эхний шатанд mysqldump эсвэл pg_dump-ийг gzip рүү дамжуулдаг энгийн cron job нь маш гоёмсог, хөнгөн бөгөөд хэмнэлттэй шийдэл мэт санагддаг.

Гэсэн хэдий ч дэд бүтэц өргөжиж, өгөгдлийн хэмжээ нэмэгдэж, ажиллах хугацааны (uptime) SLA чангарч эхлэхэд тэрхүү 10 мөр Bash скрипт нь чимээгүйхэн тэсрэх бөмбөг болон хувирдаг. Үйлдвэрлэлийн орчин нь өндөр бэлэн байдал, Сэргээх цэгийн зорилт (RPO) болон Сэргээх хугацааны зорилтыг (RTO) хатуу шаарддаг. Ийм орчинд өөрийн гараар хийсэн (DIY) нөөцлөлтийн скриптүүдэд найдах нь өгөгдлийн бүрэн бүтэн байдал, чимээгүй алдаа, аюулгүй байдлын сул тал, удирдах боломжгүй сэргээх үйл явц зэрэг ноцтой эрсдэлүүдийг дагуулдаг.

Энэ нийтлэлд бид өгөгдлийн сангийн DIY нөөцлөлтийн скриптүүдийн архитектурын алдаа болон далд аюулуудыг задлан шинжилж, логик болон физик нөөцлөлтийн техникийн бэрхшээлүүдийг судалж, таны бизнесийн чухал өгөгдлийг хамгаалахын тулд CloudSave гэх мэт аж ахуйн нэгжийн түвшний шийдлүүд рүү хэрхэн шилжих талаар ярилцах болно.

Энгийн байдлын хуурмаг байдал: Сонгодог DIY скриптийг задлан шинжлэх нь

Аюулыг ойлгохын тулд эхлээд ердийн DIY нөөцлөлтийн скриптийн бүтцийг харах хэрэгтэй. MySQL өгөгдлийн сангийн хувьд стандарт арга нь ихэвчлэн иймэрхүү харагддаг:

#!/bin/bash
# Энгийн DIY MySQL нөөцлөлтийн скрипт
BACKUP_DIR="/mnt/backups"
DATE=$(date +%F)
DB_USER="admin"
DB_PASS="SuperSecret123!"

mysqldump -u $DB_USER -p$DB_PASS my_database | gzip > $BACKUP_DIR/mydb_$DATE.sql.gz

# 30 хоногоос дээш хугацааны нөөцлөлтийг устгах
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Анх харахад энэ скрипт зорилгоо биелүүлж байгаа мэт: өгөгдлийг гаргаж, шахаж, хадгалах хугацааг удирдаж байна. Гэвч үүний цаана үйлдвэрлэлийн орчинд өгөгдөл алдахад хүргэх ноцтой алдаанууд нуугдаж байдаг.

Аюул 1: Чимээгүй алдаанууд ба дамжуулах хоолойн урхи

DIY скриптүүдийн хамгийн хортой аюулуудын нэг бол чимээгүй алдаа юм. Дээрх скриптэд mysqldump команд нь шууд gzip рүү дамжуулагддаг (|).

Bash-д дамжуулах хоолойн (pipeline) гаралтын статус нь дамжуулах хоолойн сүүлийн командын гаралтын статус байдаг. Хэрэв өгөгдлийн сангийн сервер санах ой дуусч, холболт тасарч эсвэл дампын дундуур түгжигдсэн хүснэгттэй таарвал mysqldump амжилтгүй болж алдаа гаргана. Гэсэн хэдий ч gzip нь хүлээн авсан хэсэгчилсэн гаралтыг амжилттай шахаж, 0 (амжилттай) статус кодтойгоор дуусгана.

Cron job-ын гаралтын кодыг шалгадаг таны хяналтын систем нөөцлөлт амжилттай болсон гэж мэдээлнэ. Танд диск дээр хүчинтэй .gz файл байх боловч дотор нь тасалдалтай, хэрэггүй SQL файл байх болно. Та үүнийг чухал сэргээлт хийх гэж оролдох хүртлээ олж мэдэхгүй.

Засах арга (ба түүний хязгаарлалт)

Инженерүүд ихэвчлэн Bash-д хатуу алдааг хянах аргыг идэвхжүүлж үүнийг засахыг оролддог:

set -e
set -o pipefail

set -o pipefail нь дамжуулах хоолойн аль нэг команд амжилтгүй болбол скриптийг зогсоохыг баталгаажуулдаг ч, энэ нь скриптийн эргэн тойронд бат бөх дохиолол, бүртгэл (logging) болон дахин оролдох механизмыг бий болгохыг шаарддаг. Сүлжээний түр зуурын алдаанаас болж шөнийн 2 цагт алдаа гарахад DIY скрипт зүгээр л зогсдог. Харин аж ахуйн нэгжийн платформууд эдгээр түр зуурын алдааг ухаалаг, өсөн нэмэгдэх давтамжтайгаар дахин оролдох замаар шийдвэрлэдэг.

Аюул 2: Өгөгдлийн бүрэн бүтэн байдал ба түгжигдэх хар дарсан зүүд

DIY скриптүүд нь логик нөөцлөлтөд (mysqldump, pg_dump) ихээхэн найддаг. Логик нөөцлөлт нь бүх хүснэгтүүд дээр SELECT мэдэгдлүүдийг ажиллуулж өгөгдлийг гаргаж авдаг. Гүйлгээ ихтэй үйлдвэрлэлийн өгөгдлийн санд өгөгдөл байнга өөрчлөгдөж байдаг. Хэрэв скрипт 100GB өгөгдлийн санг дампинг хийхэд 45 минут зарцуулдаг бол дампын эхэн үеийн өгөгдөл нь төгсгөлийн өгөгдлөөс 45 минутаар хуучирсан байх бөгөөд энэ нь ACID нийцлийг зөрчинө.

MySQL Гүйлгээний бүрэн бүтэн байдал

InnoDB ашиглан MySQL-д тогтвортой агшин (snapshot) авахын тулд та тусгай тугуудыг (flags) ашиглах ёстой:

mysqldump --single-transaction --quick --routines --events -u user -p db > dump.sql

--single-transaction туг нь тусгаарлалтын түвшинг REPEATABLE READ болгож, дампинг хийхээс өмнө гүйлгээг эхлүүлдэг. Гэсэн хэдий ч, хэрэв таны өгөгдлийн санд хуучин MyISAM хүснэгтүүд байгаа бол энэ туг нь тэднийг түгжигдэхээс сэргийлж чадахгүй бөгөөд нөөцлөлт хийгдэж байх үед үйлдвэрлэлийн унших/бичих урсгалыг зогсоож болзошгүй. Түүнчлэн, нөөцлөлтийн үеэр хөгжүүлэгчдийн гүйцэтгэсэн аливаа ALTER TABLE, DROP TABLE, эсвэл RENAME TABLE мэдэгдлүүд нь REPEATABLE READ агшинг эвдэж, дампинг амжилтгүй болоход хүргэнэ.

PostgreSQL ба WAL Архивлалт

PostgreSQL-ийн хувьд pg_dump нь тогтвортой логик нөөцлөлтийг хангадаг боловч зөвхөн логик нөөцлөлт нь Цаг хугацааны цэгийн сэргээлтийг (PITR) хангаж чадахгүй. Хэрэв таны өгөгдлийн сан 16:00 цагт унаж, таны сүүлийн cron скрипт шөнө дунд ажилласан бол та 16 цагийн өгөгдлөө алдана.

PITR-д хүрэхийн тулд Write-Ahead Logs (WAL)-ийг тасралтгүй архивлах шаардлагатай. archive_command-ийг аюулгүй удирдах DIY скрипт бичих нь маш хэцүү байдаг.

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'

Хэрэв очих газар (/mnt/wal_archive/) дүүрэх эсвэл боломжгүй болбол archive_command амжилтгүй болно. Дараа нь PostgreSQL нь үндсэн диск дүүрэх хүртэл WAL файлуудыг дотооддоо хадгалж, өгөгдлийн сангийн бүрэн тасалдалд хүргэнэ. DIY скриптүүд нь WAL хуримтлалыг хянах, тасалдал гарахаас өмнө администраторуудад дохио өгөхөд шаардлагатай телеметрийг ховорхон агуулдаг.

Аюул 3: Хадгалах хугацааны рулет

Бидний анхны скрипт дэх хадгалах хугацааны командыг эргэн харъя:

find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Энэ бол өгөгдлийн гамшигт алдагдал болохыг хүлээж буй үйл явдал юм. Тохиргооны өөрчлөлтөөс болж mysqldump баталгаажуулалт эвдэрсэн гэж төсөөлөөд үз дээ. Скрипт шинэ нөөцлөлт үүсгэж чадахгүй байгаа ч find команд шөнө бүр ажиллаж, 30 хоногоос дээш хугацааны файлуудыг устгасаар байна.

Нөөцлөлт 30 хоногийн турш чимээгүйхэн амжилтгүй болсны дараа find команд таны хамгийн сүүлийн сайн нөөцлөлтийг устгах болно. Ингэснээр танд ямар ч нөөцлөлт үлдэхгүй.

CloudSave гэх мэт аж ахуйн нэгжийн нөөцлөлтийн программ хангамж нь төлөвт суурилсан хадгалах бодлогыг ашигладаг. Энэ нь “30 хоногоос дээш хугацааны нөөцлөлтийг устгах” болон “хуучин өгөгдлийг цэвэрлэхээс өмнө дор хаяж 30 амжилттай сэргээх цэг байгаа эсэхийг баталгаажуулах” хоёрын ялгааг ойлгодог.

Аюул 4: Аюулгүй байдал, шифрлэлт ба дагаж мөрдөх байдлын сохор толбо

Рансомвэр (ransomware) болон хатуу дагаж мөрдөх хүрээний (GDPR, HIPAA, SOC 2) эрин үед нөөцлөлтүүд нь гол бай болдог. DIY скриптүүд нь аюулгүй байдлын шилдэг туршлагуудыг байнга зөрчдөг:

  1. Хардкод хийсэн итгэмжлэлүүд: Өгөгдлийн сангийн нууц үгсийг энгийн текст скрипт эсвэл cron тодорхойлолтод хадгалах нь аюулгүй байдлын асар том эрсдэл юм. MySQL-ийн mysql_config_editor эсвэл PostgreSQL-ийн .pgpass файл зэрэг хэрэгслүүд үүнийг багасгадаг ч, тэдгээр нь сервер дээрх дотоод түлхүүрийн файлуудыг удирдахыг шаарддаг.
  2. Хадгалалтын үеийн шифрлэлт байхгүй: Түүхий SQL-ийг диск рүү буулгах нь эмзэг PII/PHI-г ил болгодог.
  3. Нарийн төвөгтэй шифрлэлтийн дамжуулах хоолойнууд: GPG ашиглан нөөцлөлтийг шууд шифрлэх оролдлого нь CPU-ийн ачааллыг нэмэгдүүлж, түлхүүрийн удирдлагын нарийн төвөгтэй байдлыг үүсгэдэг.
# DIY шифрлэгдсэн нөөцлөлтийн дамжуулах хоолой
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

Хэрэв сервер эвдэрвэл халдагч нь шифрлэгдсэн нөөцлөлт болон /etc/keys/backup.key файл хоёуланд нь хандах боломжтой болж, шифрлэлтийг хэрэггүй болгоно. Түүнчлэн, хэрэв GPG түлхүүрийг үүсгэсэн DBA компаниас гарч, түлхүүр алдагдвал нөөцлөлтийг сэргээх боломжгүй болно.

Аюул 5: RTO-ийн бодит байдлын шалгалт (Сэргээх нь нөөцлөхөөс илүү хэцүү)

Нөөцлөлтийн эцсийн шалгалт бол сэргээлт юм. DIY скриптүүдээр үүсгэгдсэн логик нөөцлөлтүүд нь сэргээхэд маш удаан байдаг. 500GB SQL дампыг үүсгэхэд 15 минут зарцуулагдаж болох ч, үүнийг сэргээхэд өгөгдлийн сангийн хөдөлгүүр SQL-ийг задлан шинжилж, индексүүдийг дахин бүтээж, хязгаарлалтуудыг дахин тооцоолох шаардлагатай болдог. Энэ нь хэдэн цаг, бүр хэдэн өдөр үргэлжилж, таны RTO-г үгүй хийж болзошгүй.

Томоохон үйлдвэрлэлийн өгөгдлийн сангуудын хувьд физик нөөцлөлт (бодит өгөгдлийн файлуудыг хуулах) заавал шаардлагатай. Percona XtraBackup эсвэл pg_basebackup гэх мэт хэрэгслүүд байдаг ч, тэдгээрийг DIY Bash скриптүүдэд оруулах нь маш нарийн төвөгтэй юм. Та LVM агшинг удирдах, файлын системийн тогтвортой байдлыг хангах, нөөцлөлтийг сүлжээний интерфейсийг дүүргэлгүйгээр гадагш шилжүүлэхийг баталгаажуулах ёстой.

LVM агшингийн урхи

Олон инженерүүд LVM агшин ашиглан “зогсолтгүй” (zero downtime) физик нөөцлөлт хийхийг оролддог:

# Агшин үүсгэх
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# Холбох (mount) болон хуулах
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

Хэрэв өгөгдлийн санд бичих I/O гэнэт ихсэх юм бол 20G LVM агшин тэр даруй дүүрч болно. LVM агшин дүүрэхэд хүчингүй болж, нөөцлөлт амжилтгүй болно. Үүнээс ч дор нь, их ачаалалтай LVM агшин нь үндсэн өгөгдлийн сангийн эзлэхүүний I/O гүйцэтгэлийг эрс бууруулж, програмын хоцролтыг үүсгэж болзошгүй.

Аж ахуйн нэгжийн түвшний хамгаалалт руу шилжих нь

DIY скриптүүдээс аж ахуйн нэгжийн платформ руу шилжих нь аливаа дэд бүтцийн багийн хувьд төлөвшлийн чухал үе шат юм. Зорилго нь “скрипт ажиллаасай гэж найдах”-аас сэргээх боломжтой гэдгийг криптографийн хувьд батлах руу шилжих явдал юм.

CloudSave гэх мэт платформууд нь DIY скриптийн сохор толбонуудыг арилгах зорилгоор тусгайлан бүтээгдсэн. Програмд мэдрэмтгий агентуудыг байршуулснаар CloudSave нь өгөгдлийн сангийн API-уудтай (MySQL, PostgreSQL, MS SQL, Oracle) шууд харилцаж, хүснэгтүүдийг түгжихгүйгээр эсвэл гүйцэтгэлийг бууруулахгүйгээр тогтвортой физик болон логик нөөцлөлтийг зохион байгуулдаг.

Скриптүүдээс татгалзахын гол давуу талууд:

  1. Автоматжуулсан баталгаажуулалт: Орчин үеийн платформууд зөвхөн нөөцлөлт хийдэггүй; тэдгээрийг шалгадаг. CloudSave нь түр зуурын өгөгдлийн сангийн жишээг автоматаар эхлүүлж, нөөцлөлтийг сэргээж, бүрэн бүтэн байдлын шалгалтуудыг (жишээ нь, DBCC CHECKDB) ажиллуулж, нөөцлөлт нь үнэхээр ашиглах боломжтой гэсэн баталгаажуулсан тайланг гаргаж өгдөг.
  2. Өөрчлөгдөшгүй (Immutable) хадгалалт: Рансомвэртэй тэмцэхийн тулд нөөцлөлтүүд өөрчлөгдөшгүй байх ёстой. DIY скриптүүд нь WORM (Write Once, Read Many) хадгалалт руу хялбархан бичиж чадахгүй. Аж ахуйн нэгжийн шийдлүүд нь S3 Object Lock болон өөрчлөгдөшгүй үүлэн хадгалалттай шууд нэгддэг бөгөөд энэ нь сервер бүрэн эвдэрсэн ч нөөцлөлтийг халдагч устгах эсвэл шифрлэх боломжгүй гэдгийг баталгаажуулдаг.
  3. Хялбаршуулсан PITR: Нарийн төвөгтэй recovery.conf эсвэл postgresql.auto.conf параметрүүдийг ашиглан үндсэн нөөцлөлт болон олон зуун WAL файлуудыг гараар нэгтгэхийн оронд платформууд нь харааны цагийн хуваарийг өгдөг. Та зүгээр л сэргээхийг хүсч буй яг тодорхой минутаа сонгоход программ хангамж нь бүртгэлийн дахин тоглуулалтыг (log replay) автоматаар зохицуулдаг.
  4. Давхардалгүй болгох (Deduplication) болон шахалт: DIY скриптүүд нь файл бүрийг тус тусад нь шахах gzip-д найддаг. Аж ахуйн нэгжийн нөөцлөлтийн программ хангамж нь дэлхийн хэмжээний блок түвшний давхардалгүй болгох аргыг ашигладаг бөгөөд энэ нь нөөцлөлтийг гадагш шилжүүлэх үед хадгалах зардал болон сүлжээний зурвасын өргөнийг эрс бууруулдаг.

Дүгнэлт

Өгөгдлийн санг нөөцлөх тусгай Bash скрипт бичих нь амархан. Харин дамжуулах хоолойн чимээгүй алдааг зохицуулдаг, ACID нийцлийг баталгаажуулдаг, криптографийн түлхүүрүүдийг аюулгүй удирддаг, хадгалах хугацаанд суурилсан өгөгдлийн алдагдлаас сэргийлдэг, мөн хатуу RTO/RPO SLA-г баталгаажуулдаг скрипт бичих нь бараг боломжгүй юм.

Үйлдвэрлэлийн орчинд өгөгдлийн сан нь бизнесийн хамгийн чухал хөрөнгө юм. Түүний хамгаалалтыг хэдэн зуун мөр shell скриптээр хадгалагддаг хажуугийн төсөл гэж үзэх нь ямар ч аж ахуйн нэгжийн хувьд эрсдэлтэй. Одоогийн нөөцлөлтийн стратегиа аудитад оруулж, логик дампын хязгаарлалтыг ойлгож, CloudSave гэх мэт бат бөх, автоматжуулсан платформууд руу шилжсэнээр DevOps болон DBA багууд тусгай скриптүүдийн “автобусны хүчин зүйл”-ийг (bus factor) арилгаж, өгөгдлөө үнэхээр уян хатан байлгах боломжтой.

Ангилал