Plan kopii zapasowych dla Państwa serwera

Moduł 8: Kopie zapasowe i monitorowanie · Czas czytania: 11 min

Cel lekcji: Po tej lekcji będą Państwo w stanie przygotować plan kopii zapasowych dla własnego serwera: co przechowywać, gdzie, jak często i jak długo oraz jak upewnić się, że przywracanie działa.

Kluczowe pojęcia: zasada 3-2-1, snapshot, kopia zapasowa dostawcy, własna kopia zapasowa poza dostawcą, RPO, RTO, zrzut bazy danych (mariadb-dump, pg_dump), konfiguracja w /etc, wolumeny Dockera, szyfrowanie, ransomware, append-only, test przywracania

Dlaczego plan, a nie "przecież jest kopia zapasowa"?

Prawie każdy, kto stracił serwer, był przekonany, że ma kopię zapasową. Potem okazuje się, że zawiera ona tylko system operacyjny, a nie bazę danych, albo znajduje się na tym samym serwerze, którego już nie ma, albo została zaszyfrowana przez to samo ransomware, albo nikt nie zna hasła. Kopia zapasowa jest coś warta dopiero wtedy, gdy można ją przywrócić. Dlatego zaczynamy od planu, a kończymy na teście.

Plan odpowiada na pięć pytań:

1. Co musi dać się przywrócić?
2. Ile danych mogą Państwo stracić? (RPO)
3. Jak szybko wszystko musi znów działać? (RTO)
4. Gdzie znajdują się kopie i ile ich jest?
5. Skąd wiadomo, że to działa?

Co musi dać się przywrócić?

Serwer składa się z warstw. Nie każda warstwa musi trafić do kopii zapasowej:

Szczególną uwagę prosimy zwrócić na bazy danych. Działająca baza danych nieustannie zapisuje dane. Jeśli skopiują Państwo pliki działającej bazy MariaDB lub PostgreSQL, kopia może być uszkodzona. Dlatego najpierw należy wykonać zrzut (dump): spójny obraz bazy w danym momencie, zapisany jako plik, który następnie trafia do kopii zapasowej.

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 nazywało się dawniej mysqldump; to polecenie zazwyczaj nadal działa.) Jeśli baza danych działa w kontenerze, robią Państwo to samo za pomocą docker compose exec (lekcja 9.4).

RPO i RTO: ile mogą Państwo stracić?

Dwa pojęcia z praktyki zawodowej pomagają w podejmowaniu decyzji:

• RPO (recovery point objective): z jakiego okresu mogą Państwo maksymalnie stracić dane? Codzienna kopia zapasowa o 03:00 oznacza, że jeśli serwer ulegnie awarii o 22:00, tracą Państwo prawie cały dzień. Dla sklepu internetowego z zamówieniami to za dużo; dla bloga, który zmienia się raz w tygodniu, w zupełności wystarczy.
• RTO (recovery time objective): ile czasu może upłynąć, zanim wszystko znów zadziała? Przywrócenie pełnej kopii zapasowej dostawcy może potrwać kilka minut; zbudowanie nowego serwera i ręczne przywrócenie wszystkiego może zająć godziny.

Prosimy zapisać te wartości dla własnego serwera. Decydują one o tym, jak często wykonują Państwo kopię zapasową i jak ją przechowują.

Snapshot, kopia zapasowa dostawcy, własna kopia zapasowa

Na VPS mają Państwo zazwyczaj trzy rodzaje zabezpieczenia. Są do siebie podobne, ale chronią przed czymś innym.

1. Snapshot. Obraz całego dysku wirtualnego w danym momencie, wykonany w panelu Państwa dostawcy. Szybko się go tworzy i szybko przywraca. Idealny tuż przed aktualizacją systemu (lekcja 4.3). Jednak u większości dostawców snapshot znajduje się na tej samej pamięci masowej co Państwa serwer. Jeśli ta pamięć ulegnie awarii albo stracą Państwo dostęp do konta, snapshot również przepada. Snapshotu nie przechowuje się też długo: rośnie wraz ze wszystkimi późniejszymi zmianami. Snapshot nie jest kopią zapasową.

2. Kopia zapasowa dostawcy. Wielu dostawców (czasem jako opcja) automatycznie wykonuje codziennie kopię całego serwera na innej pamięci masowej. W WebOké jest to na przykład codzienna kopia zapasowa całego VPS, przechowywana przez siedem dni; u innych dostawców działa to podobnie, z własnymi okresami przechowywania. To dobra druga warstwa ochrony przed uszkodzonym sprzętem i przed Państwa własnymi pomyłkami z dnia poprzedniego. Nadal jest to jednak jeden podmiot: Państwa konto, Państwa płatność, ich awaria. Poza tym przywracanie dotyczy zazwyczaj całego serwera naraz.

3. Własna kopia zapasowa poza dostawcą. Kopia Państwa danych u innego podmiotu lub w innym miejscu, którą Państwo sami tworzą i którą zarządzają (lekcja 8.2). To warstwa, która zostaje, gdy wszystko inne zawiedzie.

Zasada 3-2-1

Powszechnie stosowana reguła:

• 3 kopie Państwa danych (oryginał plus dwie kopie zapasowe);
• na 2 różnych rodzajach pamięci masowej lub systemach;
• z czego 1 w innej lokalizacji.

W przypadku VPS może to wyglądać tak: dane na serwerze, codzienna kopia zapasowa dostawcy oraz zaszyfrowana własna kopia zapasowa wykonana za pomocą restic na pamięć masową u innego podmiotu. Współczesnym uzupełnieniem jest zasada, że co najmniej jednej kopii nie może usunąć ktoś, kto przejmie serwer (offline lub append-only, lekcja 8.2). Ransomware na serwerze aktywnie szuka kopii zapasowych, aby je również zaszyfrować lub usunąć. Kopia zapasowa, którą sam serwer może usunąć, nie stanowi przed tym ochrony.

Szyfrowanie i hasło do kopii zapasowej

Kopia zapasowa przechowywana u innego podmiotu musi być zaszyfrowana: zawiera dane klientów, hasła i klucze. restic (lekcja 8.2) domyślnie szyfruje dane. Pojawia się jednak nowe ryzyko: hasło do kopii zapasowej. Jeśli je Państwo zgubią, kopia zapasowa staje się bezużyteczna. Tak samo, jeśli hasło znajduje się tylko na serwerze, który Państwo stracili.

Dlatego prosimy przechowywać hasło również poza serwerem: w menedżerze haseł, a ewentualnie także na papierze w sejfie. To samo dotyczy danych dostępowych do pamięci masowej, na której znajduje się kopia zapasowa.

Testowanie przywracania

To najważniejsza część planu. Test przywracania oznacza, że naprawdę przywracają Państwo kopię zapasową w miejscu, w którym niczego to nie zepsuje, i sprawdzają, czy wynik działa.

• Mały test, często: przywrócenie jednego pliku lub jednego katalogu do /tmp/terug i porównanie (diff). Na przykład raz w miesiącu.
• Duży test, od czasu do czasu: zbudowanie z kopii zapasowej kompletnego nowego serwera testowego, zaimportowanie bazy danych, uruchomienie strony. Na przykład raz w roku lub przy każdej większej zmianie. To zarazem ćwiczenie na wypadek, gdyby naprawdę coś poszło nie tak (lekcja 10.3).

Prosimy zapisać, ile to trwało: to Państwa rzeczywiste RTO.

Okresy przechowywania

Nie wystarczy przechowywać tylko ostatniej kopii zapasowej. Jeśli dopiero po dwóch tygodniach odkryją Państwo, że plik został uszkodzony lub usunięty, potrzebna będzie kopia sprzed trzech tygodni. Typowy schemat: siedem wersji dziennych, cztery tygodniowe i sześć miesięcznych. restic obsługuje to za pomocą forget (lekcja 8.2). Prosimy pamiętać również o RODO: danych osobowych nie przechowuje się dłużej, niż to konieczne, także w kopiach zapasowych. Prosimy zapisać swoje okresy przechowywania.

W praktyce

Snapshotu dostawcy warto używać tuż przed ryzykownymi zmianami, a potem go usunąć; codzienną kopię zapasową dostawcy, jeśli jest dostępna, warto pozostawić włączoną; a dodatkowo należy wykonywać własną zaszyfrowaną kopię zapasową danych i konfiguracji u innego podmiotu. W WebOké w ekranie VPS nazywa się to Snapshots i Backups; u innych dostawców nazwy i okresy przechowywania są inne, ale zasada jest ta sama. Pakiet hostingowy lub usługa zarządzana często opierają się na innych ustaleniach: prosimy sprawdzić, co obowiązuje w Państwa przypadku.

Podsumowanie

• Kopia zapasowa jest coś warta dopiero wtedy, gdy przywracanie działa; należy zacząć od planu, a skończyć na teście.
• Kopią zapasową należy objąć przede wszystkim dane i konfigurację: bazy danych w postaci zrzutu, /etc, strony internetowe, wolumeny Dockera, pliki compose.
• Należy określić RPO (ile można stracić) i RTO (jak szybko wszystko musi działać).
• Snapshot (ta sama pamięć masowa, krótko), kopia zapasowa dostawcy (inna pamięć masowa, ten sam podmiot) i własna kopia zapasowa poza dostawcą to trzy różne warstwy; należy stosować zasadę 3-2-1 z co najmniej jedną kopią, której sam serwer nie może usunąć.
• Należy szyfrować kopie, przechowywać hasło do kopii zapasowej poza serwerem i testować przywracanie: w małym zakresie często, w dużym od czasu do czasu.

Quiz

Zadanie

Zadanie O8.1: Plan kopii zapasowych. Prosimy przygotować dla własnego serwera plan kopii zapasowych na jednej stronie: co musi dać się przywrócić (dla każdej warstwy), Państwa RPO i RTO, jakie kopie Państwo mają (snapshot, dostawca, własna) i gdzie, okresy przechowywania, gdzie znajduje się hasło do kopii zapasowej oraz kiedy przeprowadzają Państwo test przywracania. Prosimy wypełnić formularz; po jego wysłaniu zobaczą Państwo przykładowy plan, z którym mogą Państwo porównać własny.

Przeczytaj więcej

• Snapshoty i kopie zapasowe VPS
• Strategia kopii zapasowych: zasada 3-2-1 dla Państwa firmy
• Jak wykonać kopię zapasową bazy danych MySQL?
• W kursie Bezpiecznie online: lekcje o zasadzie 3-2-1 i kopiach zapasowych, które przetrwają atak ransomware.
• 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