Jak ustawić kopie zapasowe strony, żeby naprawdę działały

Kopia zapasowa istnieje po to, żeby uratować Cię w najgorszym dniu — po włamaniu, nieudanej aktualizacji wtyczki albo skasowaniu bazy danych. Problem w tym, że bardzo wielu właścicieli stron dowiaduje się dopiero w tym najgorszym dniu, że ich „backupy" są przestarzałe, leżą na tym samym serwerze co strona albo w ogóle nie dają się przywrócić. Poniżej znajdziesz konkretną procedurę, która zamienia kopie zapasowe z fikcji w realne zabezpieczenie: jak ustawić częstotliwość, gdzie trzymać dane, jak je testować i jak to wszystko zautomatyzować.

Krok 1: Dobierz częstotliwość do tempa zmian

Najpierw odpowiedz sobie na jedno pytanie: ile pracy jesteś w stanie stracić? To jest Twój RPO (Recovery Point Objective), czyli maksymalny akceptowalny okres utraty danych. Blog publikowany raz w tygodniu spokojnie przeżyje kopię dzienną. Sklep przyjmujący zamówienia co kilka minut potrzebuje backupu bazy danych nawet co godzinę, bo każda utracona godzina to realne zamówienia, których nikt Ci nie odtworzy.

Rozdziel przy tym dwie warstwy. Pliki (motyw, wtyczki, grafiki, kod) zmieniają się rzadko — często wystarczy kopia dzienna lub po każdej większej zmianie. Baza danych zmienia się przy każdym komentarzu, zamówieniu i wpisie, więc to ją warto kopiować częściej. Ustal częstotliwość świadomie, zamiast zostawiać domyślne ustawienia wtyczki, które rzadko pasują do Twojego przypadku.

Krok 2: Zastosuj zasadę 3-2-1

To najważniejsza reguła w całym poradniku. Zasada 3-2-1 mówi: trzymaj 3 kopie danych, na 2 różnych nośnikach, z czego 1 kopia ma być poza lokalizacją produkcyjną. Brzmi prosto, ale rozbija się o jeden błąd, który popełnia większość ludzi: trzymają wszystkie kopie na tym samym serwerze co strona.

Jeśli backup leży w katalogu domowym tego samego hostingu, to awaria dysku, atak ransomware albo zawieszenie konta przez dostawcę zabierają jednocześnie stronę i jej kopię. Dlatego co najmniej jedna kopia musi opuścić serwer: chmura obiektowa (S3, Backblaze B2, Wasabi), Twój komputer albo zewnętrzny dysk. „Poza hostingiem" jest tu kluczowe — to różnica między scenariuszem „odtworzymy w 20 minut" a „nie ma już nic".

Krok 3: Przetestuj przywracanie, zanim będzie pożar

Backup, którego nigdy nie przywróciłeś, jest tylko nadzieją, a nie zabezpieczeniem. Bardzo częsty scenariusz: kopie wykonują się codziennie przez rok, a w dniu awarii okazuje się, że archiwum jest uszkodzone, niekompletne albo brakuje w nim eksportu bazy. Test odkrywa takie problemy, gdy masz jeszcze działającą stronę i spokój.

Raz na jakiś czas (np. raz w miesiącu) wykonaj próbne przywracanie na osobnym środowisku — subdomenie testowej, lokalnej instalacji albo serwerze stagingowym. Sprawdź, czy strona faktycznie wstaje: czy ładuje się strona główna, czy działa logowanie, czy baza zawiera najnowsze wpisy i czy nie sypią się błędy. Zapisz sobie czas, jaki zajęło odtworzenie — to Twój realny RTO (Recovery Time Objective). Dopiero przetestowana kopia zasługuje na miano kopii zapasowej.

Krok 4: Zautomatyzuj i monitoruj

Ręczne kopie zawodzą, bo człowiek zapomina, wyjeżdża albo „zrobi to jutro". Backup musi działać sam. W przypadku WordPressa użyj wtyczki, która potrafi wysyłać archiwa do zewnętrznej chmury (np. UpdraftPlus, Jetpack VaultPress, BackWPup). Na serwerze z dostępem SSH możesz oprzeć się na zadaniu cron, które pakuje pliki i robi zrzut bazy poleceniem mysqldump, a następnie wysyła paczkę do chmury obiektowej.

Sama automatyzacja to za mało — potrzebujesz potwierdzenia, że zadziałała. Włącz powiadomienia o niepowodzeniu (mail albo wiadomość), żeby cicha awaria backupu nie umknęła Twojej uwadze na miesiące. Ustaw też retencję: ile kopii przechowujesz wstecz. Sensowny układ to kilka kopii dziennych, kilka tygodniowych i kilka miesięcznych — daje to ochronę także przed błędem, który zauważysz dopiero po czasie.

Tabela: szybka ściąga konfiguracji

Najczęstsze błędy, których warto unikać

Trzymanie kopii wyłącznie na serwerze produkcyjnym to błąd numer jeden — niweczy cały sens backupu. Numer dwa: kopiowanie samych plików bez bazy danych (albo odwrotnie), przez co przywrócenie nie odtwarza działającej strony. Numer trzy: brak retencji, czyli nadpisywanie jedynej kopii — jeśli strona została zaszyfrowana tydzień temu, a Ty masz tylko wczorajszą kopię, odtworzysz zaszyfrowaną wersję. I numer cztery, najgroźniejszy: założenie, że „hosting na pewno ma backup". Wielu dostawców traktuje swoje kopie jako zabezpieczenie infrastruktury, a nie gwarancję odzyskania Twoich danych — odpowiedzialność i tak spada na Ciebie.

Podsumowanie

Działająca kopia zapasowa to nie pojedyncza wtyczka, tylko proces oparty na czterech filarach: rozsądna częstotliwość dopasowana do tempa zmian, przechowywanie poza hostingiem według zasady 3-2-1, regularny test przywracania oraz pełna automatyzacja z powiadomieniami o błędach. Poświęć godzinę na ustawienie tego raz, a kupisz sobie spokój na lata. Najlepszy moment, żeby sprawdzić swoje backupy, to dzisiaj — zdecydowanie nie w dniu awarii.