Biztonsági mentési terv a szerveréhez

Modul 8: Biztonsági mentések és felügyelet · Olvasási idő: 11 perc

Tanulási cél: A lecke végére el tud készíteni egy biztonsági mentési tervet a saját szerveréhez: mit ment, hova, milyen gyakran és meddig őrzi meg, és hogyan győződik meg arról, hogy a visszaállítás működik.

Kulcsfogalmak: 3-2-1 szabály, pillanatkép (snapshot), a szolgáltató biztonsági mentése, saját mentés a szolgáltatón kívül, RPO, RTO, adatbázis-dump (mariadb-dump, pg_dump), konfiguráció a /etc könyvtárban, Docker-kötetek, titkosítás, zsarolóvírus (ransomware), append-only, visszaállítási teszt

Miért kell terv, és miért nem elég, hogy "van mentés"?

Szinte mindenki, aki elveszített már egy szervert, úgy gondolta, hogy van mentése. Aztán kiderül, hogy a mentés csak az operációs rendszert tartalmazza, az adatbázist nem, vagy ugyanazon a szerveren volt, amely most elveszett, vagy ugyanaz a zsarolóvírus titkosította, vagy senki sem tudja a jelszavát. Egy mentés csak akkor ér valamit, ha vissza is lehet állítani. Ezért tervvel kezdünk, és teszttel zárunk.

Egy terv öt kérdésre ad választ:

1. Mit kell tudni visszaállítani?
2. Mennyi adat veszhet el legfeljebb? (RPO)
3. Milyen gyorsan kell ismét működnie? (RTO)
4. Hol vannak a másolatok, és hány van belőlük?
5. Honnan tudja, hogy működik?

Mit kell tudni visszaállítani?

Egy szerver rétegekből áll. Nem minden rétegnek kell a mentésben lennie:

Különösen figyeljen az adatbázisokra. Egy futó adatbázis folyamatosan ír. Ha egy futó MariaDB vagy PostgreSQL fájljait másolja, sérült másolatot kaphat. Ezért először készítsen egy dumpot: egy konzisztens pillanatképet fájlként, amelyet aztán a mentésbe is belevesz.

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

(A mariadb-dump korábbi neve mysqldump volt; ez a parancs általában még mindig működik.) Ha az adatbázis konténerben fut, ugyanezt a docker compose exec paranccsal teszi meg (9.4. lecke).

RPO és RTO: mennyi veszhet el?

Két, a szakmai gyakorlatból ismert fogalom segít a döntésekben:

• RPO (recovery point objective, helyreállítási pont célérték): legfeljebb mennyi időnyi adat veszhet el? A napi mentés 03:00-kor azt jelenti, hogy ha a szerver 22:00-kor összeomlik, majdnem egy napnyi adat elvész. Egy rendeléseket fogadó webáruháznak ez túl sok; egy hetente egyszer változó blognak teljesen rendben van.
• RTO (recovery time objective, helyreállítási idő célérték): mennyi idő telhet el, amíg minden újra működik? A szolgáltató teljes mentésének visszaállítása perceket vehet igénybe; egy új szerver felépítése és mindennek a kézi visszaállítása órákig tarthat.

Írja le ezeket a saját szerveréhez. Ezek határozzák meg, milyen gyakran ment, és hogyan őrzi meg a mentést.

Pillanatkép, a szolgáltató mentése, saját mentés

Egy VPS-en általában háromféle biztonsági háló létezik. Hasonlítanak egymásra, de mástól védenek.

1. A pillanatkép (snapshot). A teljes virtuális lemez pillanatnyi állapota, amelyet a szolgáltató felületén készít el. Gyorsan elkészíthető és gyorsan visszaállítható. Ideális közvetlenül egy frissítés előtt (4.3. lecke). Azonban a legtöbb szolgáltatónál a pillanatkép ugyanazon a tárolón van, mint a szerver. Ha ez a tároló meghibásodik, vagy elveszíti a fiókját, a pillanatkép is elvész. Pillanatképet ráadásul nem érdemes sokáig megtartani: az azt követő összes változással együtt nő. A pillanatkép nem biztonsági mentés.

2. A szolgáltató biztonsági mentése. Sok szolgáltató (adott esetben opcióként) naponta automatikusan másolatot készít a teljes szerverről, egy másik tárolóra. A WebOké-nál ez például a teljes VPS napi mentése, amelyet hét napig őrzünk meg; más szolgáltatóknál hasonlóan működik, saját határidőkkel. Ez jó második réteg a meghibásodott hardver és az Ön tegnapi tévedései ellen. De továbbra is egyetlen félről van szó: az Ön fiókja, az Ön fizetése, az ő üzemzavaruk. A visszaállítás pedig általában egyszerre az egész szerverre vonatkozik.

3. Saját mentés, a szolgáltatón kívül. Az adatairól készült másolat egy másik félnél vagy egy másik helyen, amelyet Ön készít és kezel (8.2. lecke). Ez az a réteg, amely megmarad, ha minden más elromlik.

A 3-2-1 szabály

Egy elterjedt ökölszabály:

• 3 másolat az adatairól (az eredeti és két mentés);
• 2 különböző típusú tárolón vagy rendszeren;
• amelyek közül 1 egy másik helyszínen van.

Egy VPS esetében ez lehet: az adatok a szerveren, a szolgáltató napi mentése, és egy titkosított saját mentés restic segítségével egy másik fél tárolójára. Korszerű kiegészítés, hogy legalább egy másolatot ne tudjon törölni az, aki átveszi az irányítást a szerver felett (offline vagy append-only, 8.2. lecke). A szerveren lévő zsarolóvírus aktívan keresi a mentéseket, hogy azokat is titkosítsa vagy törölje. Az a mentés, amelyet maga a szerver törölhet, nem nyújt ez ellen védelmet.

Titkosítás és a mentés jelszava

Egy másik félnél tárolt mentésnek titkosítottnak kell lennie: ügyféladatok, jelszavak és kulcsok vannak benne. A restic (8.2. lecke) alapértelmezés szerint titkosít. Ezzel azonban új kockázat jelenik meg: a mentés jelszava. Ha elveszíti, a mentés használhatatlan. És akkor is, ha a jelszó csak azon a szerveren volt meg, amely elveszett.

Ezért a jelszót a szerveren kívül is őrizze meg: a jelszókezelőjében, és adott esetben papíron egy széfben. Ugyanez vonatkozik annak a tárolónak a hozzáférési adataira, ahol a mentés van.

A visszaállítás tesztelése

A terv legfontosabb része. A visszaállítási teszt azt jelenti, hogy egy mentést ténylegesen visszaállít, olyan helyre, ahol semmit sem ronthat el, és ellenőrzi, hogy az eredmény működik-e.

• Kicsiben és gyakran: egyetlen fájl vagy mappa visszaállítása a /tmp/terug helyre, majd összehasonlítás (diff). Például havonta.
• Nagyban és időnként: egy teljesen új tesztszerver felépítése a mentésből, az adatbázis importálása, a webhely elindítása. Például évente egyszer, vagy minden nagyobb változtatásnál. Ez egyben gyakorlás arra az esetre is, ha tényleg baj történik (10.3. lecke).

Jegyezze fel, mennyi ideig tartott: ez az Ön valódi RTO-ja.

Megőrzési idők

Ne csak a legutóbbi mentést őrizze meg. Ha csak két hét múlva veszi észre, hogy egy fájl megsérült vagy törlődött, egy három héttel korábbi mentésre lesz szüksége. Egy elterjedt séma: hét napi, négy heti és hat havi változat. A restic ezt a forget segítségével kezeli (8.2. lecke). Gondoljon a GDPR-ra is: a személyes adatokat nem őrizheti a szükségesnél tovább, a mentésekben sem. Rögzítse a megőrzési időket.

A gyakorlatban

Használja a szolgáltató pillanatképét közvetlenül a kockázatos változtatások előtt, és utána törölje; hagyja bekapcsolva a szolgáltató napi mentését, ha van ilyen; emellett készítsen saját, titkosított mentést az adatairól és a konfigurációról egy másik félhez. A WebOké-nál ez a VPS képernyőjén a Snapshots és a Backups; más szolgáltatóknál a nevek és a határidők eltérnek, de az elv ugyanaz. Egy tárhelycsomag vagy menedzselt szolgáltatás esetében gyakran más megállapodások érvényesek: nézze meg, mi van az Ön esetében szabályozva.

Összefoglalás

• Egy mentés csak akkor ér valamit, ha a visszaállítás működik; kezdjen tervvel, és zárja teszttel.
• Elsősorban az adatokat és a konfigurációt mentse: az adatbázisokat dumpként, a /etc könyvtárat, a webhelyeket, a Docker-köteteket és a compose-fájlokat.
• Határozza meg az RPO-t (mennyi veszhet el) és az RTO-t (milyen gyorsan kell működnie).
• A pillanatkép (ugyanaz a tároló, rövid ideig), a szolgáltató mentése (másik tároló, ugyanaz a fél) és a szolgáltatón kívüli saját mentés három különböző réteg; kövesse a 3-2-1 szabályt, legalább egy olyan másolattal, amelyet maga a szerver nem tud törölni.
• Titkosítson, őrizze a mentés jelszavát a szerveren kívül, és tesztelje a visszaállítást kicsiben gyakran, nagyban időnként.

Kvíz

Feladat

O8.1. feladat: Az Ön biztonsági mentési terve. Készítsen egyoldalas biztonsági mentési tervet a saját szerveréhez: mit kell tudni visszaállítani (rétegenként), mi az RPO és az RTO, milyen másolatai vannak (pillanatkép, szolgáltató, saját) és hol, mik a megőrzési idők, hol van a mentés jelszava, és mikor végez visszaállítási tesztet. Töltse ki az űrlapot; a beküldés után egy mintatervet lát, amelyet összevethet a sajátjával.

További olvasnivaló

• A VPS snapshotjai és biztonsági mentései
• Biztonsági mentési stratégia: a 3-2-1 szabály a saját vállalkozás számára
• A Biztonságosan online tanfolyamban: a 3-2-1 szabályról és a zsarolóvírust túlélő mentésekről szóló leckék.
• 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