Regularne wykonywanie kopii bezpieczeństwa naszego serwisu internetowego to podstawa. Aktualny backup plików i bazy danych pomoże nam gdy nasza strona zostanie zainfekowana, gdy aktualizacja WordPressa się nie powiedzie lub gdy sami przez nieuwagę zrobimy coś, przez co stracimy dane naszego serwisu.
Większość firm hostingowych wykonuje regularnie kopie danych swoich klientów, ale w sytuacji awaryjnej dobrze mieć również własną. Istnieje sporo wtyczek dla WordPressa pozwalających na wykonywanie backupów – ja od dłuższego czasu korzystam z darmowego rozszerzenia BackWPup i mogę je z czystym sumieniem polecić. To narzędzie proste w obsłudze, a jednocześnie posiadające olbrzymie możliwości.
BackWPup pozwala na automatyczne tworzenie kopii plików i bazy danych naszego serwisu, przy okazji wykonując kilka standardowych czynności konserwacyjnych (optymalizacja i sprawdzenie tabel w bazie danych, z opcjonalną naprawą tych uszkodzonych). Co jednak najciekawsze, utworzona kopia może zostać przesłana na inny serwer przez FTP lub skopiowana do jednej z obsługiwanych usług sieciowych, takich jak Dropbox, Amazon S3, Microsoft Azure, Rackspace Cloud Files i SugarSync. Dzięki temu możemy praktycznie za darmo przechowywać nasze kopie poza serwerem, na którym działa nasza strona.
Działanie wtyczki BackWPup opiera się na zadaniach (Jobs). Każde zadanie może wykonywać różne czynności i może być uruchamiane z różną częstotliwością i o różnym czasie. Dzięki temu możemy na przykład codziennie wykonywać kopię bazy danych i przesłanych przez nas plików (katalog wp-content), a raz w tygodniu kopię całości serwisu.
Aby utworzyć nowe zadanie wystarczy w panelu administracyjnym przejść do sekcji BackWPup → Add New Job.
Ekran edycji zadania podzielony jest na kilka sekcji, z których niektóre są widoczne w zależności od wybranych czynności, które mają być wykonane w trakcie tworzenia kopii, oraz usług, do których chcemy przesłać nasz backup (ja dla przykładu wybiorę Dropboksa, ponieważ jest to najpopularniejsza z dostępnych usług).
W zakładce General ustalamy podstawowe parametry naszego zadania. Poza nadaniem mu nazwy, musimy wybrać wybrać czynności, które zostaną wykonane podczas tworzenia kopii. Do wyboru mamy: Database backup (zrzut bazy danych), File backup (kopia plików), WordPress XML export (eksport wpisów do standardowego formatu WRX), Installed plugins list (lista zainstalowanych wtyczek), Optimize database tables (optymalizacja tabel w bazie danych) i Check database tables (sprawdzenie tabel).
Następnie określamy format nazwy plików, do których będą tworzone nasze kopie. Parametry ze znakiem % są zgodne ze składnią funkcji date().
W sekcji Job Destinations możemy wybrać miejsca, do których zostanie automatycznie przesłany plik zawierający kopię bezpieczeństwa. Można oczywiście wybrać kilka lokalizacji. Na potrzeby niniejszego opisu wybrałem Dropboksa.
Zakładka Schedule pozwala nam na ustalenie kiedy nasza kopia będzie wykonywana i w jaki sposób proces jej tworzenia będzie uruchamiany. Sposób uruchamiania zadania ustalamy za pomocą opcji Start job. Do wyboru mamy manually only (tylko ręcznie, z poziomu panelu administracyjnego), with WordPress cron (za pomocą wbudowanego w WordPressa mechanizmu automatycznego uruchamiania zadań) i with a link (uruchamianie ręczne za pomocą specjalnego linku).
Dla nieco bardziej zaawansowanych użytkowników dostępna jest również opcja uruchamiania zadań za pomocą narzędzia WP-CLI.
Do planowania automatycznego uruchamiania zadań służy specjalny interfejs, dostępny w wersji podstawowej (widocznej na zamieszczonym powyżej zrzucie ekranu) oraz zaawansowanej, dającej nieco większą kontrolę, ale bardziej skomplikowanej.
W podstawowej wersji interfejsu (wystarczającej dla większości użytkowników) dostępne mamy opcje wykonywania kopii co miesiąc (monthly), co tydzień (weekly), codziennie (daily) i co godzinę (hourly). Niezależnie od wybranej opcji, musimy ustalić godzinę, o której będzie uruchamiane zadanie tworzenia backupu. W opcji miesięcznej musimy dodatkowo ustalić dzień miesiąca, a w tygodniowej – dzień tygodnia.
Zakładka DB Backup zawiera opcje związane z kopią bazy danych. W sekcji Tables to backup znajduje się lista tabel, które będą archiwizowane. Znajdują się na niej wszystkie tabele znajdujące się w bazie danych, w której zainstalowany jest WordPress. Na zamieszczonym powyżej zrzucie ekranu widać zarówno tabele WordPressa, jak i tabele utworzone przez wtyczki (np. wp_searchmeter) i zewnętrzne skrypty (np. custom_activity). Znajdujące się nad listą przyciski pozwalają na szybkie wybranie wszystkich tabel (all) lub tylko tabel z prefiksem WordPressa w nazwie (wp_ – zostaną zaznaczone również tabele utworzone przez wtyczki). W polu Dumpfile name wpisujemy nazwę pliku, do którego zostanie zapisany zrzut bazy danych, z niżej możemy ustawić dla niego sposób kompresji (brak, GZip lub BZip2). Ponieważ plik ten zostanie umieszczony wewnątrz archiwum z kopią bezpieczeństwa, nie ma potrzeby jego kompresowania.
Zakładka Files pozwala nam na wybór katalogów, które zostaną dołączone do naszej kopii lub z niej wykluczone. Jak widać na powyższym screenie, możemy wybrać katalog, który ma być kopiowany (np. katalog główny, katalog wtyczek, katalog wp-content), a następnie wykluczyć z niego wybrane podkatalogi. Spokojnie możemy wykluczyć na przykład katalogi wp-includes czy wp-admin, ponieważ są one częścią WordPressa i w razie konieczności odtworzenia naszej strony możemy je skopiować z oryginalnej paczki instalacyjnej. To samo dotyczy wtyczek, które są dostępne w oficjalnym repozytorium WordPressa: możemy je wykluczyć z kopii, bo łatwo je później doinstalować.
Poniżej znajduje się pole Extra folders to backup, w którym możemy podać dodatkowe katalogi, które mają zostać umieszczone w kopii (każdy katalog w osobnej linii). Analogicznie w polu Exclude files/folders from backup możemy podać katalogi i pliki, które mają zostać wykluczone z kopii. Warto dodać, że należy podawać ścieżki bezwzględne (np. /home/wpzen/public_html/plik.html).
Opcja Don’t backup thumbnails from the site’s uploads folder pozwala na automatyczne wykluczenie z kopii miniatur wygenerowanych przez WordPressa. Jeśli nasza strona zawiera dużo obrazków, to włączenie tej opcji znacząco zmniejszy rozmiar archiwum z kopią bezpieczeństwa. Minusem jest to, że po odtworzeniu strony z kopii będziemy musieli jeszcze raz wygenerować miniatury (na przykład za pomocą wtyczki Regenerate Thumbnails).
Na samym dole znajduje się opcja Backup wp-config.php, robots.txt, .htaccess, .htpasswd and favicon.ico from root. Jeśli ją włączymy, w kopii znajdą się wymienione pliki. Problem jest tak naprawdę tylko z plikiem wp-config.php – gdy ktoś w jakiś sposób uzyska dostęp do naszej kopii, to w tym pliku znajdzie login i hasło do bazy danych naszego serwisu. A lepiej, żeby takie informacje nie były dostępne publicznie.
Zakładka XML Export pozwala na określenie jakie rodzaje treści będą eksportowane przy użyciu wbudowanego w WordPressa mechanizmu. Dołączony do naszej kopii plik z wyeksportowanymi wpisami i stronami może nam później posłużyć do odtworzenia treści serwisu bez konieczności importu kopii całej bazy danych. Możemy go również użyć do stworzenia lokalnej kopii naszej strony.
Opcja Items to export pozwala nam wybrać rodzaje treści, które będą eksportowane (wpisy, strony itp.). W polu XML Export file name określamy format nazwy pliku (parametry ze znakiem % są zgodne ze składnią funkcji date()). Na koniec możemy wybrać sposób kompresji pliku (podobnie jak w przypadku zrzutu bazy danych, jest to zbędne).
Zakładka DB Optimize zawiera trzy opcje mające wpływ na proces optymalizacji tabel, wykonywany podczas tworzenia kopii. Opcja Optimize WordPress Database tables only ogranicza optymalizację do tabel WordPressa – warto ją wyłączyć gdy w naszej bazie znajdują się tabele utworzone przez wtyczki lub zewnętrzne skrypty. Opcje Optimize MyISAM Tables i Optimize InnoDB Tables służą do włączenia optymalizacji odpowiednio tabel typu MyISAM i InnoDB – nie zagłębiając się w techniczne szczegóły polecam ich włączenie.
Optymalizacja powoduje między innymi przebudowę indeksów w bazie danych, dzięki którym dostęp do danych jest szybszy. Ma to sens tylko w przypadku, gdy usunęliśmy lub dodaliśmy dużą ilość danych – w przeciwnym razie optymalizacja nic nie zmieni (ale też nie zaszkodzi).
Zakładka DB Check zawiera dwie opcje dotyczące procesu sprawdzenia tabel podczas wykonywania kopii. Pierwsza z nich (Check WordPress database tables only) ogranicza sprawdzanie do tabel WordPressa. Włączenie drugiej (Try to repair defect table) spowoduje, że skrypt będzie próbował naprawić tabele, które podczas sprawdzania okazały się uszkodzone.
Tabele są najczęściej oznaczane jako uszkodzone gdy na dysku naszego serwera zabraknie miejsca do zapisania nowych danych lub gdy serwer bazy danych zostanie niepoprawnie wyłączony (na przykład w skutek awarii serwera). W znacznej większości przypadków wbudowana w MySQL funkcja REPAIR (wywoływana przez wtyczkę) potrafi sobie z takimi uszkodzeniami poradzić.
Ostatnia w przedstawianym przeze mnie przykładzie zakładka To: Dropbox służy do powiązania wtyczki z naszym kontem w serwisie Dropbox. Mamy do wyboru dwie metody autoryzacji: ograniczoną (Sandbox) i pełną (full Dropbox). W pierwszym przypadku wtyczka będzie miała dostęp tylko do specjalnego katalogu, w drugim – do wszystkich naszych katalogów. W polu Folder in Dropbox należy podać katalog, do którego będą kopiowane pliki z kopiami bezpieczeństwa (jeśli podany katalog nie istnieje, to zostanie utworzony). Ostatnia opcja Number of files to keep in folder pozwala na wprowadzenie liczby plików, które będą przechowywane w Dropboksie (wpisanie zera spowoduje, że wtyczka nie będzie automatycznie usuwać starszych plików).
Po skończonej konfiguracji należy zapisać nasze nowe zadanie klikając przycisk Save changes. Proces tworzenia kopii można w każdej chwili uruchomić ręcznie klikając link Run now znajdujący się pod każdym z dostępnych zadań. Jeśli ustawiliśmy automatyczne uruchamianie procesu, to na liście obok naszego zadania pojawi się data i godzina kolejnego uruchomienia. W każdej chwili możemy przejrzeć logi zakończonych procesów w sekcji BackWPup → Logs.
Ustawienia wtyczki
Na koniec zajrzyjmy jeszcze do ustawień wtyczki (BackWPup → Settings), gdzie znajdziemy między innymi kilka opcji przydatnych w razie problemów z tworzeniem kopii.
W zakładce General możemy włączyć lub wyłączyć menu wtyczki w pasku narzędzi (Show BackWPup links in admin bar), aktywować obliczanie wielkości folderów podczas edycji zadania na zakładce Files (Display folder sizes on Files tab if job edited – może to spowolnić wyświetlanie tej zakładki) oraz włączyć zabezpieczenia katalogów wtyczki (Protect BackWPup folders – radzę to zrobić).
Zakładka Jobs zawiera ustawienia dotyczące zadań. Opcja Maximum number of retries for job steps określa ile razy dany krok będzie powtarzany w przypadku niepowodzenia (3 jest wartością optymalną – jeśli krok nie zakończy się poprawnie po trzech próbach, to należy zidentyfikować przyczynę problemu, bo kolejne jego powtórzenia prawdopodobnie i tak nic nie dadzą).
Opcja Restart the job on every main step on a running job powoduje automatyczny restart zadania po każdy kroku. Jest to przydatne jeśli na serwerze mamy narzucony limit czasu dla pojedynczego procesu PHP, a zadanie nie jest w stanie w tym czasie się skończyć (np. gdy nasz serwis zawiera dużo treści). Podobny cel ma opcja Restart the job once a given number of Megabytes has been added to an archive, tyle że dotyczy ona etapu tworzenia archiwum. Podajemy tu liczbę megabajtów, po której dodaniu zadanie zostanie zrestartowane. Opcja Method for creating ZIP archive pozwala na wybór metody tworzenia archiwów ZIP. ZipArchive zużywa mniej pamięci, ale otwiera więcej plików jednocześnie. PclZip potrzebuje więcej pamięci, ale otwiera tylko dwa pliki na raz. Jeśli nie wiemy co wybrać, zawsze pozostaje opcja Auto.
Opcja Reduce server load służy do zmniejszenia obciążenia serwera podczas tworzenia kopii. W praktyce działa to tak, że skrypt co jakiś czas zatrzymuje się, tak aby nie obciążać zbytnio maszyny. Nie jest to moim zdaniem efektywna metoda, bo tak naprawdę rozkłada ona tylko obciążenie w czasie, ale w niektórych przypadkach może się sprawdzić.
Jak odtworzyć stronę z kopii bezpieczeństwa?
Niestety, wtyczka BackWPup nie posiada mechanizmu pozwalającego na automatyczne odtworzenie strony z kopii. Oznacza to, że będziemy musieli zrobić to ręcznie, kopiując wszystkie zawarte w archiwum pliki na serwer i importując plik ze zrzutem danych do naszej bazy danych (na przykład za pomocą narzędzia phpMyAdmin, udostępnianego przez większość firm hostingowych). Przyznaję, że nie jest to najwygodniejsza metoda, ale z kopii bezpieczeństwa korzysta się na tyle rzadko, że nie jest to jakiś wielki problem.
W przypadku konieczności odtworzenia naszej strony z kopii zawsze można poprosić o pomoc firmę hostingową, z której usług korzystamy – jestem pewien, że nie będzie z tym żadnych problemów.
Płatna wersja wtyczki BackWPup
Wtyczka BackWPup posiada również płatną, kosztującą 75 dolarów wersję Pro. Ma ona kilka dodatkowych funkcji, bez których można się spokojnie obejść, takich jak możliwość użycia własnych kluczy API dla Dropboksa i SugarSync, tworzenie kopii dodatkowych baz danych, import i eksport ustawień wtyczki i zadań, kreatory do testów systemu i tworzenia zadań oraz (co moim zdaniem najciekawsze) możliwość tworzenia kopii różnicowych (zawierających tylko te pliki, które się zmieniły) w usługach Dropbox, Rackspace Cloud Files, Amazon S3 i Microsoft Azure.