Rikthimi i kopjes rezervë të VPS në një mjedis prove
Një kopje rezervë është e dobishme kur mund ta merrni jashtë VPS-it dhe të riktheni skedarët e pritur. Ky ushtrim arkivon një faqe statike dhe një konfigurim Nginx, i transferon në kompjuter tjetër dhe verifikon përmbajtjen pa prekur faqen aktive.
VPSuntu · Përditësuar: · Leximi: rreth 5 min
Përmbajtja e udhëzuesit
Përcaktoni kufijtë e ushtrimit
Përdorni Bash, GNU tar, sha256sum dhe OpenSSH në Ubuntu ose klient Linux/WSL. Mbani një terminal SERVER dhe një KLIENT në kompjuter të veçantë; lërini hapur që variablat të mbeten. Ndaloni pas çdo gabimi komande.
Shembulli krijon dy skedarë prove nën home. Nuk ndryshon Nginx, firewall ose përmbajtje aktive; nxjerrja e arkivit nuk bëhet si root. Hapi opsional përdor vetëm dy skedarët e udhëzuesit të faqes HTTPS.
Për një faqe më të madhe inventarizoni veçmas asetet, redirects, konfigurimet e përfshira, DNS dhe varësitë. Dy skedarë nuk janë kopje e plotë e makinës ose aplikacionit.
SERVER: përgatitni dy skedarë pa ndryshuar faqen
Krijoni dosjen private të ushtrimit. Konfigurimi Nginx brenda saj është skedar për arkivim, jo konfigurim për aktivizim. Ruani shtegun e afishuar.
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"Opsionale: për të kopjuar faqen reale të udhëzuesit, zëvendësoni vetëm kopjet e provës më poshtë. Kontrolloni që burimet lexohen nga llogaria juaj dhe që konfigurimi nuk përmban sekrete të papërshtatshme. Ndaloni përkohësisht deployments gjatë mbledhjes për të marrë të njëjtin release. Anashkalojeni këtë bllok për shembullin e krijuar.
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"Komandat vetëm lexojnë burimet aktive. Nuk kopjojnë çelësa privatë certifikatash ose gjithë dosjet e sistemit. Skedarët shtesë të nevojshëm shtojini me qëllim si në inventar ashtu edhe në manifestin e kontrolleve.
SERVER: krijoni arkivin dhe kontrollet SHA256
Mbajeni përmbajtjen të pandryshuar. Regjistroni kontrollet e skedarëve, krijoni arkiv me shtigje relative dhe pastaj kontrollin e arkivit.
(
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"Lista duhet të ketë site/, nginx/, dy skedarët dhe SHA256SUMS. Kontrolli i jashtëm zbulon ndryshim të arkivit të transferuar; manifesti i brendshëm verifikon skedarët e nxjerrë. Asnjëri nuk provon autenticitetin nëse dikush mund të zëvendësojë si të dhënat ashtu edhe kontrollin e pritur.
KLIENT: transferoni kopjen në kompjuter tjetër
Në klient vendosni remote_backup në shtegun e saktë të eksportit që afishoi serveri. Zëvendësoni adresën, llogarinë dhe çelësin me aksesin tuaj. 203.0.113.10 është shembull dokumentacioni; REPLACE nuk është prapashtesa e krijuar nga 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/"Verifikoni fingerprint SSH përmes kanali të besuar para pranimit të hostit të ri. Nëse transferimi dështon për shkak të SSH, ndiqni diagnostikimin e lidhjes. Mos çaktivizoni host-key checking.
SCP e mbron transferimin përmes SSH. Arkivi tar.gz është i kompresuar, jo i enkriptuar: mbroni llogarinë dhe ruajtjen, me encryption at rest kur të dhënat e kërkojnë. Dosje tjetër në të njëjtin VPS nuk është kopje jashtë serverit.
KLIENT: kontrolloni dhe riktheni në një dosje të re
Kontrolloni arkivin para nxjerrjes. Vazhdoni vetëm kur sha256sum jep OK. Nëse dështon, hetoni ose transferojeni sërish; mos zëvendësoni vlerën e pritur për të fshehur gabimin.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Nxirreni vetëm këtë arkiv të besuar në një dosje të re bosh. Keep-old-files nuk lejon zëvendësimin e skedarëve ekzistues dhe no-same-owner shmang pronësinë e arkivuar. Mos ndryshoni destinacionin në / dhe mos përdorni 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"Prisni OK për site/index.html dhe nginx/first-site.conf, si dhe titullin e faqes së rikthyer. Kjo verifikon përmbajtjen e tyre, jo pronësinë production, ACL, disponueshmërinë ose të gjitha varësitë.
Ndani rikthimin e skedarëve nga rikthimi i shërbimit
Konfigurimi i rikthyer mbetet tekst joaktiv. Para përdorimit, në server zëvendësues të veçantë shqyrtoni shtigjet, includes, modulet, lejet dhe certifikatat. Atje validoni Nginx para reload, pastaj provoni HTTP/HTTPS nga jashtë. Testi i konfigurimit të pandryshuar aktiv nuk teston këtë kopje.
Arkivi qëllimisht përjashton çelësat privatë TLS. Planifikoni rilëshim certifikate ose kopje të mbrojtur veçmas. Mos arkivoni skedarët e një baze aktive me këtë recetë tar; përdorni procedurën konsistente backup/restore të bazës.
Snapshots mund të ndihmojnë rikuperimin e makinës, por kontrolloni afatin, kufijtë e dështimit të përbashkët dhe procedurën e rikthimit. Prania e snapshot nuk provon se eksporti i faqes rikthehet në host tjetër.
Shënoni objektivat dhe rezultatin e rikuperimit
RPO përshkruan humbjen e pranueshme të të dhënave në kohë; RTO kohën e synuar për rikthimin e shërbimit. Për faqe të vogël mund të zgjidhni 24 orë RPO dhe 60 minuta RTO. Janë objektiva ilustruese, jo rezultate të matura të ushtrimit. Backup ditor vlen vetëm kur kopjet kanë sukses dhe janë të rikthyeshme.
Në ekran të vogël, lëvizeni tabelën anash për të parë të gjitha kolonat.
| Shënimi | Çfarë provon |
|---|---|
| Koha e kopjes dhe release | Cilin version mund të riktheni |
| Destinacioni i pavarur dhe afati | Ku mbijeton kopja dhe sa kohë ruhet |
| Kontrollet e arkivit dhe skedarëve | Nëse përmbajtja e zgjedhur u rikthye |
| Fillimi dhe mbarimi i rikthimit | Kohën e hapave të përcaktuar |
| Skedarë, leje ose varësi të munguara | Çfarë mbetet para rikthimit të shërbimit |
| HTTPS nga jashtë në zëvendësues | Nëse faqja është kthyer realisht |
Matni procesin e plotë: akses, krijim instance, konfigurim, certifikata dhe DNS kur nevojitet. Nxjerrja e shpejtë lokale nuk është benchmark i rikuperimit pas ndërprerjes. Mbani disa pika të përshtatshme rikthimi dhe kontrolloni jobs të dështuar. Krahasoni ruajtjen dhe ndihmën për rikthim në zgjedhjen e burimeve VPS.
Pyetje të shpeshta
Duhet ta fshij faqen origjinale për ta provuar kopjen?
Jo. Rikthimi në dosje të veçantë bosh dhe kontrolli i manifestit provon kopjen pa krijuar ndërprerje. Shërbimin e plotë provojeni në mjedis zëvendësues të veçantë.
A tregon SHA256 i saktë që gjithë faqja është kopjuar?
Konfirmon vetëm skedarët në manifest. Nuk zbulon asete, bazë, sekrete ose DNS që nuk u përfshinë. Mbani inventar dhe provoni funksionet reale pas rikthimit të shërbimit.