Jak skonfigurować kopie zapasowe strony internetowej

Strona najczęściej nie psuje się wtedy, gdy ktoś ma czas spokojnie analizować problem. Awaria pojawia się po aktualizacji wtyczki, błędzie administratora, infekcji, nieudanej migracji albo zmianie wykonanej „tylko na chwilę”. Bez dobrej kopii zapasowej nawet prosty błąd może skończyć się wielogodzinnym odtwarzaniem treści, utratą zamówień, formularzy, zdjęć lub danych klientów.

Dobra konfiguracja backupu nie polega na kliknięciu jednej opcji w panelu hostingu. Trzeba zdecydować, co kopiować, jak często, gdzie przechowywać pliki, ile wersji trzymać i — najważniejsze — czy da się tę kopię realnie przywrócić. To ostatnie bywa pomijane, a później okazuje się, że backup istnieje, ale baza danych jest niepełna, pliki są sprzed miesiąca, a archiwum nie otwiera się na nowym serwerze.

Jak dobrać rodzaj kopii zapasowej do strony internetowej?

Najpierw trzeba rozdzielić dwie rzeczy: pliki strony i bazę danych. W plikach znajdują się między innymi motywy, wtyczki, zdjęcia, dokumenty PDF, skrypty i konfiguracje. W bazie danych zwykle siedzą treści wpisów, strony, komentarze, ustawienia CMS-a, dane użytkowników, zamówienia oraz konfiguracja części wtyczek.

W praktyce pełna kopia strony powinna obejmować:

• pliki strony internetowej, czyli katalog z instalacją CMS-a, np. WordPressa,
• bazę danych, najczęściej MySQL lub MariaDB,
• pliki konfiguracyjne, takie jak .htaccess, wp-config.php albo konfiguracje środowiska,
• katalog uploadów, bo to tam często znajdują się zdjęcia, faktury, katalogi produktów i załączniki,
• kopię przed aktualizacją, wykonywaną ręcznie lub automatycznie przed większą zmianą.

Nie każda strona wymaga takiego samego harmonogramu. Blog aktualizowany raz w tygodniu nie potrzebuje backupu co godzinę. Sklep internetowy już tak — szczególnie jeśli przyjmuje zamówienia, płatności i rejestracje użytkowników.

Dobry punkt wyjścia wygląda tak:

• strona firmowa aktualizowana sporadycznie: pełna kopia raz w tygodniu, baza danych codziennie,
• blog lub portal z regularnymi publikacjami: pełna kopia co 1–3 dni, baza danych codziennie,
• sklep internetowy: baza danych co kilka godzin, pełna kopia minimum raz dziennie,
• serwis z kontami użytkowników lub rezerwacjami: baza danych nawet co godzinę, zależnie od liczby zmian.

Największy priorytet ma baza danych, bo zmienia się częściej niż pliki. Jeżeli sklep straci pliki sprzed kilku godzin, zwykle da się je odtworzyć z repozytorium, panelu hostingu albo lokalnej kopii. Jeżeli straci zamówienia z ostatnich 12 godzin, problem robi się dużo poważniejszy.

Warto też rozróżnić kopię pełną, różnicową i przyrostową. Kopia pełna zawiera wszystko, ale zajmuje najwięcej miejsca. Kopia różnicowa zapisuje zmiany względem ostatniej pełnej kopii. Kopia przyrostowa zapisuje tylko zmiany od poprzedniego backupu, dzięki czemu jest lżejsza, ale jej przywracanie wymaga poprawnego działania całego łańcucha kopii.

Dla większości małych i średnich stron najbezpieczniejszy układ to:

• pełna kopia strony raz dziennie lub raz w tygodniu,
• częstsza kopia bazy danych,
• przechowywanie minimum kilku ostatnich wersji,
• jedna kopia poza serwerem, na którym działa strona.

Trzymanie backupu wyłącznie na tym samym hostingu to słabe zabezpieczenie. Jeżeli konto zostanie zablokowane, serwer ulegnie awarii albo ktoś uzyska dostęp do panelu i usunie pliki, kopia może zniknąć razem ze stroną. Lepszy model to zasada 3-2-1: trzy kopie danych, dwa różne nośniki lub miejsca przechowywania, jedna kopia poza głównym serwerem.

Co robić, a czego nie robić podczas konfiguracji backupu?

Najpierw trzeba sprawdzić, jakie kopie robi hosting. Nie po to, żeby na nich całkowicie polegać, ale żeby wiedzieć, jaki jest pierwszy poziom ochrony. W panelu hostingu należy znaleźć informacje o:

• częstotliwości backupu,
• czasie przechowywania kopii, np. 7, 14 albo 30 dni,
• tym, czy backup obejmuje pliki i bazę danych,
• sposobie przywracania kopii,
• ewentualnych opłatach za odtworzenie danych,
• ograniczeniach wielkości konta lub liczby plików.

Niektóre firmy hostingowe oferują automatyczne kopie w cenie usługi, ale zakres bywa różny. Czasem backup obejmuje całe konto, czasem tylko pliki, a czasem przywrócenie danych wymaga kontaktu z supportem. To trzeba sprawdzić w panelu klienta lub regulaminie konkretnej usługi, bo te warunki potrafią się zmieniać.

Drugi krok to konfiguracja własnego backupu. Przy stronie na WordPressie można użyć wtyczki, narzędzia hostingu albo rozwiązania po stronie serwera. Wtyczka jest wygodna, ale ma ograniczenia: działa w obrębie CMS-a, może obciążać stronę i czasem nie radzi sobie z dużymi katalogami uploadów. Backup serwerowy zwykle jest stabilniejszy, ale wymaga większej kontroli technicznej.

Minimalna konfiguracja powinna wyglądać tak:

1. Ustaw automatyczny harmonogram kopii.
2. Włącz osobne kopiowanie bazy danych.
3. Zapisuj kopie poza głównym serwerem, np. w chmurze, na innym hostingu lub w zewnętrznym repozytorium.
4. Ogranicz liczbę przechowywanych wersji, żeby backup nie zapełnił konta.
5. Dodaj powiadomienia e-mail o błędach wykonywania kopii.
6. Raz na jakiś czas pobierz kopię lokalnie i sprawdź, czy archiwum da się otworzyć.

Najczęstszy błąd to ustawienie backupu i zapomnienie o nim. Po kilku miesiącach okazuje się, że zadanie przestało działać, bo zmieniła się wersja PHP, skończyło się miejsce na dysku albo zewnętrzny token dostępu do chmury wygasł. Backup bez monitoringu daje fałszywe poczucie bezpieczeństwa.

Czego nie robić?

• Nie trzymaj kopii tylko w katalogu strony, np. /public_html/backups/.
• Nie zostawiaj archiwów dostępnych publicznie przez przeglądarkę.
• Nie zakładaj, że hosting zawsze przywróci wszystko w kilka minut.
• Nie wykonuj aktualizacji CMS-a, motywu lub wtyczek bez świeżej kopii.
• Nie trzymaj jednej wersji backupu, bo możesz skopiować już zainfekowaną lub uszkodzoną stronę.
• Nie ignoruj komunikatów o nieudanym backupie.

W praktyce dobrze działa prosta hierarchia: najpierw automatyzacja, potem zewnętrzne miejsce przechowywania, dopiero później dopieszczanie zaawansowanych ustawień. Nie ma sensu zaczynać od skomplikowanych scenariuszy, jeśli podstawowy backup nie działa codziennie i nikt nie sprawdza raportów.

Ważna jest też retencja, czyli czas przechowywania kopii. Dla małej strony firmowej sensowne minimum to 7–14 dni. Dla sklepu internetowego lepiej trzymać dłuższy zakres, np. kopie dzienne z ostatnich 14 dni oraz kopie tygodniowe z ostatniego miesiąca. Przy infekcjach to ma znaczenie, bo złośliwy kod może zostać zauważony dopiero po kilku lub kilkunastu dniach.

Dlaczego test przywracania kopii jest ważniejszy niż samo jej tworzenie?

Backup, którego nikt nigdy nie przywrócił testowo, jest tylko założeniem. Może działać. Może też zawierać pustą bazę, uszkodzone archiwum, niekompletne uploady albo pliki, które po przeniesieniu na inny serwer wysypią stronę przez różnice w wersji PHP.

W praktyce test przywracania powinien być wykonany przynajmniej po pierwszej konfiguracji backupu, po zmianie hostingu, po dużej przebudowie strony i po wdrożeniu sklepu. Nie trzeba od razu nadpisywać produkcyjnej strony. Bezpieczniej postawić kopię na subdomenie technicznej, środowisku stagingowym albo lokalnie.

Procedura testowa może być prosta:

1. Pobierz ostatnią pełną kopię plików.
2. Pobierz kopię bazy danych z tego samego momentu.
3. Utwórz testową bazę danych.
4. Wgraj pliki na subdomenę lub środowisko testowe.
5. Zmień dane dostępowe do bazy w pliku konfiguracyjnym.
6. Sprawdź stronę główną, podstrony, formularze, logowanie, koszyk i panel administracyjny.
7. Zanotuj czas przywracania oraz problemy, które wystąpiły.

To właśnie tutaj wychodzą szczegóły, których nie widać w raportach. Na przykład sklep działa, ale nie wyświetla zdjęć produktów. Formularz kontaktowy ładuje się poprawnie, ale nie wysyła wiadomości. Panel administratora otwiera się, lecz nie można zaktualizować wtyczek, bo prawa do plików są źle ustawione.

W poradnikach technicznych, także w podejściu, jakie podaje szymonsarnecki.pl, takie problemy warto traktować nie jako drobne niedogodności, lecz jako sygnał, że backup nie jest jeszcze gotowym planem awaryjnym. Sama obecność pliku .zip na dysku nie oznacza, że firma odzyska stronę po awarii bez strat.

Dobry test powinien odpowiedzieć na trzy pytania:

• Ile czasu zajmuje przywrócenie strony?
• Jakie dane mogą zniknąć między ostatnim backupem a awarią?
• Kto konkretnie ma dostęp do kopii i potrafi ją odtworzyć?

Dla strony wizytówkowej utrata zmian z jednego dnia może być akceptowalna. Dla sklepu internetowego utrata zamówień z kilku godzin już nie. Tu pojawiają się dwa ważne parametry: RPO i RTO.

RPO określa, ile danych można maksymalnie stracić. Jeśli backup bazy sklepu wykonuje się co 24 godziny, realne RPO wynosi do 24 godzin. RTO mówi, jak szybko strona ma wrócić do działania. Jeżeli nikt nie testował przywracania, RTO jest zgadywanką, a nie parametrem.

Najrozsądniej zacząć od konkretnej decyzji: ile godzin danych możesz stracić bez poważnych konsekwencji? Odpowiedź ustala harmonogram backupu. Potem trzeba określić, jak szybko strona musi wrócić po awarii. To decyduje, czy wystarczy ręczne przywracanie z panelu hostingu, czy potrzebny jest gotowy proces awaryjny i osoba odpowiedzialna za jego uruchomienie.

Największy błąd do usunięcia jako pierwszy? Backup przechowywany tylko na tym samym serwerze co strona. Dopóki kopia nie znajduje się również poza głównym hostingiem i nie została testowo przywrócona, konfiguracja jest niepełna.

FAQ: najczęstsze pytania o kopie zapasowe strony internetowej

Jak często robić kopię zapasową strony internetowej?
Dla prostej strony firmowej zwykle wystarczy pełna kopia raz w tygodniu i kopia bazy codziennie. Dla sklepu internetowego baza danych powinna być kopiowana częściej, nawet co kilka godzin, bo to w niej zapisują się zamówienia, klienci i statusy płatności.

Czy kopia z hostingu wystarczy?
Nie zawsze. Kopia z hostingu jest przydatna jako pierwszy poziom ochrony, ale nie powinna być jedynym backupem. Bezpieczniej mieć dodatkową kopię poza głównym serwerem, szczególnie przed aktualizacjami, migracją albo większą przebudową strony.

Co powinien zawierać pełny backup strony?
Pełny backup powinien obejmować pliki strony, bazę danych, katalog z mediami, pliki konfiguracyjne oraz dane potrzebne do ponownego uruchomienia serwisu. Przy WordPressie sama kopia motywu nie wystarczy, bo treści i ustawienia są zapisane głównie w bazie danych.

Gdzie przechowywać kopie zapasowe?
Najlepiej w co najmniej dwóch miejscach: na hostingu oraz poza nim, np. w zewnętrznej chmurze, na innym serwerze lub lokalnym zaszyfrowanym nośniku. Kopia w katalogu publicznym strony jest ryzykowna, bo może zostać pobrana przez niepowołaną osobę.

Czy trzeba szyfrować backup?
Tak, jeśli kopia zawiera dane klientów, użytkowników, zamówienia, adresy e-mail albo inne informacje wrażliwe biznesowo. Backup bywa pełniejszym źródłem danych niż sama strona, dlatego dostęp do niego powinien być ograniczony.

Kiedy wykonać ręczną kopię zapasową?
Zawsze przed aktualizacją CMS-a, motywu, ważnych wtyczek, migracją na inny serwer, zmianą wersji PHP, wdrożeniem nowego szablonu lub większą edycją sklepu. Automatyczny backup nie zwalnia z ręcznej kopii przed ryzykowną operacją.

Jak sprawdzić, czy backup działa?
Trzeba wykonać testowe przywrócenie na subdomenie, środowisku stagingowym albo lokalnie. Sam komunikat „backup zakończony sukcesem” nie wystarczy, bo nie pokazuje, czy strona po odtworzeniu działa poprawnie.

Ile wersji kopii warto przechowywać?
Minimum to kilka ostatnich wersji. Dla małej strony sensowne jest 7–14 dni historii. Dla sklepu lub portalu lepiej połączyć kopie dzienne z tygodniowymi, ponieważ infekcja albo błąd mogą zostać zauważone dopiero po czasie.

Czy backup chroni przed atakiem hakerskim?
Backup nie blokuje ataku, ale pozwala szybciej wrócić do działania po usunięciu przyczyny infekcji. Nie wolno jednak przywracać kopii bez analizy, bo można odtworzyć także zainfekowane pliki.

Od czego zacząć konfigurację backupu?
Najpierw sprawdź, jakie kopie robi hosting i przez ile dni je przechowuje. Potem ustaw własny automatyczny backup plików i bazy danych, dodaj zewnętrzne miejsce przechowywania oraz wykonaj test przywracania. Bez tego ostatniego nie wiadomo, czy kopia naprawdę nadaje się do użycia.