Kopia zapasowa WordPressa, która naprawdę działa. Jak ją zrobić i sprawdzić?

Większość właścicieli stron na WordPressie jest przekonana, że ma kopię zapasową. Przekonanie kończy się w dniu awarii: okazuje się, że kopia leżała na tym samym serwerze co strona, że zawiera same pliki bez bazy danych albo że nikt nigdy nie próbował jej odtworzyć. Kopia, której nie da się przywrócić, nie jest kopią, tylko plikiem zajmującym miejsce na dysku.

Ta instrukcja jest przeznaczona dla osób prowadzących firmową stronę lub sklep na WordPressie, także dla tych, które nie zajmują się stroną zawodowo. Opisuję trzy drogi wykonania kopii: w panelu hostingu, wtyczką oraz ręcznie, każdą krok po kroku.

Najwięcej miejsca poświęcam temu, co zwykle się pomija, czyli próbnemu odtworzeniu strony z kopii. Po lekturze czytelnik będzie wiedział, co musi trafić do kopii, gdzie ją trzymać, jak często ją robić i jak sprawdzić, że w razie awarii naprawdę zadziała.

Z czego składa się strona na WordPressie i co musi trafić do kopii?

Strona na WordPressie to dwie osobne części: pliki i baza danych. Dokumentacja WordPressa mówi o tym wprost: do pełnego odtworzenia typowej strony potrzebne są obie. Na pytanie, czy skopiowanie plików zabezpiecza także bazę, ta sama dokumentacja odpowiada krótko: nie.

Pliki leżą w katalogu strony na serwerze. Baza danych działa w osobnym systemie, zwykle MySQL lub MariaDB, i nie da się jej skopiować przez zwykłe pobranie katalogu. Trzeba ją wyeksportować do pliku, najczęściej z rozszerzeniem .sql, a przy odtwarzaniu zaimportować z powrotem.

W praktyce podział wygląda tak:

• Baza danych – treść wpisów i stron, komentarze, konta użytkowników, ustawienia WordPressa, ustawienia wtyczek i motywu, a w sklepie także produkty, klienci i zamówienia.
• Katalog wp-content – motywy, wtyczki oraz wszystkie zdjęcia i dokumenty wgrane do biblioteki mediów (podkatalog uploads).
• Plik wp-config.php – dane połączenia z bazą danych i najważniejsze ustawienia techniczne.
• Plik .htaccess – reguły serwera, między innymi przyjazne adresy i przekierowania.
• Pliki samego WordPressa – katalogi wp-admin i wp-includes oraz pliki w katalogu głównym.

Plików samego WordPressa, motywów z oficjalnego katalogu i wtyczek da się w razie potrzeby pobrać ponownie. Nie da się natomiast odzyskać skądkolwiek własnych tekstów, zdjęć, ustawień i zamówień. Dlatego baza danych i katalog uploads są w kopii najcenniejsze, a mimo to radzę kopiować cały katalog strony: odtworzenie trwa wtedy krócej i nie wymaga szukania właściwych wersji wtyczek.

Dokumentacja podaje też kolejność. Przy tworzeniu kopii najpierw eksportuje się bazę, potem kopiuje pliki. Przy odtwarzaniu odwrotnie: najpierw pliki, potem baza. Jeżeli po odtworzeniu baza ma inną nazwę, użytkownika lub hasło, trzeba poprawić te dane w pliku wp-config.php.

Po czym poznać, że obecna kopia nie wystarczy?

Zanim powstanie nowa kopia, trzeba uczciwie ocenić tę, która już jest. Wystarczy odpowiedzieć na pięć pytań: gdzie fizycznie leży plik kopii, czy zawiera bazę danych, z jakiego dnia pochodzi najnowsza wersja, ile starszych wersji jest dostępnych i czy ktokolwiek kiedykolwiek odtworzył z niej stronę.

Odpowiedź „nie wiem” na którekolwiek z tych pytań oznacza, że kopii w praktyce nie ma. Najczęstsze sytuacje są trzy: kopia leży wyłącznie na serwerze strony, kopia to sam katalog pobrany kiedyś przez FTP bez bazy danych, albo kopie robi hosting, ale właściciel nie wie, jak długo są przechowywane i jak się je przywraca.

Sygnałem ostrzegawczym jest także wtyczka, która od dawna nie wysłała żadnego powiadomienia. Zadania wtyczek potrafią przestać działać po zmianie hasła do dysku w chmurze, po zapełnieniu miejsca albo po aktualizacji. Dokumentacja WordPressa zaleca, aby kopie automatyczne co jakiś czas uzupełniać kopią wykonaną ręcznie, właśnie po to, by mieć pewność, że cały proces działa.

Jak zrobić kopię w panelu hostingu?

Większość firm hostingowych wykonuje kopie całych kont i udostępnia je w panelu klienta. To najwygodniejsza droga, bo nie wymaga instalowania niczego na stronie. Nazwy sekcji różnią się między dostawcami, najczęściej jest to „Kopie zapasowe” albo „Backup”, dlatego poniższe kroki opisują czynności, a nie konkretny panel.

1. Po zalogowaniu do panelu hostingu należy odszukać sekcję kopii zapasowych i sprawdzić listę dostępnych kopii: z jakich dni pochodzą i jak daleko wstecz sięgają.
2. Trzeba ustalić, czy kopia obejmuje osobno pliki i osobno bazy danych. W wielu panelach są to dwie oddzielne listy i każdą część przywraca się osobno.
3. Jeżeli panel pozwala wykonać kopię na żądanie, należy ją uruchomić i poczekać na zakończenie. Taka kopia przydaje się zwłaszcza tuż przed aktualizacją.
4. Gotową kopię plików i kopię bazy trzeba pobrać na własny komputer. Kopia, która istnieje tylko u dostawcy hostingu, znika razem z kontem.
5. Na koniec należy sprawdzić w panelu lub w regulaminie usługi, jak przebiega przywracanie: czy klient robi to sam, czy przez zgłoszenie do pomocy technicznej, i czy usługa wymaga dodatkowej opłaty.

Jeżeli panel nie daje jasnych odpowiedzi, warto wysłać do pomocy technicznej krótkie zapytanie. Gotowa treść: „Proszę o informację, jak często wykonywane są kopie zapasowe mojego konta, jak długo są przechowywane, czy obejmują bazy danych, czy są przechowywane na innym serwerze niż strona oraz w jaki sposób mogę przywrócić lub pobrać wybraną kopię.”

Kopie hostingu traktuję jako pierwszą linię, a nie jedyną. Dokumentacja WordPressa ujmuje to podobnie: większość firm hostingowych kopiuje cały serwer, jednak lepiej, aby właściciel strony miał także własną kopię swoich plików. Dostawca odpowiada za swoją infrastrukturę, a nie za to, że konkretna strona da się odtworzyć po błędzie jej właściciela.

Jak ustawić kopię zapasową wtyczką?

Druga droga to wtyczka do kopii zapasowych z oficjalnego katalogu wtyczek WordPressa. Jej zaletą jest harmonogram i wysyłanie kopii poza serwer bez udziału człowieka. Nie wskazuję jednej wtyczki, ponieważ ważniejsze od nazwy jest to, co potrafi.

Przy wyborze trzeba sprawdzić cztery rzeczy: czy wtyczka kopiuje zarówno bazę danych, jak i pliki, czy potrafi wysłać kopię do zewnętrznego miejsca (dysk w chmurze, inny serwer), czy ma harmonogram z limitem przechowywanych wersji oraz czy pozwala odtworzyć stronę z własnej kopii. Dodatkowo należy spojrzeć w katalogu wtyczek na datę ostatniej aktualizacji i zgodność z używaną wersją WordPressa.

1. W kokpicie WordPressa, w menu „Wtyczki”, należy przejść do dodawania nowej wtyczki, wyszukać wybraną wtyczkę do kopii zapasowych, zainstalować ją i włączyć.
2. W ustawieniach wtyczki trzeba wskazać zakres kopii: baza danych oraz pliki, czyli co najmniej wtyczki, motywy i przesłane pliki.
3. Należy połączyć wtyczkę z zewnętrznym miejscem przechowywania i potwierdzić dostęp. Bez tego kopie trafiają do katalogu na tym samym serwerze.
4. W harmonogramie ustawia się osobno częstotliwość kopii bazy i kopii plików oraz liczbę wersji, które mają być zachowane.
5. Jeżeli wtyczka ma taką możliwość, trzeba włączyć powiadomienia e-mail o wyniku każdej kopii.
6. Pierwszą kopię należy uruchomić ręcznie i od razu sprawdzić w zewnętrznym miejscu, czy pliki rzeczywiście tam są i mają sensowny rozmiar.

Wtyczka ma dwa ograniczenia. Po pierwsze działa wewnątrz WordPressa, więc przy bardzo dużych stronach wykonanie kopii może przekraczać limity czasu serwera i kończyć się niepełnym plikiem. Po drugie każda kolejna wtyczka obciąża stronę, o czym piszę szerzej w tekście o tym, jak sprawdzić, co spowalnia WordPressa. Kopie warto planować na godziny najmniejszego ruchu.

Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: ustawię kopie zapasowe i wykonam próbne odtworzenie strony.

Jak zrobić kopię ręcznie: pliki i baza danych?

Kopia ręczna nie wymaga żadnych dodatkowych narzędzi poza dostępem do serwera. Trwa najdłużej, ale daje pełną kontrolę i uczy, gdzie co leży. Uważam, że każdy właściciel strony powinien wykonać ją przynajmniej raz, choćby po to, żeby wiedzieć, czy ma komplet haseł.

Potrzebne są: dane dostępu do FTP lub do menedżera plików w panelu hostingu oraz dostęp do phpMyAdmin, czyli narzędzia do obsługi bazy danych, do którego wchodzi się zwykle z panelu hostingu. Zgodnie z kolejnością z dokumentacji zaczyna się od bazy, a kończy na plikach. Poniżej opisuję obie czynności osobno.

Eksport bazy danych w phpMyAdmin

Na jednym koncie hostingowym bywa kilka baz. Nazwę tej właściwej podaje plik wp-config.php w wierszu zaczynającym się od define( 'DB_NAME'. Warto to sprawdzić przed eksportem, aby nie zabezpieczyć bazy innej strony.

Dokumentacja WordPressa opisuje dwa tryby eksportu: szybki i niestandardowy. Nazwy podaję tak, jak w dokumentacji, czyli po angielsku. W panelu ustawionym na język polski mają one polskie odpowiedniki, a układ ekranu pozostaje ten sam.

1. Należy zalogować się do phpMyAdmin.
2. W oknie po lewej stronie trzeba wybrać bazę danych WordPressa.
3. W górnym pasku należy otworzyć zakładkę „Export”.
4. W trybie szybkim pozostawia się zaznaczoną opcję „Quick” i potwierdza przyciskiem „Go”. Plik z kopią bazy zostanie pobrany na komputer.
5. Jeżeli potrzebne są dodatkowe ustawienia, zamiast „Quick” wybiera się „Custom”. W części z tabelami powinny być zaznaczone wszystkie tabele, a gdy baza jest wspólna dla kilku stron, tylko te z przedrostkiem danej instalacji WordPressa.
6. W części „Output” w polu „Compression” można wybrać „zipped” lub „gzipped”, co zmniejsza plik. Format powinien pozostać ustawiony na SQL.
7. W opcjach tworzenia obiektów dokumentacja zaleca zaznaczenie dodawania instrukcji DROP przed tworzeniem tabel. Dzięki temu import nadpisze tabele, które już istnieją.
8. Na dole okna należy potwierdzić przyciskiem „Go” i zachować pobrany plik.

Po pobraniu trzeba sprawdzić dwie rzeczy. Plik nie może mieć rozmiaru zerowego ani kilku kilobajtów przy stronie z setkami wpisów. Po otwarciu w edytorze tekstu na końcu pliku powinny być widoczne dane ostatnich tabel, a nie komunikat błędu lub urwany wiersz.

Dokumentacja zastrzega, że phpMyAdmin nie radzi sobie z dużymi bazami. Jeżeli eksport się urywa, pozostają trzy drogi: kopia bazy pobrana z panelu hostingu, wtyczka albo eksport z wiersza poleceń narzędziem mysqldump, który najlepiej zlecić administratorowi serwera.

Pobranie plików przez FTP lub menedżera plików

Pliki można pobrać programem FTP albo spakować i pobrać w menedżerze plików panelu hostingu. Druga droga jest zwykle szybsza, bo zamiast tysięcy małych plików przesyła się jedno archiwum.

1. Należy połączyć się z serwerem programem FTP, najlepiej przez połączenie szyfrowane (SFTP lub FTPS), jeżeli hosting je udostępnia.
2. Trzeba odszukać katalog strony. To ten, w którym widać katalogi wp-admin, wp-content i wp-includes oraz plik wp-config.php.
3. W programie FTP należy włączyć pokazywanie plików ukrytych. Bez tego plik .htaccess, którego nazwa zaczyna się od kropki, może nie być widoczny i nie trafi do kopii.
4. Całą zawartość katalogu strony pobiera się do pustego folderu na komputerze.
5. Po zakończeniu trzeba przejrzeć listę nieudanych transferów w programie FTP i ponowić pobieranie plików, które się nie przesłały.
6. Pobrany folder należy spakować do jednego archiwum razem z plikiem bazy i nadać mu nazwę z adresem strony oraz dniem wykonania kopii.

W menedżerze plików czynność jest krótsza: zaznacza się katalog strony, wybiera funkcję pakowania do archiwum, pobiera gotowy plik na komputer, a następnie usuwa archiwum z serwera. Ten ostatni krok jest ważny. Archiwum z całą stroną i plikiem wp-config.php, pozostawione w publicznym katalogu, może zostać pobrane przez osobę niepowołaną.

Gdzie trzymać kopie i ile wersji zachować?

Podstawowa zasada brzmi: kopia nie może leżeć wyłącznie tam, gdzie strona. Awaria dysku, włamanie na konto, przypadkowe usunięcie katalogu albo wygaśnięcie nieopłaconej usługi zabierają wtedy stronę i kopię jednocześnie.

Dokumentacja WordPressa zaleca przechowywanie co najmniej trzech kopii w różnych miejscach i na różnych nośnikach. W firmie sprawdza się prosty układ: jedna kopia u dostawcy hostingu, druga na dysku w chmurze, trzecia na komputerze lub dysku zewnętrznym w biurze.

Równie ważna jest liczba wersji. Jedna, stale nadpisywana kopia nie pomoże, gdy problem zostanie zauważony po czasie. Zainfekowana strona albo treści usunięte przez pomyłkę często wychodzą na jaw dopiero po kilku tygodniach, a wtedy najnowsza kopia zawiera już ten sam problem.

Radzę trzymać kilka ostatnich kopii z bieżącego rytmu oraz po jednej starszej z poprzednich miesięcy. Ile dokładnie, zależy od miejsca na dysku i wielkości strony. Ważne, aby zawsze dało się cofnąć zarówno o jeden dzień, jak i o kilka tygodni.

Plik kopii zawiera dane logowania do bazy, a w sklepie także dane klientów. Dostęp do miejsca, w którym leżą kopie, powinny mieć wyłącznie osoby upoważnione, a konto dysku w chmurze powinno być zabezpieczone silnym hasłem i logowaniem dwuetapowym. Archiwum przechowywane na nośniku przenośnym warto zaszyfrować hasłem.

Jak często robić kopię zapasową?

Częstotliwość wynika z jednego pytania: ile pracy lub danych firma może stracić bez szkody. Kopia sprzed tygodnia oznacza, że w razie awarii przepada wszystko, co pojawiło się na stronie przez ostatni tydzień.

Strona wizytówka, na której treść zmienia się kilka razy w roku, nie potrzebuje kopii codziennej. Wystarczy kopia raz w tygodniu lub nawet rzadziej, pod warunkiem że dodatkowa kopia powstaje po każdej większej zmianie treści i przed każdą aktualizacją.

Blog lub serwis z nowymi wpisami kilka razy w tygodniu, z komentarzami albo formularzami zapisującymi zgłoszenia do bazy, powinien mieć kopię bazy codziennie. Pliki zmieniają się tu rzadziej, więc ich kopia może powstawać raz w tygodniu.

Wiele wtyczek i paneli pozwala ustawić te dwa rytmy osobno i warto z tego korzystać. Baza danych jest mała i zmienia się stale. Pliki są duże i zmieniają się głównie wtedy, gdy przybywa zdjęć albo aktualizowane są wtyczki i motyw.

Jak sprawdzić kopię, czyli próbne odtworzenie krok po kroku

To najważniejsza część całej instrukcji. Kopię sprawdza się w jeden sposób: odtwarzając z niej stronę w osobnym miejscu, bez dotykania strony działającej. Dopiero wtedy wiadomo, czy pliki są kompletne, czy baza się importuje i ile czasu zajmuje cała operacja.

Próbę przeprowadza się na kopii testowej. Może to być subdomena założona w panelu hostingu, na przykład test.nazwafirmy.pl, z własnym katalogiem i własną bazą danych. Niektóre firmy hostingowe mają gotową funkcję tworzenia kopii testowej strony, ale do sprawdzenia kopii zapasowej lepiej odtworzyć ją ręcznie, z tych samych plików, które miałyby ratować stronę po awarii.

Przygotowanie miejsca na kopię testową

W panelu hostingu zakłada się subdomenę z osobnym katalogiem oraz nową, pustą bazę danych z własnym użytkownikiem i hasłem. Nazwę bazy, nazwę użytkownika, hasło i adres serwera bazy trzeba zanotować, ponieważ będą potrzebne za chwilę.

Najpoważniejszy błąd na tym etapie to użycie bazy działającej strony. Import z instrukcjami DROP nadpisuje istniejące tabele, więc pomyłka w wyborze bazy cofa prawdziwą stronę do stanu z kopii. Baza testowa musi być osobna i mieć nazwę, której nie da się pomylić.

Odtworzenie plików i bazy

1. Zawartość archiwum z plikami strony wgrywa się do katalogu subdomeny testowej przez FTP lub menedżera plików.
2. W phpMyAdmin należy wybrać z listy po lewej stronie nową, pustą bazę testową i upewnić się, że to właśnie jej nazwa widnieje u góry ekranu.
3. Trzeba otworzyć zakładkę „Import”, wskazać plik kopii bazy z komputera, pozostawić format SQL i potwierdzić przyciskiem na dole strony. Po zakończeniu na liście po lewej powinny pojawić się tabele WordPressa.
4. W katalogu testowym należy otworzyć do edycji plik wp-config.php i w wierszach DB_NAME, DB_USER, DB_PASSWORD oraz DB_HOST wpisać dane bazy testowej.
5. W tym samym pliku, powyżej wiersza z komentarzem kończącym część do edycji, dopisuje się dwa wiersze z adresem kopii testowej, podane niżej.
6. Należy otworzyć adres testowy w przeglądarce i zalogować się do kokpitu tym samym loginem i hasłem, co na stronie działającej.
7. W kokpicie kopii testowej, w menu „Ustawienia” i dalej „Czytanie”, trzeba zaznaczyć pole „Proś wyszukiwarki o nieindeksowanie tej witryny” i zachować zmiany.

Wiersze do dopisania w pliku wp-config.php kopii testowej, zgodne z dokumentacją WordPressa, z własnym adresem w miejscu przykładowego:

define( 'WP_HOME', 'https://test.nazwafirmy.pl' );
define( 'WP_SITEURL', 'https://test.nazwafirmy.pl' );

Bez tych dwóch wierszy WordPress odczyta adres z bazy danych i przekieruje przeglądarkę na stronę działającą. Dokumentacja zaznacza, że po ich dopisaniu adresów nie da się już zmienić na ekranie ustawień ogólnych, co na kopii testowej nie przeszkadza.

Sama opcja zniechęcania wyszukiwarek to za mało, by mieć pewność, że kopia testowa nie trafi do wyników Google. Pewniejsze jest zabezpieczenie katalogu testowego hasłem w panelu hostingu. Po zakończeniu próby kopię testową wraz z jej bazą najlepiej usunąć.

Co sprawdzić na odtworzonej stronie?

Fakt, że strona główna się wyświetla, niczego jeszcze nie dowodzi. Trzeba przejść przez listę:

• strona główna, kilka podstron i kilka wpisów otwierają się bez błędów, a adres w przeglądarce pozostaje adresem testowym,
• zdjęcia w najnowszych i w najstarszych wpisach są widoczne, a biblioteka mediów w kokpicie pokazuje miniatury,
• logowanie do kokpitu działa, a lista wpisów, stron i użytkowników zgadza się ze stanem z dnia wykonania kopii,
• na liście wtyczek są wszystkie wtyczki ze strony działającej i żadna nie zgłasza błędu,
• w sklepie widać produkty, a ostatnie zamówienie na liście pochodzi z dnia wykonania kopii.

Część zdjęć i odnośników w treści nadal może prowadzić do adresu strony działającej, ponieważ adresy są zapisane w bazie. Do oceny kopii to nie przeszkadza. Pełna zamiana adresów w bazie jest potrzebna dopiero przy prawdziwym przenoszeniu strony i wymaga narzędzia, które nie uszkodzi danych. Opisuję to w tekście o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google.

Co zrobić, gdy próba się nie powiedzie?

Komunikat o błędzie połączenia z bazą danych oznacza prawie zawsze literówkę w jednym z czterech wierszy pliku wp-config.php albo brak uprawnień użytkownika do bazy testowej. Należy porównać wpisane dane z tymi z panelu hostingu, znak po znaku.

Jeżeli przeglądarka przenosi na stronę działającą, trzeba sprawdzić, czy wiersze z adresem testowym zostały dopisane we właściwym miejscu i czy plik .htaccess nie zawiera przekierowania na główną domenę. Jeżeli nie widać żadnych zdjęć, w kopii plików najpewniej brakuje katalogu uploads lub jego części.

Przerwany import bazy oznacza zwykle plik zbyt duży dla phpMyAdmin albo eksport urwany w połowie. W obu przypadkach wniosek jest ten sam i bardzo cenny: dotychczasowa metoda tworzenia kopii nie działa i trzeba ją zmienić teraz, a nie w dniu awarii. Próbę radzę powtarzać co kilka miesięcy oraz po każdej zmianie hostingu lub sposobu wykonywania kopii.

Dlaczego kopia jest potrzebna przed każdą aktualizacją?

Aktualizacja WordPressa, wtyczki lub motywu zmienia pliki, a czasem także strukturę bazy danych. Większość przebiega bez problemów, ale gdy coś pójdzie źle, wycofanie zmian bez kopii bywa bardzo trudne. Dokumentacja WordPressa mówi jednoznacznie: kopię bazy robi się regularnie i zawsze przed aktualizacją.

Kopia z nocnego harmonogramu nie wystarcza, jeżeli od nocy na stronie przybyły zamówienia, zgłoszenia lub wpisy. Potrzebna jest świeża kopia wykonana tuż przed aktualizacją.

1. Tuż przed aktualizacją należy wykonać kopię bazy danych i plików: na żądanie w panelu hostingu, wtyczką lub ręcznie.
2. Trzeba potwierdzić, że kopia się zakończyła i że plik znajduje się poza serwerem strony.
3. Aktualizacje wykonuje się pojedynczo, a nie wszystkie naraz. Po każdej należy otworzyć stronę główną, jedną podstronę, formularz kontaktowy, a w sklepie także koszyk.
4. Jeżeli po którejś aktualizacji pojawia się błąd, wiadomo dokładnie, która go spowodowała. Wtedy przywraca się kopię albo wyłącza daną wtyczkę i zgłasza problem jej autorowi.
5. Kopię sprzed aktualizacji przechowuje się jeszcze przez kilka dni, ponieważ część błędów wychodzi na jaw dopiero w trakcie zwykłej pracy strony.

Większe zmiany, takie jak nowa wersja motywu, zmiana wersji PHP na serwerze albo duża aktualizacja wtyczki sklepowej, bezpieczniej jest najpierw wykonać na kopii testowej. To ta sama kopia, która służy do próbnego odtwarzania, więc jedna czynność służy dwóm celom.

Sklep internetowy i zamówienia: na co uważać?

W sklepie baza danych zmienia się z każdym zamówieniem, każdą płatnością i każdą zmianą stanu magazynowego. Odtworzenie bazy z kopii sprzed kilku godzin oznacza utratę wszystkich zamówień złożonych po jej wykonaniu, mimo że klienci za nie zapłacili.

Z tego wynikają trzy zasady. Kopia bazy sklepu powinna powstawać częściej niż raz na dobę, w rytmie dopasowanym do liczby zamówień. Aktualizacje wykonuje się w godzinach najmniejszego ruchu, po świeżej kopii. Przywracanie całej bazy na działającym sklepie jest ostatecznością i wymaga wcześniejszego zabezpieczenia bieżącego stanu.

Jeżeli sklep trzeba cofnąć do kopii, najpierw eksportuje się aktualną bazę, nawet uszkodzoną, oraz listę zamówień złożonych od czasu wykonania kopii. Pomocne są też powiadomienia e-mail o nowych zamówieniach i historia transakcji u operatora płatności: pozwalają odtworzyć brakujące zamówienia ręcznie.

Na kopii testowej sklepu trzeba wyłączyć wszystko, co kontaktuje się ze światem: wysyłkę wiadomości do klientów, połączenia z operatorem płatności, firmami kurierskimi, systemem magazynowym i programem do faktur. W przeciwnym razie kopia testowa może wysłać do prawdziwych klientów wiadomości albo zmienić stany w zewnętrznych systemach.

Kopia sklepu zawiera dane osobowe klientów. Miejsce jej przechowywania, krąg osób z dostępem i czas trzymania starych wersji powinny być zgodne z zasadami ochrony danych przyjętymi w firmie. Kopii testowej z danymi klientów nie należy zostawiać w sieci dłużej, niż trwa próba.

Jakich błędów unikać?

Kopia tylko na tym samym serwerze

To błąd najczęstszy i najgroźniejszy. Wtyczka domyślnie zapisuje kopie w katalogu strony, a właściciel uznaje sprawę za zamkniętą. Wystarczy awaria serwera albo włamanie, aby strona i wszystkie kopie przepadły razem. Naprawa polega na ustawieniu wysyłki do zewnętrznego miejsca i sprawdzeniu, że pliki naprawdę tam trafiają.

Kopia nigdy niesprawdzona

Komunikat „kopia wykonana” mówi tylko, że powstał plik. Nie mówi, czy plik jest kompletny i czy da się z niego odtworzyć stronę. Jedynym sprawdzianem jest próbne odtworzenie opisane wyżej. Kto wykona je raz, ten w dniu awarii działa według znanej listy czynności, a nie pod presją czasu.

Kopia bez bazy danych

Katalog pobrany przez FTP wygląda jak cała strona, ale nie zawiera ani jednego wpisu, ustawienia czy zamówienia. Po wgraniu takich plików na pusty serwer WordPress pokaże błąd połączenia z bazą albo instalator nowej, pustej strony. Każda kopia musi składać się z dwóch części i obie trzeba widzieć na własne oczy: archiwum plików i plik bazy.

Inne częste pomyłki

Do tej samej grupy należą: jedna nadpisywana wersja kopii, archiwum z całą stroną pozostawione w publicznym katalogu serwera, pominięty plik .htaccess, brak dostępu do haseł potrzebnych do odtworzenia oraz poleganie wyłącznie na zapewnieniu dostawcy hostingu. Stan kopii radzę sprawdzać przy okazji każdego przeglądu technicznego serwisu, podobnie jak elementy opisane w tekście o tym, co sprawdzić w audycie SEO strony. Długa niedostępność serwisu szkodzi również jego widoczności w wyszukiwarce.

Najczęstsze pytania

Czy kopia robiona przez hosting wystarczy?

Jako jedyne zabezpieczenie nie wystarczy. Kopie hostingu są wygodne i warto z nich korzystać, ale są przechowywane przez ograniczony czas, znikają razem z kontem i nie zawsze da się je przywrócić samodzielnie. Potrzebna jest co najmniej jedna własna kopia poza infrastrukturą dostawcy.

Czy trzeba kopiować pliki samego WordPressa?

Nie jest to konieczne, ponieważ pliki WordPressa da się pobrać ponownie z oficjalnej strony projektu. Niezbędne są: baza danych, katalog wp-content, plik wp-config.php i plik .htaccess. Mimo to kopia całego katalogu jest wygodniejsza, bo skraca odtwarzanie i eliminuje ryzyko niezgodności wersji.

Ile czasu trwa odtworzenie strony z kopii?

Zależy to od wielkości strony, szybkości łącza i wprawy osoby, która to robi. Mała strona firmowa wraca do działania w czasie liczonym w minutach, a duży sklep z tysiącami zdjęć potrzebuje wyraźnie więcej. Rzetelną odpowiedź dla konkretnej strony daje tylko próbne odtworzenie z pomiarem czasu.

Czy eksport z menu „Narzędzia” w kokpicie jest kopią zapasową?

Nie. Narzędzie eksportu w kokpicie tworzy plik z treścią wpisów, stron i komentarzy, przeznaczony do przenoszenia treści między stronami. Nie obejmuje ustawień, wtyczek, motywu ani plików z biblioteki mediów, więc nie pozwala odtworzyć całej strony.

Co zrobić, gdy plik bazy jest za duży na import w phpMyAdmin?

Limit rozmiaru przesyłanego pliku jest widoczny na ekranie importu. Pomaga eksport z kompresją, a gdy to nie wystarcza, import wykonuje się z wiersza poleceń albo przez pomoc techniczną hostingu. Dokumentacja WordPressa sama zaznacza, że phpMyAdmin nie jest narzędziem do dużych baz.

Czy kopie można trzymać na poczcie e-mail?

Dla małej bazy danych jest to rozwiązanie awaryjne, ale nie polecam go jako stałego. Skrzynki mają limity wielkości załączników, a plik kopii zawiera dane logowania i często dane osobowe. Lepszy jest dysk w chmurze z kontrolą dostępu i logowaniem dwuetapowym.

Czy przywrócenie kopii usuwa wirusa ze strony?

Tylko wtedy, gdy kopia pochodzi sprzed infekcji, a po jej przywróceniu zostanie zamknięta droga, którą doszło do włamania: nieaktualna wtyczka, słabe hasło lub przejęte konto FTP. W przeciwnym razie strona zostanie zainfekowana ponownie. Dlatego potrzebne są starsze wersje kopii, a nie tylko najnowsza.

Kto w firmie powinien odpowiadać za kopie?

Jedna, wskazana z imienia i nazwiska osoba, która wie, gdzie leżą kopie, ma dostęp do haseł i potrafi przeprowadzić odtworzenie. Opis miejsc przechowywania i czynności odtwarzania powinien być spisany i dostępny także dla drugiej osoby. Kopia, o której wie tylko ktoś, kto właśnie jest na urlopie, w dniu awarii nie pomoże.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: ustawię kopie zapasowe i wykonam próbne odtworzenie strony.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.