Kopia zapasowa strony firmowej – jak często ją wykonywać, gdzie przechowywać pliki i co zrobić po awarii

Awaria serwera rzadko jest największym problemem. Znacznie gorszy scenariusz zaczyna się wtedy, gdy firma po awarii odkrywa, że ostatnia działająca kopia ma trzy tygodnie, backup był przechowywany na tym samym hostingu albo nikt nigdy nie sprawdził, czy da się go odtworzyć. Plik ZIP nazwany „backup” nie daje jeszcze bezpieczeństwa.

Dobra kopia zapasowa strony firmowej musi spełniać trzy warunki: być wystarczająco świeża, znajdować się poza środowiskiem produkcyjnym i dać się odtworzyć w przewidywalnym czasie. Dopiero te trzy elementy pozwalają mówić o realnym zabezpieczeniu. Sam harmonogram wykonywania kopii jest tylko częścią układanki.

Inaczej trzeba też chronić prostą stronę usługową aktualizowaną dwa razy w miesiącu, inaczej sklep WooCommerce, a jeszcze inaczej system przyjmujący rezerwacje lub formularze sprzedażowe. Najważniejsze pytanie brzmi więc nie „jak często robić backup?”, lecz: ile danych firma może zaakceptować jako bezpowrotnie utracone po awarii?

Jak często wykonywać kopię zapasową strony firmowej

Dla typowej strony firmowej opartej na WordPressie rozsądnym minimum jest automatyczny backup raz na 24 godziny oraz dodatkowa kopia wykonywana przed każdą większą aktualizacją. Taki harmonogram sprawdza się jednak przede wszystkim wtedy, gdy witryna pełni funkcję informacyjną i w ciągu dnia nie pojawiają się w niej istotne nowe dane.

Jeżeli przez stronę przechodzą zamówienia, formularze kontaktowe, rezerwacje, konta klientów albo płatności, jedna kopia na dobę jest zwykle zbyt rzadka. Awaria o 18:00 przy backupie wykonanym o 2:00 może oznaczać utratę 16 godzin zamówień i zmian w bazie danych.

Praktyczne częstotliwości można ustawić tak:

• strona wizytówkowa: pełna kopia raz na dobę;

• blog lub serwis regularnie publikujący: backup co 6–12 godzin;

• strona generująca leady i rezerwacje: kopia bazy co 1–4 godziny;

• sklep internetowy: kopia bazy co 15–60 minut, zależnie od liczby zamówień;

• serwis z intensywnie zmieniającymi się danymi: backup ciągły albo mechanizmy umożliwiające odtworzenie bazy do konkretnego momentu.

Administratorzy posługują się tutaj pojęciem RPO – Recovery Point Objective. To maksymalny okres danych, który firma jest gotowa utracić. Jeśli właściciel sklepu deklaruje RPO wynoszące 30 minut, system backupu powinien pozwalać odzyskać dane sprzed nie więcej niż pół godziny.

Drugi parametr to RTO – Recovery Time Objective, czyli dopuszczalny czas niedostępności. Firma może wykonywać backup co 15 minut, ale niewiele to pomoże, jeśli przywrócenie strony trwa osiem godzin, bo kopia wymaga ręcznego pobierania setek gigabajtów i odtwarzania bez przygotowanej procedury.

Dla niewielkiej strony firmowej rozsądnym celem jest zwykle RPO 24 godziny i RTO 2–4 godziny. Dla sklepu RPO powinno zejść przynajmniej do 15–60 minut, a RTO często powinno wynosić maksymalnie 1–2 godziny.

Nie ma również powodu przechowywać wszystkich kopii bezterminowo. Powoduje to wzrost kosztów i utrudnia znalezienie właściwej wersji podczas awarii. W praktyce dobrze działa retencja typu:

• 7 kopii dziennych,

• 4 kopie tygodniowe,

• 3–6 kopii miesięcznych,

• dodatkowa kopia wykonana przed dużą zmianą techniczną.

Przy serwisach częściej zmieniających dane można trzymać np. kopie godzinowe z ostatnich 24–48 godzin, dzienne przez 30 dni i miesięczne przez pół roku.

Backup przed aktualizacją jest szczególnie ważny przy WordPressie. Aktualizacja PHP, WordPressa, WooCommerce, motywu albo kilku wtyczek jednocześnie może skończyć się błędem krytycznym, konfliktem rozszerzeń albo problemem ze strukturą bazy. Kopię należy wykonać przed zmianą, a nie wtedy, gdy serwis już przestał działać.

Trzeba też pilnować, co właściwie trafia do backupu. W WordPressie potrzebne są co najmniej baza danych, katalog wp-content oraz konfiguracja niezbędna do ponownego uruchomienia strony. Kopiowanie wyłącznie plików z FTP bez bazy MySQL lub MariaDB jest częstym i bardzo kosztownym błędem. Strona może wyglądać na zabezpieczoną, a po awarii okazuje się, że nie ma wpisów, użytkowników, zamówień ani ustawień.

Nie trzeba natomiast bezmyślnie archiwizować wszystkiego. Kilkadziesiąt gigabajtów cache, starych logów i tymczasowych miniatur potrafi wielokrotnie zwiększyć kopię, mimo że dane te można wygenerować ponownie.

Gdzie przechowywać backup i dlaczego kopia na tym samym serwerze to za mało

Najgorszym miejscem na jedyną kopię zapasową jest ten sam serwer, na którym działa witryna. Awaria macierzy, usunięcie konta hostingowego, przejęcie panelu administracyjnego albo ransomware może wtedy zniszczyć stronę i jej backup w jednym zdarzeniu.

Podobny problem występuje, gdy hosting automatycznie tworzy snapshoty, ale wszystkie znajdują się na tym samym koncie klienta. Snapshot dostawcy jest wygodnym pierwszym poziomem ochrony, lecz nie powinien być jedynym backupem firmy.

Dobrym punktem odniesienia jest zasada 3-2-1-1-0:

• utrzymuj co najmniej 3 kopie danych;

• wykorzystuj 2 niezależne miejsca lub technologie przechowywania;

• co najmniej 1 kopię trzymaj poza główną infrastrukturą;

• 1 kopia powinna być offline albo niezmienialna;

• 0 błędów powinien wykazywać regularny test odtwarzania.

W małej firmie nie trzeba budować skomplikowanej infrastruktury. Praktyczny zestaw może wyglądać następująco: strona działa na hostingu, hosting wykonuje własne snapshoty, a niezależny system wysyła zaszyfrowaną kopię do magazynu obiektowego albo na drugi serwer znajdujący się u innego operatora.

Do przechowywania zewnętrznych backupów wykorzystuje się m.in. Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, serwery SFTP oraz urządzenia NAS. Sam koszt przestrzeni dla strony zajmującej kilka lub kilkadziesiąt gigabajtów jest zazwyczaj niewielki — często istotniejszym kosztem okazuje się licencja systemu backupowego, obsługa, dodatkowe wersje plików i transfer podczas odtwarzania.

Przy stronie zajmującej 10 GB nie trzeba od razu rezerwować 300 GB. Trzeba jednak pamiętać, że 30 backupów nie musi zajmować tylko 30 × 10 GB ani dokładnie tyle samo co jedna kopia. Wynik zależy od kompresji, deduplikacji i tego, czy system wykonuje kopie pełne, różnicowe czy przyrostowe.

Pełna kopia codziennie jest prosta do zrozumienia, ale przy większych serwisach marnuje przestrzeń i obciąża serwer. Lepszym rozwiązaniem bywa wykonywanie okresowego pełnego backupu oraz częstszych kopii przyrostowych, zapisujących tylko dane zmienione od poprzedniego punktu.

Szczególnie przydatna jest funkcja immutable storage, Object Lock albo WORM, czyli mechanizm blokujący możliwość zmiany lub usunięcia kopii przez określony czas. Jeżeli napastnik przejmie konto administratora, zwykły backup dostępny tymi samymi danymi logowania może zostać skasowany razem ze stroną. Kopia niezmienialna znacząco ogranicza to ryzyko.

Są jednak dwa minusy. Pierwszy to koszt dodatkowej przestrzeni. Drugi jest bardziej irytujący: źle ustawionej retencji nie da się po prostu „cofnąć”, bo właśnie na tym polega niezmienialność danych. Przed włączeniem blokady na rok lepiej przetestować konfigurację z krótszym okresem.

Osobną kwestią są dane osobowe. Backup sklepu, CRM-u połączonego ze stroną albo formularzy może zawierać nazwiska, adresy, telefony, adresy e-mail i historię zamówień. Kopia zapasowa nie przestaje być przetwarzaniem danych tylko dlatego, że leży w archiwum. Trzeba więc kontrolować dostęp, szyfrowanie, retencję oraz warunki korzystania z zewnętrznego dostawcy.

Dla polskiej firmy najprostsza organizacyjnie jest zwykle infrastruktura z możliwością przechowywania danych na terenie UE lub EOG. Nie oznacza to automatycznie zgodności z RODO, ale upraszcza część problemów związanych z międzynarodowym transferem danych.

Hasło administratora do WordPressa nie powinno jednocześnie otwierać magazynu backupów. Konto przeznaczone do zapisu kopii powinno mieć minimalne potrzebne uprawnienia, a dostęp administracyjny należy chronić MFA. Klucze API warto ograniczyć do konkretnego zasobu zamiast używać jednego głównego klucza do wszystkich usług.

Najważniejsze jest jednak testowanie. Backup, którego nikt nie odtworzył, jest tylko założeniem, że wszystko działa. Pełny test odtworzenia przynajmniej raz na kwartał jest rozsądnym minimum dla zwykłej strony firmowej. W sklepie lub systemie istotnym dla sprzedaży taki test dobrze wykonywać co miesiąc oraz po większych zmianach infrastruktury.

Co zrobić po awarii i jak odtworzyć stronę bez pogorszenia sytuacji

Pierwsza reakcja po awarii często wygląda tak samo: administrator zaczyna szybko zmieniać wtyczki, nadpisywać pliki, przywracać losowy backup i restartować kolejne usługi. To zrozumiałe, ale potrafi skasować informacje potrzebne do ustalenia przyczyny problemu.

Najpierw trzeba ustalić rodzaj awarii. Inaczej postępuje się po błędnej aktualizacji WordPressa, inaczej po uszkodzeniu bazy, a jeszcze inaczej po włamaniu.

Praktyczna kolejność jest następująca:

1. Zatrzymaj dalsze zmiany. Jeśli to możliwe, wykonaj snapshot obecnego stanu, nawet jeśli witryna jest uszkodzona.

2. Sprawdź zasięg awarii. Zweryfikuj DNS, certyfikat TLS, serwer WWW, PHP, bazę danych, przestrzeń dyskową oraz logi błędów.

3. Ustal moment wystąpienia problemu. Pozwala to wybrać ostatnią kopię wykonaną przed awarią.

4. Nie przywracaj od razu na produkcję, jeżeli istnieje podejrzenie włamania. Kopię najlepiej najpierw uruchomić w odizolowanym środowisku testowym.

5. Sprawdź integralność danych. Zweryfikuj bazę, pliki aplikacji, media, konfigurację i prawa dostępu.

6. Po włamaniu zmień hasła, klucze API, dane dostępowe do bazy, FTP/SFTP i panelu hostingu. Samo odtworzenie strony nie usuwa skradzionych poświadczeń.

7. Usuń przyczynę awarii: podatną wtyczkę, błędną konfigurację, przejęte konto albo wadliwy kod.

8. Dopiero wtedy przełącz ruch na odtworzoną wersję.

Przy sklepie sytuacja komplikuje się jeszcze bardziej. Załóżmy, że awaria zaczęła się o 14:30, a ostatni pełny backup pochodzi z 12:00. Proste cofnięcie całej bazy może usunąć zamówienia złożone między 12:00 a 14:30. W takim przypadku trzeba rozdzielić przywracanie aplikacji od przywracania danych transakcyjnych albo wykorzystać logi bazy umożliwiające odtworzenie zmian do wybranego momentu.

To właśnie dlatego w systemach sprzedażowych backup raz dziennie jest słabym rozwiązaniem. Problemem nie jest samo ponowne uruchomienie sklepu, lecz późniejsze uzgadnianie brakujących zamówień, płatności, stanów magazynowych i wiadomości wysłanych do klientów.

Po przywróceniu strony nie wystarczy sprawdzić strony głównej. Trzeba wykonać krótki test funkcjonalny:

• otworzyć kilka podstron i sprawdzić pliki statyczne;

• zalogować się do panelu;

• wysłać formularz kontaktowy;

• sprawdzić wysyłkę wiadomości e-mail;

• w sklepie wykonać testowe zamówienie;

• sprawdzić płatność w trybie testowym lub kontrolowanym;

• zweryfikować integracje z ERP, CRM, kurierami i systemem fakturowym;

• sprawdzić zadania CRON i kolejki;

• przejrzeć logi po ponownym uruchomieniu.

Szczególnie zdradliwe są awarie, po których witryna „wygląda normalnie”. Formularz może przestać wysyłać wiadomości, CRON może nie wykonywać zaplanowanych zadań, a integracja sklepu może nie przekazywać zamówień do ERP. Dlatego test po odtworzeniu powinien obejmować proces biznesowy, a nie tylko wygląd strony.

Jeżeli incydent był związany z atakiem, nie należy automatycznie zakładać, że najnowsza kopia jest czysta. Złośliwy plik mógł znajdować się w serwisie przez tygodnie przed wykryciem. Czasami trzeba porównać kilka wersji backupu i cofnąć się znacznie dalej, a następnie osobno odzyskać prawidłowe dane powstałe później.

Największy priorytet po awarii to nie „jak najszybciej wrzucić ZIP-a na serwer”, lecz odtworzyć ostatnią pewną wersję i jednocześnie nie przywrócić przyczyny awarii.

FAQ – najczęstsze pytania o kopie zapasowe strony firmowej

Czy backup wykonywany przez hosting wystarczy?
Nie jako jedyna kopia. Snapshot hostingu jest wygodny i przy drobnej awarii często pozwala odtworzyć stronę w kilka minut, ale firma powinna mieć również kopię przechowywaną niezależnie od głównego dostawcy.

Jak długo przechowywać backup strony?
Dla zwykłej strony rozsądnym punktem startowym jest 7 kopii dziennych, 4 tygodniowe i 3–6 miesięcznych. Dla sklepu warto dodatkowo trzymać znacznie częstsze kopie bazy z ostatnich 24–48 godzin.

Czy trzeba wykonywać backup przed aktualizacją WordPressa?
Tak, zwłaszcza przed zmianą wersji PHP, większą aktualizacją WordPressa, WooCommerce, motywu albo kilku istotnych wtyczek. Kopia powinna obejmować zarówno pliki, jak i bazę danych.

Czy można przechowywać backup na Dysku Google, OneDrive lub Dropboxie?
Technicznie tak, szczególnie przy małych stronach, ale takie rozwiązanie ma ograniczenia w automatyzacji, zarządzaniu wersjami, uprawnieniach i ochronie przed usunięciem. Przy serwisach istotnych dla sprzedaży lepszy jest magazyn przeznaczony do backupów lub object storage.

Czy pendrive albo dysk USB jest dobrym backupem?
Jako dodatkowa kopia offline — tak. Jako jedyny backup — nie. Nośnik może się uszkodzić, zaginąć albo przez kilka miesięcy nie zostać zaktualizowany.

Jak sprawdzić, czy backup naprawdę działa?
Trzeba go odtworzyć na osobnym serwerze lub środowisku testowym. Sprawdzenie, że plik ZIP istnieje i ma kilka gigabajtów, nie jest testem backupu.

Co najpierw poprawić, jeśli firma ma dziś tylko jeden backup na tym samym hostingu?
Najpierw uruchomić automatyczną kopię poza głównym hostingiem i wykonać próbne odtworzenie. Dopiero później warto dopracowywać dłuższą retencję, kopie przyrostowe czy zaawansowane blokady Object Lock. Największym błędem do usunięcia w pierwszej kolejności jest pojedynczy punkt awarii: strona i wszystkie jej kopie znajdujące się w jednym miejscu.

Więcej informacji na: https://hd-biznes.com