Kopie zapasowe strony – jak często robić backup?

Informacja „backup jest aktywny” daje poczucie bezpieczeństwa.

Problem w tym, że nie każda kopia zapasowa rzeczywiście pozwala uratować stronę po awarii.

Backup może być nieaktualny, niekompletny albo przechowywany na tym samym serwerze co strona. Może zawierać pliki, ale nie bazę danych. Może być wykonywany regularnie, ale nikt nigdy nie sprawdził, czy można go poprawnie odtworzyć.

Dopiero w chwili awarii okazuje się, czy kopia naprawdę działa.

Dlatego backup strony internetowej nie powinien być traktowany jako dodatkowa funkcja hostingu. To część planu ciągłości działania firmy.

Co może spowodować utratę strony?

Strona internetowa może przestać działać z wielu powodów.

Najczęstsze sytuacje to:

• błędna aktualizacja,
• konflikt wtyczek,
• awaria serwera,
• uszkodzenie bazy danych,
• przypadkowe usunięcie plików,
• infekcja lub włamanie,
• błąd administratora,
• wygaśnięcie usługi,
• przepełnienie dysku,
• nieudana migracja,
• błąd aplikacji,
• awaria integracji.

Nie każdą awarię można przewidzieć.

Można jednak przygotować się tak, aby jej skutki były możliwie małe.

Dobra kopia zapasowa nie zapobiega wszystkim problemom. Pozwala jednak szybciej przywrócić stronę i ograniczyć utratę danych.

Kopia zapasowa strony to nie tylko pliki

Wiele osób utożsamia backup z pobraniem katalogu strony przez FTP.

To za mało.

Typowa strona składa się z kilku elementów:

• plików,
• bazy danych,
• konfiguracji,
• ustawień domeny,
• certyfikatu SSL,
• zadań automatycznych,
• danych poczty,
• integracji,
• danych przechowywanych poza serwerem.

W WordPressie pliki zawierają między innymi motywy, wtyczki i zdjęcia. Treści, użytkownicy, ustawienia i formularze są natomiast zapisane w bazie danych.

Skopiowanie samych plików nie pozwoli odtworzyć całej strony.

W przypadku aplikacji internetowej backup może wymagać również zapisania:

• zmiennych środowiskowych,
• konfiguracji serwera,
• kluczy dostępu,
• ustawień procesów,
• danych Redis,
• konfiguracji workerów,
• zawartości magazynu plików.

Dlatego przed ustaleniem strategii kopii trzeba wiedzieć, z jakich elementów składa się projekt.

Jak często wykonywać kopię strony?

Nie istnieje jedna częstotliwość odpowiednia dla wszystkich stron.

Najważniejsze pytanie brzmi:

**Ile danych firma może zaakceptować jako potencjalnie utracone?**

Jeżeli kopia jest wykonywana raz dziennie, awaria może oznaczać utratę zmian z ostatnich 24 godzin.

Dla prostej strony informacyjnej może to być akceptowalne.

Dla sklepu obsługującego kilkadziesiąt zamówień dziennie już nie.

Częstotliwość backupu powinna zależeć od:

• częstotliwości zmian,
• liczby użytkowników,
• liczby zamówień,
• wartości danych,
• rodzaju projektu,
• kosztu utraty informacji,
• czasu potrzebnego na odtworzenie.

Backup prostej strony firmowej

Strona firmowa, na której treści zmieniają się sporadycznie, zwykle nie wymaga kopii co kilka minut.

Rozsądny schemat może obejmować:

• codzienną kopię bazy i plików,
• dodatkową kopię przed aktualizacją,
• kopię po większej zmianie,
• kilka przechowywanych wersji.

Jeżeli strona jest aktualizowana tylko kilka razy w miesiącu, najważniejsze jest zachowanie kilku poprzednich wersji.

Problem może zostać zauważony dopiero po kilku dniach. Jeżeli dostępna jest wyłącznie najnowsza kopia, może ona już zawierać błąd lub infekcję.

Backup bloga

Blog zmienia się częściej niż typowa strona-wizytówka.

Nowe wpisy, komentarze, aktualizacje treści i przesłane zdjęcia oznaczają częstsze zmiany.

Najczęściej wystarczy:

• codzienna kopia bazy,
• codzienna kopia plików,
• kopia przed aktualizacją WordPressa,
• przechowywanie kilku lub kilkunastu wersji.

Jeżeli blog publikuje kilka materiałów dziennie lub posiada aktywną społeczność, backup bazy może być wykonywany częściej.

Backup sklepu internetowego

Sklep internetowy wymaga bardziej ostrożnego podejścia.

Baza WooCommerce może zmieniać się przy każdym:

• zamówieniu,
• płatności,
• utworzeniu konta,
• zmianie stanu magazynowego,
• zastosowaniu kodu rabatowego,
• aktualizacji produktu.

Kopia raz dziennie może oznaczać utratę wszystkich zamówień z ostatnich godzin.

Dlatego aktywny sklep może wymagać:

• częstych kopii bazy danych,
• codziennych kopii plików,
• dodatkowego backupu przed aktualizacjami,
• kopii przed dużą kampanią,
• przechowywania wielu wersji.

Częstotliwość zależy od skali sprzedaży.

Mały sklep z kilkoma zamówieniami tygodniowo ma inne potrzeby niż sklep przetwarzający setki transakcji dziennie.

Backup systemu rezerwacji

System rezerwacyjny przechowuje dane, których utrata może prowadzić do podwójnych rezerwacji, nieporozumień i strat finansowych.

Kopia powinna obejmować między innymi:

• rezerwacje,
• dane gości,
• płatności,
• dostępność pokoi lub usług,
• konfigurację cen,
• integracje z kalendarzami,
• historię zmian.

Im częściej pojawiają się rezerwacje, tym krótszy powinien być odstęp między kopiami bazy.

W takim systemie warto również prowadzić dziennik zdarzeń, który może pomóc odtworzyć część zmian powstałych między backupami.

Backup aplikacji internetowej

Aplikacja może składać się z wielu usług.

Oprócz bazy i plików trzeba zabezpieczyć:

• konfigurację środowiska,
• kontenery,
• kolejki,
• magazyny danych,
• klucze API,
• harmonogramy zadań,
• konfigurację reverse proxy,
• repozytorium kodu.

Kod aplikacji powinien znajdować się w systemie kontroli wersji.

Repozytorium nie zastępuje jednak kopii bazy, plików użytkowników ani konfiguracji produkcyjnej.

Backup aplikacji powinien być zaplanowany jako odtworzenie całego środowiska, a nie tylko pojedynczego katalogu.

Czym jest RPO?

RPO określa, ile danych firma może maksymalnie utracić.

Jeżeli backup jest wykonywany co 24 godziny, możliwa utrata danych może wynieść nawet dobę.

Jeżeli kopia bazy powstaje co godzinę, potencjalna strata jest znacznie mniejsza.

W uproszczeniu:

• RPO 24 godziny oznacza możliwość utraty danych z ostatniej doby,
• RPO 1 godzina oznacza możliwość utraty danych z ostatniej godziny,
• RPO 15 minut oznacza znacznie częstsze kopie lub replikację.

Nie każda firma potrzebuje bardzo niskiego RPO.

Trzeba jednak świadomie ustalić, jaki poziom utraty danych jest akceptowalny.

Czym jest RTO?

RTO określa, jak szybko strona powinna wrócić do działania po awarii.

Można wykonywać doskonałe kopie, ale jeżeli ich odtworzenie trwa dwa dni, firma nadal ponosi duże straty.

Na czas przywracania wpływają:

• rozmiar kopii,
• lokalizacja backupu,
• sposób odtwarzania,
• dostępność nowego serwera,
• doświadczenie osoby technicznej,
• przygotowana procedura,
• szybkość transferu danych.

Mała strona może zostać przywrócona szybko.

Duży sklep lub aplikacja z wieloma usługami może wymagać znacznie więcej czasu.

Dlatego strategia backupu powinna określać nie tylko częstotliwość kopii, ale również plan odtwarzania.

Dlaczego backup na tym samym serwerze nie wystarczy?

Kopia przechowywana na tym samym serwerze jest lepsza niż brak kopii.

Nie daje jednak pełnego bezpieczeństwa.

Jeżeli dojdzie do:

• awarii dysków,
• uszkodzenia systemu,
• przejęcia serwera,
• usunięcia konta,
• szyfrowania danych,
• problemu centrum danych,

kopia może zostać utracona razem ze stroną.

Dlatego przynajmniej jedna wersja backupu powinna znajdować się poza głównym środowiskiem.

Może to być:

• drugi serwer,
• zewnętrzny magazyn obiektowy,
• niezależna usługa chmurowa,
• fizycznie oddzielna lokalizacja,
• zaszyfrowany magazyn kopii.

Najważniejsze, aby awaria jednego środowiska nie niszczyła jednocześnie strony i wszystkich backupów.

Zasada 3-2-1

Popularna zasada wykonywania kopii mówi o przechowywaniu:

• trzech kopii danych,
• na dwóch różnych rodzajach nośników lub środowisk,
• jednej kopii poza główną lokalizacją.

W praktyce może to wyglądać tak:

1. działająca strona na serwerze,
2. lokalna kopia na oddzielnym dysku lub serwerze,
3. zewnętrzny backup poza główną infrastrukturą.

Nie każda mała strona potrzebuje rozbudowanego systemu klasy korporacyjnej.

Sama zasada dobrze pokazuje jednak, że jedna kopia w jednym miejscu nie jest pełnym zabezpieczeniem.

Jak długo przechowywać backupy?

Przechowywanie wyłącznie najnowszej kopii jest ryzykowne.

Niektóre problemy są wykrywane z opóźnieniem.

Przykładowo infekcja mogła pojawić się tydzień wcześniej, ale strona zaczęła wyświetlać błędy dopiero dziś. Wszystkie kopie z ostatnich kilku dni mogą już zawierać złośliwe pliki.

Dlatego warto zachowywać różne punkty przywracania.

Przykładowa polityka może obejmować:

• kopie dzienne z ostatnich 7–14 dni,
• kopie tygodniowe z ostatnich kilku tygodni,
• kopie miesięczne z ostatnich kilku miesięcy.

Dokładna retencja zależy od dostępnego miejsca, wartości danych i rodzaju projektu.

Ważniejsze od ogromnej liczby kopii jest posiadanie kilku wersji z różnych momentów.

Czy kopie powinny być szyfrowane?

Backup może zawierać:

• dane klientów,
• dane kontaktowe,
• zamówienia,
• faktury,
• dane użytkowników,
• konfigurację systemu,
• hasła i klucze techniczne.

Dlatego kopie powinny być zabezpieczone przed nieautoryzowanym dostępem.

W zależności od rozwiązania warto stosować:

• szyfrowanie danych,
• szyfrowany transfer,
• ograniczone dostępy,
• osobne konta techniczne,
• uwierzytelnianie dwuskładnikowe,
• rejestrowanie dostępu.

Publicznie dostępny plik backupu może być większym zagrożeniem niż sama awaria strony.

Kopie nie powinny znajdować się w katalogu dostępnym bezpośrednio przez przeglądarkę.

Backup a RODO

Kopia zapasowa może zawierać dane osobowe.

Oznacza to, że należy uwzględnić:

• miejsce przechowywania,
• dostęp do kopii,
• retencję,
• szyfrowanie,
• umowy z dostawcami,
• procedurę usuwania danych,
• bezpieczeństwo transferu.

Backup nie może być traktowany jako niekontrolowany magazyn przechowywany bezterminowo.

Polityka kopii powinna być spójna z zasadami przetwarzania danych w firmie.

Czy backup z wtyczki WordPress wystarczy?

Wtyczka do kopii może być dobrym dodatkowym zabezpieczeniem.

Pozwala często:

• tworzyć kopie plików i bazy,
• wysyłać je do zewnętrznej chmury,
• planować harmonogram,
• przywracać stronę.

Nie powinna jednak być jedyną warstwą ochrony.

Wtyczka działa wewnątrz WordPressa. Jeżeli system jest uszkodzony, zainfekowany lub przeciążony, backup może się nie wykonać.

Dodatkowo duże kopie mogą obciążać serwer i zajmować dużo miejsca.

Najlepszym rozwiązaniem jest połączenie:

• backupu na poziomie serwera,
• kopii bazy,
• dodatkowej kopii zewnętrznej,
• kontroli procesu odtwarzania.

Backup hostingu a backup własny

Wielu dostawców hostingu wykonuje automatyczne kopie.

To wartościowa funkcja, ale warto sprawdzić:

• jak często powstają kopie,
• co dokładnie obejmują,
• jak długo są przechowywane,
• gdzie się znajdują,
• czy klient może je pobrać,
• czy przywrócenie jest płatne,
• czy kopie obejmują pocztę,
• czy backup może zostać usunięty razem z kontem.

Dobrze jest posiadać również kopię niezależną od dostawcy hostingu.

Daje to dodatkową ochronę podczas:

• sporu z operatorem,
• utraty dostępu do konta,
• awarii całej usługi,
• migracji,
• błędnego usunięcia hostingu.

Kiedy wykonywać dodatkową kopię?

Niezależnie od regularnego harmonogramu backup warto wykonać przed:

• aktualizacją WordPressa,
• aktualizacją WooCommerce,
• zmianą wersji PHP,
• instalacją nowej wtyczki,
• migracją,
• przebudową strony,
• zmianą motywu,
• aktualizacją aplikacji,
• większym importem danych,
• zmianą konfiguracji serwera.

Taka kopia tworzy bezpieczny punkt powrotu.

Jeżeli zmiana spowoduje błąd, można szybko przywrócić poprzedni stan.

Czy backup może spowolnić stronę?

Tak, szczególnie jeżeli jest wykonywany w godzinach największego ruchu.

Kopiowanie dużej liczby plików, kompresowanie archiwum i eksport bazy zużywają:

• procesor,
• pamięć,
• transfer,
• operacje dyskowe.

Dlatego backupy warto planować w czasie mniejszego obciążenia.

Dla dużych systemów można stosować:

• kopie przyrostowe,
• migawki,
• replikację,
• oddzielne procesy backupowe,
• kopie bazy bez blokowania działania.

Strategia powinna chronić dane bez powodowania regularnych problemów z wydajnością.

Kopia pełna i przyrostowa

Kopia pełna obejmuje wszystkie wskazane dane.

Jest prosta w odtwarzaniu, ale zajmuje więcej miejsca i może trwać dłużej.

Kopia przyrostowa zapisuje tylko zmiany od poprzedniego backupu.

Zajmuje mniej przestrzeni i może być wykonywana częściej. Odtworzenie może jednak wymagać połączenia kilku kolejnych kopii.

Wybór zależy od wielkości systemu i dostępnych narzędzi.

W mniejszych projektach często wystarczają regularne kopie pełne. W większych rozwiązaniach opłaca się połączyć pełne backupy z kopiami przyrostowymi.

Najważniejszy test: czy kopię można odtworzyć?

Backup, którego nigdy nie próbowano przywrócić, jest tylko założeniem.

Proces może zakończyć się niepowodzeniem z powodu:

• uszkodzonego archiwum,
• niepełnego eksportu,
• braku pliku,
• błędnego kodowania,
• braku hasła,
• niezgodnego środowiska,
• brakującej konfiguracji,
• problemu z uprawnieniami.

Dlatego kopie powinny być okresowo testowane.

Test może polegać na odtworzeniu strony w:

• środowisku testowym,
• osobnym katalogu,
• tymczasowej domenie,
• oddzielnym serwerze.

Celem nie jest wyłącznie sprawdzenie, czy plik da się rozpakować.

Trzeba potwierdzić, że strona uruchamia się, łączy z bazą i realizuje najważniejsze funkcje.

Procedura odtwarzania strony

Firma powinna wiedzieć, co wydarzy się po awarii.

Podstawowa procedura może obejmować:

1. rozpoznanie przyczyny problemu,
2. zabezpieczenie obecnych danych,
3. wybór właściwego punktu przywrócenia,
4. przygotowanie czystego środowiska,
5. odtworzenie plików,
6. odtworzenie bazy,
7. przywrócenie konfiguracji,
8. test strony,
9. uruchomienie ruchu,
10. monitoring po odtworzeniu.

Nie zawsze należy natychmiast nadpisywać obecną stronę najnowszą kopią.

Najpierw warto zabezpieczyć istniejący stan, ponieważ może zawierać dane potrzebne do analizy lub nowsze informacje, których nie ma w backupie.

Ile miejsca potrzeba na kopie?

To zależy od:

• rozmiaru strony,
• rozmiaru bazy,
• liczby wersji,
• częstotliwości kopii,
• stopnia kompresji,
• rodzaju backupu.

Jeżeli strona zajmuje 20 GB, a przechowywanych jest 14 pełnych kopii, zapotrzebowanie na miejsce może być znaczące.

Dlatego warto:

• usuwać niepotrzebne pliki,
• kontrolować logi,
• stosować retencję,
• wykorzystywać kopie przyrostowe,
• oddzielić backup od przestrzeni strony.

Nie należy przechowywać nieograniczonej liczby kopii bez kontroli.

Z drugiej strony zbyt agresywne usuwanie backupów może pozbawić firmę starszego, czystego punktu przywrócenia.

Backup poczty

Jeżeli poczta działa na tym samym hostingu, trzeba ustalić, czy kopia obejmuje skrzynki.

Nie każdy backup strony zawiera wiadomości e-mail.

Przy migracji lub awarii można stracić:

• odebrane wiadomości,
• wysłane wiadomości,
• foldery,
• kontakty,
• ustawienia przekierowań.

Ważne skrzynki firmowe powinny być uwzględnione w strategii kopii albo działać u dostawcy zapewniającego własny system backupu.

Backup konfiguracji DNS

Same rekordy DNS zajmują niewiele miejsca, ale ich odtworzenie może być problematyczne.

Warto zachować kopię ustawień:

• A,
• AAAA,
• CNAME,
• MX,
• TXT,
• SPF,
• DKIM,
• DMARC,
• subdomen.

Błędna konfiguracja DNS może unieruchomić stronę i pocztę, nawet jeżeli serwer oraz pliki działają prawidłowo.

Przed większymi zmianami warto zapisać aktualny stan strefy DNS.

Backup na VPS

Własny VPS daje większą kontrolę, ale wymaga samodzielnego zaplanowania kopii.

Sam fakt korzystania z serwera wirtualnego nie oznacza, że backup jest wykonywany.

Trzeba ustalić:

• co jest kopiowane,
• jak często,
• gdzie trafiają kopie,
• jak długo są przechowywane,
• kto otrzymuje alert o błędzie,
• jak odtworzyć cały serwer.

Dobrym rozwiązaniem może być połączenie:

• kopii baz danych,
• kopii plików,
• snapshotów,
• zewnętrznego magazynu,
• monitoringu skuteczności backupu.

Snapshot nie zawsze zastępuje niezależny backup. Jeżeli znajduje się u tego samego dostawcy, nadal istnieje wspólny punkt awarii.

Alarm, gdy kopia się nie wykona

Automatyczny backup może przestać działać z powodu:

• braku miejsca,
• utraty połączenia,
• błędnego hasła,
• zmiany konfiguracji,
• problemu z usługą zewnętrzną,
• uszkodzenia bazy.

Jeżeli nikt nie otrzyma informacji o błędzie, firma może przez kilka tygodni sądzić, że kopie są aktualne.

Dlatego system powinien raportować:

• poprawne wykonanie backupu,
• błąd procesu,
• rozmiar kopii,
• czas wykonania,
• brak miejsca,
• wiek ostatniego poprawnego backupu.

Monitoring kopii jest równie ważny jak sam harmonogram.

Kopie zapasowe w opiece HeatLogic

W HeatLogic backup traktujemy jako część utrzymania strony, a nie tylko opcję zaznaczoną w panelu.

Zakres może obejmować:

• kopie plików,
• kopie bazy danych,
• backup przed aktualizacjami,
• przechowywanie wielu wersji,
• kopię poza głównym serwerem,
• kontrolę skuteczności,
• alerty o błędach,
• pomoc przy odtwarzaniu,
• testowe przywrócenie,
• dobór częstotliwości do projektu.

Inaczej planujemy backup prostej strony firmowej, inaczej sklepu WooCommerce, a jeszcze inaczej systemu rezerwacji lub aplikacji SaaS.

Częstotliwość i retencję ustalamy na podstawie tego, jak często zmieniają się dane oraz jakie skutki spowoduje ich utrata.

Lista kontrolna kopii zapasowych

Sprawdź:

1. Czy backup obejmuje pliki?
2. Czy obejmuje bazę danych?
3. Czy obejmuje konfigurację?
4. Czy kopia znajduje się poza głównym serwerem?
5. Jak często wykonywany jest backup?
6. Ile danych można maksymalnie utracić?
7. Jak długo przechowywane są kopie?
8. Ile wersji jest dostępnych?
9. Czy kopie są szyfrowane?
10. Kto ma do nich dostęp?
11. Czy system zgłasza błędy backupu?
12. Czy wykonywana jest kopia przed aktualizacją?
13. Czy backup obejmuje pocztę?
14. Czy zachowano ustawienia DNS?
15. Czy kopia była testowo odtwarzana?
16. Jak długo potrwa przywrócenie?
17. Kto odpowiada za odtworzenie?
18. Czy istnieje procedura awaryjna?
19. Czy retencja odpowiada wymaganiom firmy?
20. Czy po migracji uruchomiono nowy system kopii?

Podsumowanie

Dobra kopia zapasowa powinna być:

• regularna,
• kompletna,
• przechowywana poza głównym serwerem,
• dostępna w kilku wersjach,
• zabezpieczona,
• monitorowana,
• możliwa do odtworzenia.

Nie wystarczy informacja, że hosting „wykonuje backup”.

Trzeba wiedzieć, co jest kopiowane, jak często, gdzie trafiają dane i ile potrwa przywrócenie strony.

Częstotliwość kopii powinna zależeć od wartości danych.

Prosta strona może potrzebować jednej kopii dziennie. Sklep, system rezerwacji lub aplikacja mogą wymagać znacznie częstszych backupów bazy.

Najważniejsze pytanie nie brzmi:

„Czy mamy kopię?”.

Najważniejsze pytanie brzmi:

**„Czy potrafimy z niej szybko i bezpiecznie odtworzyć działającą stronę?”**

Nie masz pewności, czy backup Twojej strony rzeczywiście działa?

Skontaktuj się z HeatLogic. Sprawdzimy obecny system kopii, częstotliwość, retencję i możliwość przywrócenia danych po awarii.

Najczęściej zadawane pytania

Jak często robić kopię strony WordPress?

Dla typowej strony firmowej najczęściej wystarczy codzienna kopia oraz dodatkowy backup przed aktualizacją. Częstotliwość należy zwiększyć, jeżeli treści i dane zmieniają się wiele razy dziennie.

Jak często wykonywać backup sklepu WooCommerce?

Aktywny sklep może wymagać kopii bazy nawet kilka razy dziennie lub częściej. Częstotliwość zależy od liczby zamówień i akceptowalnej utraty danych.

Czy backup na tym samym hostingu jest bezpieczny?

Chroni przed częścią błędów, ale nie przed awarią całego serwera lub utratą konta. Przynajmniej jedna kopia powinna znajdować się poza głównym hostingiem.

Ile kopii strony należy przechowywać?

Warto posiadać kilka wersji dziennych oraz starsze kopie tygodniowe lub miesięczne. Dokładna liczba zależy od rodzaju strony i dostępnego miejsca.

Czy wtyczka do backupu WordPress wystarczy?

Może być dodatkową warstwą zabezpieczenia, ale lepiej połączyć ją z kopią serwerową i zewnętrznym magazynem danych.

Jak sprawdzić, czy backup działa?

Najpewniejszym sposobem jest testowe odtworzenie strony w oddzielnym środowisku. Sam fakt utworzenia archiwum nie potwierdza, że kopia jest kompletna.

Czy kopia zapasowa obejmuje pocztę?

Nie zawsze. Zależy to od hostingu i konfiguracji. Trzeba sprawdzić, czy skrzynki pocztowe są objęte oddzielnym backupem.