Obsah návodu
Vymezte rozsah a připravte dva terminály
Použijte Bash, GNU tar, sha256sum a OpenSSH na Ubuntu nebo klientu Linux/WSL. Serverové příkazy spouštějte v jednom serverovém terminálu, klientské v jednom terminálu jiného počítače. Ponechte je otevřené, aby proměnné zůstaly dostupné. Při jakékoli chybě přerušte postup.
Pracuje se se dvěma cvičnými soubory v domovském adresáři. Nginx, firewall ani živý obsah se nemění; obnova neběží jako root. Volitelná větev používá jen dva soubory z nasazení statického webu.
Větší web potřebuje vlastní inventář dat, přesměrování, vložených konfigurací, DNS a závislostí. Dva soubory nejsou zálohou celého stroje nebo aplikace.
Připravte soubory bez zásahu do webu
Na serveru vytvořte neveřejný pracovní adresář. Nginx blok níže je jen soubor k archivaci; neaktivuje se jako konfigurace služby.
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="cs"><title>Nácvik obnovy</title><h1>Obnovená statická stránka</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 'Pracovní adresář: %s\n' "$backup_lab"Volitelně nahraďte cvičné kopie skutečnou stránkou a konfigurací z návodu. Oba zdroje musí váš účet umět číst. Prohlédněte konfiguraci kvůli tajným údajům a pozastavte nasazování, aby oba soubory patřily stejnému vydání. Pro čistě cvičnou variantu další blok přeskoč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"Čtou se pouze vybrané živé zdroje; nic se v nich neupravuje. Nekopírují se TLS soukromé klíče ani celé systémové složky. Další potřebné soubory přidávejte vědomě do inventáře i manifestu.
Vytvořte archiv a kontrolní součty
Na serveru zaznamenejte SHA-256 souborů, archiv s relativními cestami a součet samotného archivu. Obsah během tohoto kroku neměň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 'Exportní adresář na serveru: %s\n' "$backup_lab/export"Výpis má obsahovat site/, nginx/, oba soubory a SHA256SUMS. Vnější checksum ověřuje přenesený archiv, vnitřní manifest rozbalené soubory. Pokud někdo nahradí data i očekávaný součet, checksum jejich pravost nezaručí.
Přeneste kopii na jiný počítač
Na klientovi nastavte remote_backup přesně na exportní cestu vypsanou serverem. Nahraďte dokumentační IP, účet a klíč skutečnými hodnotami. REPLACE je zástupný text, ne přípona vytvořená 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/"Nový host key před přijetím ověřte důvěryhodným kanálem. Při potížích postupujte podle diagnostiky SSH, ne vypnutím jeho kontroly.
SCP chrání přenos pomocí SSH. tar.gz je ale komprimovaný, nikoli šifrovaný archiv. Chraňte cílový účet i úložiště a podle dat použijte šifrování uložené kopie. Jiná složka na stejném VPS není nezávislá kopie.
Ověřte archiv a obnovte jej do prázdné složky
Na klientovi před rozbalením ověřte checksum. Pokračujte jen s výsledkem OK. Chybu prošetřete nebo přenos opakujte; nepřepisujte očekávaný součet.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Důvěryhodný archiv rozbalte do nově vytvořené složky. Keep-old-files brání nahrazení existujících souborů a no-same-owner neobnovuje původního vlastníka. Nikdy nezměňte cíl na / a nepoužívejte 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čekávejte OK pro site/index.html i nginx/first-site.conf a obnovený nadpis. To ověřuje vybrané bajty, nikoli produkční vlastníky, ACL, službu nebo všechny závislosti webu.
Odlište obnovu souborů od obnoveného provozu
Obnovený Nginx blok je stále neaktivní textový soubor. Na samostatném náhradním serveru ověřte jeho cesty, includes, moduly, oprávnění a certifikáty. Před reloadem validujte sestavenou konfiguraci právě tam a pak HTTP/HTTPS zvenčí. Kontrola nezměněného živého serveru neověřuje obnovenou kopii.
Archiv záměrně neobsahuje soukromé TLS klíče. Připravte nové vystavení certifikátu nebo zvlášť chráněnou zálohu. Živé databázové soubory tímto tar postupem nekopírujte: použijte konzistentní metodu podporovanou databází.
Snapshot může pomoci s obnovou stroje, ale ověřte jeho retenci, sdílená rizika a postup obnovy. Jeho existence nedokazuje přenositelnost exportovaného webu.
Zapište cíle obnovy a skutečný výsledek
RPO vyjadřuje přípustnou ztrátu dat v čase, RTO cílovou dobu návratu služby. U malého statického informačního webu můžete plánovat například RPO 24 hodin a RTO 60 minut. Jde o ilustrační obchodní cíle, nikoli naměřené výsledky. Denní plán záloh pomáhá jen tehdy, když kopie skutečně vznikají a jsou obnovitelné.
Tabulku lze posouvat vodorovně.
| Záznam | Co doloží |
|---|---|
| Čas zálohy a verze | K jakému stavu se vracíte |
| Nezávislé umístění a retence | Kde a jak dlouho kopie zůstává |
| Výsledky obou checksum kontrol | Zda se obnovily vybrané soubory |
| Začátek a konec obnovy | Doba vymezených kroků |
| Chybějící soubory a závislosti | Co ještě brání obnově služby |
| Vnější HTTPS kontrola náhrady | Zda web skutečně znovu funguje |
Změřte celý návrat služby včetně přístupu, vytvoření stroje, konfigurace, certifikátů a případného DNS. Rychlé lokální rozbalení není benchmark obnovy výpadku. Udržujte vhodné body obnovy a sledujte selhané úlohy; retenci a pomoc poskytovatele zahrňte do výběru VPS.
Cvičný archiv a checksum postup byly testovány lokálně nástroji GNU v Git Bash na Windows. Test nezahrnoval Ubuntu server, vzdálené SSH, certifikáty ani aktivaci Nginx.
Časté otázky
Mám smazat původní web, abych ověřil zálohu?
Není to potřeba. Samostatná prázdná složka s ověřením manifestu testuje kopii bez výpadku. Celou službu otestujte v náhradním prostředí.
Zaručuje správný checksum úplnou zálohu webu?
Potvrzuje jen položky manifestu. Neodhalí vynechanou databázi, soubor, tajný údaj či DNS. Úplnost ověřte inventářem a reálnými funkcemi obnoveného webu.
Nahrazuje snapshot nezávislou kopii?
Záleží na jeho umístění, retenci a rozsahu selhání. Ověřte zvlášť možnost získat data mimo původní instanci a obnovit je na náhradě.