VPS بیک اپ اور بحالی کی مشق کریں
بیک اپ اس وقت مفید ہے جب VPS سے باہر مل سکے اور مطلوبہ files واپس لا سکے۔ یہ مشق ایک static page اور Nginx config کو archive کرکے الگ کمپیوٹر پر copy اور checksum سے verify کرتی ہے۔ چلتی ویب سائٹ اور فعال configuration تبدیل نہیں ہوتی۔
VPSuntu · تازہ کاری · تقریباً 5 منٹ
اس مضمون میں
مشق کا محدود دائرہ سمجھیں
Bash، GNU tar، sha256sum اور OpenSSH استعمال ہوں گے۔ Server-labelled commands ایک server terminal میں اور client commands الگ کمپیوٹر کے Linux/WSL terminal میں چلائیں۔ دونوں کھلے رکھیں تاکہ variables باقی رہیں۔ کسی command error کے بعد رکیں۔
پہلے home directory کی دو disposable files استعمال کریں۔ Extraction کبھی root کے طور پر نہیں۔ اختیاری substitution صرف static HTTPS tutorial کی دو files لیتا ہے۔
بڑی site کے assets، redirects، included configuration، DNS اور dependencies کی الگ inventory چاہیے۔ یہ دو-file مثال پورے server، database یا ایپ کا بیک اپ نہیں۔
ویب سائٹ بدلے بغیر دو files تیار کریں
Server پر private practice directory بنائیں۔ نیچے configuration صرف archive کرنے کی file ہے، service میں activate نہیں کرنی۔
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"اختیاری: tutorial کا actual page اور server block لینا ہو تو صرف disposable copies کو اگلے commands سے بدلیں۔ دونوں sources اپنے account سے readable ہوں۔ Secrets کے لیے config پڑھیں اور collection کے دوران deployment روکیں تاکہ ایک release ملے۔ Fixture exercise میں یہ block چھوڑ دیں۔
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"اصل files صرف پڑھی جاتی ہیں۔ Certificate private keys اور مکمل system directories copy نہیں ہوتیں۔ دوسری ضروری files جان بوجھ کر inventory اور checksum manifest دونوں میں شامل کریں۔
Archive اور دو سطح کے checksums
Server پر منتخب files کے checksums لکھیں، relative paths والا archive بنائیں، پھر archive کا checksum لیں۔ اس دوران payload نہ بدلیں۔
(
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"Listing میں site/، nginx/، دو منتخب files اور SHA256SUMS ہونے چاہییں۔ Archive checksum منتقل شدہ archive میں تبدیلی، اندرونی manifest extracted files دیکھتا ہے۔ اگر کوئی data اور expected checksum دونوں بدل سکے تو checksum اکیلا authenticity ثابت نہیں کرتا۔
الگ کمپیوٹر پر copy کریں
Client پر remote_backup کو server کے دکھائے ہوئے exact export directory سے بدلیں۔ Sample address، account اور key اپنی working SSH details سے بدلیں۔ REPLACE placeholder ہے، mktemp کا اصل suffix نہیں۔
نیا SSH host trusted channel سے verify کریں۔ ناکامی پر SSH مسئلے کی جانچ کریں؛ transfer کے لیے host-key checking بند نہ کریں۔
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/"SCP، SSH کے ذریعے transfer محفوظ کرتا ہے۔ tar.gz خود compressed ہے، encrypted نہیں۔ Destination account/storage محفوظ کریں اور جہاں ضروری ہو encryption at rest رکھیں۔ اسی VPS کی دوسری directory، off-server copy نہیں ہے۔
نئی خالی directory میں verify اور restore
Client پر extraction سے پہلے archive checksum جانچیں۔ OK آئے تب آگے بڑھیں۔ Failure پر وجہ یا fresh transfer دیکھیں؛ expected checksum بدل کر غلطی نہ چھپائیں۔
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Trusted archive ایک نئی directory میں extract کریں۔ --keep-old-files موجودہ files بدلنے سے روکتا اور --no-same-owner archived ownership واپس لگانے سے بچاتا ہے۔ Destination کو / نہ بنائیں اور sudo سے extract نہ کریں۔
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 اور nginx/first-site.conf کے لیے OK اور واپس آئے page کا heading دیکھیں۔ یہ bytes کی تصدیق ہے، production ownership، ACLs، مکمل dependencies یا service availability کی نہیں۔
File recovery اور service recovery الگ ہیں
Restored Nginx configuration ابھی غیر فعال text file ہے۔ الگ replacement server پر paths، includes، modules، permissions اور certificates دیکھیں۔ وہاں assembled configuration validate کریں، reload کے بعد HTTP/HTTPS باہر سے جانچیں۔ موجودہ live server کا syntax check restored copy کا test نہیں۔
Archive میں TLS private keys دانستہ شامل نہیں۔ Certificate reissue یا الگ محفوظ key backup کی منصوبہ بندی کریں۔ Active database files اس tar recipe سے نہ لیں؛ database کا supported consistent backup/restore طریقہ اپنائیں۔
Provider snapshot machine recovery میں مدد دے سکتا ہے، مگر retention، failure domain اور actual restore procedure دیکھیں۔ Snapshot موجود ہونا exported files کی نئی machine پر recovery ثابت نہیں کرتا۔
Recovery اہداف اور نتیجہ ریکارڈ کریں
RPO وقت کی صورت میں قابل قبول data loss اور RTO service واپس لانے کا target وقت ہے۔ چھوٹی static site کے لیے 24-hour RPO اور 60-minute RTO مثالیں ہیں، اس مشق کے measured results نہیں۔ Daily schedule تب مفید ہے جب copies کامیاب اور قابل بحالی ہوں۔
چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔
| ریکارڈ | کیا معلوم ہوتا ہے |
|---|---|
| Backup وقت اور release | کون سا version واپس آئے گا |
| Independent location اور retention | Copy کہاں اور کب تک بچے گی |
| Archive اور file checksums | منتخب bytes درست واپس آئیں یا نہیں |
| Restore کا آغاز اور اختتام | مقررہ مرحلوں میں لگا وقت |
| غائب files، permissions، dependencies | Service بحالی کا باقی کام |
| Replacement پر بیرونی HTTPS | ویب سائٹ واقعی واپس آئی یا نہیں |
Access، provisioning، configuration، certificates اور DNS سمیت پورا replacement process ناپیں۔ Local extraction کا مختصر وقت outage-recovery benchmark نہیں۔ کئی restore points اور failed backup alerts رکھیں۔ Storage retention اور support کو VPS انتخاب میں شامل کریں۔
سوال جواب
کیا test کے لیے اصل ویب سائٹ حذف کر دوں؟
ضرورت نہیں۔ الگ خالی directory میں restore اور manifest check سے outage کے بغیر files جانچی جاتی ہیں۔ مکمل service الگ replacement environment میں آزمائیں۔
Checksum کامیاب ہو تو پورا site backed up ہے؟
صرف manifest میں درج files کی تصدیق ہوتی ہے۔ چھوٹا ہوا asset، database، secret یا DNS setting خود نہیں ملتا۔ Inventory رکھیں اور service restoration کے بعد actual functions آزمائیں۔