VPS zaxira nusxasini tiklashni sinab ko‘ring
Zaxira nusxa VPS’dan tashqarida olinib, kutilgan fayllar tiklanganda foyda beradi. Ushbu mashq statik sahifa va bitta Nginx konfiguratsiyasini arxivlaydi, boshqa kompyuterga ko‘chiradi va ishlayotgan saytga tegmasdan baytlarni tekshiradi.
VPSuntu · Yangilandi: · O‘qish: taxminan 5 daqiqa
Qo‘llanma mazmuni
Kichik tiklash mashqining chegarasini belgilang
Ubuntu yoki Linux/WSL mijozida Bash, GNU tar, sha256sum va OpenSSH kerak. Server buyruqlarini bitta server terminalida, mijoz buyruqlarini boshqa kompyuterdagi bitta terminalda bajaring. O‘zgaruvchilar saqlanishi uchun terminallarni ochiq qoldiring. Har qanday buyruq xatosidan keyin to‘xtang.
Mashq home katalogida ikkita vaqtinchalik fayl ishlatadi. Nginx, firewall va faol kontent o‘zgarmaydi; arxiv root sifatida ochilmaydi. Avval sinov fayllaridan boshlang. Ixtiyoriy almashtirish faqat statik HTTPS qo‘llanmasidagi ikki faylga tegishli.
Katta saytda asset, redirect, include konfiguratsiya, DNS va bog‘liqliklarni alohida ro‘yxatlang. Ikki faylli misol butun mashina yoki ilovaning to‘liq backup’i emas.
Saytni o‘zgartirmay ikkita fayl tayyorlang
Serverda xususiy mashq katalogini yarating. Quyidagi konfiguratsiya faqat arxivlash uchun fayl, yoqiladigan xizmat konfiguratsiyasi emas.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"Ixtiyoriy ravishda haqiqiy qo‘llanma sahifasi va server block’ini olish uchun faqat ushbu vaqtinchalik nusxalarni pastdagi buyruq bilan almashtiring. Ikkala manba ham hisobingizga o‘qiladigan bo‘lsin. Sirli ma’lumot borligini tekshiring, fayllar bir xil relizga tegishli bo‘lishi uchun yig‘ish paytida deploy’ni to‘xtatib turing. Oddiy sinov fayllari bilan mashqda bu blokni o‘tkazing.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"Bu buyruqlar faol manbani o‘qiydi, o‘zgartirmaydi. TLS yopiq kalitlari yoki butun tizim kataloglari ko‘chirilmaydi. Haqiqiy saytning boshqa fayllarini ham ro‘yxat va checksum manifest’iga ataylab kiriting.
Arxiv va ikki darajadagi checksum yarating
Serverda tanlangan fayllarning checksum’larini yozing, relative yo‘llar bilan arxivlang va arxiv checksum’ini oling. Shu paytda payload o‘zgarmasin.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"Ro‘yxatda site/, nginx/, ikki tanlangan fayl va SHA256SUMS bo‘lsin. Tashqi checksum ko‘chirilgan arxiv o‘zgarmaganini, ichki manifest esa ochilgan fayllarni tekshiradi. Kimdir faylni ham, kutilgan checksum’ni ham almashtira olsa, bu tekshiruv backup manbasining haqiqiyligini tasdiqlamaydi.
Nusxani boshqa kompyuterga ko‘chiring
Mijoz kompyuterida remote_backup’ga server chiqargan aniq export katalogini qo‘ying. Manzil, foydalanuvchi va kalitni ishlaydigan SSH qiymatlaringizga almashtiring. 203.0.113.10 hujjat manzili; REPLACE — placeholder, mktemp yaratgan haqiqiy suffix emas.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"Yangi host fingerprint’ini ishonchli yo‘l bilan tasdiqlang. SSH xatosida diagnostika qo‘llanmasini ishlating; ko‘chirish o‘tsin deb host tekshiruvini o‘chirmang.
SCP uzatishni SSH bilan himoyalaydi. tar.gz siqilgan, lekin shifrlangan emas; manzil hisobini va diskni himoyalang, kerak bo‘lsa saqlashdagi shifrlashni qo‘llang. Xuddi shu VPS’dagi ikkinchi papka mustaqil tashqi nusxa hisoblanmaydi.
Tekshiring va yangi bo‘sh katalogda tiklang
Mijozda arxivni ochishdan oldin tekshiring. sha256sum OK degandagina davom eting. Xato bo‘lsa, sababni aniqlang yoki qayta ko‘chiring; kutilgan checksum’ni almashtirib xatoni yashirmang.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Faqat shu ishonchli arxivni yangi katalogga oching. Keep-old-files mavjud fayl ustiga yozishni rad etadi; no-same-owner arxiv egalarini qayta qo‘llamaydi. Manzilni / qilib o‘zgartirmang va sudo bilan ochmang.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"site/index.html va nginx/first-site.conf uchun OK hamda tiklangan sahifa sarlavhasini kuting. Bu fayl mazmunini tasdiqlaydi, production owner, ACL, xizmat mavjudligi yoki barcha bog‘liqliklarni emas.
Fayl tiklanishi va xizmat tiklanishini ajrating
Tiklangan konfiguratsiya hali faollashtirilmagan matn faylidir. Alohida almashtiruvchi serverda yo‘llar, include, modullar, ruxsat va sertifikatlarni tekshiring. O‘sha yerda yig‘ilgan Nginx konfiguratsiyasini reload’dan oldin tekshiring, keyin HTTP/HTTPS’ni tashqaridan sinang. Eski ishlayotgan serverdagi syntax check tiklangan nusxani tekshirmaydi.
Arxiv TLS yopiq kalitlarini ataylab olmaydi. Sertifikatni qayta chiqarish yoki alohida himoyalangan nusxa rejasini tuzing. Faol baza fayllarini shu tar usuli bilan olmang; bazaning mos consistent backup va restore tartibini ishlating.
Provayder snapshot’i mashinani qaytarishga yordam berishi mumkin. Retention, birgalikda yo‘qolish xavfi va tiklash usulini tekshiring. Snapshot borligi eksport qilingan sayt boshqa host’da tiklanishini isbotlamaydi.
Tiklash maqsadi va natijasini yozing
RPO vaqt bilan ifodalangan maqbul ma’lumot yo‘qotilishi, RTO esa xizmatni tiklash uchun maqsadli vaqtdir. Kichik statik sayt uchun 24 soatlik RPO va 60 daqiqalik RTO tanlanishi mumkin; ular biznes misoli, ushbu mashqda o‘lchangan natija emas. Kundalik backup faqat nusxalar muvaffaqiyatli va tiklanadigan bo‘lsa maqsadga xizmat qiladi.
Kichik ekranda barcha ustunlarni ko‘rish uchun jadvalni yon tomonga suring.
| Qayd | Nimani ko‘rsatadi |
|---|---|
| Backup vaqti va reliz ID | Qaysi versiya tiklanishi mumkin |
| Mustaqil manzil va retention | Nusxa qayerda va qancha saqlanadi |
| Arxiv va fayl checksum natijalari | Tanlangan baytlar tiklanganmi |
| Tiklash boshlangan va tugagan vaqt | Belgilangan bosqichlarga ketgan vaqt |
| Yetishmagan fayl, ruxsat yoki bog‘liqlik | Xizmat uchun yana nima kerak |
| Yangi serverda tashqi HTTPS tekshiruvi | Sayt amalda qaytdimi |
RTO erishiladigan deyishdan oldin kirish, provisioning, sozlash, sertifikat va kerakli DNS bilan butun almashtirish jarayonini o‘lchang. Tez mahalliy arxiv ochish uzilishdan tiklanish benchmark’i emas. Bir necha mos tiklash nuqtasini saqlang, backup xatolarini kuzating va hostingning tiklash mezonlarini solishtiring.
Ko‘p so‘raladigan savollar
Backup’ni isbotlash uchun asl saytni o‘chiraymi?
Kerak emas. Alohida bo‘sh katalogga ochib manifest’ni tekshirish uzilishsiz fayl nusxasini sinaydi. To‘liq xizmatni boshqa almashtiruvchi muhitda tekshiring.
Checksum muvaffaqiyati butun sayt nusxalanganini bildiradimi?
U faqat manifest’dagi fayllarni tasdiqlaydi. Tushib qolgan asset, baza, sirli sozlama yoki DNS’ni topmaydi. Ro‘yxat yuriting va xizmat tiklangach haqiqiy funksiyalarini sinang.