Asosiy kontentga o‘tish
Innovialabs

VPS snapshot va backup: farqi nimada va nega ikkalasi kerak

Asoslar3 daq

Qisqacha

Snapshot — o‘sha provayder ichida saqlanadigan butun diskning tezkor nusxasi, muvaffaqiyatsiz yangilanishdan keyin orqaga qaytish uchun qulay; backup esa fayllar va ma’lumotlar bazalarining boshqa joydagi mustaqil nusxasi bo‘lib, server, akkaunt yoki provayder yo‘qolganda ham saqlanib qoladi. Ikkalasi ham kerak.

Qisqa javob: snapshot — orqaga qaytish uchun, backup — qutqarish uchun

Snapshot — VPS diskining ma’lum bir lahzadagi to‘liq surati: operatsion tizim, sozlamalar, kod va ma’lumotlar. U provayder panelida bir-ikki bosishda yaratiladi va undan butun serverni tezda tiklash yoki nusxasini ochish mumkin.

Backup (zaxira nusxa) qat’iy ma’noda — muhim ma’lumotlarning server va provayderdan alohida saqlanadigan va tekshirilgan tartib bo‘yicha tiklanadigan mustaqil nusxasi.

Snapshot «kechagi holatga qanday tez qaytaman» degan savolga javob beradi. Backup esa «server yo‘q bo‘lsa, ma’lumotlarni qanday saqlab qolaman» degan savolga.

Snapshot nimani saqlaydi va qayerda turadi

  • U blokli qurilmani butunligicha nusxalaydi — qaysi bloklar fayl, qaysilari keraksiz ekanini ajratmaydi.
  • Odatda inkremental bo‘ladi: birinchi snapshot to‘liq, keyingilari faqat o‘zgargan bloklarni saqlaydi.
  • U o‘sha provayder infratuzilmasida saqlanadi, ko‘pincha o‘sha regionda va doim o‘sha akkauntda.
  • Tiklash — butun diskni orqaga qaytarish yoki obrazdan yangi server yaratish. Bitta faylni chiqarib olish ko‘pincha noqulay.

Asosiy xulosa: snapshot qulay, lekin bitta provayderdagi bitta akkauntga bog‘langan.

Nega o‘sha provayderdagi snapshot haqiqiy backup emas

Butun akkaunt yoki provayderga ta’sir qiladigan holatlarda snapshot yordam bermaydi:

  • Akkaunt buzib kirilsa. Panelga kirgan hujumchi serverlarni ham, snapshotlarni ham o‘chiradi.
  • Bloklash yoki to‘lanmagan hisob. Akkaunt muzlatiladi — hech narsaga kirish imkoni qolmaydi.
  • Server o‘chirilsa. Ba’zi provayderlarda avtomatik nusxalar serverga bog‘langan va u bilan birga yo‘qoladi.
  • Ma’lumotlardagi xato. Buzilgan yoki o‘chirilgan yozuvlar bir haftadan keyin sezilsa-yu, snapshotlar uch kun saqlansa, qaytadigan joy qolmaydi.
  • Data-markaz yoki regiondagi nosozlik. Kamdan-kam bo‘ladi, ammo o‘sha regiondagi nusxalar server bilan birga mavjud bo‘lmay qolishi mumkin.

Ma’lumotlar bazalaridagi izchillik muammosi

Ishlab turgan serverning snapshoti taxminan elektr kabelini sug‘urib olishga o‘xshaydi: nusxa crash-consistent bo‘ladi. Baza fayllari yozish jarayonining o‘rtasida qolgan bo‘lishi mumkin.

  • PostgreSQL va MySQL (InnoDB) odatda jurnal orqali tiklanadi, lekin bu kafolat emas, ayniqsa ma’lumotlar bir nechta diskka taqsimlangan bo‘lsa.
  • Ishonchliroq yo‘l — MBBTning o‘z vositalari bilan mantiqiy dump olish yoki jurnal arxivi (WAL, binlog) bilan fizik backup qilish.
  • Aynan izchil snapshot kerak bo‘lsa, yozishni qisqa muddatga to‘xtatishadi: xizmatni to‘xtatish yoki snapshot vaqtida fayl tizimini muzlatish (fsfreeze).
# PostgreSQL: bazani to‘xtatmasdan izchil dump
pg_dump -Fc -d app_db -f /backup/app_db.dump

# MySQL/InnoDB: bitta tranzaksiya ichida dump
mysqldump --single-transaction --routines app_db > /backup/app_db.sql

Snapshot va backupni qanday birlashtirish kerak

Ko‘pchilik loyihalar uchun ishlaydigan sxema:

  1. Provayderning avtomatik snapshotlari — har kuni, bir necha kun saqlanadi. Har bir yirik yangilanishdan oldin qo‘lda snapshot ham qiling.
  2. Ma’lumotlar bazasi dumplari jadval bo‘yicha — kamida kuniga bir marta, muhim ma’lumotlar uchun tez-tez yoki jurnalni uzluksiz arxivlash bilan.
  3. Fayllar backupi — foydalanuvchi yuklamalari, konfiglar va maxfiy kalitlar restic yoki borg kabi vositalar bilan, shifrlangan holda.
  4. Tashqi ombor — boshqa provayderdagi yoki alohida hisob ma’lumotlariga ega boshqa akkauntdagi obyektli ombor. Server u yerga faqat yoza olishi, lekin o‘chira olmasligi kerak.
  5. Saqlash siyosati — masalan, kunlik nusxalar bir hafta, haftalik nusxalar bir oy, oylik nusxalar bir yil saqlanadi. Talablaringizga moslang.
  6. Monitoring — backup bajarilmasa, buni avariya kuni emas, darhol bilasiz.

Sinov tiklash — majburiy qism

Hech qachon tiklab ko‘rilmagan backup — himoya emas, umid. Muntazam ravishda:

  • toza server ochib, unga baza dumpi va fayllarni tiklang;
  • ilova ishga tushishini va ma’lumotlar dolzarb ekanini tekshiring;
  • tiklash vaqtini o‘lchang — bu sizning haqiqiy RTO ko‘rsatkichingiz;
  • qadamlarni qisqa yo‘riqnomaga yozib qo‘ying, toki tiklashni faqat bitta odam bilmasin.

Ko‘p uchraydigan xatolar

  • Provayderning avtomatik snapshotlarini yagona himoya deb hisoblash.
  • Backuplarni o‘sha serverning boshqa bo‘limida saqlash.
  • Serverga tashqi nusxalarni o‘chirish huquqini berish.
  • Shaxsiy ma’lumotlar va kalitlar bor backuplarni shifrlamaslik.
  • Tiklashni bir marta ham tekshirmaslik.

Ko‘p beriladigan savollar

Odatda kunlik avtomatik snapshot yetarli, bundan tashqari tizim yangilanishlari va yirik deploylardan oldin qo‘lda snapshot oling. Baza backupi chastotasini qancha ma’lumot yo‘qotishga tayyor ekaningiz belgilaydi.

Bunda yordam beramiz

O‘zingiz shug‘ullanmasdan natija olishni istasangiz — biz har kuni shu bilan shug‘ullanamiz.

Loyihani muhokama qilish

Yana o‘qing

G‘oya yoki vazifangiz bormi? Bizga aytib bering

Ish kuni davomida javob beramiz va yechim taklif qilamiz. Konsultatsiya bepul.