Záloha a obnova VPS s kontrolou obnovených súborov
Záloha a obnova VPS má zmysel až vtedy, keď viete kópiu získať mimo servera a obnoviť správne súbory. V tomto cvičení zabalíte statickú stránku a konfiguráciu Nginx, prenesiete ich na iný počítač a overíte obsah v novom adresári bez zásahu do živého webu.
VPSuntu · Aktualizované · Približne 5 min čítania
Obsah návodu
Určte rozsah cvičenia
Použijeme Bash, GNU tar, sha256sum a OpenSSH na Ubuntu alebo klientovi s Linuxom či WSL. Serverové príkazy spúšťajte v jednom serverovom termináli a klientske v jednom termináli samostatného počítača. Nezatvárajte ich, aby zostali dostupné premenné. Po každej chybe zastavte postup.
Pracujeme s dvoma dočasnými súbormi v domovskom adresári. Nemeníme aktívny Nginx, firewall ani živý obsah a obnovu nespúšťame ako root. Celý web môže potrebovať ďalšie dáta, presmerovania, DNS, certifikáty a závislosti; tento príklad s dvoma súbormi nie je záloha celého stroja.
Pripravte skúšobné súbory
Na serveri vytvorte súkromný adresár. Ukážková konfigurácia sa iba archivuje, nezapína ako služba.
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"Voliteľne môžete nahradiť iba tieto dočasné kópie skutočnými dvoma súbormi z návodu na statický web. Zdrojové súbory musia byť čitateľné vaším účtom. Najprv prezrite konfiguráciu kvôli tajným údajom a počas zberu pozastavte nasadzovanie, aby súbory patrili k rovnakému vydaniu. Pri cvičení s ukážkou tento blok preskočte.
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"Príkazy iba čítajú živé zdroje. Nekopírujú súkromné TLS kľúče ani celý systém. Ďalšie potrebné súbory pridávajte vedome do inventára aj manifestu kontrolných súčtov.
Vytvorte archív a kontrolné súčty
Na serveri vypočítajte súčty jednotlivých súborov, archív s relatívnymi cestami a súčet archívu. Počas tohto kroku obsah nemeňte.
(
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"Vo výpise očakávajte site/, nginx/, dva vybrané súbory a SHA256SUMS. Súčet archívu odhalí zmenu preneseného archívu; vnútorný manifest overí rozbalené súbory. Ak útočník vie nahradiť dáta aj očakávaný súčet, samotný hash nepotvrdí pravosť zálohy.
Preneste kópiu na iný počítač
Na klientskom počítači nastavte remote_backup na presný exportný adresár vypísaný serverom. Nahraďte IP, účet a cestu ku kľúču funkčným SSH prístupom. 203.0.113.10 je dokumentačná adresa; REPLACE je miesto na skutočnú príponu vytvorenú 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/"Pred prijatím nového hostiteľa overte jeho kľúč dôveryhodným spôsobom. Pri probléme pokračujte diagnostikou SSH, nevypínajte overovanie identity. SCP chráni prenos cez SSH, ale tar.gz je komprimovaný, nie šifrovaný súbor. Chráňte cieľový účet a úložisko; podľa dát použite šifrovanie v pokoji. Druhý adresár na tom istom VPS nie je nezávislá kópia.
Overte archív a obnovte do prázdneho adresára
Na klientovi pokračujte iba pri výsledku OK. Nezhodu preskúmajte alebo zopakujte prenos; očakávaný hash neprepisujte, aby chyba zmizla.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Dôveryhodný archív rozbaľte do nového adresára. Prepínač --keep-old-files odmietne prepísať existujúce súbory; --no-same-owner neobnovuje archivované vlastníctvo. Cieľ nikdy nemeňte na / a nepoužívajte 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"Očakávajte OK pre site/index.html a nginx/first-site.conf a obnovený nadpis stránky. Overili ste bajty vybraných súborov, nie produkčné vlastníctvo, ACL, dostupnosť služby ani všetky závislosti.
Oddeľte obnovu súborov od obnovy služby
Konfigurácia je stále neaktívny textový súbor. Na samostatnom náhradnom serveri overte cesty, zahrnuté súbory, moduly, oprávnenia a certifikáty. Skontrolujte celú konfiguráciu Nginx pred načítaním a potom HTTP/HTTPS zvonka. Test nezmeneného živého Nginx neoveruje túto obnovenú kópiu.
TLS súkromné kľúče sa zámerne nearchivujú; naplánujte nové vydanie certifikátu alebo osobitnú chránenú zálohu. Aktívnu databázu nekopírujte týmto tar postupom. Použite jej podporovaný konzistentný spôsob zálohy a obnovy.
Snapshot poskytovateľa môže pomôcť, ale overte uchovanie, spoločné riziko zlyhania a postup obnovy. Existencia snapshotu nepreukazuje, že exportované súbory viete obnoviť na inom hostiteľovi.
Zaznamenajte cieľ obnovy aj výsledok
RPO je prijateľná strata dát vyjadrená časom; RTO je cieľový čas návratu služby. Pre malý informačný web si môžete stanoviť napríklad RPO 24 hodín a RTO 60 minút. Sú to modelové ciele, nie namerané výsledky tohto postupu. Denná záloha pomáha iba vtedy, keď úspešne vznikne a zostane obnoviteľná.
Na malom displeji posuňte tabuľku do strán, aby ste videli všetky stĺpce.
| Záznam | Čo preukazuje |
|---|---|
| Čas zálohy a verzia nasadenia | Ktorý stav dát sa dá obnoviť |
| Nezávislé miesto a uchovanie | Kde kópia prežije a ako dlho |
| Súčty archívu a súborov | Či sa obnovili vybrané bajty |
| Začiatok a koniec obnovy | Čas vykonaných krokov |
| Chýbajúce súbory a závislosti | Čo ešte treba na návrat služby |
| Vonkajší HTTPS test náhradného servera | Či skutočne funguje web |
Pred sľúbením RTO zmerajte celý proces vrátane prístupu, vytvorenia servera, konfigurácie, certifikátov a prípadného DNS. Rýchle rozbalenie súboru nie je benchmark obnovy po výpadku. Uchovávajte vhodné body obnovy a sledujte neúspešné zálohovacie úlohy. Rozsah pomoci poskytovateľa zahrňte do výberu služby.
Otázky a odpovede
Musím odstrániť pôvodný web, aby som overil zálohu?
Nie. Obnova do samostatného prázdneho adresára s overením manifestu nevyžaduje výpadok. Celú službu otestujte v náhradnom prostredí.
Úspešný kontrolný súčet znamená zálohu celého webu?
Potvrdzuje súbory uvedené v manifeste. Neodhalí vynechanú databázu, súbor, tajný údaj ani DNS záznam. Preto udržujte inventár a po obnove testujte skutočné funkcie.