Jak wykonać kopię zapasową WordPress i zaplanować backupy

Pełna kopia WordPressa obejmuje pliki strony oraz bazę danych, ponieważ te składniki przechowują różne części serwisu. Pliki zawierają rdzeń WordPressa, motywy, wtyczki, przesłane media i konfigurację, a baza przechowuje między innymi wpisy, strony, użytkowników, ustawienia i dane sklepu.

Baza i pliki powinny pochodzić z tego samego okresu, aby ograniczyć rozbieżność między treścią a kodem strony. Eksport bazy zapisany jako `.sql`, `.gz` lub `.bz2` nie zawiera katalogu `wp-content`, a kopia katalogu strony nie obejmuje bazy MySQL lub MariaDB. WordPress wskazuje pliki i bazę jako dwa składniki potrzebne do pełnego odtworzenia typowej witryny.

Zestawienie pokazuje, które elementy zabezpieczyć i jaki może być skutek ich pominięcia. Poczta w domenie zwykle wymaga osobnego mechanizmu kopii u dostawcy hostingu.

Sprawdź, czy eksport bazy zawiera wszystkie tabele WordPressa oraz tabele dodane przez wtyczki, zwłaszcza sklepowe i formularzy. Eksport z menu `Narzędzia > Eksport` zapisuje wybrane treści w formacie WXR, ale nie kopiuje plików ani całej bazy.

Harmonogram backupu dopasuj do częstotliwości zmian, które trudno odtworzyć ręcznie, oraz do maksymalnej straty danych, którą firma może zaakceptować. Strona wizytówkowa aktualizowana sporadycznie ma inne potrzeby niż sklep przyjmujący zamówienia każdego dnia.

Podane częstotliwości są rekomendacją operacyjną KC Mobile, a nie wymaganiem WordPressa ani ustawowym minimum. Retencję, czyli czas przechowywania kopii, uzgodnij z osobą odpowiedzialną za stronę, uwzględniając pojemność, czas odtworzenia i sposób wykrywania problemów.

Tabela pomaga dobrać harmonogram do rodzaju strony i częstotliwości zmian. Dla sklepu częstsze kopie bazy mogą uzupełniać rzadsze kopie pełne plików.

W sklepie zamówienia powstają między planowymi kopiami, dlatego sam nocny backup może oznaczać utratę części nowych danych po awarii. Z naszych wdrożeń wynika, że harmonogram warto uzgodnić z realizacją zamówień i integracjami magazynowymi, żeby przywrócenie nie zdublowało ani nie pominęło operacji.

Ustal cel punktu odtworzenia (RPO), czyli maksymalny akceptowalny czas utraconych zmian, oraz cel czasu odtworzenia (RTO), czyli zakładany czas przywrócenia serwisu. RPO i RTO są parametrami planu działania firmy, a nie gwarantowanym czasem wykonania przez wtyczkę. Jeśli strona działa na WordPressie i wymaga uporządkowania konfiguracji oraz utrzymania, serwis i wdrożenie strony na WordPressie mogą objąć również przygotowanie techniczne zaplecza.

Ręczna kopia wymaga pobrania bazy danych oraz plików WordPressa, a następnie sprawdzenia, czy oba archiwa są kompletne. Przed aktualizacją lub migracją wykonaj backup i nie zapisuj jedynej kopii na tym samym koncie hostingowym.

Nazwę bazy i jej użytkownika znajdziesz w `wp-config.php`; nie udostępniaj zawartości pliku osobom nieuprawnionym. Zaloguj się do panelu hostingu, otwórz phpMyAdmin, wybierz właściwą bazę, uruchom eksport i zapisz plik SQL. Jeżeli panel oferuje kopie bazy, pobierz eksport dla tej samej witryny i sprawdź datę utworzenia.

Pobierz pliki przez menedżer plików hostingu lub SFTP. SFTP to szyfrowany protokół przesyłania plików; do pobrania możesz użyć klienta FileZilla i danych dostępowych od administratora hostingu. Uwzględnij katalog instalacji WordPressa, szczególnie `wp-content`, `wp-config.php` i reguły serwera, takie jak `.htaccess`, jeśli występują.

Nazwij zestaw tak, aby można było wybrać właściwą wersję, na przykład `sklep-2026-10-17-pliki.zip` oraz `sklep-2026-10-17-baza.sql.gz`. Nie umieszczaj w nazwie haseł ani danych klientów. Datę, nazwę witryny i wersję środowiska zapisuj w bezpiecznym rejestrze kopii.

Zweryfikuj, czy archiwum można otworzyć, plik bazy nie ma zerowego rozmiaru, a liczba plików jest wiarygodna względem witryny. Eksport bazy nie obejmuje wtyczek, motywów, multimediów ani `wp-config.php`, dlatego trzeba zabezpieczyć oba składniki osobno.

Automatyczny backup skonfiguruj tak, aby obejmował bazę i pliki, działał według harmonogramu oraz wysyłał kopię do niezależnej lokalizacji. Zadanie powinno raportować powodzenie i błąd, a wskazana osoba powinna monitorować te informacje.

Możesz użyć mechanizmu kopii hostingu albo wtyczki backupowej. W panelu hostingu sprawdź zakres danych, częstotliwość, retencję i sposób pobrania kopii. Przy wtyczce skonfiguruj osobno harmonogram bazy i plików, listę wykluczeń, lokalizację zdalną, limit miejsca oraz powiadomienia o błędach.

UpdraftPlus jest wtyczką do kopii WordPressa; jej konfigurację opisuje poradnik UpdraftPlus krok po kroku. Nazwy zakładek i dostępne lokalizacje zdalne zależą od wersji wtyczki i planu. Nie uruchamiaj kilku narzędzi tworzących równocześnie pełne kopie bez oceny obciążenia hostingu i zużycia miejsca.

Po zapisaniu harmonogramu uruchom kopię i przeanalizuj log zadania. Zapisz datę ostatniej udanej kopii, lokalizację, zakres danych i osobę odpowiedzialną za reakcję na błąd. Powiadomienie "sukces" potwierdza zakończenie zadania, ale nie dowodzi, że archiwum da się odtworzyć.

Przechowuj przynajmniej jedną kopię poza hostingiem produkcyjnym, aby awaria lub przejęcie konta nie objęły jednocześnie strony i backupu. Zasada 3-2-1 oznacza trzy kopie danych na dwóch rodzajach nośników, z jedną kopią poza główną lokalizacją.

Tabela porównuje typowe miejsca przechowywania pod względem niezależności od serwera strony, dostępności i ryzyka wspólnej awarii. Lokalizacja zdalna również wymaga zabezpieczenia konta oraz kontroli uprawnień do usuwania kopii.

Ogranicz dostęp do zdalnego magazynu do kont, które go potrzebują, włącz uwierzytelnianie wieloskładnikowe i nie używaj tych samych danych logowania co do hostingu. Kopie z danymi osobowymi przechowuj zgodnie z polityką bezpieczeństwa i retencji firmy. W razie potrzeby szyfruj archiwa przed przekazaniem do lokalizacji zewnętrznej.

WordPress wskazuje możliwość przechowywania kopii zarówno na serwerze hosta, jak i na komputerze. W firmie warto rozszerzyć taki układ o odrębne konto zdalne. Kopia na tym samym koncie co strona pomaga przy prostym błędzie, ale nie chroni przed utratą całego konta.

Kopia nadaje się do odtworzenia dopiero po sprawdzeniu jej zawartości i udanym teście na odizolowanym środowisku. Rozmiar archiwum i komunikat wtyczki nie potwierdzają, że strona po przywróceniu uruchomi się prawidłowo.

Zweryfikuj datę, nazwę domeny, zestaw plików i bazę, a następnie otwórz archiwum lub użyj narzędzia do jego kontroli. W pliku bazy sprawdź obecność tabel i brak błędu eksportu. Porównaj czas utworzenia kopii plików i bazy, by nie odtwarzać niespójnych wersji.

Test wykonuj na stagingu, czyli prywatnej kopii strony odseparowanej od produkcji. Ogranicz dostęp, wyłącz wysyłkę e-maili i integracje, które mogłyby wykonać rzeczywistą operację. Zweryfikuj logowanie do panelu, stronę główną, ważne podstrony, formularz oraz kluczowe funkcje sklepu, jeśli witryna przyjmuje zamówienia.

Po teście zapisz datę kopii, wynik odtworzenia, wykryte braki i czas potrzebny na przywrócenie. Test musi obejmować import danych i plików strony, a nie tylko uruchomienie zadania backupu.

Przywracanie WordPressa rozpocznij od zabezpieczenia obecnego stanu, a następnie odtwórz właściwy zestaw plików i bazę. Jeśli bieżąca strona nadal częściowo działa, wykonaj jej dodatkową kopię przed nadpisaniem danych.

Ogólna kolejność odtworzenia wygląda następująco:
- wybierz ostatni sprawdzony zestaw plików i bazy sprzed awarii;
- przygotuj hosting lub środowisko testowe z kompatybilną wersją PHP i bazy;
- przywróć pliki strony, a następnie zaimportuj bazę danych;
- sprawdź dane połączenia w `wp-config.php` i adres witryny;
- zweryfikuj logowanie, podstrony, media, formularze oraz zamówienia;
- skieruj ruch na przywróconą stronę po kontroli działania.

Import bazy przez phpMyAdmin zmienia dane w wybranej bazie, dlatego upewnij się, że wskazujesz właściwe środowisko. Przywrócenie starszej bazy może usunąć nowsze zamówienia, konta i wpisy. W sklepie uzgodnij z zespołem obsługę zamówień z okresu między kopią a awarią.

Skorzystaj z pomocy administratora, jeśli nie masz pewności co do nazwy bazy, konfiguracji hostingu, przyczyny awarii lub wpływu odtworzenia na zamówienia. Gdy przywrócenie łączy się ze zmianą serwera, proces opisuje poradnik migracji WordPress na nowy hosting.

Backup nie chroni strony, gdy brakuje jednego z jej składników, kopia leży wyłącznie na produkcyjnym hostingu albo nikt nie sprawdził odtworzenia. Najczęstsze luki można wykryć przez kontrolę zakresu, lokalizacji, logów i testów.

Sprawdź, czy kopia obejmuje wszystkie tabele bazy, `wp-content`, konfigurację i pliki potrzebne do uruchomienia serwisu. Skontroluj, czy wtyczka nie pomija dużych katalogów, harmonogram się uruchamia, a zdalne konto przyjmuje połączenie.

Lista typowych luk:
- baza znajduje się w kopii, ale brakuje plików lub odwrotnie;
- jedyny backup leży na tym samym koncie i w tej samej infrastrukturze;
- retencja jest zbyt krótka, by wykryć wcześniej powstały problem;
- zadanie cykliczne kończy się błędem, a powiadomień nikt nie monitoruje;
- odtworzenia nigdy nie sprawdzano na środowisku testowym;
- konto magazynu kopii używa tych samych danych logowania co konto administratora strony.

Wykonaj kontrolę po aktualizacji WordPressa, wtyczek lub motywu oraz przed migracją. Instrukcję aktualizacji opisuje poradnik jak aktualizować WordPress. Jeśli potrzebujesz wykonawcy, który zajmie się przygotowaniem i konfiguracją serwisu, realizacja strony firmowej w WordPressie obejmuje prace przy zapleczu technicznym witryny.

• Przejęcie strony WordPress: jak sprawdzić dostęp, kopię i działanie serwisu
• Jak poprawić bezpieczeństwo strony internetowej? Plan wdrożeń poza samym WordPressem
• Jak skonfigurować zadania cron dla WordPressa i sprawdzić, czy działają
• Serwer pod WordPress: jak dobrać parametry i przygotować środowisko