8. modulis · 8.1
Rezerves kopiju plāns Jūsu serverim
8. modulis: Rezerves kopijas un uzraudzība · Lasīšanas laiks: 11 min.
Mācīšanās mērķis: Pēc šīs nodarbības Jūs varēsiet izveidot rezerves kopiju plānu savam serverim: ko glabājat, kur, cik bieži un cik ilgi, kā arī kā pārliecināties, ka atjaunošana darbojas.
Pamatjēdzieni: 3-2-1 likums, momentuzņēmums (snapshot), pakalpojuma sniedzēja rezerves kopija, sava rezerves kopija ārpus pakalpojuma sniedzēja, RPO, RTO, datubāzes izgāztne (mariadb-dump, pg_dump), konfigurācija mapē /etc, Docker sējumi, šifrēšana, izspiedējvīruss (ransomware), append-only, atjaunošanas tests
Kāpēc plāns, nevis "rezerves kopija taču ir"?
Gandrīz ikviens, kurš ir zaudējis serveri, domāja, ka rezerves kopija ir. Tad izrādās, ka tajā ir tikai operētājsistēma, bet nav datubāzes, vai arī tā atrodas tajā pašā serverī, kura vairs nav, vai to ir nošifrējis tas pats izspiedējvīruss, vai neviens nezina paroli. Rezerves kopijai ir vērtība tikai tad, ja to var atjaunot. Tāpēc Jūs sākat ar plānu un beidzat ar testu.
Plāns atbild uz pieciem jautājumiem:
- Kas ir jāspēj atjaunot?
- Cik daudz datu drīkst zaudēt? (RPO)
- Cik ātri visam atkal jādarbojas? (RTO)
- Kur atrodas kopijas, un cik to ir?
- Kā Jūs zināt, ka tas darbojas?
Kas ir jāspēj atjaunot?
Serveris sastāv no slāņiem. Ne katram slānim ir vajadzīga rezerves kopija:
| Slānis | Piemērs | Rezerves kopija? |
|---|---|---|
| Operētājsistēma un pakotnes | Debian, nginx, PHP | Ne obligāti: var instalēt no jauna. Tomēr saglabājiet sarakstu: dpkg --get-selections |
| Konfigurācija | /etc (nginx, SSH, ugunsmūris, systemd vienības), Jūsu compose faili | Jā, neliela un neaizstājama |
| Lietotnes un vietnes | /var/www, /opt/<app>, /srv | Jā, ja vien tās nenāk no Git |
| Dati | datubāzes, augšupielādes, Docker sējumi (/var/lib/docker/volumes) | Jā, tas ir pats svarīgākais |
| Noslēpumi | paroles, API atslēgas, pašas rezerves kopijas atslēga | Jā, bet atsevišķi un šifrēti (skatīt zemāk) |
| Žurnāli, kešatmiņa, pagaidu faili | /var/log, /var/cache, /tmp | Parasti nē |
Īpašu uzmanību pievērsiet datubāzēm. Datubāze, kas darbojas, nepārtraukti raksta. Ja kopējat strādājošas MariaDB vai PostgreSQL failus, Jūs varat iegūt bojātu kopiju. Tāpēc vispirms izveidojiet izgāztni (dump): konsekventu momentuzņēmumu failā, ko pēc tam iekļaujat rezerves kopijā.
root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz(mariadb-dump agrāk sauca mysqldump; šī komanda parasti joprojām darbojas.) Ja datubāze darbojas konteinerā, Jūs to pašu darāt ar docker compose exec (nodarbība 9.4).
RPO un RTO: cik daudz drīkst zaudēt?
Divi jēdzieni no profesionālās prakses palīdz izdarīt izvēli:
- RPO (recovery point objective): cik ilga laika datus Jūs drīkstat zaudēt maksimāli? Ikdienas rezerves kopija plkst. 03:00 nozīmē: ja serveris avarē plkst. 22:00, Jūs zaudējat gandrīz dienu. Interneta veikalam ar pasūtījumiem tas ir par daudz; emuāram, kas mainās reizi nedēļā, tas ir pilnīgi pietiekami.
- RTO (recovery time objective): cik ilgi drīkst paiet, līdz viss atkal darbojas? Pakalpojuma sniedzēja pilnās rezerves kopijas atjaunošana var notikt dažās minūtēs; jauna servera izveide un visa atjaunošana manuāli var aizņemt stundas.
Pierakstiet tos savam serverim. Tie nosaka, cik bieži veidojat rezerves kopiju un kā to glabājat.
Momentuzņēmums, pakalpojuma sniedzēja rezerves kopija, sava rezerves kopija
VPS serverī parasti ir trīs veidu drošības tīkli. Tie ir līdzīgi, taču aizsargā pret dažādām lietām.
1. Momentuzņēmums (snapshot). Visa virtuālā diska momentuzņēmums, kas izveidots pakalpojuma sniedzēja panelī. To var ātri izveidot un ātri atjaunot. Ideāli piemērots tieši pirms jaunināšanas (nodarbība 4.3). Taču: lielākajai daļai pakalpojuma sniedzēju momentuzņēmums atrodas tajā pašā krātuvē, kur Jūsu serveris. Ja šī krātuve sabojājas vai Jūs zaudējat savu kontu, momentuzņēmuma arī vairs nav. Turklāt momentuzņēmumu ilgi neglabā: tas aug līdzi visām turpmākajām izmaiņām. Momentuzņēmums nav rezerves kopija.
2. Pakalpojuma sniedzēja rezerves kopija. Daudzi pakalpojuma sniedzēji (dažkārt kā papildu iespēju) katru dienu automātiski izveido visa Jūsu servera kopiju citā krātuvē. WebOké tā, piemēram, ir visa VPS ikdienas rezerves kopija, ko glabā septiņas dienas; citiem pakalpojuma sniedzējiem tas darbojas līdzīgi, ar saviem termiņiem. Tas ir labs otrais slānis pret bojātu aparatūru un pret Jūsu pašu vakardienas kļūdām. Taču tā joprojām ir viena puse: Jūsu konts, Jūsu maksājums, viņu traucējumi. Un atjaunošana parasti notiek visam serverim uzreiz.
3. Jūsu pašu rezerves kopija ārpus pakalpojuma sniedzēja. Jūsu datu kopija pie citas puses vai citā vietā, ko izveidojat un pārvaldāt Jūs paši (nodarbība 8.2). Šis ir slānis, kas paliek, ja viss pārējais neizdodas.
3-2-1 likums
Plaši izmantots īkšķa likums:
- 3 Jūsu datu kopijas (oriģināls plus divas rezerves kopijas);
- 2 dažādos krātuves veidos vai sistēmās;
- no kurām 1 atrodas citā vietā.
VPS gadījumā tas var būt: dati serverī, pakalpojuma sniedzēja ikdienas rezerves kopija un šifrēta sava rezerves kopija ar restic krātuvē pie citas puses. Mūsdienīgs papildinājums: vismaz vienu kopiju nedrīkst varēt izdzēst tas, kurš pārņem serveri (bezsaistē vai append-only, nodarbība 8.2). Izspiedējvīruss serverī aktīvi meklē rezerves kopijas, lai arī tās nošifrētu vai izdzēstu. Rezerves kopija, ko serveris pats drīkst izdzēst, pret to neaizsargā.
Šifrēšana un Jūsu rezerves kopijas parole
Rezerves kopijai pie citas puses jābūt šifrētai: tajā ir klientu dati, paroles un atslēgas. restic (nodarbība 8.2) šifrē pēc noklusējuma. Taču tas rada jaunu risku: Jūsu rezerves kopijas parole. Ja to pazaudējat, rezerves kopija kļūst nelietojama. Un tāpat, ja tā glabājas tikai serverī, kuru esat zaudējuši.
Tāpēc glabājiet paroli arī ārpus servera: savā paroļu pārvaldniekā un, ja vēlaties, uz papīra seifā. Tas pats attiecas uz piekļuves datiem krātuvei, kurā atrodas Jūsu rezerves kopija.
Atjaunošanas testēšana
Plāna svarīgākā daļa. Atjaunošanas tests nozīmē: Jūs tiešām atjaunojat rezerves kopiju vietā, kur tā neko nesabojā, un pārbaudāt, vai rezultāts darbojas.
- Mazi un bieži: atjaunojiet vienu failu vai vienu mapi uz
/tmp/terugun salīdziniet (diff). Piemēram, reizi mēnesī. - Lieli un reizēm: izveidojiet no rezerves kopijas pilnīgi jaunu testa serveri, importējiet datubāzi, palaidiet vietni. Piemēram, reizi gadā vai pēc katras lielas izmaiņas. Tas vienlaikus ir arī treniņš gadījumam, ja tiešām kaut kas noiet greizi (nodarbība 10.3).
Pierakstiet, cik ilgi tas aizņēma: tas ir Jūsu patiesais RTO.
Glabāšanas termiņi
Neglabājiet tikai pēdējo rezerves kopiju. Ja tikai pēc divām nedēļām atklājat, ka fails ir bojāts vai izdzēsts, Jums vajadzēs trīs nedēļas vecu rezerves kopiju. Plaši izmantota shēma: septiņas ikdienas, četras iknedēļas un sešas ikmēneša versijas. restic to nodrošina ar forget (nodarbība 8.2). Atcerieties arī par VDAR (GDPR): personas datus neglabājiet ilgāk, nekā nepieciešams, arī rezerves kopijās ne. Dokumentējiet savus glabāšanas termiņus.
Praksē
Izmantojiet pakalpojuma sniedzēja momentuzņēmumu tieši pirms riskantām izmaiņām un pēc tam to izdzēsiet; atstājiet ieslēgtu pakalpojuma sniedzēja ikdienas rezerves kopiju, ja tāda ir; un papildus veidojiet savu šifrētu datu un konfigurācijas rezerves kopiju pie citas puses. WebOké VPS ekrānā tas saucas Snapshots un Backups; citiem pakalpojuma sniedzējiem nosaukumi un termiņi atšķiras, bet princips ir tas pats. Hostinga pakai vai pārvaldītam pakalpojumam bieži ir citas vienošanās: noskaidrojiet, kas ir paredzēts Jūsu gadījumā.
Kopsavilkums
- Rezerves kopijai ir vērtība tikai tad, ja atjaunošana darbojas; sāciet ar plānu un beidziet ar testu.
- Veidojiet rezerves kopijas galvenokārt datiem un konfigurācijai: datubāzēm kā izgāztnei,
/etc, vietnēm, Docker sējumiem, compose failiem. - Nosakiet RPO (cik daudz drīkst zaudēt) un RTO (cik ātri visam jādarbojas).
- Momentuzņēmums (tā pati krātuve, īslaicīgi), pakalpojuma sniedzēja rezerves kopija (cita krātuve, tā pati puse) un sava rezerves kopija ārpus pakalpojuma sniedzēja ir trīs dažādi slāņi; ievērojiet 3-2-1 likumu ar vismaz vienu kopiju, ko serveris pats nevar izdzēst.
- Šifrējiet, glabājiet rezerves kopijas paroli ārpus servera un testējiet atjaunošanu: mazos apjomos bieži, lielos apjomos reizēm.
Tests (quiz)
Uzdevums
Uzdevums O8.1: Jūsu rezerves kopiju plāns. Izveidojiet savam serverim rezerves kopiju plānu uz vienas lapas: kas jāspēj atjaunot (pa slāņiem), Jūsu RPO un RTO, kādas kopijas Jums ir (momentuzņēmums, pakalpojuma sniedzēja, sava) un kur, Jūsu glabāšanas termiņi, kur glabājas rezerves kopijas parole un kad veicat atjaunošanas testu. Aizpildiet veidlapu; pēc iesniegšanas redzēsiet plāna piemēru, ar ko salīdzināt savu plānu.
Uzdevums O8.1: Jūsu rezerves kopiju plāns
Šo uzdevumu veicat paši; neviens to nepārbauda. Atzīmējiet, ko esat izdarījuši, un atzīmējiet uzdevumu kā paveiktu.
Datubāzes ar dump, nevis kā atsevišķi strādājošas datubāzes faili. Katru dienu šifrēti (restic) pie cita pakalpojumu sniedzēja; momentuzņēmums (snapshot) tikai izmaiņu laikā. Labs sākums ir 7 dienas, 4 nedēļas un 6 mēneša versijas. Katru mēnesi neliela atjaunošana, katru gadu pilna sistēmas atjaunošana no nulles. Nekad neievadiet īstu paroli.
Jūsu atzīmes un piezīmes paliek tikai šajā pārlūkprogrammā; mēs tās nekur nesūtām. Ja esat pieteikušies, sadaļā Mani kursi saglabājam tikai to, ka uzdevums ir paveikts.
Vairāk lasīt
- VPS snapshot kopijas un rezerves kopijas
- Dublēšanas stratēģija: 3-2-1 noteikums Jūsu uzņēmumam
- Kursā "Droši tiešsaistē": nodarbības par 3-2-1 likumu un rezerves kopijām, kas pārdzīvo izspiedējvīrusu.
- MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
- PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html
