Kopie zapasowe strony i bazy danych: co musi działać

Kopia na tym samym serwerze to nie backup

Snapshot dysku, migawka hostingu albo kopia w tym samym katalogu co strona chronią przed jedną rzeczą: przypadkowym usunięciem pliku. Nie chronią przed awarią dysku, atakiem na serwer ani przejęciem konta hostingowego: w każdym z tych scenariuszy kopia znika razem z oryginałem. Backup, który ma sens, leży w innym miejscu niż to, co kopiuje: na innym serwerze, u innego dostawcy albo offline.

Co kopiować, a czego nie trzeba

Kod aplikacji czy strony sam w sobie nie musi mieć backupu w klasycznym sensie: jeśli leży w repozytorium Git, historia zmian jest już jego kopią. Realnie ważne są rzeczy, których nie da się odtworzyć z kodu:

• Baza danych: zamówienia, konta użytkowników, treść wpisana przez klienta.
• Pliki wgrywane przez użytkowników: zdjęcia, dokumenty, załączniki.
• Konfiguracja serwera i certyfikaty, których odtworzenie od zera zajmuje więcej czasu, niż się wydaje.
• Zmienne środowiskowe i sekrety (klucze API, dane dostępowe): osobno, w menedżerze haseł, nie w tym samym miejscu co backup danych.

Co na temat backupów mówi RODO

Jeśli serwer przetwarza dane osobowe (a robi to praktycznie każda baza klientów), art. 32 ust. 1 lit. c RODO nakłada obowiązek zapewnienia „zdolności do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego”. Ten sam artykuł w lit. b wymaga zdolności do zapewnienia ciągłej dostępności i odporności systemów, a w lit. d regularnego testowania skuteczności tych środków.

W praktyce: sam fakt posiadania kopii nie wystarczy. Trzeba też umieć z niej skorzystać w rozsądnym czasie i regularnie to sprawdzać, zamiast zakładać, że działa.

Zasada 3-2-1

Powszechnie stosowana w branży reguła upraszcza decyzję, ile kopii i gdzie trzymać: trzy kopie danych, na dwóch różnych nośnikach lub systemach, z czego jedna poza główną lokalizacją: innym serwerem, innym dostawcą, innym regionem. Serwer produkcyjny plus jeden backup u tego samego dostawcy w tym samym centrum danych to dwie kopie na jednym nośniku. Spełnia to minimum, ale nie chroni przed awarią całego centrum danych ani przed dostawcą, który traci dostęp do własnej infrastruktury.

Jak często i jak szybko: RPO i RTO

Dwa pytania, które warto sobie zadać, zamiast zgadywać harmonogram:

• Ile danych możesz stracić? (RPO, recovery point objective): backup raz na dobę oznacza, że w najgorszym przypadku tracisz prawie całą dobę pracy klientów.
• Jak długo może trwać przywracanie? (RTO, recovery time objective): sklep internetowy, który nie działa przez godzinę, to inny koszt niż wewnętrzne narzędzie firmy, które może stać dzień.

Dla bazy danych z ruchem w ciągu dnia sensowny punkt startowy to codzienny backup pełny i częstsze kopiowanie logów transakcji, żeby w razie awarii stracić minuty, nie godziny. Dla statycznej strony firmowej, która zmienia się raz na tydzień, backup przy każdej zmianie wystarczy.

Backup, którego nikt nie przywracał, nie istnieje

Najczęstszy sposób, w jaki firmy odkrywają, że backup nie działa, to próba jego przywrócenia podczas prawdziwej awarii. Plik może być uszkodzony, hasło do archiwum zgubione, a proces przywracania (nigdy wcześniej nie sprawdzony) może zająć dzień, a nie godzinę. Przywracanie testowe na osobnym środowisku, choćby raz na kwartał, jest jedynym sposobem, żeby wiedzieć, że kopia faktycznie się do czegoś przyda.

Sprawdź, czy Twoja strona albo aplikacja to ma

• Czy kopia leży fizycznie gdzie indziej niż produkcja: jeśli to ten sam serwer albo to samo konto, to nie jest backup.
• Czy ktoś wie, kiedy była ostatnia udana kopia. Harmonogram, który od tygodni kończy się błędem, jest gorszy niż brak harmonogramu, bo daje złudne poczucie bezpieczeństwa.
• Czy ktokolwiek kiedykolwiek przywrócił dane z tej kopii na osobnym środowisku i porównał wynik z produkcją.
• Czy dostęp do backupu ma inne konto niż konto administratora serwera produkcyjnego: inaczej atak na jedno konto niszczy obie kopie naraz.

Co przejmujemy

Konfigurację kopii zapasowych i serwera zapasowego przejmujemy w ramach utrzymania serwerów: automatyczne kopie baz danych i plików na serwerze innym niż produkcyjny, z harmonogramem i monitoringiem dostępności. To samo dotyczy certyfikatów i konfiguracji: każde wdrożenie, które robimy, zostawia możliwość powrotu do poprzedniej wersji. Zadzwoń pod 697 004 905 albo napisz na kontakt@apkarze.pl. Sprawdzimy, jak wygląda to u Ciebie.