VPS बॅकअप आणि पुनर्स्थापनेची चाचणी करा
VPS बाहेरून प्रत मिळवून अपेक्षित files परत मिळाल्यावरच बॅकअप उपयोगी असल्याची तपासणी होते. या सरावात static पान व एक Nginx configuration archive करून दुसऱ्या संगणकावर नेतो आणि bytes पडताळतो. चालू वेबसाइट बदलली जात नाही.
VPSuntu · अद्ययावत: · वाचनासाठी सुमारे 5 मिनिटे
मार्गदर्शिकेतील विभाग
छोट्या recovery सरावाची मर्यादा ठरवा
Ubuntu किंवा Linux/WSL client वर Bash, GNU tar, sha256sum आणि OpenSSH लागते. Server commands एका server terminal मध्ये, client commands वेगळ्या संगणकाच्या एका terminal मध्ये चालवा. Variables टिकण्यासाठी दोन्ही terminals उघडी ठेवा; कोणतीही command चुकल्यास थांबा.
Home खाली दोन disposable files वापरतो. Nginx, firewall किंवा live content बदलत नाही; extraction root म्हणून होत नाही. आधी fixtures वापरा. Optional substitution फक्त static HTTPS उदाहरणातील दोन files साठी आहे. मोठ्या site चे assets, redirects, includes, DNS व dependencies स्वतंत्र नोंदवा; हे पूर्ण machine/application backup नाही.
वेबसाइट न बदलता दोन फाइल तयार करा
Server वर private practice directory तयार करा. पुढील configuration ही archive साठी file आहे; active service configuration नाही.
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 च्या खऱ्या files चा backup हवा असल्यास फक्त disposable copies पुढील commands ने बदला. दोन्ही source files account ला readable हव्यात. Configuration मधील secrets आधी तपासा; files गोळा करताना deployments थांबवून एकाच release ची प्रत घ्या. Fixture सरावासाठी पुढील 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 किंवा पूर्ण system directories घेत नाही. अतिरिक्त 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 अपेक्षित आहेत. बाहेरचा checksum transfer झालेला archive तपासतो; आतला manifest extracted files तपासतो. कोणीतरी data आणि अपेक्षित checksum दोन्ही बदलू शकत असेल तर हे backup ची authenticity सिद्ध करत नाहीत.
प्रत वेगळ्या संगणकावर न्या
Client वर remote_backup मध्ये server ने छापलेली अचूक export directory द्या. पत्ता, account व key नाव स्वतःच्या कार्यरत SSH तपशिलांनी बदला. 203.0.113.10 उदाहरणासाठी राखीव; 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 अयशस्वी असल्यास SSH निदान करा; checking बंद करू नका. SCP transfer SSH ने संरक्षित करतो, पण tar.gz स्वतः compressed आहे, encrypted नाही. Destination account/storage सुरक्षित ठेवा आणि गरजेनुसार encryption at rest वापरा. त्याच VPS वरील दुसरा folder म्हणजे off-server copy नाही.
Archive तपासून नवीन रिकाम्या directory मध्ये restore करा
Client वर extraction आधी archive तपासा. Sha256sum ने OK दिल्यावरच पुढे जा. Failure असल्यास कारण शोधा किंवा transfer पुन्हा करा; चुकीचा expected checksum बदलून error लपवू नका.
(
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 विद्यमान फाइल overwrite होऊ देत नाही; no-same-owner जुनी मालकी लागू करत नाही. 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 व पुनर्प्राप्त पानाचे heading अपेक्षित आहे. यात contents तपासतात; production ownership, ACLs, service availability किंवा सर्व dependencies नाहीत.
फाइल recovery आणि service recovery वेगळी तपासा
पुनर्प्राप्त configuration अजून inactive text file आहे. वेगळ्या replacement server वर paths, includes, modules, permissions व certificates तपासा. पूर्ण Nginx configuration तिथे validate करूनच reload करा आणि बाहेरून HTTP/HTTPS तपासा. न बदललेल्या live server वर syntax test केल्याने restored copy तपासली जात नाही.
या archive मध्ये TLS private keys नाहीत. Certificate reissue किंवा स्वतंत्र संरक्षित backup ठरवा. Active database files ला ही tar पद्धत वापरू नका; database ची supported consistent backup/restore पद्धत वापरा. Provider snapshots साठी retention, failure domain व restore प्रक्रिया तपासा. Snapshot असणे म्हणजे exported site files दुसऱ्या host वर परत मिळतात असा पुरावा नाही.
Recovery उद्दिष्टे आणि निकाल लिहा
RPO म्हणजे वेळेत मोजलेले स्वीकारार्ह data loss; RTO म्हणजे service पुनर्स्थापनेचे लक्ष्य. लहान static site साठी 24 तास RPO/60 मिनिटे RTO ही उदाहरणातील business targets आहेत, मोजलेले निकाल नाहीत. Daily backups यशस्वी व recoverable राहिले तरच नियोजन उपयोगी ठरते.
लहान स्क्रीनवर सर्व स्तंभ पाहण्यासाठी तक्ता बाजूला सरकवा.
| नोंद | काय समजते |
|---|---|
| Backup वेळ व release ID | कोणती आवृत्ती परत मिळेल |
| स्वतंत्र destination व retention | प्रत कुठे आणि किती काळ टिकेल |
| Archive/file checksums | निवडलेले bytes परत मिळाले का |
| Restore सुरुवात व शेवट | ठरलेल्या पायऱ्यांना लागलेला वेळ |
| उणीव files/permissions/dependencies | Service recovery साठी उरलेले काम |
| Replacement वर बाह्य HTTPS | वेबसाइट खरोखर परत आली का |
RTO साध्य मानण्याआधी access, provisioning, configuration, certificates आणि गरजेनुसार DNS यांसह पूर्ण प्रक्रिया वेळेत मोजा. जलद local extraction हा outage-recovery benchmark नाही. योग्य अनेक restore points ठेवा; failed jobs तपासा. होस्टिंग तुलना करताना retention व restore support पहा.
प्रश्नोत्तरे
बॅकअप तपासण्यासाठी मूळ वेबसाइट पुसावी का?
त्याची गरज नाही. स्वतंत्र रिकाम्या directory मध्ये restore व manifest तपासता येतो. पूर्ण service वेगळ्या replacement environment मध्ये तपासा.
Checksum जुळला म्हणजे पूर्ण वेबसाइटचा backup आहे का?
तो manifest मधील files तपासतो. वगळलेला asset, database, secret किंवा DNS शोधत नाही. Inventory ठेवा आणि service परत आल्यानंतर प्रत्यक्ष कामे तपासा.