VPS backup અને પુનઃપ્રાપ્તિ અજમાવો
Backup ત્યારે ઉપયોગી બને જ્યારે VPSની બહારથી copy મેળવીને અપેક્ષિત files પુનઃસ્થાપિત કરી શકો. આ અભ્યાસ static page અને એક Nginx configuration archive કરે છે, બીજા કમ્પ્યુટર પર મોકલે છે અને ચાલતી siteને અડ્યા વગર restored bytes તપાસે છે.
VPSuntu · અપડેટ: · વાંચવાનો અંદાજિત સમય: 5 મિનિટ
માર્ગદર્શિકાના વિભાગો
આ નાની recovery testની મર્યાદા સમજો
Ubuntu અથવા Linux/WSL client પર Bash, GNU tar, sha256sum અને OpenSSH વાપરો. Server-labelled commands એક server terminalમાં અને client-labelled commands બીજા કમ્પ્યુટરના એક terminalમાં ચલાવો. Variables ઉપલબ્ધ રહે તે માટે terminals ખુલ્લાં રાખો. કોઈ command error આવે તો અટકો.
Home directoryમાં બે disposable filesથી શરૂઆત કરો. Nginx, firewall અથવા live content બદલાતું નથી અને extraction root તરીકે થતું નથી. Optional branch માત્ર static HTTPS tutorialની બે files લે છે.
મોટી site માટે assets, redirects, included configs, DNS અને dependenciesની અલગ inventory જોઈએ. આ બે-file example આખી machine કે applicationનો backup નથી.
વેબસાઇટ બદલ્યા વગર બે files બનાવો
Server પર private practice directory બનાવો. નીચેની configuration archive કરવાની file છે, activate કરવાની 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ની real page અને server blockનો backup લેવો હોય તો માત્ર disposable copiesને આ commandsથી બદલો. બંને source files accountથી readable હોવી જોઈએ. Secrets તપાસો અને એક જ releaseની files મળે તે માટે copy લેતી વખતે deployments રોકો. 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"આ commands live source વાંચે છે, બદલે નહીં. Certificate private keys કે આખી system directories copy કરતા નથી. Real siteની વધારાની 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 transferમાં ફેરફાર પકડે છે; internal manifest extracted files તપાસે છે. Data અને expected checksum બંને કોઈ બદલી શકે તો checksum authenticity સાબિત કરતું નથી.
અલગ કમ્પ્યુટર પર backup મોકલો
Client પર remote_backupમાં serverએ print કરેલી exact export directory મૂકો. IP, account અને key filenameને હાલ કામ કરતી SSH વિગતો આપો. 203.0.113.10 documentation address છે; REPLACE actual 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 channelથી fingerprint ખાતરી કરો. SSH ન ચાલે તો SSH troubleshooting કરો. Transfer કરાવવા host checking disable ન કરો.
SCP transferને SSHથી સુરક્ષિત રાખે છે. Tar.gz file compressed છે, encrypted નથી. Destination account અને storage સુરક્ષિત રાખો; dataને જરૂરી હોય તો encryption at rest રાખો. એ જ VPSની બીજી directory off-server copy નથી.
નવી ખાલી directoryમાં restore કરો
Client પર extraction પહેલાં archive checksum તપાસો. Sha256sum 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 existing files overwrite થવા દેતું નથી; 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 page heading અપેક્ષિત છે. આ file content તપાસે છે, production ownership, ACL, service availability અથવા બધી dependencies નહીં.
File recovery અને service recovery અલગ છે
Restored configuration હજી inactive text file છે. અલગ replacement server પર paths, includes, modules, permissions અને certificates તપાસો. ત્યાં assembled Nginx configuration validate કર્યા પછી reload કરો અને બહારથી HTTP/HTTPS જુઓ. Unchanged live serverનો syntax check આ restored copyને validate કરતો નથી.
આ archiveમાં TLS private keys જાણીજોઈને નથી. Certificate reissue અથવા અલગ protected backupની યોજના બનાવો. આ tar recipeથી active database files copy ન કરો; databaseની supported consistent backup/restore પદ્ધતિ વાપરો.
Provider snapshots machine recoveryમાં મદદરૂપ થઈ શકે, પણ retention, failure domain અને restore procedure તપાસો. Snapshot હોવું exported site files replacement host પર પાછી મળી શકે તે સાબિત કરતું નથી.
Recoveryના લક્ષ્યો અને પરિણામ નોંધો
RPO એટલે સમય પ્રમાણે સ્વીકાર્ય data loss; RTO એટલે service પાછી લાવવાનું target time. નાની static information site માટે ઉદાહરણરૂપ RPO 24 કલાક અને RTO 60 મિનિટ હોઈ શકે. આ business targets છે, આ અભ્યાસના measured results નહીં. Daily backup ત્યારે જ ઉપયોગી છે જ્યારે copies સફળ અને recoverable રહે.
નાની સ્ક્રીન પર બધા કૉલમ જોવા કોષ્ટકને આડું સરકાવો.
| નોંધ | શું બતાવે છે |
|---|---|
| Backup સમય અને release ID | કઈ version પાછી મેળવી શકાય |
| Independent destination અને retention | Copy ક્યાં અને કેટલો સમય રહે છે |
| Archive/file checksums | પસંદ કરેલા bytes પુનઃસ્થાપિત થયા કે નહીં |
| Restoreનો start/end સમય | નક્કી કરેલા recovery stepsનો સમય |
| Missing files, permissions, dependencies | Service શરૂ કરતાં પહેલાં બાકી કામ |
| Replacement પર external HTTPS | Site ખરેખર પાછી આવી કે નહીં |
RTOને શક્ય માનતાં પહેલાં access, provisioning, configuration, certificates અને જરૂરી DNS સહિત આખી પ્રક્રિયાનો સમય માપો. ઝડપી local extraction outage-recovery benchmark નથી. યોગ્ય restore points રાખો અને failed backup jobs તપાસો. Hosting recovery criteriaમાં storage retention અને restore support સરખાવો.
પ્રશ્નો અને જવાબો
Backup સાબિત કરવા original site કાઢી નાખવી પડે?
ના. અલગ ખાલી directoryમાં restore અને manifest check outage વગર file copy તપાસે છે. સંપૂર્ણ serviceને અલગ replacement environmentમાં અજમાવો.
Checksum સફળ એટલે આખી site backup થઈ ગઈ?
તે manifestમાં લખેલી files જ ચકાસે છે. છૂટી ગયેલી asset, database, secret અથવા DNS શોધી શકતું નથી. Inventory રાખો અને service restore પછી siteના actual functions અજમાવો.