Kopia zapasowa strony internetowej — pytanie nie brzmi, czy ją macie

Większość właścicieli stron śpi spokojnie, bo opłaca hosting, a w ofercie dostawcy widniała wzmianka o regularnych kopiach zapasowych. Problem w tym, że w krytycznym momencie — po ataku, po błędzie pracownika, po awarii — pytanie nie brzmi „czy macie kopie".

Prawdziwe pytanie brzmi: kto ostatnio próbował ją odtworzyć i ile czasu to zajęło?

Kopia, której nikt nigdy nie odtworzył, daje wyłącznie poczucie bezpieczeństwa. Kończy się ono w chwili, gdy okazuje się, że automat od miesięcy nadpisywał uszkodzone pliki albo że przywrócenie to kwestia dni, nie godzin.

Co się właściwie kopiuje — i dlaczego pliki to za mało

Odtworzenie strony to nie jest „kopiuj-wklej" jednego katalogu. Działający serwis to system naczyń połączonych: odtworzenie samych plików bez aktualnej bazy przywróci najwyżej wygląd — bez treści, bez historii zamówień, bez kont klientów.

Żeby strona wznowiła działanie, potrzebna jest spójna kopia czterech warstw.

Dwie rzeczy warto tu doprecyzować, bo bywają mylone. Certyfikat SSL zwykle nie jest częścią kopii strony — wydaje go i odnawia hosting, więc po odtworzeniu na tym samym serwerze wraca sam; problemem bywa natomiast utrata ustawień wymuszających szyfrowane połączenie, i to jest warstwa konfiguracji. A hasła administratorów leżą w bazie danych, nie w osobnej warstwie — osobno trzymane są klucze do usług zewnętrznych, i to one najczęściej nie wracają razem z kopią.

Praktyczny wniosek: pytanie do dostawcy albo wykonawcy brzmi „co dokładnie obejmuje kopia", a nie „czy jest". Odpowiedź „pliki i baza" jest dobra. Odpowiedź „cała strona" nie jest odpowiedzią.

Jest jeszcze piąta rzecz, która nie mieści się w żadnej warstwie, a bez której odtworzenie się nie zaczyna: wiedza, gdzie ta kopia jest i jak się do niej dostać. Brzmi to trywialnie do momentu, w którym osoba, która to konfigurowała, nie pracuje już w firmie, a kopie leżą na koncie założonym na jej służbowy adres. Widzieliśmy to częściej niż uszkodzone archiwa — i jest to jedyna pozycja z tej listy, która nie kosztuje nic, tylko jedno zdanie zapisane obok dostępów do hostingu i domeny.

Gdzie leży kopia — i przed czym to chroni

„Mam backup w hostingu" opisuje miejsce, nie zabezpieczenie. A miejsce decyduje o tym, przed czym kopia w ogóle chroni.

Kopia na tym samym serwerze nie jest kopią zapasową — to drugi plik obok pierwszego. Ginie razem z dyskiem, razem z kontem i razem z zaszyfrowaniem zasobów.

Kopia w systemie kopii hostingu jest już czymś realnym, bo zwykle leży na innym wolumenie. Przeżyje awarię sprzętu. Nie przeżyje skasowania konta — ani przy sporze z dostawcą, ani przy niezapłaconej fakturze, ani przy przejęciu dostępu do panelu przez kogoś niepowołanego.

Kopia poza kontem, u innego dostawcy, przeżywa wszystkie trzy scenariusze. Nie dlatego, że jest droższa czy technicznie lepsza — dlatego, że nie dzieli losu z tym, co ma ratować. To jest cała treść powtarzanej zasady o kopii poza infrastrukturą, i jedyna jej część, którą trzeba zapamiętać.

Ransomware zasługuje tu na osobne zdanie, bo to on unieważnia najwięcej planów: złośliwe oprogramowanie szyfruje nie tylko dane, ale i zamontowane zasoby sieciowe, do których serwer ma dostęp. Kopia podpięta do tego samego systemu jako dysk sieciowy zostaje zaszyfrowana razem z resztą.

Z tego wynika rozróżnienie, które w praktyce robi całą różnicę, a brzmi technicznie: kopia powinna być dla serwera nieosiągalna w zapisie. Innymi słowy to kopia sięga po dane, a nie serwer po kopię. Jeśli konfiguracja wygląda odwrotnie — strona sama wypycha archiwa na podpięty dysk — to wszystko, co przejmie stronę, przejmie też archiwa. Przy typowej usłudze hostingu to jest pytanie na jedno zdanie do wsparcia technicznego: czy kopie leżą poza kontem i czy da się je nadpisać z poziomu serwera.

Utrata dostępu to naruszenie, nie tylko awaria

Ta część jest pomijana w poradnikach o kopiach, a zmienia kategorię problemu.

Naruszeniem ochrony danych osobowych jest nie tylko wyciek. Jest nim także przypadkowa utrata danych i utrata dostępu do nich — czyli dokładnie to, co dzieje się po awarii bez działającej kopii. Wynika to z RODO, a rozwijają to wytyczne Europejskiej Rady Ochrony Danych 9/2022, dostępne po polsku.

Z tego wynikają trzy rzeczy, o których warto wiedzieć przed awarią:

Zegar liczy 72 godziny od stwierdzenia naruszenia — nie od jego usunięcia i nie od ustalenia przyczyny. Zgłoszenie po terminie jest możliwe, ale wymaga wyjaśnienia zwłoki.

Ransomware jest w wytycznych przykładem kanonicznym, łącznie z sytuacją, w której zaszyfrowane zostają także kopie zapasowe. Jeśli kopia działa i dane wracają szybko, ocena ryzyka wygląda zupełnie inaczej niż wtedy, gdy nie wracają wcale.

Nikt nie musi niczego wykraść, żeby doszło do naruszenia. To jest najmniej intuicyjna część i najczęściej zaskakuje: dane zaszyfrowane na miejscu, bez kopiowania ich na zewnątrz, to nadal utrata dostępu.

Warto przy tym wiedzieć, czego ta sekcja nie twierdzi. Nie twierdzi, że każda awaria strony jest naruszeniem do zgłoszenia — jeśli strona nie przetwarza danych osobowych i nie ma formularzy, to jej niedostępność jest problemem biznesowym, nie prawnym. Próg przebiega przy pytaniu, czy w tym, co stało się niedostępne, były dane osób: zgłoszenia z formularza, konta klientów, zamówienia, historia korespondencji. Przy typowej stronie firmowej odpowiedź brzmi „tak", i dlatego ta sekcja w ogóle tu jest.

Praktyczny skutek dla kopii zapasowej jest prosty i nieoczywisty: działająca kopia nie tylko skraca przestój — ona zmienia to, co trzeba zgłosić i z jakim ryzykiem. Sam obowiązek zgłoszenia i to, jak go wykonać, opisujemy przy obowiązku informacyjnym.

Kara, która pokazuje, kto właściwie odpowiada

W decyzji DKN.5131.1.2021 Prezes Urzędu Ochrony Danych Osobowych ukarał firmę, która straciła dostęp do danych pracowników i klientów — w tym numerów PESEL, danych dokumentów i numerów rachunków — po ataku ransomware. Atak był możliwy, bo pracownik wyłączył program antywirusowy.

Zarzuty nie dotyczyły jednak samego ataku. Dotyczyły tego, czego nie zrobiono wcześniej: brakowało analizy ryzyka, oprogramowanie w infrastrukturze nie było aktualne, a szkolenia były szczątkowe.

Kwoty: ponad 350 000 zł dla administratora danych, czyli firmy. Ale istotniejsza jest druga: po 9 800 zł dla wspólników podmiotu przetwarzającego, czyli podwykonawcy obsługującego dane — za to, że nie poinformował administratora o podatnościach serwera i o potrzebie aktualizacji.

Ta druga kwota rozbraja zdanie, które słyszymy najczęściej: „tym zajmuje się hosting" albo „tym zajmuje się nasz informatyk". Zajmuje się — i może odpowiadać razem z Wami, co nie zmienia faktu, że administratorem danych pozostajecie Wy. Odpowiedzialności nie da się zlecić na zewnątrz razem z obsługą.

Test, który rozstrzyga wszystko

Pięć pytań. Odpowiedź „mamy backup" nie odpowiada na żadne z nich.

Najważniejsze jest pierwsze i drugie razem: kto odtwarzał i ile to trwało. Dopóki nikt nie spróbował, nie wiadomo, czy kopia jest kompletna, czy da się ją rozpakować i czy zawiera bazę. A czas odtworzenia to Wasz realny czas przestoju — nie ten z oferty dostawcy, tylko ten, który podacie klientowi, gdy zapyta, kiedy wrócicie.

Test robi się na kopii środowiska, nie na żywej stronie, i najlepiej wtedy, gdy nic się nie pali. To jest popołudnie raz w roku, które zamienia „chyba mamy" na liczbę godzin.

Trzy rzeczy, które przy takim teście wychodzą najczęściej: kopia nie zawierała bazy, dostęp do kopii miał wyłącznie wykonawca, albo odtworzenie wymagało hasła, którego nikt już nie pamiętał.

Co zapisać po teście, żeby nie robić go od zera za rok: datę, czas odtworzenia, miejsce, z którego kopia pochodziła, i to, czego zabrakło. Cztery linijki w tym samym dokumencie, w którym trzymacie dostępy do hostingu i domeny. Przy następnej awarii to jest pierwsza rzecz, po którą sięga ktokolwiek — łącznie z wykonawcą, którego wezwiecie w środku nocy.

Jest też wersja tego testu dla firm, które nie mają gdzie odtwarzać: poproście dostawcę hostingu o odtworzenie kopii na środowisko testowe. Większość ma taką usługę i bywa bezpłatna przy pierwszym uruchomieniu. Odmowa albo brak takiej możliwości też jest informacją — i to dość poważną.

Kto to robi i ile to kosztuje

Uczciwie: przy stronie firmowej kopia zapasowa jest jedną z najtańszych pozycji w całym utrzymaniu i jedną z niewielu, przy których tanio naprawdę znaczy wystarczająco.

Trzy poziomy, które w praktyce widzimy:

Kopie w ramach hostingu, włączone i sprawdzone. Zwykle są w cenie pakietu albo kosztują kilka złotych miesięcznie. Wystarczają stronie wizytówkowej pod warunkiem, że ktoś raz sprawdził, co obejmują i jak długo są trzymane.

Wtyczka albo usługa wypychająca kopię poza konto. Kilkanaście do kilkudziesięciu złotych miesięcznie, czasem wersja bezpłatna wystarcza. To jest ten poziom, na którym pojawia się kopia przeżywająca utratę konta — i dla większości firm to właściwy wybór.

Kopia zarządzana przez wykonawcę, z testem odtworzenia w umowie. Sensowna przy sklepie i przy stronie, która zarabia; płacicie wtedy nie za samo kopiowanie, tylko za to, że ktoś odpowiada za czas powrotu.

Czego nie warto kupować: pakietów, w których „backup" jest jedyną pozycją i kosztuje więcej niż powyższe. Pytanie kontrolne jest jedno i rozstrzyga w jednym zdaniu — czy w tej usłudze ktoś kiedykolwiek odtwarza kopię, czy tylko ją tworzy.

Ile kopii i jak często

Zasadę „trzy kopie, dwa nośniki, jedna poza infrastrukturą" powtarza się jak liturgię, więc warto ją opisać przez to, przed czym chroni, a nie przez liczby.

Trzy kopie — bo druga może być uszkodzona, a dowiadujecie się o tym dopiero przy odtwarzaniu.

Dwa różne miejsca — bo jedno miejsce to jedna awaria.

Jedna poza infrastrukturą — bo to jedyna, która przeżyje utratę konta i zaszyfrowanie zasobów.

Częstotliwość ustala jedno pytanie: ile pracy jesteście gotowi stracić? Strona firmowa, na której nic się nie zmienia tygodniami, spokojnie znosi kopię dzienną. Sklep przyjmujący zamówienia potrzebuje częstszej, bo każda godzina to zamówienia, których nie da się odtworzyć z niczego innego.

Jak długo trzymać: na tyle długo, żeby dało się cofnąć przed moment, w którym coś poszło źle. To jest argument praktyczny, nie prawny — infekcje i uszkodzenia bywają zauważane po tygodniach, a kopia z wczoraj jest wtedy kopią stanu już zepsutego.

W praktyce oznacza to zwykle rotację: kilka kopii dziennych, kilka tygodniowych i jedna miesięczna. Nie dlatego, że tak każe jakaś norma — dlatego, że pokrywa trzy różne scenariusze. Dzienna ratuje przed błędem sprzed godzin, tygodniowa przed nieudaną aktualizacją zauważoną w poniedziałek, miesięczna przed infekcją, która siedziała cicho i wyszła dopiero przy skardze klienta albo w komunikacie wyszukiwarki. Domyślne ustawienia większości usług hostingowych pokrywają pierwszy scenariusz i czasem drugi — trzeci prawie nigdy, i to jest jedyna rzecz w tej sekcji, którą warto świadomie dołożyć.

Czego w tym tekście świadomie nie ma

• RTO, RPO i rozwiązań klasy enterprise. To jest język działu IT i innej skali problemu; przy stronie firmowej zastępuje go pytanie „ile trwało odtworzenie".
• Porównania konkretnych narzędzi i dostawców. Zmieniają się szybciej, niż da się utrzymać tekst w aktualności.
• Okresów retencji per branża. To rozstrzygnięcie prawne, nie techniczne, i zależy od tego, jakie dane trzymacie.
• Kontroli dostępu i kont w panelu — jak zabezpieczyć stronę.
• Aktualizacji oprogramowania — osobno, a w decyzji UODO powyżej to właśnie ich brak był jednym z zarzutów.

Cztery zdania, które słyszymy najczęściej

„Hosting robi kopie, więc mam to z głowy." Robi — i to jest dobre. Nie wie jednak, co obejmuje Wasza baza, nie odtworzy jej za Was i nie przeżyje skasowania konta. Zdanie jest prawdziwe i niewystarczające naraz, a różnica między jednym a drugim ujawnia się wyłącznie w dniu awarii.

„Mamy wtyczkę do backupu." Wtyczka tworzy archiwa. Pytanie brzmi, gdzie je odkłada — jeśli w katalogu na tym samym serwerze, to jest to drugi plik obok pierwszego, a przy okazji rosnący, który potrafi zapchać konto hostingu i położyć stronę bez żadnego ataku.

„Sprawdzimy to, jak będzie trzeba." Wtedy jest najgorszy możliwy moment: pod presją, bez wiedzy, ile to potrwa, i bez miejsca, na którym można próbować bez ryzyka. Test wykonany na spokojnie kosztuje popołudnie; ten sam test wykonany w trakcie awarii kosztuje dzień i kilka złych decyzji.

„To strona firmowa, nie sklep — nie ma czego tracić." Jest: zgłoszenia z formularza, treści pisane przez lata, pozycje wypracowane na konkretnych adresach. Odtworzenie wyglądu trwa dni, odtworzenie tekstów — tygodnie, a części nie da się odtworzyć wcale, bo nikt ich nie ma w żadnym innym miejscu.

Sklep to inna kategoria

Wszystko powyżej dotyczy strony firmowej. Przy sklepie zmieniają się trzy rzeczy i warto je wymienić osobno, bo zmieniają też wybory.

Zamówień nie da się odtworzyć z niczego innego. Treść strony istnieje w głowach i w plikach; zamówienie z wczoraj istnieje wyłącznie w bazie. To przesuwa częstotliwość z dziennej na godzinową i jest jedynym miejscem w tym artykule, gdzie rekomendujemy więcej niż minimum.

Odtworzenie musi obejmować stan płatności. Sklep przywrócony do wczorajszego stanu ma zamówienia opłacone po tej godzinie oznaczone jako nieopłacone — i to jest gorsze niż brak sklepu przez godzinę. Przy sklepie odtworzenie planuje się razem z tym, co zrobić z luką czasową, a nie zamiast tego.

Dane klientów podnoszą stawkę prawną. Przy sklepie w bazie są adresy, historia zakupów i czasem dane płatnicze — więc ocena ryzyka po utracie dostępu wygląda inaczej niż przy stronie z formularzem kontaktowym.

Co zrobić w tej kolejności

Jeśli zaczynacie od zera, pięć kroków i jedno popołudnie.

1. Ustalcie, co obejmuje obecna kopia. Jedno pytanie do hostingu albo wykonawcy: pliki, baza, jak często, jak długo trzymane, gdzie leżą.
2. Sprawdźcie, czy jakakolwiek kopia leży poza kontem hostingu. Jeśli nie — to jest pierwsza rzecz do dołożenia i zwykle najtańsza.
3. Odtwórzcie ją na środowisku testowym i zmierzcie czas.
4. Zapiszcie cztery linijki: data, czas, źródło, czego zabrakło.
5. Dopiszcie do tego dostępy — kto ma wejście do kopii, obok informacji, kto ma wejście do hostingu i domeny.

Kroki od pierwszego do trzeciego robi się raz. Czwarty i piąty sprawiają, że za rok nie zaczynacie od nowa — i są jedyną częścią, o której nikt nigdy nie pamięta, bo nic się nie psuje z ich powodu aż do dnia, w którym psuje się wszystko naraz.

Najkrótsze podsumowanie: kopia zapasowa zaczyna istnieć w momencie, w którym ktoś ją odtworzył. Wcześniej jest pozycją w ofercie hostingu — a pozycja w ofercie nie skraca przestoju i nie zmienia oceny ryzyka przy zgłoszeniu naruszenia.