Kopia strony na WordPressie składa się z dwóch części: plików i bazy danych. Same pliki bez bazy dają pustą stronę bez treści, sama baza bez plików nie ma zdjęć, motywu i wtyczek. Kopia ma też leżeć poza serwerem, na którym stoi strona, i być sprawdzona: dopóki nikt nie spróbował odtworzyć z niej strony, nie wiadomo, czy w ogóle zadziała. Poniżej opisuję, co kopiować, jak często i jak to sprawdzić bez ryzyka dla działającej strony.
Co jest w plikach, a co w bazie
| Część | Co zawiera | Gdzie leży |
|---|---|---|
| Baza danych | treść stron i wpisów, ustawienia, użytkownicy, zamówienia w sklepie, układy z Elementora | MySQL albo MariaDB na serwerze |
| Folder wp-content | zdjęcia i pliki z biblioteki mediów, motyw, wtyczki | na serwerze, w katalogu strony |
| Plik wp-config.php | dane do bazy, klucze, ustawienia | w głównym katalogu strony |
| Plik .htaccess | przekierowania, adresy, reguły serwera | w głównym katalogu strony |
Samego WordPressa, czyli plików systemu, kopiować nie trzeba, bo da się go pobrać od nowa w tej samej wersji. W praktyce łatwiej skopiować cały katalog strony, niż rozdzielać go na części, więc większość wtyczek do kopii tak właśnie robi.
Kopia na tym samym serwerze to za mało
Wiele hostingów robi kopie automatycznie i trzyma je na swoich serwerach. To dobra pierwsza linia, ale nie jedyna. Jeśli zaginie konto hostingowe, na przykład przez nieopłaconą fakturę, przejęte hasło albo spór z poprzednią agencją, giną razem z nim kopie. Dlatego przynajmniej jedna kopia powinna leżeć w innym miejscu: w chmurze firmy, na dysku Google albo OneDrive, u innego dostawcy. To zasada 3-2-1, którą opisałem we wpisie o kopii zapasowej w małej firmie.
Jak często robić kopię
Częstotliwość zależy od tego, ile możesz stracić. Strona wizytówka, w której treść zmienia się raz w miesiącu, wystarczy z kopią raz w tygodniu. Sklep, w którym codziennie przybywa zamówień, potrzebuje kopii bazy codziennie, a w sezonie nawet częściej, bo każde zamówienie z ostatniego dnia to klient, któremu trzeba wysłać towar. Zdjęcia i pliki zmieniają się rzadziej, więc pełną kopię plików można robić raz w tygodniu, a bazę codziennie.
Kopia przed każdą zmianą
Najwięcej awarii na stronach, którymi się opiekuję, nie bierze się z ataków, tylko ze zmian: aktualizacji wtyczki, nowej wersji motywu, przeniesienia na inny serwer. Dlatego przed każdą zmianą robię osobną kopię tego, co zmieniam. Przy stronie na WordPressie to zrzut bazy i kopia plików, które zmiana dotknie. Przy treściach w panelu Websly to kopia bazy panelu z datą i godziną w nazwie. Dzięki temu, gdy coś pójdzie źle, wracam do stanu sprzed godziny, a nie sprzed tygodnia.
Jak długo trzymać kopie
Ostatnia kopia nie wystarczy. Jeśli strona została zainfekowana dwa tygodnie temu, a zauważyłeś to dziś, wczorajsza kopia też zawiera złośliwy kod. Rozsądny układ dla małej firmy: kopie dzienne z ostatnich dwóch tygodni, tygodniowe z ostatnich dwóch miesięcy i miesięczne z ostatniego pół roku. Wtyczki do kopii i hostingi pozwalają ustawić to automatycznie, żeby stare kopie same znikały.
Gdzie przechowywać hasła do kopii
Kopia zawiera wp-config.php, czyli hasło do bazy, a baza zawiera dane klientów: adresy, telefony, zamówienia. Dlatego miejsce, w którym leżą kopie, musi być chronione jak sama strona: konto firmowe, nie prywatne konto pracownika, logowanie dwuetapowe, dostęp tylko dla osób, które go potrzebują. Jeśli kopie są szyfrowane, klucz do nich trzymaj w menedżerze haseł firmy. Kopia, której nikt nie umie otworzyć, nie przyda się w dniu awarii.
Test odtworzenia: jedyny dowód, że kopia działa
Kopia może być niepełna z powodów, których nie widać na pierwszy rzut oka: wtyczka przerwała pracę przy dużym folderze ze zdjęciami, baza zapisała się bez jednej tabeli, plik wyszedł pusty, bo zabrakło miejsca. Wszystko to wychodzi dopiero przy odtwarzaniu. Test wygląda tak:
- Załóż osobne miejsce na test: subdomenę w rodzaju test.twojafirma.pl albo kopię na komputerze.
- Wgraj tam pliki z kopii i zaimportuj bazę.
- Zmień adres strony w bazie na testowy, żeby linki nie prowadziły do prawdziwej strony.
- Zablokuj testową stronę przed Google hasłem albo ustawieniem „nie indeksuj”.
- Przejdź po stronie: strona główna, kilka podstron, zdjęcia, formularz, w sklepie koszyk i ostatnie zamówienia w panelu.
- Zapisz datę testu i to, co nie zadziałało.
Taki test dobrze zrobić dwa razy w roku i po każdej zmianie sposobu robienia kopii. Trwa godzinę, a odpowiada na pytanie, które inaczej pada dopiero w dniu awarii.
Na co uważać przy sklepie WooCommerce
W sklepie baza zmienia się cały czas: zamówienia, stany magazynowe, konta klientów. Odtworzenie wczorajszej kopii oznacza, że zamówienia z dzisiejszego dnia znikną ze strony, choć pieniądze od klientów już przyszły. Przed odtworzeniem sklepu spisz więc zamówienia z okresu po kopii, z panelu albo z maili, które sklep wysłał. Przy testowym odtwarzaniu wyłącz wysyłkę maili, inaczej klienci dostaną drugi raz potwierdzenia starych zamówień.
Kopia u hostingu, wtyczka czy własny skrypt
Kopie hostingu są wygodne i działają bez Twojej pracy, ale leżą u tego samego dostawcy. Wtyczka do kopii wysyła je do chmury, ale jeśli strona przestanie działać, wtyczka też przestaje. Własny skrypt na serwerze, który codziennie robi zrzut bazy i wysyła go do chmury, nie zależy od działania WordPressa, ale ktoś musi go postawić i pilnować. Dla małej firmy dobrze sprawdza się połączenie: kopie hostingu jako pierwsza linia i wtyczka albo skrypt, który kopiuje do chmury firmy.
Strona to nie wszystko
Przy kopii strony łatwo zapomnieć o rzeczach, które leżą obok niej na tym samym hostingu. Poczta firmowa, jeśli jest u tego samego dostawcy, ma własne skrzynki i nie trafia do kopii strony. Zgłoszenia z formularza zapisują się czasem tylko w bazie, czasem tylko w mailu. Ustawienia DNS domeny, czyli wpisy, które kierują ruch na serwer i pocztę do skrzynek, są w panelu rejestratora i też powinny być spisane. Ustal więc listę wszystkiego, co składa się na Twoją obecność w sieci, i przy każdej pozycji zapisz, gdzie leży jej kopia. Przy przenosinach na inny hosting ta lista oszczędza dzień szukania.
Kto ma pilnować, że kopie się robią
Kopia, która przestała się robić pół roku temu, bo wygasła licencja wtyczki albo zmieniło się hasło do chmury, to częsty widok przy przejmowaniu stron. Ktoś musi dostawać informację, że kopia się nie udała, i na nią reagować. W stałej opiece robi to informatyk. Jeśli robisz to sam, ustaw powiadomienia mailowe z wtyczki i raz w miesiącu zajrzyj do folderu z kopiami, czy jest w nim plik z ostatnich dni.
Jeśli nie wiesz, czy Twoja strona ma kopie i czy da się z nich coś odtworzyć, zacznij od sprawdzenia tego jednego. Kopie stron i test odtworzenia są częścią tego, czym zajmuję się w ramach pomocy IT dla firm, a o swojej stronie możesz napisać przez formularz.