Aktualizacja „silnika”, motywu, wtyczek to jedna z podstawowych czynności serwisowych strony opartej na WordPressie. I jedna z tych, po których najłatwiej o awarię objawiającą się tym że np. niektóre elementy wizulane „rozjeżdżają się” i/lub pewne funkcje przestają działać.
Nie dlatego, że aktualizacje są złe. Dlatego, że kod jednej wtyczki może kolidować z kodem innej. Że motyw napisany dwa lata temu może nie współpracować z nową wersją WordPressa. Że na serwerze może brakować rozszerzenia PHP którego nowa wersja wymaga. Konsekwencje zmian w złożonym systemie bywają różne i mogą mieć szeroki zasięg. Nie zawsze wszystkie elementy są na te zmiany gotowe i zachowują kompatybilność. Kopia zapasowa to jedyna polisa, która pozwala niejako cofnąć czas i wrócić do stanu sprzed zmiany w ciągu kilku minut.
1. Dlaczego kopia PRZED aktualizacją, a nie po
Odpowiedź jest prosta: kopia zrobiona po aktualizacji, która coś zepsuła, jest kopią zepsutej strony – jest bezużyteczna.
Kopia zrobiona tuż przed aktualizacją to punkt przywrócenia – działająca strona, z działającą bazą danych, które możesz przywrócić gdyby po aktualizacji strona się „wysypała”.
Dodatkowo:
- Większość problemów po aktualizacji ujawnia się natychmiast lub w ciągu kilku godzin, ale skutki są de facto od razu, anwet jeśli ich nie widzisz.
- Hosting robi automatyczne kopie, ale zazwyczaj raz dziennie lub rzadziej i z doświadczenia wiem, że niestety nie można na nich polegać.
- Automatyczna kopia hostingu może nadpisać starą wersję (wykonaną przed problematyczną aktualizacją) nową (zepsutą) zanim zdążysz zareagować
2. Co powinna zawierać pełna kopia zapasowa
Pełna kopia to dwa elementy – oba są niezbędne:
Pliki – cała instalacja WordPressa: rdzeń systemu, motywy, wtyczki, zdjęcia i inne media, plik konfiguracyjny.
Baza danych – wszystkie treści: wpisy, strony, komentarze, ustawienia wtyczek, dane WooCommerce, użytkownicy. Bez bazy danych pliki to pusta skorupa.
Kopia tylko plików bez bazy danych, lub tylko bazy danych bez plików – to niepełna kopia, która nie pozwoli przywrócić działającej strony.
3. Gdzie przechowywać kopię i czego absolutnie unikać
Największy błąd: zostawienie kopii na tym samym serwerze co strona. Jeśli serwer padnie, zostanie zaatakowany lub pliki zostaną skasowane – tracisz stronę i kopię jednocześnie.
Zasada 3-2-1:
- 3 kopie łącznie
- na 2 różnych nośnikach/lokalizacjach
- z czego 1 poza serwerem (off-site)
W praktyce dla właściciela strony oznacza to: kopia pobrana na komputer + kopia na zewnętrznym dysku lub drugim nośniku fizycznym przechowywanym w innym miejscu. Dane w chmurze przestają być wyłącznie Twoje – serwer to nie jedyne miejsce na archiwum kopii, ale chmura zewnętrzna to nie rozwiązanie które warto rekomendować.
Gdzie przechowywać kopię na serwerze tymczasowo (zanim pobierzesz):
Jeśli Twój hosting na to pozwala – katalog jeden poziom wyżej niż public_html, czyli poza zasięgiem serwera WWW. Serwer nigdy tam nie zajrzy, więc pliki kopii nie są dostępne przez przeglądarkę – niezależnie od konfiguracji .htaccess. To dokładnie ta sama zasada co relokacja wp-config.php opisana w protokole T.A.R.C.Z.A.
Jeśli hosting nie pozwala na zapis poza public_html – kopia powinna trafić do folderu wewnątrz wp-content, zabezpieczonego plikiem .htaccess blokującym dostęp z zewnątrz. To słabsza ochrona, zależna od konfiguracji serwera, ale lepsza niż nic.
W obu przypadkach – oprócz kopii na serwerze pobierz kopię na swój komputer oraz nośnik zewnętrzny.
4. Nazewnictwo plików i folderów
Dobre nazewnictwo to oszczędność czasu gdy przywracasz stronę w stresie. Zła praktyka to pliki o nazwach backup.zip, kopia.tar.gz czy stara-strona – po tygodniu nie wiesz co jest czym.
Dobry schemat:
nazwa-domeny_kopia-zapasowa_RRRR-MM-DD_GG-MM-SS
Przykład:
jochymczyk-com_kopia-zapasowa_2026-07-05_14-30-00/
baza.sql.gz
pliki.tar.gz
info.txt
Kilka zasad:
- Data w formacie RRRR-MM-DD – sortuje się chronologicznie automatycznie.
- Nazwa domeny na początku – gdy masz kilka stron, od razu wiesz do której należy kopia.
- Czas (godzina i minuta) – gdy robisz kilka kopii tego samego dnia.
- Osobny plik info.txt lub przeczytaj_mnie.txt lub iread_me.txtz datą, obowiązkowo opisem powodu/okoliczności wykonania kopii, wersją strony (po której można ją odróżnić od wersji poprzednich) i listą zawartości – bezcenny gdy wracasz do kopii po tygodniu.
5. Jak często robić kopie
Nie ma jednej odpowiedzi – zależy od tego jak często zmienia się zawartość strony.
| Typ strony | Zalecana częstotliwość |
| Wizytówka firmowa (rzadko aktualizowana) | Przed każdą aktualizacją |
| Blog (nowe wpisy kilka razy w tygodniu) | Po każdym nowym wpisie |
| Sklep (nowe zamówienia codziennie) | Raz dziennie, baza danych nawet częściej |
| Portal z dużym ruchem i aktywnością użytkowników | Kilka razy dziennie |
Zawsze: kopia tuż przed każdą aktualizacją – WordPressa, wtyczki, motywu, bez wyjątków.
6. Metody tworzenia kopii zapasowych
Panel hostingu – najprościej i najszybciej
Większość hostingów oferuje własny system tworzenia kopii zapasowych dostępny z poziomu panelu administracyjnego serwera (cPanel, DirectAdmin, Plesk i inne). Zazwyczaj znajdziesz go pod nazwą „Backup and Restore”.
Działa na poziomie serwera – nie przez WordPress, więc działa nawet gdy WordPress jest zepsuty. Interfejs różni się między hostingami, więc jeśli nie możesz znaleźć odpowiedniej sekcji – zapytaj support hostingu.
Unikaj opcji zintegrowanego backupu (pliki + baza w jednym archiwum) – może nie działać poprawnie już na etapie tworzenia kopii, a przy przywracaniu ryzyko niepowodzenia jest jeszcze większe. Zamiast tego wykonaj dwie osobne kopie:
- Pliki – przez Backup and Restore wybierz i pobierz tylko katalog z domeną (czyli zawartość public_html)
- Baza danych – wyeksportuj przez narzędzie zarządzania bazami danych w panelu hostingu
Wady:
- Interfejs użytkownika różni się między hostingami.
- Nie zawsze możesz pobrać kopię bezpośrednio na dysk z poziomu panelu.
FTP + phpMyAdmin – ręcznie, zawsze działa
Metoda nie wymagająca żadnych dodatkowych narzędzi poza dostępem FTP i panelem hostingu.
Pliki: połącz się z serwerem przez klienta FTP (FileZilla, Cyberduck), zaznacz cały katalog główny strony i pobierz na dysk. W zależności od rozmiaru strony może to potrwać od kilku minut do kilku godzin.
Baza danych: zaloguj się do phpMyAdmin (np. bezpośrednio przez panel hostingu), wybierz bazę danych swojej strony, kliknij „Eksportuj” → metoda „Szybko” → format SQL → „Eksport”. Pobierz plik .sql.
Zalety:
- Zero zależności – działa zawsze, na każdym hostingu.
- Pełna kontrola nad tym co pobierasz.
Wady:
- Czasochłonne przy dużych stronach.
- Wymaga ręcznego kompresowania pobranych plików (jeśli chcesz zaoszczędzić miejsce).
- Łatwo zapomnieć o bazie albo o plikach.
- Wymaga odpowiedzniego skonfigurowania programu do połączeń ftp (agresywne ustawienia mogą wyzwalać reakcje obronne serwera – np. blokadę adresu ip z którego nastąpiło połączenie ftp).
Terminal (PuTTY / terminal w DirectAdmin)
Metoda dla osób z dostępem SSH (od ang. Secure Shell – Bezpieczna Powłoka, protokół sieciowy służący do zdalnego zarządzania komputerami i serwerami w trybie tekstowym) do serwera. Łączysz się przez PuTTY lub terminal wbudowany w panel hostingu i wpisujesz komendy bezpośrednio na serwerze. Działa poza limitami PHP, bez żadnych zależności od WordPressa.
Pliki:
tar -czf pliki_$(date +%Y-%m-%d_%H-%M-%S).tar.gz \
--exclude=wp-content/cache \
/sciezka/do/strony
Baza danych – do wyboru jedna z dwóch komend:
Przez WP-CLI (WordPress Command Line Interface, Interfejs Wiersza Poleceń WordPressa) – jeśli hosting udostępnia to narzędzie:
wp db export baza.sql --add-drop-table
Przez mysqldump – działa na każdym hostingu z dostępem SSH, niezależnie od WordPressa:
mysqldump --single-transaction --quick \
-u UZYTKOWNIK -pHASLO NAZWA_BAZY \
| gzip > baza_$(date +%Y-%m-%d_%H-%M-%S).sql.gz
Zalety:
- Działa nawet przy bardzo dużych bazach i plikach – bez limitów czasu wykonania PHP.
- Kompresja gzip w locie – mniejsze pliki bez zajmowania dodatkowego miejsca na dysku.
- Łatwe do zautomatyzowania przez crontab.
- Niezależne od WordPressa i jego wtyczek.
Wada:
- Wymaga dostępu SSH i podstawowej znajomości terminala.
Automatyzacja przez crontab – jeśli chcesz żeby kopia robiła się sama, dodaj wpis do crontab (crontab -e):
# Kopia codziennie o 3:00 w nocy
0 3 * * * mysqldump --single-transaction -u UZYTKOWNIK -pHASLO NAZWA_BAZY | gzip > /sciezka/backup/baza_$(date +%Y-%m-%d).sql.gz
Własna wtyczka – rozwiązanie szyte na miarę
Każda z powyższych metod ma swoje ograniczenia. Wtyczki backupowe z repozytorium WordPress mogą zawodzić, mają ograniczone wersje darmowe a ich płatne wersje nie zawsze są warte swojej ceny. Bywa, że przestają być rozwijane i wsperane lub chocaiżby sprawdzane i dostosowywane pod względem kompatybilności do aktualnych wersji Worpressa. Metody manualne wymagają pamiętania o wykonaniu kopii i czasu na jej zrobienie.
Alternatywa: własna wtyczka stworzona dokładnie pod potrzeby konkretnej strony.
Przykład z praktyki – wtyczka którą stworzyłem na własne potrzeby działa następująco:
- Jeden przycisk w panelu WordPress (Narzędzia → Kopia zapasowa).
- Automatycznie próbuje najlepszej dostępnej metody: najpierw mysqldump przez terminal (szybkie, bez limitów PHP), jeśli hosting na to nie pozwala – przełącza się na metodę PHP.
- To samo z plikami: najpierw tar przez terminal, jeśli niedostępny – ZipArchive w PHP.
- Wbudowane bezpieczniki weryfikacji: sprawdza czy archiwum da się w ogóle odczytać (uszkodzone archiwum jest wykrywane natychmiast), a następnie porównuje liczbę plików w archiwum z liczbą plików na serwerze. Różnica może być naturalna – wtyczka celowo pomija folder kopii zapasowych i cache, żeby nie pakować niepotrzebnych danych – dlatego alarm uruchamia się dopiero gdy brakuje więcej niż 10% plików. Dodatkowo porównuje rozmiar archiwum z rozmiarem katalogu – podejrzanie małe archiwum również generuje alert.
- Przechowuje kopię poza public_html jeśli hosting pozwala, w przeciwnym razie wewnątrz wp-content z zabezpieczeniem .htaccess.
- Każdy plik kopii ma uprawnienia 0600 – tylko właściciel może go odczytać.
- Nazewnictwo automatyczne: nazwa-domeny_kopia-zapasowa_RRRR-MM-DD_GG-MM-SS.
- Gotowe do pobrania bezpośrednio z panelu.
Zalety własnego rozwiązania:
- Robi dokładnie to czego potrzebujesz – nic więcej, nic mniej.
- Brak zachęt do płatnej wersji, brak zewnętrznych zależności.
- Możliwość dostosowania do specyfiki konkretnego serwera i projektu.
- Pełna wiedza o tym jak działa – brak niespodzianek.
Wada:
- Wymaga kogoś kto potrafi to napisać i przetestować.
7. Kompresja – co i dlaczego
Kopia bez kompresji zajmuje wielokrotnie więcej miejsca niż potrzeba. Standardy które warto znać:
| Format | Zastosowanie | Uwagi |
| .sql.gz | Baza danych | mysqldump pipe do gzip – szybkie i bardzo skuteczne |
| .tar.gz | Pliki | Natywny format Linuxa, najlepsza kompatybilność z serwerami |
| .zip | Pliki (gdy tar.gz niedostępny) | Obsługiwany wszędzie, wolniejszy od tar.gz |
Jaka jest różnica między .tar.gz a .zip?
Format .tar.gz to dwa kroki w jednym: tar pakuje pliki w jedno archiwum (bez kompresji), a gz (gzip) to archiwum następnie kompresuje. Stąd podwójne rozszerzenie. Format .zip robi obie rzeczy jednocześnie – pakuje i kompresuje w jednym kroku. W praktyce tar.gz osiąga lepszą kompresję i jest natywnym formatem serwerów Linux, dlatego jest preferowany. .zip to opcja awaryjna – gdy tar.gz z jakiegoś powodu nie jest dostępny.
Unikaj niekompresowanych archiwów .tar i nieskompresowanych plików .sql – zajmują niepotrzebnie dużo miejsca i wolniej się pobierają.
Czym jest tzw. pipe?
Znak | w komendach terminala to tzw. potok (ang. pipe – rura) – łączy dwa programy tak, że wynik działania pierwszego wpada bezpośrednio do drugiego, bez tworzenia pośrednich plików na dysku. W przypadku mysqldump … | gzip działa to następująco: mysqldump wyciąga dane z bazy i zamiast zapisać je do pliku – wlewa do rury. gzip odbiera surowy SQL z rury i na bieżąco go kompresuje. Dopiero skompresowany wynik ląduje w pliku .sql.gz.
Przy dużej bazie danych – np. sklepie z tysiącami zamówień – plik SQL może mieć kilka gigabajtów. Bez pipe musiałbyś najpierw zapisać te kilka GB na dysk, a potem skompresować – zajmując podwójne miejsce i podwójny czas. Pipe eliminuje pośredni krok: dane są kompresowane w locie, a na dysk trafia od razu gotowy, mały plik.
8. Jak przywrócić kopię zapasową
Przywrócenie to operacja odwrotna do tworzenia – i wymaga równie dużo uwagi.
Kolejność przywracania: zawsze najpierw pliki, potem baza danych. WordPress przy pierwszym uruchomieniu po przywróceniu plików próbuje połączyć się z bazą – jeśli baza jest już przywrócona i spójna z plikami, wszystko gra. Odwrotna kolejność może w pewnych sytuacjach doprowadzić do modyfikacji bazy przez niekompletną instalację.
Przywracanie przez panel hostingu (DirectAdmin, cPanel i inne)
Przed przywróceniem – usuń zawartość public_html w całości. Przywrócenie kopii na istniejące pliki nie usuwa tego czego w kopii nie ma. Jeśli od czasu wykonania kopii pojawiły się na serwerze złośliwe pliki (np. w wyniku ataku), stare wtyczki z lukami które już usunąłeś, albo pliki tymczasowe – wszystkie zostaną na serwerze po przywróceniu. Czyste public_html eliminuje to ryzyko całkowicie.
Pliki:
- Usuń zawartość public_html przez FTP lub menedżer plików hostingu.
- Przywróć przez opcję przywracania kopii w panelu hostingu.
Baza danych:
Zaimportuj przez narzędzie zarządzania bazami danych w panelu hostingu.
Przywracanie ręczne
Pliki:
Przed wgraniem plików usuń zawartość public_html. Przy metodzie FTP stare pliki których nie ma w kopii zostaną na serwerze jeśli tego nie zrobisz.
- Usuń zawartość public_html.
- Rozpakuj archiwum .tar.gz lub .zip.
- Wgraj przez FTP na serwer.
Baza danych:
- Zaloguj się do phpMyAdmin.
- Wybierz bazę danych strony.
- Kliknij „Importuj” i wskaż plik .sql (lub .sql.gz jeśli phpMyAdmin obsługuje kompresję).
- Potwierdź – istniejące tabele zostaną zastąpione (dobry dump zawiera DROP TABLE IF EXISTS przed każdą tabelą, więc nie ma ryzyka konfliktów).
Przywracanie przez terminal (PuTTY / terminal w DirectAdmin)
Pliki:
# Usuń stare pliki
rm -rf /sciezka/do/public_html/*
# Przywróć pliki
tar -xzf pliki.tar.gz -C /sciezka/do/strony
Baza danych – do wyboru jedna z dwóch komend:
Przez WP-CLI – jeśli hosting udostępnia to narzędzie:
wp db import baza.sql
Przez mysql – działa na każdym hostingu z dostępem SSH:
gunzip < baza.sql.gz | mysql -u UZYTKOWNIK -pHASLO NAZWA_BAZY
Na co zwrócić uwagę przy przywracaniu
- Adres URL – jeśli przywracasz stronę pod inną domenę lub środowisko, musisz zaktualizować adresy URL w bazie danych. Inaczej strona będzie próbowała ładować zasoby ze starej domeny.
- Wersja PHP – jeśli serwer docelowy ma inną wersję PHP niż oryginał, mogą pojawić się błędy zgodności.
- Uprawnienia plików – po przywróceniu sprawdź czy uprawnienia są poprawne (katalogi 755, pliki 644, wp-config.php 600 lub 400).
- Cache – wyczyść cache wtyczek, serwera i CDN (jeśli korzystasz) po przywróceniu.
- wp-config.php – jeśli przywracasz stronę na inny serwer, dane do bazy danych w wp-config.php wymagają aktualizacji
9. Najczęstsze błędy i czego unikać
Kopia tylko wtyczką backupową bez sprawdzenia czy działa – wtyczka może raportować sukces, a jednocześnie plik kopii może być uszkodzony lub niekompletny. Raz na jakiś czas pobierz kopię i sprawdź czy da się ją rozpakować.
Przechowywanie kopii tylko na serwerze – opisane wyżej. Jeśli serwer padnie, tracisz wszystko.
Kopia tylko bazy bez plików lub odwrotnie – niepełna kopia to żadna kopia.
Aktualizacja bez kopii bo „to tylko mała wtyczka” – większość poważnych awarii po aktualizacji zdarza się przy aktualizacjach które „na pewno nic nie zepsują”.
Pozostawienie starych kopii na serwerze – zajmują miejsce i stanowią potencjalny cel ataku jeśli nie są odpowiednio zabezpieczone. Pobierz, zarchiwizuj lokalnie na dysku zewnętrznym i usuń z serwera.
10. Podsumowanie
Kopia zapasowa przed aktualizacją to elementarna higiena zarządzania stroną. Każda metoda opisana w tym artykule jest lepsza niż brak kopii. Wybierz tę która pasuje do Twojego poziomu technicznego i rodzaju hostingu.
Jeśli chcesz mieć pewność, że kopia jest zrobiona dobrze i że w razie awarii da się ją sprawnie przywrócić – jestem do dyspozycji.
Twoja strona sprawia kłopoty?
Jeśli wolisz, żeby ktoś się tym zajął zamiast Ciebie – opisz swój projekt albo po prostu napisz. Odpowiadam konkretnie i bez zobowiązań.