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.

Har bir ma’lumotlar bazasi ma’muri (DBA) va tizim muhandisi o’z faoliyati davomida qachondir ma’lumotlar bazasini zaxiralash uchun maxsus shell-skript yozgan. Bu deyarli o’tish marosimi kabidir. Loyihaning dastlabki bosqichlarida mysqldump yoki pg_dump buyruqlarini gzip ga yo’naltiruvchi oddiy cron vazifasi oqlangan, yengil va tejamkor yechimdek tuyuladi.

Biroq, infratuzilma kengayib, ma’lumotlar hajmi ortib va ish faoliyati (uptime) bo’yicha SLA talablari qattiqlashganda, o’sha 10 qatorli Bash skripti asta-sekin vaqtli bombaga aylanadi. Ishlab chiqarish muhitlari yuqori mavjudlik, qat’iy Tiklash Nuqtasi Maqsadlari (RPO) va tezkor Tiklash Vaqti Maqsadlarini (RTO) talab qiladi. Bunday muhitlarda o’z qo’lingiz bilan yozilgan (DIY) zaxira skriptlariga tayanish ma’lumotlar yaxlitligi, yashirin nosozliklar, xavfsizlik zaifliklari va boshqarib bo’lmaydigan tiklash jarayonlari bilan bog’liq jiddiy xavflarni keltirib chiqaradi.

Ushbu maqolada biz DIY ma’lumotlar bazasi zaxira skriptlarining arxitektura kamchiliklari va yashirin xavflarini tahlil qilamiz, mantiqiy va fizik zaxira nusxalarining texnik tuzoqlarini o’rganamiz hamda muhim ma’lumotlaringizni himoya qilish uchun CloudSave kabi korporativ darajadagi yechimlarga qanday o’tish kerakligini muhokama qilamiz.

Soddalik illyuziyasi: Klassik DIY skriptini tahlil qilish

Xavfni tushunish uchun avvalo odatiy DIY zaxira skriptining tuzilishiga qarashimiz kerak. MySQL ma’lumotlar bazasi uchun standart yondashuv ko’pincha quyidagicha ko’rinadi:

#!/bin/bash
# Oddiy DIY MySQL zaxira skripti
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 kundan eski zaxira nusxalarini o'chirish
find $BACKUP_DIR -type f -name "*.sql.gz" -mtime +30 -exec rm {} ;

Dastlabki qarashda bu skript o’z maqsadiga erishgandek: u ma’lumotlarni chiqaradi, siqadi va saqlash muddatini boshqaradi. Ammo uning ostida ishlab chiqarish muhitida ma’lumotlar yo’qolishiga olib keladigan jiddiy kamchiliklar yashiringan.

1-xavf: Yashirin nosozliklar va quvur (pipe) tuzog’i

DIY skriptlarining eng xavfli tomonlaridan biri bu yashirin nosozliklardir. Yuqoridagi skriptda mysqldump buyrug’i to’g’ridan-to’g’ri gzip ga yo’naltirilgan (|).

Bash-da quvur liniyasining chiqish holati (exit status) quvur liniyasidagi oxirgi buyruqning chiqish holatidir. Agar ma’lumotlar bazasi serverida xotira tugab qolsa, ulanish uzilsa yoki dump jarayonining yarmida qulflangan jadvalga duch kelsa, mysqldump ishdan chiqadi va xatolik yuz beradi. Biroq, gzip o’zi qabul qilgan qisman ma’lumotni muvaffaqiyatli siqadi va 0 (muvaffaqiyat) holat kodi bilan yakunlanadi.

Cron vazifasining chiqish kodini tekshiruvchi monitoring tizimingiz zaxira nusxasi muvaffaqiyatli yaratilgani haqida xabar beradi. Diskda haqiqiy .gz fayli bo’ladi, lekin uning ichida chala va yaroqsiz SQL fayli bo’ladi. Buni siz faqat muhim tiklash jarayonini amalga oshirishga uringaningizda bilib olasiz.

Yengillashtirish (va uning chegaralari)

Muhandislar ko’pincha Bash-da qat’iy xatolarni boshqarishni yoqish orqali buni tuzatishga harakat qilishadi:

set -e
set -o pipefail

set -o pipefail quvur liniyasidagi har qanday buyruq ishdan chiqqanda skriptning to’xtashini ta’minlasa-da, u baribir skript atrofida mustahkam ogohlantirish, jurnal yuritish va qayta urinish mexanizmlarini qurishni talab qiladi. Tarmoqdagi vaqtinchalik xatolik soat 02:00 da nosozlikka olib kelganda, DIY skripti shunchaki to’xtab qoladi. Korporativ platformalar esa bunday vaqtinchalik xatolarni aqlli, eksponentsial qayta urinishlar bilan hal qiladi.

2-xavf: Ma’lumotlar yaxlitligi va qulflash dahshatlari

DIY skriptlari asosan mantiqiy zaxira nusxalariga (mysqldump, pg_dump) tayanadi. Mantiqiy zaxira nusxalari barcha jadvallar bo’ylab SELECT so’rovlarini bajarish orqali ma’lumotlarni chiqaradi. Yuqori tranzaksiyali ishlab chiqarish bazasida ma’lumotlar doimiy ravishda o’zgarib turadi. Agar skript 100 GB hajmli bazani dump qilish uchun 45 daqiqa sarflasa, dump boshidagi ma’lumotlar oxiridagi ma’lumotlardan 45 daqiqa eskiroq bo’ladi, bu esa ACID muvofiqligini buzadi.

MySQL Tranzaksiya yaxlitligi

InnoDB yordamida MySQL-da izchil (consistent) snapshot olish uchun siz maxsus bayroqlardan foydalanishingiz kerak:

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

--single-transaction bayrog’i izolyatsiya darajasini REPEATABLE READ ga o’rnatadi va dump qilishdan oldin tranzaksiyani boshlaydi. Biroq, agar bazangizda hali ham eski MyISAM jadvallari bo’lsa, bu bayroq ularning qulflanishiga to’sqinlik qila olmaydi va zaxiralash jarayonida ishlab chiqarishdagi o’qish/yozish trafikini to’xtatib qo’yishi mumkin. Bundan tashqari, zaxiralash vaqtida dasturchilar tomonidan bajarilgan har qanday ALTER TABLE, DROP TABLE yoki RENAME TABLE buyruqlari REPEATABLE READ snapshotini buzadi va dump jarayonini ishdan chiqaradi.

PostgreSQL va WAL arxivlash

PostgreSQL uchun pg_dump izchil mantiqiy zaxira nusxalarini taqdim etadi, ammo faqat mantiqiy zaxira nusxalari «Point-in-Time Recovery» (PITR) imkoniyatini bera olmaydi. Agar bazangiz soat 16:00 da ishdan chiqsa va oxirgi cron skriptingiz yarim tunda ishlagan bo’lsa, siz 16 soatlik ma’lumotni yo’qotasiz.

PITR ga erishish uchun «Write-Ahead Logs» (WAL) ni uzluksiz arxivlash talab qilinadi. archive_command ni xavfsiz boshqarish uchun DIY skriptini yozish juda qiyin.

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

Agar maqsadli xotira (/mnt/wal_archive/) to’lib qolsa yoki mavjud bo’lmasa, archive_command ishdan chiqadi. PostgreSQL keyin WAL fayllarini asosiy disk to’lguncha mahalliy darajada to’playdi, bu esa ma’lumotlar bazasining to’liq ishdan chiqishiga olib keladi. DIY skriptlarida WAL to’planishini kuzatish va nosozlik yuz bermasdan oldin ma’murlarni ogohlantirish uchun zarur bo’lgan telemetriya kamdan-kam hollarda bo’ladi.

3-xavf: Saqlash muddati ruletkasi

Dastlabki skriptimizdagi saqlash muddatini boshqarish buyrug’iga qayta qarang:

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

Bu halokatli ma’lumot yo’qotish hodisasining yuz berishini kutishdir. Tasavvur qiling, konfiguratsiya o’zgarishi mysqldump autentifikatsiyasini buzdi. Skript yangi zaxira nusxalarini yarata olmayapti, lekin find buyrug’i har kecha ishlashda davom etib, 30 kundan eski fayllarni o’chirib tashlayapti.

30 kunlik yashirin zaxira nosozliklaridan so’ng, find buyrug’i sizning oxirgi qolgan yaxshi zaxira nusxangizni ham o’chirib tashlaydi. Sizda endi umuman zaxira nusxasi qolmaydi.

CloudSave kabi korporativ zaxira dasturlari holatga asoslangan saqlash siyosatlaridan foydalanadi. U «30 kundan eski zaxiralarni o’chirish» va «eski ma’lumotlarni tozalashdan oldin kamida 30 ta muvaffaqiyatli tiklash nuqtasi mavjudligiga ishonch hosil qilish» o’rtasidagi farqni tushunadi.

4-xavf: Xavfsizlik, shifrlash va muvofiqlikdagi ko’r nuqtalar

Ransomware va qat’iy muvofiqlik tizimlari (GDPR, HIPAA, SOC 2) davrida zaxira nusxalari asosiy nishon hisoblanadi. DIY skriptlari ko’pincha xavfsizlikning eng yaxshi amaliyotlarini buzadi:

  1. Qattiq kodlangan ma’lumotlar: Ma’lumotlar bazasi parollarini oddiy matnli skriptlarda yoki cron ta’riflarida saqlash katta xavfsizlik xavfidir. MySQL-ning mysql_config_editor yoki PostgreSQL-ning .pgpass fayli kabi vositalar buni yumshatsa-da, ular hali ham serverdagi mahalliy kalit fayllarini boshqarishni talab qiladi.
  2. Saqlash vaqtida shifrlashning yo’qligi: Xom SQL ni diskka chiqarish sezgir PII/PHI ma’lumotlarini ochiq qoldiradi.
  3. Murakkab shifrlash quvurlari: GPG yordamida zaxira nusxalarini tezkor shifrlashga urinish protsessorga katta yuk va kalitlarni boshqarishda murakkabliklarni keltirib chiqaradi.
# DIY shifrlangan zaxira quvuri
pg_dump mydb | gzip | gpg --symmetric --cipher-algo AES256 --passphrase-file /etc/keys/backup.key > backup.sql.gz.gpg

Agar server buzib kirilsa, hujumchi ham shifrlangan zaxira nusxasiga, ham /etc/keys/backup.key fayliga kirish huquqiga ega bo’ladi, bu esa shifrlashni foydasiz qiladi. Bundan tashqari, agar GPG kalitini yaratgan DBA kompaniyani tark etsa va kalit yo’qolsa, zaxira nusxalarini tiklab bo’lmaydi.

5-xavf: RTO haqiqati (Tiklash zaxiralashdan ko’ra qiyinroq)

Zaxira nusxasining yakuniy sinovi uni tiklashdir. DIY skriptlari tomonidan yaratilgan mantiqiy zaxira nusxalarini tiklash juda sekin kechadi. 500 GB hajmli SQL dumpini yaratish 15 daqiqa vaqt olishi mumkin, ammo uni tiklash ma’lumotlar bazasi dvigatelidan SQL ni tahlil qilishni, indekslarni qayta qurishni va cheklovlarni qayta hisoblashni talab qiladi. Bu soatlab yoki hatto kunlab vaqt olishi mumkin, bu esa RTO maqsadlaringizni yo’qqa chiqaradi.

Katta ishlab chiqarish bazalari uchun fizik zaxira nusxalari (haqiqiy ma’lumotlar fayllarini nusxalash) majburiydir. Percona XtraBackup yoki pg_basebackup kabi vositalar mavjud bo’lsa-da, ularni DIY Bash skriptlariga o’rash juda murakkab. Siz LVM snapshotlarini boshqarishingiz, fayl tizimini to’xtatib turishingiz va zaxira nusxasi tarmoq interfeysini to’ldirmasdan tashqi manzilga o’tkazilishini ta’minlashingiz kerak.

LVM snapshot tuzog’i

Ko’pgina muhandislar LVM snapshotlari yordamida «nol ishlamay qolish vaqti» (zero downtime) bilan fizik zaxira nusxalarini olishga urinishadi:

# Snapshot yaratish
lvcreate --size 20G --snapshot --name db_snap /dev/vg0/db_vol

# Mount qilish va nusxalash
mount /dev/vg0/db_snap /mnt/snap
tar -czf /backups/db_physical.tar.gz /mnt/snap/mysql

Agar ma’lumotlar bazasida yozish I/O keskin oshsa, 20 GB hajmli LVM snapshot darhol to’lib qolishi mumkin. LVM snapshot to’lganda, u yaroqsiz holga keladi va zaxiralash muvaffaqiyatsiz tugaydi. Eng yomoni, intensiv foydalaniladigan LVM snapshotlari asosiy ma’lumotlar bazasi hajmining I/O unumdorligini keskin pasaytirishi va ilovada kechikishlarga olib kelishi mumkin.

Korporativ darajadagi himoyaga o’tish

DIY skriptlaridan korporativ platformaga o’tish har qanday infratuzilma jamoasi uchun muhim yetuklik bosqichidir. Maqsad «skript ishlashiga umid qilish»dan tiklanish imkoniyatining kriptografik isbotiga ega bo’lishga o’tishdir.

CloudSave kabi platformalar DIY skriptlarining ko’r nuqtalarini yo’q qilish uchun maxsus ishlab chiqilgan. Ilovani tushunadigan agentlarni joylashtirish orqali CloudSave to’g’ridan-to’g’ri ma’lumotlar bazasi API’lari (MySQL, PostgreSQL, MS SQL, Oracle) bilan o’zaro aloqada bo’lib, jadvallarni qulflamasdan yoki unumdorlikni pasaytirmasdan izchil fizik va mantiqiy zaxira nusxalarini tashkil qiladi.

Skriptlardan voz kechishning asosiy afzalliklari:

  1. Avtomatlashtirilgan tekshirish: Zamonaviy platformalar shunchaki zaxira nusxalarini olmaydi; ular ularni sinab ko’radi. CloudSave avtomatik ravishda vaqtinchalik ma’lumotlar bazasi instansini ishga tushirishi, zaxira nusxasini tiklashi, yaxlitlik tekshiruvlarini (masalan, DBCC CHECKDB) bajarishi va uni o’chirib tashlashi mumkin, bu esa zaxira nusxasining haqiqatan ham yaroqli ekanligi haqida tasdiqlangan hisobotni taqdim etadi.
  2. O’zgarmas (Immutable) xotira: Ransomware ga qarshi kurashish uchun zaxira nusxalari o’zgarmas bo’lishi kerak. DIY skriptlari WORM (Write Once, Read Many) xotirasiga osonlikcha yoza olmaydi. Korporativ yechimlar S3 Object Lock va o’zgarmas bulutli xotira bilan mahalliy darajada integratsiyalashgan bo’lib, server to’liq buzib kirilgan taqdirda ham zaxira nusxalari hujumchi tomonidan o’chirilmasligi yoki shifrlanmasligini ta’minlaydi.
  3. Soddalashtirilgan PITR: Murakkab recovery.conf yoki postgresql.auto.conf parametrlari yordamida asosiy zaxira nusxasi va yuzlab WAL fayllarini qo’lda birlashtirish o’rniga, platformalar vizual vaqt jadvalini taqdim etadi. Siz shunchaki tiklamoqchi bo’lgan aniq daqiqani tanlaysiz va dastur jurnalni qayta ijro etishni avtomatik ravishda amalga oshiradi.
  4. Deduplikatsiya va siqish: DIY skriptlari har bir faylni alohida siqadigan gzip ga tayanadi. Korporativ zaxira dasturlari global blok darajasidagi deduplikatsiyadan foydalanadi, bu esa zaxira nusxalarini tashqi manzilga o’tkazishda saqlash xarajatlarini va tarmoq o’tkazuvchanligini keskin kamaytiradi.

Xulosa

Ma’lumotlar bazasini zaxiralash uchun maxsus Bash skriptini yozish oson. Yashirin quvur nosozliklarini boshqaradigan, ACID yaxlitligini kafolatlaydigan, kriptografik kalitlarni xavfsiz boshqaradigan, saqlash muddatiga asoslangan ma’lumotlar yo’qolishining oldini oladigan va qat’iy RTO/RPO SLA talablarini ta’minlaydigan skriptni yozish esa deyarli imkonsizdir.

Ishlab chiqarish muhitlarida ma’lumotlar bazasi biznesning eng muhim aktividir. Uning himoyasini bir necha yuz qatorli shell skripti bilan boshqariladigan yon loyiha sifatida ko’rish hech bir korxona ko’tara olmaydigan xavfdir. Hozirgi zaxiralash strategiyalaringizni audit qilish, mantiqiy dump’larning cheklovlarini tushunish va CloudSave kabi mustahkam, avtomatlashtirilgan platformalarga o’tish orqali DevOps va DBA jamoalari maxsus skriptlarning «avtobus omili»ni (bus factor) yo’q qilishi va ma’lumotlarining haqiqatan ham chidamli bo’lishini ta’minlashi mumkin.

Bo’limlar