VPS बैकअप और रिस्टोर का अभ्यास करें
VPS बैकअप तभी उपयोगी है जब copy server से बाहर मिले और अपेक्षित files वापस लाई जा सकें। इस अभ्यास में एक static page और Nginx configuration का archive बनता है, दूसरे computer पर copy होता है और नई directory में bytes सत्यापित होते हैं। चालू वेबसाइट नहीं बदली जाती।
VPSuntu · अपडेट · लगभग 5 मिनट में पढ़ें
इस गाइड में
छोटे recovery अभ्यास की सीमा समझें
Bash, GNU tar, sha256sum और OpenSSH चाहिए। Server-labelled commands एक server terminal में और client-labelled commands अलग computer के एक terminal में चलाएँ। Variables बचाने के लिए terminals खुले रखें। Command error पर रुकें।
अपने home में दो disposable files इस्तेमाल होती हैं। Nginx, firewall या live content नहीं बदलता और extraction root के रूप में नहीं होता। Optional substitution केवल static HTTPS tutorial की दो files पढ़ता है।
बड़ी site के assets, redirects, included configs, DNS और dependencies की अलग inventory चाहिए। यह पूरे server या database का backup नहीं है।
वेबसाइट बदले बिना दो sample files बनाएँ
Server पर private practice directory बनाएँ। नीचे की Nginx configuration केवल archive करने के लिए file है; इसे enable नहीं करना है।
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"Optional: tutorial की वास्तविक page/configuration लेनी हों तो केवल practice copies बदलें। Sources readable हों, secrets की जाँच करें और समान release की copy के लिए deployment रोकें। Sample 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"इससे live sources पढ़े जाते हैं, बदले नहीं जाते। TLS private keys और पूरा filesystem शामिल नहीं हैं। अतिरिक्त files को inventory और checksum manifest में स्पष्ट रूप से जोड़ें।
Files और archive दोनों के checksums बनाएँ
Server पर selected files के checksums, relative-path 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 transfer में बदलाव पकड़ता है; अंदर का manifest extracted files जाँचता है। यदि कोई data और expected checksum दोनों बदल सके तो checksum अकेले authenticity नहीं देता।
अलग computer पर स्वतंत्र copy लें
Client पर remote_backup में server से छपा exact export directory path लगाएँ। Documentation IP, user और key filename बदलें। REPLACE placeholder है, mktemp का वास्तविक suffix नहीं।
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/"नया host स्वीकार करने से पहले trusted fingerprint मिलाएँ। SSH fail हो तो SSH troubleshooting करें; verification बंद करके transfer न चलाएँ।
SCP का transport SSH से सुरक्षित होता है, लेकिन tar.gz compression खुद encryption नहीं है। Destination account/storage का access तथा जरूरत के अनुसार encryption at rest तय करें। उसी VPS की दूसरी directory off-server backup नहीं है।
नई खाली directory में verify और restore करें
Client पर extraction से पहले archive checksum जाँचें। OK मिलने पर ही आगे बढ़ें। Failure को expected checksum बदलकर न छिपाएँ; source या transfer का कारण देखें।
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"अपने बनाए trusted archive को नई directory में निकालें। Keep-old-files existing 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 तथा recovered heading अपेक्षित हैं। इससे listed file content की जाँच होती है; production ownership, ACL, availability या बाकी dependencies की नहीं।
File restore और service recovery अलग हैं
Restored config अभी inactive text है। अलग replacement server पर paths, includes, modules, permissions और certificates मिलाएँ। वहाँ assembled Nginx config validate करके reload और बाहरी HTTP/HTTPS जाँच करें। Unchanged live Nginx का syntax test restored copy की परीक्षा नहीं है।
TLS keys इस archive में नहीं हैं; अलग protected backup या certificate reissuance तय करें। Active database files पर यही tar recipe न चलाएँ—database की consistent backup/restore प्रक्रिया इस्तेमाल करें।
Snapshot मशीन वापस लाने में मदद कर सकता है, पर retention, failure domain और restore procedure देखें। Snapshot मौजूद होने से दूसरे host पर exported files की recovery साबित नहीं होती।
Recovery लक्ष्य और वास्तविक परिणाम लिखें
RPO समय के रूप में स्वीकार्य data loss है; RTO service वापस लाने का target समय है। छोटी static site के लिए 24-hour RPO और 60-minute RTO उदाहरण हो सकते हैं, इस अभ्यास के measured results नहीं। Daily schedule तभी उपयोगी है जब copy सफल और recoverable रहे।
छोटी स्क्रीन पर सभी कॉलम देखने के लिए तालिका को बगल में स्क्रॉल करें।
| क्या दर्ज करें | क्या पता चलता है |
|---|---|
| Backup समय और release | कौन-सा version वापस आएगा |
| Independent location और retention | Copy कहाँ और कितने समय बचेगी |
| Archive तथा file checksums | चुनी bytes वापस मिलीं या नहीं |
| Restore शुरू/समाप्त होने का समय | तय चरणों में लगा समय |
| छूटी files, permissions, dependencies | Service recovery का बाकी काम |
| Replacement पर HTTPS जाँच | वेबसाइट वास्तव में लौटी या नहीं |
Access, provisioning, config, certificates और DNS सहित पूरा replacement process मापें। तेज़ local extraction outage-recovery benchmark नहीं। कई उपयोगी restore points रखें और failed backup jobs देखें। Storage retention तथा support को VPS चयन में शामिल करें।
सवाल-जवाब
Backup जाँचने के लिए क्या मूल वेबसाइट हटानी पड़ेगी?
नहीं। अलग खाली directory में restore और manifest जाँच से files जाँची जा सकती हैं। पूरी service की recovery अलग replacement environment में परखें।
Checksum OK हो तो क्या पूरी site सुरक्षित है?
यह केवल manifest में listed files की पुष्टि करता है। छूटा asset, database, secret या DNS setting इससे नहीं मिलेगा। पूरी inventory और service के वास्तविक functions की जाँच जरूरी है।