Praktiska pamācība / Failu atjaunošana

VPS rezerves kopijas ar pārbaudītu atjaunošanu

VPS rezerves kopijas vērtība parādās atjaunošanas pārbaudē. Šajā vingrinājumā arhivēsiet divus failus, pārsūtīsiet kopiju ārpus servera un salīdzināsiet SHA-256 kontrolsummas. Tas nav pilns datubāzes vai visas sistēmas atjaunošanas plāns.

· Atjaunināts · Lasīšana aptuveni 5 min.

Šajā pamācībā

Sagatavojiet divus termināļus un drošu vingrinājumu

Servera soļiem izmantojiet vienu nemainīgu Bash sesiju, bet lokālajiem soļiem — otru sesiju Linux vai WSL vidē ar GNU tar, sha256sum un OpenSSH. Turpmākie soļi izmanto iepriekš definētus mainīgos. Kļūdas gadījumā apstājieties un noskaidrojiet cēloni.

Vingrinājums izveido divus pagaidu paraugfailus lietotāja mājas direktorijā. Tas nemaina aktīvo Nginx, ugunsmūri vai vietni un neprasa arhīva atjaunošanu kā root. Pēc izvēles paraugus var aizstāt ar divu reālu failu kopijām no statiskās vietnes piemēra.

Pirms īstas dublēšanas uzskaitiet arī citus vietnes failus, pāradresācijas, DNS, atkarības un nepieciešamos noslēpumus. Divu failu kopija neietver to, kas nav izvēlēts arhīvam.

Izveidojiet atsevišķus paraugfailus serverī

Servera sesijā izveidojiet privātu vingrinājuma direktoriju. Nginx fragments tajā ir neaktīvs paraugs.

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"

Ja vēlaties pārbaudīt tieši agrākās pamācības lapu un konfigurāciju, pēc izvēles izpildiet nākamo bloku. Abiem avotiem jābūt nolasāmiem. Pirms kopēšanas pārskatiet saturu un apturiet vienlaicīgu izvietošanu, lai kopija atbilstu vienam laidienam. Pretējā gadījumā palieciet pie paraugfailiem.

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"

Nepievienojiet sertifikātu privātās atslēgas vai veselus sistēmas direktorijus tikai arhīva apjoma palielināšanai. Katram papildu failam jābūt skaidri iekļautam inventarizācijā un kontrolsummu sarakstā.

Izveidojiet kontrolsummas un arhīvu

Tajā pašā servera sesijā izveidojiet failu kontrolsummu sarakstu, arhīvu ar relatīviem ceļiem un paša arhīva kontrolsummu.

(
    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"

Arhīvā jābūt site un nginx direktorijiem, abiem paredzētajiem failiem un SHA256SUMS sarakstam. Nemainiet failus starp kontrolsummu aprēķinu un arhivēšanu. Arhīva kontrolsumma pārbauda pārsūtītos baitus, failu kontrolsummas — atjaunoto saturu. Ja uzbrucējs var aizstāt gan arhīvu, gan kontrolsummu, šī metode viena pati nepierāda izcelsmes autentiskumu.

Pārsūtiet kopiju uz citu ierīci

Lokālajā sesijā remote_backup vērtībai izmantojiet serverī izdrukāto precīzo ceļu, nevis paraugā atstāto REPLACE vērtību. Norādiet savu IP, kontu un atslēgu. Lokālais direktorijs tiks izveidots ar 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/"

Pirms pārsūtīšanas apstipriniet SSH servera identitāti. Ja ir savienojuma kļūda, izmantojiet SSH diagnostiku, nevis atslēgas pārbaudes apiešanu. SCP šifrē pārsūtīšanu, bet tar.gz ir saspiests, nevis šifrēts arhīvs. Kopijas glabāšanas vietai vajadzīga piemērota aizsardzība. Otra mape tajā pašā VPS nav neatkarīga kopija.

Pārbaudiet arhīvu un atjaunojiet tukšā direktorijā

Saglabātajā lokālajā sesijā vispirms pārbaudiet arhīva kontrolsummu. Turpiniet tikai pēc OK. Neaprēķiniet jaunu atsauces kontrolsummu bojātam arhīvam, lai kļūdu paslēptu.

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

Uzticamo arhīvu izpakojiet jaunā tukšā direktorijā. Komanda saglabā esošus failus un nepārņem arhīvā ierakstīto īpašnieku. Neizmantojiet sudo vai sistēmas saknes direktoriju.

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 paredzētajiem failiem kontrolsummas pārbaudē jābūt OK; apskatiet arī atjaunotās lapas virsrakstu. Tas apliecina izvēlēto failu saturu, nevis visu servera tiesību, ACL, lietotnes vai servisu atjaunošanu.

Atdaliet failu pārbaudi no pakalpojuma atjaunošanas

Pirms atjaunotas Nginx konfigurācijas aktivizēšanas atsevišķā aizvietotājvidē pārskatiet include ceļus, moduļus, īpašniekus, tiesības un sertifikātus. Nginx konfigurācijas tests jāveic samontētajai atjaunotajai konfigurācijai; nemainīta strādājošā servera tests to nepārbauda.

Šajā arhīvā nav TLS privāto atslēgu. Sertifikātus atkārtoti izsniedziet vai atjaunojiet no atsevišķas aizsargātas kopijas. Aktīvas datubāzes datu direktoriju nevar uzskatīt par konsekventu kopiju tikai tāpēc, ka to izdevies ievietot tar arhīvā: izmantojiet datubāzei atbilstošu metodi.

Pakalpojumu sniedzēja momentuzņēmumam pārbaudiet saglabāšanas termiņu, piekļuvi konta kļūmes gadījumā un atjaunošanas procesu. Tas pats par sevi nepierāda neatkarīgu kopiju vai veiksmīgu lietotnes atjaunošanu.

Nosakiet datu zuduma un atjaunošanas mērķi

RPO apraksta pieļaujamo datu zuduma intervālu, RTO — mērķi pakalpojuma atjaunošanas laikam. Piemēram, 24 stundas un 60 minūtes ir plānošanas mērķi, nevis šajā vingrinājumā izmērīti rezultāti. Ikdienas dublēšana palīdz tikai tad, ja kopija ir veiksmīga un atjaunojama.

Mazā ekrānā ritiniet tabulu sāniski, lai redzētu visas kolonnas.

Pārbaudes ierakstsKas jānorāda
KopijaIzveides laiks, lietotnes versija, galamērķis un termiņš
IntegritāteArhīva un failu kontrolsummu rezultāti
Atjaunošanas laiksVisa procesa sākums un beigas
IzņēmumiKas nav iekļauts: datubāze, atslēgas, DNS vai citi dati
PakalpojumsLietotnes darbplūsmas, HTTPS un ārējās pārbaudes

Mēriet visu atjaunošanu: piekļuves iegūšanu, jauno VM, konfigurāciju, sertifikātus un DNS. Lokāla arhīva izpakošana ir tikai daļa. Saglabājiet vairākus atjaunošanas punktus un uzraugiet neveiksmīgas dublēšanas paziņojumus. Kopiju glabāšanu iekļaujiet servera izmaksās.

Jautājumi un atbildes

Vai pēc vingrinājuma var izdzēst sākotnējo vietni?

Nē. Divu failu pārbaude nepierāda pilnu pakalpojuma atjaunošanu. Saglabājiet sākotnējos datus līdz brīdim, kad atsevišķajā vidē pārbaudīts viss vajadzīgais pakalpojums un tā atkarības.

Vai OK kontrolsumma atrod iztrūkstošu datubāzi?

Nē. Kontrolsummu saraksts pārbauda tikai tajā norādītos failus. Neiekļauta datubāze, noslēpums vai DNS iestatījums jāatklāj ar iepriekš sagatavotu inventarizāciju un pilnu atjaunošanas pārbaudi.

Paraugfailu arhivēšana un kontrolsummas pārbaudītas ar GNU rīkiem Git Bash vidē Windows. Tas nav attāla Ubuntu servera, SCP, sertifikātu vai Nginx aktivizēšanas izmēģinājums.

Saistītās pamācības