VPS atsarginės kopijos, kurių atkūrimą patikrinote
VPS atsarginės kopijos vertė paaiškėja atkuriant failus iš kitos vietos. Šioje užduotyje supakuosite statinį puslapį ir vieną Nginx konfigūraciją, perkelsite archyvą į kitą kompiuterį ir patikrinsite atkurtus duomenis neliesdami veikiančios svetainės.
VPSuntu · Atnaujinta · Skaitymas: apie 5 min.
Šiame gide
Apibrėžkite nedidelį bandymą
Naudokite Bash, GNU tar, sha256sum ir OpenSSH Ubuntu arba Linux/WSL aplinkoje. Serverio komandas vykdykite viename serverio terminale, kliento — kitame kompiuteryje. Abu terminalus laikykite atidarytus, kad išliktų kintamieji. Gavę bet kurią klaidą sustokite.
Bandymas naudoja du laikinus failus jūsų namų kataloge. Jis neaktyvina Nginx konfigūracijos ir nekeičia gyvos svetainės ar ugniasienės. Išpakavimas nevykdomas kaip root. Papildoma šaka gali paimti du failus iš pirmos HTTPS svetainės gido. Tai nėra viso serverio, programos ar duomenų bazės kopija.
Paruoškite du failus
Serveryje sukurkite privatų bandymo katalogą. Konfigūracija šiame bloke skirta archyvui, o ne Nginx aktyvinimui.
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"Pasirinktinai: jei norite kopijuoti tikrą ankstesnio gido puslapį ir serverio bloką, pakeiskite tik bandymo kopijas žemiau pateiktomis komandomis. Abu šaltiniai turi būti skaitomi jūsų paskyrai. Patikrinkite, ar juose nėra paslapčių, ir sustabdykite diegimus kopijavimo metu, kad failai priklausytų tai pačiai versijai. Jei naudojate vien bandymo failus, šį bloką praleiskite.
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"Šios komandos tik skaito gyvus šaltinius. TLS privatūs raktai ir sistemos katalogai nekopijuojami. Tikrai svetainei gali reikėti papildomų failų; sąmoningai įtraukite juos į inventorių ir kontrolinių sumų sąrašą.
Sukurkite archyvą su kontrolinėmis sumomis
Serveryje užrašykite pasirinktų failų SHA-256, sukurkite archyvą su santykiniais keliais, tada apskaičiuokite ir jo sumą. Šio veiksmo metu turinio nekeiskite.
(
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"Sąraše turi būti site/, nginx/, du pasirinkti failai ir SHA256SUMS. Archyvo suma tikrina perkėlimo metu pasikeitusius baitus, vidinis sąrašas — išpakuotus failus. Kontrolinė suma nepatvirtina kilmės, jei pašalinis asmuo gali pakeisti ir duomenis, ir laukiamą sumą.
Perkelkite kopiją už VPS ribų
Savo kompiuteryje remote_backup nustatykite į tikslų serverio išvestą eksportavimo katalogą. Pakeiskite adresą, vartotoją ir rakto failą veikiančios SSH prieigos duomenimis. 203.0.113.10 yra dokumentacijos pavyzdys, o REPLACE — vieta tikrajai mktemp sugeneruotai priesagai.
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/"Naujo serverio rakto atspaudą patvirtinkite patikimu kanalu. Jei SCP neveikia dėl ryšio, naudokite SSH klaidų patikrą, o ne išjunkite tapatybės tikrinimą.
SCP perduoda per SSH, tačiau tar.gz failas tik suglaudintas, ne užšifruotas. Apsaugokite paskyrą bei laikmeną ir prireikus šifruokite saugomus duomenis. Antras katalogas tame pačiame VPS nėra nepriklausoma kopija.
Patikrinkite ir atkurkite į tuščią katalogą
Kliento kompiuteryje prieš išpakuodami patikrinkite archyvą. Tęskite tik kai sha256sum grąžina OK. Klaida reiškia, kad reikia tirti priežastį ar pakartoti perkėlimą, o ne perrašyti laukiamą sumą.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Šį patikimą archyvą išpakuokite į naujai sukurtą katalogą. keep-old-files neleidžia perrašyti jau esančių failų, no-same-owner neatkuria archyve nurodytos nuosavybės. Nekeiskite paskirties į / ir nenaudokite 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"Abiem failams — site/index.html ir nginx/first-site.conf — turi būti OK, taip pat turi pasirodyti atkurto puslapio antraštė. Tai patvirtina turinį, bet ne sistemos teises, ACL, visus svetainės komponentus ar paslaugos veikimą.
Atskirkite failų ir paslaugos atkūrimą
Atkurta Nginx konfigūracija kol kas yra neveikiantis tekstinis failas. Kitame serveryje patikrinkite kelius, include, modulius, teises ir sertifikatus. Prieš įkeldami patikrinkite visą ten surinktą Nginx konfigūraciją, paskui HTTP/HTTPS iš išorės. Nepakeisto seno serverio sintaksės patikra šios kopijos netikrina.
TLS privatūs raktai į archyvą neįtraukti. Suplanuokite sertifikatų išdavimą iš naujo arba atskirą apsaugotą kopiją. Aktyvių duomenų bazės failų šiuo tar receptu nekopijuokite: naudokite bazės palaikomą nuoseklios kopijos ir atkūrimo procedūrą.
Tiekėjo momentinė kopija gali padėti atkurti mašiną, bet patikrinkite jos saugojimo laiką, nepriklausomumą nuo gedimo vietos ir atkūrimo procesą. Vien kopijos buvimas nepatvirtina, kad svetainę atkursite naujame serveryje.
Užrašykite tikslą ir bandymo rezultatą
RPO apibūdina priimtiną duomenų praradimą laiko vienetais, RTO — tikslinę paslaugos atkūrimo trukmę. 24 valandų RPO ir 60 minučių RTO statinei svetainei gali būti planavimo pavyzdys, ne šio bandymo rezultatas. Kasdienės kopijos padeda tik jei jos sėkmingos ir atkuriamos.
Mažame ekrane slinkite lentelę į šoną, kad matytumėte visus stulpelius.
| Ką užrašyti | Ką tai parodo |
|---|---|
| Kopijos laikas ir versija | Kokį turinį galima grąžinti |
| Nepriklausoma saugojimo vieta ir terminas | Kur kopija išlieka ir kiek laiko |
| Archyvo ir failų SHA-256 rezultatai | Ar atkurti pasirinkti baitai |
| Atkūrimo pradžia ir pabaiga | Apibrėžtų veiksmų trukmę |
| Trūkstami failai, teisės ar priklausomybės | Kas liko iki paslaugos atkūrimo |
| Išorinis HTTPS bandymas naujame serveryje | Ar svetainė vėl veikia |
Laikuokite visą procesą, įskaitant prieigą, naujo serverio sukūrimą, sertifikatus ir DNS. Greitas išpakavimas vietiniame diske nėra paslaugos atkūrimo benchmark. Laikykite kelis tinkamus atkūrimo taškus ir reaguokite į nesėkmingas kopijas. Rinkdamiesi VPS palyginkite ir tiekėjo atkūrimo pagalbą.
Dažni klausimai
Ar reikia ištrinti veikiančią svetainę bandymui?
Ne. Atkūrimas į atskirą tuščią katalogą ir sumų patikra leidžia išbandyti kopiją nesukeliant prastovos. Visą paslaugą bandykite kitoje aplinkoje.
Ar teisinga SHA-256 reiškia, kad nukopijuota visa svetainė?
Ji patvirtina tik į sąrašą įtrauktus failus. Praleistos duomenų bazės, DNS įrašo ar kito komponento ji neaptinka. Reikia inventoriaus ir tikrų funkcijų bandymo.