Modul 8 · 8.1
Načrt varnostnega kopiranja za Vaš strežnik
Modul 8: Varnostne kopije in nadzor · Čas branja: 11 minut
Učni cilj: Po tej lekciji boste za svoj strežnik znali pripraviti načrt varnostnega kopiranja: kaj shranjujete, kje, kako pogosto in kako dolgo ter kako zagotovo veste, da obnovitev deluje.
Ključni pojmi: pravilo 3-2-1, posnetek (snapshot), varnostna kopija ponudnika, lastna varnostna kopija zunaj ponudnika, RPO, RTO, izpis podatkovne baze (mariadb-dump, pg_dump), konfiguracija v /etc, nosilci Docker (volumes), šifriranje, izsiljevalska programska oprema (ransomware), append-only, preizkus obnovitve
Zakaj načrt in ne samo "saj imamo varnostno kopijo"?
Skoraj vsak, ki je izgubil strežnik, je mislil, da ima varnostno kopijo. Nato se izkaže, da vsebuje samo operacijski sistem, podatkovne baze pa ne, ali pa je na istem strežniku, ki ga zdaj ni več, ali pa jo je šifrirala ista izsiljevalska programska oprema, ali pa nihče ne pozna gesla. Varnostna kopija je nekaj vredna šele, ko jo lahko obnovite. Zato začnete z načrtom in končate s preizkusom.
Načrt odgovori na pet vprašanj:
- Kaj mora biti mogoče obnoviti?
- Koliko podatkov lahko izgubite? (RPO)
- Kako hitro mora vse spet delovati? (RTO)
- Kje so kopije in koliko jih je?
- Kako veste, da deluje?
Kaj mora biti mogoče obnoviti?
Strežnik je sestavljen iz plasti. Ni treba, da je vsaka plast v varnostni kopiji:
| Plast | Primer | Varnostna kopija? |
|---|---|---|
| Operacijski sistem in paketi | Debian, nginx, PHP | Ne nujno: lahko jih znova namestite. Shranite pa seznam: dpkg --get-selections |
| Konfiguracija | /etc (nginx, SSH, požarni zid, enote systemd), Vaše datoteke compose | Da, majhna in nepogrešljiva |
| Aplikacije in spletna mesta | /var/www, /opt/<app>, /srv | Da, razen če prihajajo iz Gita |
| Podatki | podatkovne baze, naložene datoteke, nosilci Docker (/var/lib/docker/volumes) | Da, to je najpomembnejše |
| Skrivnosti | gesla, ključi API, ključ same varnostne kopije | Da, vendar ločeno in šifrirano (glejte spodaj) |
| Dnevniki, predpomnilniki, začasne datoteke | /var/log, /var/cache, /tmp | Večinoma ne |
Posebej pazite na podatkovne baze. Podatkovna baza, ki teče, nenehno piše. Če kopirate datoteke delujoče baze MariaDB ali PostgreSQL, lahko dobite poškodovano kopijo. Zato najprej naredite izpis (dump): dosleden trenutni posnetek v obliki datoteke, ki ga nato vključite v varnostno kopijo.
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 se je prej imenoval mysqldump; ta ukaz običajno še vedno deluje.) Če podatkovna baza teče v vsebniku, storite enako z docker compose exec (lekcija 9.4).
RPO in RTO: koliko lahko izgubite?
Pri odločitvah Vam pomagata dva pojma iz stroke:
- RPO (recovery point objective): koliko časa podatkov lahko največ izgubite? Dnevna varnostna kopija ob 03:00 pomeni: če se strežnik sesuje ob 22:00, ste izgubili skoraj en dan. Za spletno trgovino z naročili je to preveč; za blog, ki se spremeni enkrat na teden, je povsem v redu.
- RTO (recovery time objective): koliko časa lahko traja, da vse spet deluje? Obnovitev celotne varnostne kopije ponudnika lahko traja nekaj minut; postavitev novega strežnika in ročna obnovitev vsega lahko traja ure.
Zapišite si ju za svoj strežnik. Določata, kako pogosto delate varnostne kopije in kako jih shranjujete.
Posnetek, varnostna kopija ponudnika, lastna varnostna kopija
Na VPS imate običajno tri vrste varovalne mreže. Med seboj so si podobne, vendar ščitijo pred različnimi stvarmi.
1. Posnetek (snapshot). Trenutni posnetek celotnega navideznega diska, ki ga naredite v nadzorni plošči ponudnika. Hitro ga naredite in hitro obnovite. Idealen je tik pred nadgradnjo (lekcija 4.3). Vendar: pri večini ponudnikov je posnetek na isti shrambi kot Vaš strežnik. Če se ta shramba pokvari ali izgubite račun, je tudi posnetka konec. Posnetka tudi ne hranite dolgo: raste z vsemi poznejšimi spremembami. Posnetek ni varnostna kopija.
2. Varnostna kopija ponudnika. Številni ponudniki (po potrebi kot dodatna možnost) vsak dan samodejno naredijo kopijo celotnega strežnika na drugi shrambi. Pri WebOké je to na primer dnevna varnostna kopija celotnega VPS, ki se hrani sedem dni; pri drugih ponudnikih deluje podobno, z lastnimi roki. To je dobra druga plast proti pokvarjeni strojni opremi in proti Vašim včerajšnjim napakam. A še vedno gre za eno stranko: Vaš račun, Vaše plačilo, njihov izpad. Obnovitev pa običajno poteka za celoten strežnik naenkrat.
3. Vaša lastna varnostna kopija, zunaj ponudnika. Kopija Vaših podatkov pri drugi stranki ali na drugem mestu, ki jo naredite in upravljate sami (lekcija 8.2). To je plast, ki ostane, ko gre vse drugo narobe.
Pravilo 3-2-1
Uveljavljeno pravilo:
- 3 kopije Vaših podatkov (izvirnik in dve varnostni kopiji);
- na 2 različnih vrstah shrambe ali sistemih;
- od tega 1 na drugi lokaciji.
Za VPS je to lahko: podatki na strežniku, dnevna varnostna kopija ponudnika in šifrirana lastna varnostna kopija z orodjem restic v shrambo pri drugi stranki. Sodobna dopolnitev je, da mora biti vsaj ene kopije nemogoče izbrisati za nekoga, ki prevzame strežnik (brez povezave ali append-only, lekcija 8.2). Izsiljevalska programska oprema na strežniku dejavno išče varnostne kopije, da bi jih prav tako šifrirala ali izbrisala. Varnostna kopija, ki jo sme strežnik sam izbrisati, pred tem ne ščiti.
Šifriranje in geslo Vaše varnostne kopije
Varnostna kopija pri drugi stranki mora biti šifrirana: v njej so podatki strank, gesla in ključi. restic (lekcija 8.2) privzeto šifrira. S tem pa nastane novo tveganje: geslo Vaše varnostne kopije. Če ga izgubite, je varnostna kopija neuporabna. Enako velja, če je shranjeno le na strežniku, ki ste ga izgubili.
Zato geslo shranite tudi zunaj strežnika: v upravitelju gesel in po potrebi na papirju v sefu. Enako velja za dostopne podatke shrambe, v kateri je Vaša varnostna kopija.
Preizkus obnovitve
Najpomembnejši del načrta. Preizkus obnovitve pomeni: varnostno kopijo zares obnovite na mestu, kjer ničesar ne pokvari, in preverite, ali rezultat deluje.
- Majhen in pogost: eno datoteko ali eno mapo obnovite v
/tmp/terugin primerjate (diff). Na primer enkrat na mesec. - Velik in občasen: iz varnostne kopije postavite celoten nov preizkusni strežnik, uvozite podatkovno bazo, zaženete spletno mesto. Na primer enkrat na leto ali ob vsaki večji spremembi. To je hkrati tudi vaja za primer, ko gre zares kaj narobe (lekcija 10.3).
Zapišite si, koliko časa je trajalo: to je Vaš resnični RTO.
Roki hrambe
Ne hranite samo zadnje varnostne kopije. Če šele po dveh tednih odkrijete, da je datoteka poškodovana ali izbrisana, potrebujete varnostno kopijo izpred treh tednov. Uveljavljen razpored: sedem dnevnih, štiri tedenske in šest mesečnih različic. restic to uredi z forget (lekcija 8.2). Pomislite tudi na GDPR (splošna uredba o varstvu podatkov): osebnih podatkov ne hranite dlje, kot je potrebno, tudi v varnostnih kopijah ne. Svoje roke hrambe zapišite.
V praksi
Posnetek ponudnika uporabite tik pred tveganimi spremembami in ga nato izbrišite; dnevno varnostno kopijo ponudnika pustite vklopljeno, če jo imate; poleg tega pa naredite lastno šifrirano varnostno kopijo podatkov in konfiguracije pri drugi stranki. Pri WebOké se to na zaslonu VPS imenuje Snapshots in Backups; pri drugih ponudnikih so imena in roki drugačni, načelo pa je enako. Paket gostovanja ali upravljana storitev ima pogosto drugačne dogovore: preverite, kaj je urejeno v Vašem primeru.
Povzetek
- Varnostna kopija je nekaj vredna šele, ko obnovitev deluje; začnite z načrtom in končajte s preizkusom.
- Varnostno kopirajte predvsem podatke in konfiguracijo: podatkovne baze kot izpis,
/etc, spletna mesta, nosilce Docker, datoteke compose. - Določite RPO (koliko lahko izgubite) in RTO (kako hitro mora delovati).
- Posnetek (ista shramba, kratko), varnostna kopija ponudnika (druga shramba, ista stranka) in lastna varnostna kopija zunaj ponudnika so tri različne plasti; upoštevajte pravilo 3-2-1 z vsaj eno kopijo, ki je strežnik sam ne more izbrisati.
- Šifrirajte, geslo varnostne kopije shranite zunaj strežnika in obnovitev preizkušajte v majhnem obsegu pogosto, v velikem občasno.
Kviz
Naloga
Naloga O8.1: Vaš načrt varnostnega kopiranja. Za svoj strežnik pripravite načrt varnostnega kopiranja na eni strani: kaj mora biti mogoče obnoviti (po plasteh), Vaš RPO in RTO, katere kopije imate (posnetek, ponudnik, lastna) in kje, Vaše roke hrambe, kje je shranjeno geslo varnostne kopije in kdaj izvedete preizkus obnovitve. Izpolnite obrazec; po oddaji boste videli primer načrta, s katerim lahko primerjate svojega.
Naloga O8.1: Vaš načrt varnostnega kopiranja
To nalogo opravite sami; nihče je ne pregleda. Odkljukajte, kar ste naredili, in nalogo označite kot opravljeno.
Baze podatkov z izvozom (dump), ne kot posamezne datoteke delujoče baze. Vsak dan šifrirano (restic) k drugemu ponudniku; posnetek (snapshot) samo ob spremembah. 7 dnevnih, 4 tedenske in 6 mesečnih različic je dober začetek. Vsak mesec manjša obnovitev, vsako leto popolna ponovna postavitev. Nikoli ne vpišite pravega gesla.
Vaše kljukice in zapiski ostanejo samo v tem brskalniku, nikamor jih ne pošiljamo. Če ste prijavljeni, v Moji tečaji shranimo samo podatek, da ste nalogo opravili.
Za nadaljnje branje
- Posnetki in varnostne kopije Vašega VPS
- Strategija varnostnega kopiranja: pravilo 3-2-1 za Vaše lastno podjetje
- Brezplačen tečaj Varno na spletu za podjetnike 6.1: Pravilo 3-2-1 in kaj morate varnostno kopirati
- Brezplačen tečaj Varno na spletu za podjetnike 6.2: Varnostne kopije, ki prežijejo izsiljevalsko programje
- 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
- VPS: od prve prijave do varnega strežnika 1.5: Posnetki stanja: varnostna mreža za vsako večjo spremembo
- VPS: od prve prijave do varnega strežnika 1.6: Obnovitev varnostnih kopij WebOké
