Problemy z kopią zapasową WordPress – backup, restore, narzędzia 2026

Zainstalowany plugin to nie jest backup. To dopiero intencja backupu. Różnica wychodzi dopiero w dniu, kiedy trzeba coś przywrócić – i wtedy zaczynają się niespodzianki.

W naszej praktyce agencyjnej, kiedy klient trafia do nas po awarii, scenariusz wygląda najczęściej tak: UpdraftPlus pokazuje zielone Ostatni backup: wczoraj, ale archiwum ma 200 kB zamiast kilkuset MB. Albo paczka jest kompletna, ale nie ma w niej bazy danych. Albo backup siedzi na serwerze w tym samym katalogu co strona – i po włamaniu zaszyfrowały go te same boty, które zaszyfrowały resztę.

Dlaczego to się dzieje tak często:

• Backup nie jest nigdy testowany – plugin mówi sukces, więc zakładamy, że faktycznie sukces
• Przechowywanie tylko lokalnie, w `/wp-content/updraft/` – czyli tam, gdzie pierwsze padnie przy problemach z serwerem
• Domyślne ustawienia pluginów zapisują tylko pliki, bez bazy danych (albo odwrotnie)
• Brak monitoringu – nikt nie dostaje maila, kiedy backup nie wykonał się 3 dni z rzędu
• Zaufanie do jednego źródła, bez dublowania (tylko plugin albo tylko hosting)

To prowadzi do fałszywego poczucia bezpieczeństwa – największego wroga w dyskusji o danych. Jeśli nie widziałeś na własne oczy, jak Twój backup działa w praktyce, zakładaj, że nie działa. Więcej o prewencji w problemy z aktualizacjami WordPress – połowa awarii zaczyna się od rutynowego update'u. Warto też zajrzeć do problemy z wydajnością WordPress, bo powolny serwer to pierwszy sygnał, że z backupami też może być krucho.

UpdraftPlus to najpopularniejszy plugin backupowy w Polsce – i jednocześnie źródło największej liczby zgłoszeń backup mi nie działa. W 95% przypadków przyczyna sprowadza się do jednej z sześciu rzeczy.

1. Brak miejsca na dysku serwera. Backup tworzy się w `/wp-content/updraft/` zanim pójdzie w cloud. Jeśli hosting ma 10 GB, a strona waży 4 GB, plugin nie skończy archiwizacji. Sprawdź w CloudPanel lub cPanel, ile miejsca zostało wolnego.

2. PHP timeout (`max_execution_time`). Domyślnie serwery dają 30-60 sekund na wykonanie skryptu. Backup 2 GB strony nie zmieści się w tym oknie. Rozwiązanie: zwiększ limit do 300 s w `php.ini` albo włącz w UpdraftPlus opcję Split archives every i ustaw 100-200 MB na paczkę.

3. Permissions na katalogu `/updraft/`. Jeśli folder nie ma praw 755 albo właściciela zgodnego z użytkownikiem PHP, plugin nie zapisze pliku. Diagnoza: `ls -la wp-content/updraft/`.

4. Zablokowany folder przez security plugin. Wordfence, iThemes Security, Solid Security czasem blokują zapis do `/backups/` uznając to za próbę malware'u. Sprawdź logi pluginu bezpieczeństwa.

5. Memory limit (`memory_limit`). Przy backupie bazy danych WordPress ładuje wiele rekordów do pamięci. 128 MB często nie wystarcza – ustaw 512 MB w `wp-config.php`: `define('WP_MEMORY_LIMIT', '512M');`.

6. Konflikt z innym pluginem backupowym. Dwa pluginy backupowe naraz potrafią się wzajemnie zablokować. Wybierz jeden i drugi wyłącz.

Jeśli UpdraftPlus nadal pada, włącz tryb debug w Ustawienia → UpdraftPlus → Expert Settings i sprawdź `/wp-content/updraft/log.*.txt` – tam widać, gdzie dokładnie skrypt się zatrzymał. Głębsze przyczyny problemów PHP opisaliśmy w problemy z hostingiem WordPress.

To jest zdradliwy scenariusz: plugin raportuje sukces, archiwum siedzi w `/wp-content/updraft/`, ale do Google Drive nie leci już od dwóch miesięcy. Pierwszy sygnał, że coś jest nie tak, dostajesz w dniu, kiedy serwer pada i okazuje się, że cloud jest pusty.

Google Drive – wygasły OAuth token. Google co jakiś czas wymaga ponownej autoryzacji. Kiedy token wygasa, UpdraftPlus pisze w logu Authentication failed, ale e-maila o tym nie dostajesz, jeśli nie włączyłeś powiadomień. Rozwiązanie: Ustawienia → UpdraftPlus → Settings → Google Drive → kliknij Reauthenticate.

Dropbox API – przekroczony limit. Dropbox free to 2 GB, kiedy zapełni się w 100%, nowe pliki nie lecą. Dodatkowo Dropbox API ma limit zapytań – przy dużej częstotliwości backupu plugin dostaje `429 Too Many Requests`.

Amazon S3 / S3-compatible – bucket permissions. Niewłaściwa polityka IAM albo bucket ustawiony jako private bez właściwego klucza powoduje błąd `403 Forbidden`. Test w konsoli AWS CLI: `aws s3 cp test.txt s3://twoj-bucket/` – jeśli działa z CLI, ustawienia w pluginie są złe.

OneDrive, pCloud, Backblaze B2 – te same klasy problemów co wyżej. Backblaze B2 jest tańsze (~$6/TB/mies) i popularne w 2026.

Checklista diagnostyczna:

1. Sprawdź datę ostatniego pliku w cloud – czy zgadza się z ostatnim sukcesem w panelu pluginu
2. Przeczytaj `/wp-content/updraft/log.*.txt` – szukaj słów `auth`, `403`, `401`, `timeout`
3. Wykonaj ręczny backup (przycisk Backup Now) i patrz na progres na żywo
4. Jeśli wysyłka pada w 50% – to limit cloudu; jeśli na starcie – to auth

Na co zwrócić uwagę: ustaw w UpdraftPlus mailowe powiadomienia o błędach (Settings → Reporting). Bez tego o awarii dowiesz się dopiero, gdy strona padnie. Problem cloudu często zahacza też o problemy z SSL i certyfikatami – wygasły certyfikat na endpointach API potrafi wywalić cały transfer.

Kliknąłem Restore, coś trwało pół godziny, a teraz strona pokazuje biały ekran albo błąd bazy." Znane? Przywracanie z backupu to osobny problem – bardzo często paczka jest w porządku, ale proces restore źle ją rozpakowuje.

Najczęstsze błędy przy restore:

• Error establishing a database connection – zwykle zła nazwa bazy, usera albo hasła w `wp-config.php` po restore. Backup zapisał `wp-config.php` ze starego serwera, a na nowym dane dostępowe są inne. Rozwiązanie: zaktualizuj `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_HOST` w `wp-config.php`.
• Biały ekran (White Screen of Death) – zwykle PHP fatal error. Włącz `WP_DEBUG` w `wp-config.php` i zobacz prawdziwy komunikat.
• Błąd serialized data – WordPress trzyma wiele danych (widgety, ustawienia motywu) jako serialized PHP objects. Zwykły find & replace stringów w bazie (na przykład przy zmianie domeny) psuje długości stringów w serializacji. Rozwiązanie: użyj narzędzia `WP-CLI search-replace` lub Better Search Replace, które rozumieją serialized data.
• Nieaktualne URL-e – po przywróceniu kopii na staging widzisz linki do domeny produkcyjnej. Naprawa: `wp search-replace 'https://stara.pl' 'https://staging.stara.pl' --all-tables`.
• 404 na wszystkich podstronach poza homepage – brak `.htaccess` albo nieaktualne permalinks. Wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij Zapisz.

Złoty standard restore:

1. Zawsze przywracaj na staging, nigdy bezpośrednio na produkcję
2. Zrób backup aktualnego złego stanu przed restorem – czasem trzeba wrócić
3. Po restorze sprawdź stronę jako zalogowany i niezalogowany, na desktop i mobile
4. Sprawdź, czy cron WordPress działa (wp-cron)
5. Przetestuj kluczowe funkcje: checkout w sklepie, formularz kontaktowy, logowanie

Więcej o specyficznych błędach bazy w problemy z bazy danych WordPress – większość tam opisanych procedur stosuje się też po restore. Jeśli po restore widzisz biały ekran śmierci, zacznij od włączenia `WP_DEBUG` – pełną procedurę opisaliśmy w problemy z pluginami WordPress.

Duplicator Pro to ulubione narzędzie agencji do migracji stron i przenoszenia między hostingami. Jednocześnie potrafi zrobić sporo problemów na dużych stronach.

PHP version mismatch. Duplicator generuje paczkę pod konkretną wersję PHP. Jeśli eksportujesz ze strony na PHP 8.2, a importujesz na hosting z PHP 7.4, instaler może się wywalić przy rozpakowywaniu. Sprawdź wersje przed migracją – w 2026 standardem jest PHP 8.2-8.3.

Duże strony (>2 GB). Na darmowym Duplicatorze limit to ~500 MB i skrypt timeout'uje. Duplicator Pro obsługuje multi-part archives, ale wymaga konfiguracji `Max Chunk Size` w ustawieniach. Dla stron >5 GB lepiej rozważyć backup przez WP-CLI lub rsync.

Błędy przy rozpakowywaniu na targecie. Najczęstsze:

• `ZipArchive not found` – PHP bez rozszerzenia ZIP, skontaktuj się z hostingiem
• `Max execution time exceeded` – zwiększ `max_execution_time` do 600 s
• `MySQL server has gone away` – zwiększ `max_allowed_packet` w MySQL do 256 MB
• `Out of memory` – zwiększ `memory_limit` w PHP do 512 MB

Hasła i klucze bezpieczeństwa. Duplicator generuje nowe salt keys w `wp-config.php` na targecie – to dobra praktyka, ale oznacza, że wszyscy zalogowani użytkownicy zostaną wylogowani. Poinformuj klienta przed migracją.

Pliki >100 MB w wp-content. Duplicator domyślnie pomija duże pliki. Jeśli masz wideo albo PDF-y 500 MB, zaznacz je w Large files albo przenoś osobno przez FTP/SFTP.

Dla migracji między hostingami warto też przeczytać problemy z migracją WordPress – tam szczegóły dotyczące DNS, SSL i propagacji. Jeśli Twoja strona pada na błąd 503 Service Unavailable, nie próbuj robić backupu na żywej witrynie – najpierw naprawa, potem kopia.

Jeden z najczęstszych i najbardziej bolesnych błędów: backup ma wp-content, ma motyw, ma pluginy, ale nie ma `.sql`. Klient mówi: mam kopię, a my patrzymy na paczkę i widzimy, że brakuje 90% wartości.

Co faktycznie siedzi tylko w bazie danych WordPress:

• Posty i strony (`wp_posts`) – cała treść, wszystkie wersje robocze, menu, produkty WooCommerce
• Ustawienia witryny (`wp_options`) – nazwa, adres, wszystkie ustawienia pluginów i motywu
• Użytkownicy i ich hasła (`wp_users`, `wp_usermeta`) – konta, role, capabilities
• Komentarze (`wp_comments`) – jeśli masz aktywną społeczność, to często największa wartość
• Metadane postów (`wp_postmeta`) – custom fields, ACF, dane SEO z Yoast/Rank Math
• Kategorie i tagi (`wp_terms`, `wp_term_relationships`) – cała taksonomia
• Zamówienia WooCommerce (`wp_wc_orders` w HPOS albo `wp_posts` w classic) – historia sprzedaży
• Transients i cron – tymczasowe dane, których faktycznie nie potrzebujesz z kopii

Backup tylko plików to jest zasadniczo backup motywu i pluginów. Treść, użytkowników, zamówienia – wszystko tracisz. Na sklepie WooCommerce z historią zamówień to oznacza, że po awarii wracasz do jak nowy.

Jak to zweryfikować:

1. Rozpakuj paczkę backupową lokalnie
2. Szukaj pliku `.sql` albo `.sql.gz` – jeśli nie ma, masz backup tylko plików
3. W UpdraftPlus sprawdź zakładkę Existing backups – każda paczka ma listę komponentów (Database, Plugins, Themes, Uploads, Others). Wszystkie pięć powinno być zielone.

Domyślne ustawienia większości pluginów backupują wszystko, ale po pierwszej konfiguracji warto zajrzeć i potwierdzić. Na stronach e-commerce (zobacz problemy z WooCommerce) backup bazy jest absolutnie krytyczny – każda godzina bez bazy to tracone zamówienia. Zajrzyj też do problemy z płatnościami online – tam wyjaśniamy, dlaczego restore bazy sklepu wymaga dodatkowej weryfikacji transakcji.

Pluginy backupowe to 80% przypadków. Pozostałe 20% – migracje dużych sklepów, strony z wyłączonym PHP exec, hostingi bez cron jobs – wymagają ręcznego backupu. Nie jest to skomplikowane, ale trzeba wiedzieć co robić.

Kiedy zamiast pluginu użyć manual backup:

• Strona >5 GB – pluginy często padają przy takich rozmiarach
• Migracja między hostingami z różnymi wersjami PHP/MySQL
• Full control nad procesem – backup zdejmujesz przed krytyczną operacją
• Strona kompletnie padła i nie ma dostępu do WP admin
• Hosting blokuje wykonywanie długich skryptów PHP

Backup plików przez SFTP (rsync/FileZilla):

Cała magia WordPressa siedzi w `/wp-content/`. Pliki z katalogu głównego (`wp-admin`, `wp-includes`) możesz w razie czego pobrać z WordPress.org.

# Przez rsync z lokalnej maszyny
rsync -avz -e ssh user@serwer:/sciezka/do/wp-content/ ./backup-wp-content/

Backup bazy przez phpMyAdmin:

1. Zaloguj się do phpMyAdmin (panel hostingu)
2. Wybierz bazę WordPressa z lewej listy
3. Kliknij zakładkę Eksport
4. Format: SQL, metoda: Szybki (Quick) lub Własny dla dużych baz
5. Zaznacz Add DROP TABLE jeśli backup ma nadpisywać istniejącą bazę
6. Pobierz plik `.sql` (dla baz >200 MB warto skompresować przez gzip)

Backup bazy przez SSH (większe bazy):

mysqldump -u user -p nazwa_bazy | gzip > backup-$(date +%Y%m%d).sql.gz

Metoda SSH jest o 10-20x szybsza niż phpMyAdmin na dużych bazach i nie ma ryzyka timeout browsera.

Restore:

• Pliki: wgraj przez SFTP do docelowego katalogu
• Baza: w phpMyAdmin zakładka Import → wybierz plik `.sql`; dla dużych baz `mysql -u user -p baza < backup.sql` przez SSH

Metoda ręczna jest niewygodna do regularnego użytku, ale absolutnie niezawodna – nie polega na żadnym pluginie, który może się zepsuć.

Branża IT wypracowała tę regułę kilkadziesiąt lat temu i nadal jest złotym standardem. Dla WordPressa wygląda to tak:

3 – Trzy kopie danych. Jedna to oryginał (działająca strona), dwie to kopie zapasowe. Jedna kopia to za mało, bo może paść razem z serwerem. Trzecia to ubezpieczenie na wypadek, gdyby druga okazała się uszkodzona.

2 – Dwa różne nośniki. Nie wszystkie kopie na tym samym dysku. W praktyce WordPress: backup lokalny na serwerze (szybki restore) plus backup w cloud (niezależny od serwera).

1 – Jedna kopia offsite. Fizycznie odseparowana od serwera produkcyjnego. Jeśli serwer padnie, ta kopia żyje.

Dla sklepów e-commerce dodajemy czwartą warstwę – backup bazy co godzinę. Stracić godzinę zamówień to mniej bolesne niż stracić cały dzień. Plugin WP Time Capsule robi incremental backup co kilka minut i jest tańszy od godzinnego UpdraftPlus.

Offsite oznacza: inna lokalizacja fizyczna albo przynajmniej inne konto u innego dostawcy. Backup na tym samym serwerze w katalogu `/backups/` to nie jest offsite – po włamaniu backup szyfruje się razem ze stroną.

Test restore. Reguła 3-2-1 bez regularnego testowania restore to złudzenie. Raz w miesiącu wybierz losowy backup i przywróć go na staging. Jeśli się nie udaje – wiesz o tym w spokojny dzień, a nie podczas awarii.

Ten schemat kosztuje ~30-50 zł miesięcznie na niewielką stronę (hosting z daily backup + UpdraftPlus Premium za $70/rok). Dla sklepu rozliczaj to w kontekście ryzyka: ile kosztuje godzina przestoju?

Scenariusz: strona zainfekowana, pluginy Wordfence alarmują, klienci widzą redirect na podejrzane URL-e. Pierwszy odruch: przywróćmy backup sprzed tygodnia. I tu pojawia się pytanie, o którym rzadko się myśli – czy backup sprzed tygodnia też już był zainfekowany?

Malware często siedzi w stronie miesiącami zanim da znać. Skaner wykrywa go dopiero, kiedy zaczyna działać agresywnie (redirecty, injection). Backup sprzed 7 dni może zawierać te same złośliwe pliki, tylko nieaktywne. Restore = powrót do zainfekowanego stanu.

Co zrobić przed przywróceniem backupu:

1. Data zero dnia infekcji. Sprawdź logi hostingu, GSC (alerty Security Issues), daty modyfikacji plików. Zwykle widać, kiedy malware wszedł.
2. Wybór backupu sprzed infekcji. Jeśli znasz datę infekcji, wybierz backup z dnia wcześniej. Retention 30-60 dni się wtedy opłaca.
3. File integrity check. Po wybraniu backupu rozpakuj go lokalnie i przeskanuj: Wordfence CLI, Sucuri SiteCheck, albo zwyczajne porównanie z czystą instalacją WordPress (`wp core verify-checksums`).
4. Porównanie hashy. `wp core verify-checksums --allow-root` porównuje pliki rdzenia z oficjalnymi sumami kontrolnymi. To samo dla pluginów: `wp plugin verify-checksums --all`.
5. Backup bazy też skanuj. Malware potrafi injectować JavaScript do `wp_options` (pole `siteurl`, `home`) albo do treści postów. Przejrzyj eksport bazy pod kątem `eval(`, `base64_decode(`, `