VPS backup at restore: subukan ang iyong kopya
May silbi ang backup kapag makukuha mo ito sa labas ng VPS at maibabalik ang inaasahang files. Sa exercise na ito, ia-archive ang static page at isang Nginx configuration, kokopyahin sa hiwalay na computer at susuriin ang restored bytes nang hindi binabago ang gumaganang website.
VPSuntu · Na-update noong · Tinatayang 6 minutong pagbasa
Nilalaman ng gabay
Linawin ang saklaw ng recovery exercise
Gumamit ng Bash, GNU tar, sha256sum at OpenSSH sa Ubuntu o Linux/WSL client. Patakbuhin ang server commands sa isang server terminal at ang client commands sa isang terminal ng hiwalay na computer. Panatilihing bukas ang bawat terminal upang manatili ang variables. Huminto kapag may command error.
Dalawang disposable file sa home directory ang gamit. Hindi nito binabago ang Nginx, firewall o live content, at hindi root ang extraction. Magsimula sa fixtures; opsyonal ang paggamit sa dalawang tunay na file mula sa static HTTPS tutorial.
Para sa mas malaking site, ilista nang hiwalay ang assets, redirects, included configuration, DNS at dependencies. Hindi buong machine o application backup ang dalawang-file na halimbawa.
Maghanda ng dalawang file sa hiwalay na directory
Sa server, gumawa ng private practice directory. File na ia-archive ang configuration dito, hindi configuration na ia-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"Opsyonal: para sa tunay na page at server block ng tutorial, palitan lamang ang disposable copies gamit ang sumusunod. Kailangang readable ng account mo ang dalawang source. Suriin muna ang secrets at ihinto sandali ang deployments habang kinokopya upang parehong release ang makuha. Laktawan ito para sa fixture exercise.
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"Binabasa lamang nito ang live sources. Hindi kinokopya ang certificate private keys o buong system directories. Kung may dagdag na kailangang files, sadyang isama ang mga iyon sa inventory at checksum manifest.
Gumawa ng archive at dalawang antas ng checksum
Sa server, kunin ang checksums ng napiling files, gumawa ng archive na may relative paths, at kunin din ang checksum ng archive. Huwag baguhin ang payload habang ginagawa ito.
(
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"Dapat kasama sa listing ang site/, nginx/, dalawang files at SHA256SUMS. Nakikita ng archive checksum ang pagbabago sa nailipat na archive; ang internal manifest ang sumusuri sa extracted files. Hindi authentication ang checksum kung kayang palitan ng isang tao ang data at pati inaasahang checksum.
Kopyahin sa hiwalay na computer
Sa client computer, itakda ang remote_backup sa eksaktong export directory na ipinakita ng server. Palitan ang address, account at key filename ng gumaganang SSH details. Documentation address ang 203.0.113.10; placeholder ang REPLACE, hindi ang suffix na ginawa ng mktemp.
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/"Patunayan ang bagong SSH host fingerprint sa trusted channel. Kung SSH ang pumapalya, gamitin ang troubleshooting guide. Huwag i-disable ang host-key checking para mapilit ang transfer.
Protektado ng SSH ang SCP transfer. Compressed lamang ang tar.gz, hindi encrypted: protektahan ang destination account at storage at gumamit ng encryption at rest kung kailangan ng data. Hindi off-server backup ang isa pang directory sa parehong VPS.
Suriin at i-restore sa bagong bakanteng directory
Sa client, suriin ang archive bago mag-extract. Magpatuloy lamang kapag OK ang sha256sum. Imbestigahan o ulitin ang transfer kapag may failure; huwag palitan ang expected checksum para itago ito.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"I-extract ang trusted archive sa bagong directory. Tumatanggi ang keep-old-files na patungan ang umiiral na file, at hindi ibinabalik ng no-same-owner ang archived ownership. Huwag gawing / ang destination at huwag gumamit ng sudo.
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"Dapat OK ang site/index.html at nginx/first-site.conf at makita ang heading ng recovered page. File contents ang napapatunayan, hindi production ownership, ACLs, availability o lahat ng dependencies.
Ihiwalay ang file recovery sa service recovery
Inactive text file pa rin ang restored configuration. Bago gamitin, suriin ang paths, includes, modules, permissions at certificates sa hiwalay na replacement server. I-validate doon ang buong Nginx configuration bago mag-reload, pagkatapos suriin ang HTTP/HTTPS mula sa labas. Hindi test ng restored copy ang syntax check sa hindi binagong live server.
Sadyang wala rito ang TLS private keys. Planuhin ang certificate reissuance o hiwalay na protektadong backup. Huwag i-tar ang active database files gamit ang paraang ito: gamitin ang consistent backup at restore procedure ng database.
Makakatulong ang provider snapshot sa machine recovery, ngunit suriin ang retention, failure domain at restore procedure. Hindi patunay ang pagkakaroon ng snapshot na maibabalik mo ang exported site files sa ibang host.
Itala ang target at aktuwal na resulta
Ang RPO ay katanggap-tanggap na data loss na sinusukat sa oras; ang RTO ay target na oras para maibalik ang serbisyo. Halimbawa sa maliit na static information site ang 24-hour RPO at 60-minute RTO. Business targets ang mga ito, hindi nasukat na resulta ng exercise. May silbi ang daily schedule kapag matagumpay at recoverable ang mga kopya.
Sa maliit na screen, i-scroll ang talahanayan pahalang upang makita ang lahat ng column.
| Record | Ipinapakita nito |
|---|---|
| Backup time at release identifier | Aling bersyon ang maibabalik |
| Independent destination at retention | Saan mabubuhay ang kopya at gaano katagal |
| Archive at file checksums | Kung naibalik ang napiling bytes |
| Restore start at finish | Tagal ng tinukoy na recovery steps |
| Kulang na files, permissions o dependencies | Natitirang trabaho bago maibalik ang service |
| External HTTPS check sa replacement | Kung bumalik talaga ang website |
Sukatin ang buong replacement process bago sabihing maaabot ang RTO: access, provisioning, configuration, certificates at DNS kung kailangan. Hindi outage-recovery benchmark ang mabilis na local extraction. Panatilihin ang angkop na restore points at bantayan ang failed backup jobs. Isama ang retention at restore support sa hosting comparison.
Mga karaniwang tanong
Kailangan bang burahin ang original website para subukan ang backup?
Hindi. Sapat para sa file check ang hiwalay na bakanteng directory at manifest verification. Subukan ang buong service sa ibang replacement environment.
Kapag OK ang checksum, kumpleto na ba ang backup ng website?
Mga file sa manifest lamang ang nakumpirma. Hindi nito mahahanap ang nakalimutang asset, database, secret o DNS setting. Panatilihin ang inventory at subukan ang tunay na website functions pagkatapos ng service recovery.