Zaxira nusxa va tiklash: 3-2-1 qoidasidan tiklash testigacha

Ko'p jamoalarda zaxira nusxa "bor" deb hisoblanadi: panelda avtomatik backup yoqilgan, har kecha qandaydir arxiv paydo bo'ladi. Lekin savol boshqacha qo'yilishi kerak: agar bugun server butunlay ishdan chiqsa yoki fayllar shifrlab qo'yilsa, tizimni qancha vaqtda va qaysi holatgacha tiklay olasiz? Bu savolga aniq javob bo'lmasa, zaxira nusxa aslida yo'q deb hisoblash xavfsizroq.

Bu maqolada zaxira nusxa strategiyasini qanday qurish, ma'lumotlar bazasini to'g'ri dump qilish, nusxalarni shifrlash va eng muhimi — tiklashni muntazam sinab ko'rishni ko'rib chiqamiz.

Muammo nimada

Zaxira nusxa bilan bog'liq odatiy xatolar texnik emas, balki tashkiliy:

• Nusxa o'sha serverda saqlanadi. Disk ishdan chiqsa yoki server buzilsa, asl ma'lumot ham, nusxa ham birga yo'qoladi.
• Nusxa doimo ulangan joyda turadi. Serverga kirgan buzg'unchi yoki shifrlovchi dastur (ransomware) ulangan tarmoq diskini ham, bulut papkasini ham ko'radi va ularni ham o'chiradi yoki shifrlaydi.
• Nusxa shifrlanmagan. Arxivda ma'lumotlar bazasi, .env fayli, foydalanuvchilarning shaxsiy ma'lumotlari bor. Arxiv sizib chiqsa, bu to'liq ma'lumot oqishi bilan teng.
• Tiklash hech qachon sinab ko'rilmagan. Arxiv buzilgan, dump yarim yozilgan yoki tiklash tartibini hech kim bilmaydi — bu odatda eng noqulay paytda ma'lum bo'ladi.
• Faqat fayllar nusxalanadi, baza esa yo'q (yoki aksincha). Ishlab turgan baza fayllarini oddiy nusxalash ko'pincha yaxlit bo'lmagan holatni beradi.

Nega bu ekspertiza uchun muhim

Rasmiy kiberxavfsizlik ekspertizasi asosan zaifliklarni qidiradi, lekin server konfiguratsiyasi va axborot xavfsizligini ta'minlash choralari ham ko'rib chiqiladi. Zaxira nusxa bilan bog'liq topilmalar ikki xil ko'rinishda bo'ladi:

1. Ma'lumot ochiqlanishi. Veb-papkada qolgan backup.zip, db.sql, site.tar.gz kabi fayllar brauzer orqali yuklab olinishi mumkin. Bunday faylni topish uchun skanerlar odatiy nomlarni tekshiradi, shuning uchun bu tez aniqlanadi.
2. Tiklanuvchanlik. Tizimning hodisadan keyin ishga qaytishi — xavfsizlikning bir qismi. Ma'lumotlar yaxlitligi va mavjudligi xavf ostida bo'lgan joyda zaxira va tiklash tartibi hujjatlashtirilgan bo'lishi kutiladi.

Asosiy qoida: zaxira nusxa — bu arxiv emas, balki tiklash imkoniyati. Tekshirilmagan nusxa — taxmin.

3-2-1 qoidasi

Keng tarqalgan va sodda printsip:

• 3 nusxa ma'lumot: asl ma'lumot va ikkita zaxira;
• 2 xil saqlash vositasida (masalan, server diski va obyekt saqlash xizmati);
• 1 nusxa boshqa joyda (boshqa data-markaz, boshqa provayder yoki ofisdagi oflayn disk).

Bugungi kunda bunga yana bir talab qo'shiladi: kamida bitta nusxa oflayn yoki o'zgartirib bo'lmaydigan (immutable) bo'lishi kerak. Bu shifrlovchi dasturga qarshi asosiy himoya: serverga to'liq kirish huquqini olgan buzg'unchi ham bu nusxani o'chira olmasligi lozim.

Amalda immutable nusxa quyidagicha olinadi:

• obyekt saqlash xizmatida "object lock" yoki versiyalash funksiyasi va saqlash muddati;
• zaxira serveri nusxani o'zi "tortib oladi" (pull), asosiy server esa zaxira serveriga yozish huquqiga ega emas;
• faqat qo'shishga ruxsat beruvchi (append-only) rejim — masalan, restic yoki borg uchun shunday sozlangan repozitoriy;
• vaqti-vaqti bilan uzib qo'yiladigan tashqi disk.

Nimani nusxalash kerak

Ro'yxatni oldindan yozib qo'ying, chunki keyin "u ham kerak edi" degan narsalar chiqadi:

• ma'lumotlar bazasi (dump ko'rinishida);
• foydalanuvchi yuklagan fayllar (storage/app, uploads va h.k.);
• konfiguratsiya: nginx, PHP-FPM, cron, systemd unitlari, firewall qoidalari;
• .env va sirlar — alohida, kuchli shifrlangan holda;
• ilova kodi odatda git'da bor, lekin aynan qaysi versiya ishlayotgani qayd etilishi kerak.

Kesh, sessiya fayllari, vendor va node_modules papkalarini nusxalash shart emas — ular qayta tiklanadi.

O'zingiz tekshiring

Avval veb-papkada zaxira fayllari qolmaganini tekshiring:

find /var/www -type f \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.zip" \
  -o -name "*.tar.gz" -o -name "*.bak" -o -name "*.dump" \) 2>/dev/null

Tashqaridan ham sinab ko'ring (faqat o'z saytingizda):

for f in backup.zip backup.sql db.sql site.tar.gz dump.sql .env; do
  printf "%s " "$f"; curl -s -o /dev/null -w "%{http_code}\n" "https://example.uz/$f"
done

Javob 200 bo'lsa — fayl ochiq. Keyin quyidagi savollarga javob yozing: oxirgi nusxa qachon olingan, qayerda saqlanadi, kim uni o'chira oladi, oxirgi marta qachon undan tiklangan.

Ma'lumotlar bazasini to'g'ri dump qilish

PostgreSQL

pg_dump ishlab turgan bazadan yaxlit (izchil) nusxa oladi. Maxsus format (-Fc) siqilgan va tanlab tiklash imkonini beradi:

pg_dump -h 127.0.0.1 -U app_backup -Fc -f /backup/app_$(date +%F).dump appdb

Rollar va umumiy sozlamalar alohida saqlanadi:

pg_dumpall -h 127.0.0.1 -U postgres --globals-only > /backup/globals_$(date +%F).sql

Parolni buyruq qatorida yozmang — ~/.pgpass faylidan foydalaning (chmod 600).

MySQL / MariaDB

InnoDB jadvallari uchun --single-transaction jadvallarni bloklamasdan izchil nusxa beradi:

mysqldump --single-transaction --routines --triggers --events \
  -u app_backup appdb | gzip > /backup/appdb_$(date +%F).sql.gz

Login ma'lumotlarini ~/.my.cnf faylining [mysqldump] bo'limida saqlang. Zaxira uchun alohida, faqat o'qish va dump uchun kerakli huquqlarga ega foydalanuvchi yarating.

Katta bazalar uchun dump yetarli bo'lmasligi mumkin: PostgreSQL'da WAL arxivlash bilan ma'lum vaqt nuqtasiga tiklash (PITR), MySQL'da binlog bunday imkoniyat beradi. Kichik va o'rta loyihalar uchun esa kunlik dump va to'g'ri saqlash ko'pincha yetarli boshlanish nuqtasidir.

Shifrlash

Zaxira nusxa serverdan chiqishidan oldin shifrlanishi kerak. Ikki keng tarqalgan yo'l:

restic — shifrlashni o'zi bajaradi, deduplikatsiya va saqlash siyosatini qo'llab-quvvatlaydi:

export RESTIC_REPOSITORY=s3:https://s3.example.com/backups/app
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic backup /backup /var/www/app/storage/app /etc/nginx
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

age yoki gpg — oddiy arxivni ochiq kalit bilan shifrlash. Bu holda serverda faqat ochiq kalit turadi, shaxsiy kalit esa boshqa joyda saqlanadi — server buzilsa ham eski nusxalarni ochib bo'lmaydi:

tar -czf - /backup | age -r age1...publickey > /offsite/app_$(date +%F).tar.gz.age

Shifrlash kaliti yoki parolini zaxira bilan bir joyda saqlamang va uni yo'qotmang: kalitsiz nusxa — foydasiz nusxa. Kalitni ikki mas'ul shaxs biladigan xavfsiz joyda (parol menejeri, seyf) saqlang.

Avtomatlashtirish

Qo'lda olinadigan nusxa vaqt o'tishi bilan unutiladi. Oddiy cron yoki systemd timer yetarli:

# /etc/cron.d/app-backup
30 2 * * * backup /usr/local/bin/app-backup.sh >> /var/log/app-backup.log 2>&1

Skript muvaffaqiyatsiz tugasa, xabar kelishi kerak. Eng sodda usul — skript oxirida "tirik" signal yuboradigan monitoring (heartbeat): signal kelmasa, ogohlantirish chiqadi. Laravel loyihalarida spatie/laravel-backup paketi baza va fayllarni nusxalash, eski nusxalarni tozalash va xabar yuborishni bitta joyda boshqaradi.

Tiklash testi

Bu eng ko'p o'tkazib yuboriladigan va eng muhim qadam. Kamida oyda bir marta:

1. Alohida test serveri yoki konteyner tayyorlang (ishlab turgan tizimga tegmang).
2. Oxirgi nusxani yuklab oling va shifrini oching.
3. Bazani tiklang:

createdb -h 127.0.0.1 -U postgres restore_test
pg_restore -h 127.0.0.1 -U postgres -d restore_test --no-owner app_2026-10-24.dump
psql -h 127.0.0.1 -U postgres -d restore_test -c "SELECT count(*) FROM users;"

MySQL uchun:

gunzip -c appdb_2026-10-24.sql.gz | mysql -u root restore_test

4. Ilovani shu baza bilan ishga tushiring va asosiy amallarni bajaring: kirish, hujjat ochish, fayl yuklab olish.
5. Natijani yozib qo'ying: qancha vaqt ketdi, nima to'siq bo'ldi, qaysi qadam hujjatda yo'q edi.

Shu sinovdan ikki muhim ko'rsatkich chiqadi: RPO — qancha vaqtlik ma'lumotni yo'qotishga tayyorsiz (kunlik nusxa bo'lsa, bir kungacha), va RTO — tizimni qancha vaqtda qayta ishga tushira olasiz. Bu raqamlarni rahbariyat bilan kelishib oling.

Shifrlovchi dastur (ransomware) nuqtai nazaridan

Shifrlovchi hujumda buzg'unchi odatda avval zaxira nusxalarni topib yo'q qilishga harakat qiladi. Shuning uchun:

• asosiy serverda zaxira omboridan nusxa o'chirish huquqi bo'lmasin;
• zaxira omboriga kirish kalitlari asosiy serverdagi .env bilan bir xil bo'lmasin;
• kamida bitta nusxa immutable yoki oflayn bo'lsin;
• tiklashda buzilgan holatni qayta tiklab qo'ymaslik uchun hodisa sodir bo'lgan vaqtdan oldingi nusxani tanlang va tiklangan tizimdagi zaiflikni avval yoping.

Tiklashdan keyin barcha parollar va kalitlarni almashtirish ham tartibning bir qismi bo'lishi kerak.

Qisqa checklist

• Veb-papkada .sql, .zip, .tar.gz, .bak fayllari yo'q va ular tashqaridan ochilmaydi
• Nusxalanadigan narsalar ro'yxati yozilgan (baza, yuklangan fayllar, konfiguratsiya, sirlar)
• Baza pg_dump / mysqldump --single-transaction bilan izchil dump qilinadi
• 3-2-1: kamida bitta nusxa boshqa joyda, bittasi immutable yoki oflayn
• Nusxalar serverdan chiqishidan oldin shifrlanadi, kalit alohida saqlanadi
• Zaxira jarayoni avtomatik, muvaffaqiyatsizlik haqida xabar keladi
• Saqlash siyosati bor (kunlik, haftalik, oylik)
• Tiklash testi muntazam o'tkaziladi va natijasi yozib boriladi
• RPO va RTO kelishilgan

Xulosa

Yaxshi zaxira tizimi murakkab bo'lishi shart emas: kunlik izchil dump, shifrlash, boshqa joydagi immutable nusxa va oyiga bir tiklash testi kichik jamoa uchun ham bajariladigan ish. Bizning jarayonda Claude AI agenti server sozlamalari, cron vazifalari va veb-papkani ko'rib chiqib, ochiq qolgan arxivlar va yetishmayotgan qadamlarni aniqlaydi, mutaxassis esa zaxira va tiklash tartibini sozlab, sinovdan o'tkazadi.

Zaxira va tiklash tartibingiz ekspertizaga tayyorligini bilmoqchi bo'lsangiz, skanerlash uchun ariza qoldiring. Sizga ekspertizadan oldin teshiklarni yopishga yordam beramiz.