Backup WordPress przez SSH – jak wykonać kopię plików i bazy danych krok po kroku

Backup WordPress przez SSH to jedna z najwygodniejszych metod wykonania pełnej kopii strony internetowej. Zamiast pobierać przez FTP dziesiątki tysięcy plików osobno, można bezpośrednio na serwerze spakować cały katalog strony do jednego archiwum, wykonać kopię bazy danych za pomocą mysqldump, a następnie pobrać oba pliki na komputer. Taki sposób jest szybki, stosunkowo prosty i daje pełną kontrolę nad tym, co faktycznie znajduje się w kopii zapasowej.

W przypadku większych instalacji WordPressa różnica w wygodzie jest bardzo wyraźna. Serwis może zawierać kilka gigabajtów zdjęć, tysiące plików wtyczek, motywów, cache i innych danych. Pobieranie ich pojedynczo przez FTP oznacza ogromną liczbę operacji. SSH pozwala większość pracy wykonać po stronie serwera, a lokalnie pobieramy później tylko dwa pliki: archiwum z WordPressem oraz skompresowany dump bazy danych.

Co jest potrzebne do wykonania backupu WordPress przez SSH?

Przede wszystkim hosting musi udostępniać dostęp SSH. Potrzebne będą dane:

• adres serwera SSH,
• port SSH,
• login użytkownika,
• hasło lub klucz SSH,
• dostęp do katalogu, w którym znajduje się WordPress.

Na Windows 10 i Windows 11 nie jest już konieczne instalowanie osobnych programów takich jak PuTTY. Klient SSH oraz SCP są standardowo dostępne w systemie i można korzystać z nich przez PowerShell lub Windows Terminal.

Schemat połączenia wygląda następująco:

ssh-p PORT LOGIN@SERWER

Przykładowo:

ssh-p1022 user@example-host.pl

Przy pierwszym połączeniu system może zapytać o akceptację fingerprintu serwera. Po jego zaakceptowaniu należy podać hasło.

Po zalogowaniu warto sprawdzić aktualny katalog:

pwd

oraz jego zawartość:

ls-la

Katalog WordPressa można rozpoznać między innymi po obecności:

wp-adminwp-contentwp-includeswp-config.php

Jak znaleźć katalog WordPressa przez SSH?

Jeżeli nie wiadomo dokładnie, gdzie znajduje się instalacja, można wyszukać plik wp-config.php:

find . -maxdepth3-name wp-config.php -print

W wielu hostingach struktura wygląda mniej więcej tak:

domains/└── example.pl/    └── public_html/

public_html jest wtedy katalogiem dostępnym przez WWW i jednocześnie katalogiem głównym WordPressa.

Do wykonania backupu najlepiej przejść poziom wyżej:

cd ..

Dzięki temu archiwum nie zostanie utworzone wewnątrz public_html.

Ma to znaczenie z punktu widzenia bezpieczeństwa. Plik zawierający pełną kopię strony nie powinien być możliwy do pobrania przez przeglądarkę.

Jak sprawdzić wielkość strony przed wykonaniem backupu?

Przed rozpoczęciem kompresji dobrze sprawdzić, ile miejsca zajmuje katalog WordPressa:

du -sh public_html

Przykładowy wynik:

7.0G    public_html

Przy dużej instalacji można również sprawdzić, które katalogi zajmują najwięcej miejsca:

du -h--max-depth=1 public_html | sort-h

Jeszcze dokładniejsze informacje dla katalogu wp-content uzyskamy przez:

du -h--max-depth=1 public_html/wp-content | sort-h

Najczęściej największym katalogiem okazuje się:

wp-content/uploads

czyli biblioteka mediów WordPressa.

W przypadku stron działających od wielu lat mogą się tam znajdować tysiące zdjęć, miniaturek, grafik WebP, dokumentów PDF i innych plików.

Jak spakować public_html przez SSH?

Do utworzenia archiwum można użyć programu tar.

Najpierw warto sprawdzić, czy jest dostępny:

command -v tar

Jeżeli system zwróci np.:

/usr/bin/tar

program jest dostępny.

Wersję można sprawdzić poleceniem:

tar --version

Pełny backup katalogu public_html można wykonać za pomocą:

tar -czf wordpress-files-2026-08-19.tar.gz public_html

Parametry oznaczają:

-c  utworzenie nowego archiwum-z  kompresję gzip-f  zapis do wskazanego pliku

W efekcie otrzymamy:

wordpress-files-2026-08-19.tar.gz

Archiwum zawiera cały katalog public_html, włącznie z ukrytymi plikami znajdującymi się w jego strukturze.

To ważne między innymi w przypadku .htaccess.

Dlaczego archiwum WordPressa może kompresować się słabo?

Jeżeli instalacja WordPressa zajmuje np. 7 GB, nie oznacza to, że archiwum tar.gz będzie miało 2 czy 3 GB.

W przypadku strony zawierającej dużą liczbę zdjęć wynik może wynosić np.:

6.6 GB

Powód jest prosty. Pliki takie jak:

JPGPNGWebPAVIFMP4ZIPPDF

często są już skompresowane.

gzip musi przeczytać i przeanalizować dane, ale nie jest w stanie zmniejszyć ich rozmiaru w takim stopniu jak zwykłych plików tekstowych.

Dlatego przy stronie, której większość danych stanowią obrazy, główną zaletą tar.gz jest często nie zmniejszenie rozmiaru, lecz połączenie tysięcy plików w jedno archiwum.

I właśnie to znacznie ułatwia późniejsze pobranie backupu.

Jak sprawdzić poprawność archiwum tar.gz?

Po utworzeniu backupu warto sprawdzić jego rozmiar:

ls-lh wordpress-files-2026-08-19.tar.gz

Następnie można przeprowadzić pełny test odczytu archiwum:

tar -tzf wordpress-files-2026-08-19.tar.gz > /dev/null; echo$?

Jeżeli polecenie zwróci:

0

oznacza to, że tar był w stanie poprawnie przejść przez archiwum.

Przy dużych backupach test może potrwać kilka minut. Program musi bowiem faktycznie odczytać całe skompresowane archiwum.

Można również zastosować czytelniejszą wersję:

tar -tzf wordpress-files-2026-08-19.tar.gz > /dev/null && echo"BACKUP OK" || echo"BACKUP USZKODZONY"

Jeżeli interesuje nas jedynie szybkie podejrzenie początku archiwum:

tar -tzf wordpress-files-2026-08-19.tar.gz | head

Nie jest to jednak pełny test integralności.

Backup bazy danych WordPress przez SSH

Same pliki WordPressa nie wystarczą do pełnego odtworzenia strony.

Treść wpisów, strony, ustawienia, użytkownicy, konfiguracja wielu wtyczek oraz inne dane znajdują się w bazie MySQL lub MariaDB.

Dane dostępowe do bazy znajdują się w:

wp-config.php

Można podejrzeć nazwę bazy, użytkownika i hosta:

grep-E"DB_NAME|DB_USER|DB_HOST" wp-config.php

Hasło można znaleźć osobno:

grep"DB_PASSWORD" wp-config.php

Danych tych nie należy publikować ani przesyłać osobom trzecim.

Przykładowa konfiguracja może wyglądać tak:

define('DB_NAME', 'nazwa_bazy');define('DB_USER', 'uzytkownik_bazy');define('DB_PASSWORD', 'haslo');define('DB_HOST', 'localhost');

Jak wykonać mysqldump bazy WordPressa?

Najpierw warto sprawdzić dostępność narzędzia:

command -v mysqldump

Backup wykonujemy poleceniem:

mysqldump -u UZYTKOWNIK_BAZY -p NAZWA_BAZY > wordpress-db-2026-08-19.sql

Przykład:

mysqldump -u user_wordpress -p wordpress_db > wordpress-db-2026-08-19.sql

Po uruchomieniu polecenia mysqldump poprosi o hasło.

Jest to bezpieczniejsze niż wpisywanie hasła bezpośrednio w poleceniu, ponieważ nie trafia ono wtedy do historii powłoki.

Po zakończeniu warto sprawdzić plik:

ls-lh wordpress-db-2026-08-19.sql

Jak skompresować backup bazy danych?

Dump SQL zwykle bardzo dobrze poddaje się kompresji, ponieważ w większości składa się z tekstu.

Wystarczy wykonać:

gzip wordpress-db-2026-08-19.sql

Po zakończeniu otrzymamy:

wordpress-db-2026-08-19.sql.gz

Warto pamiętać, że gzip domyślnie usuwa oryginalny plik .sql.

Nie jest to błąd.

Jeżeli chcemy zachować zarówno wersję nieskompresowaną, jak i .gz, można użyć:

gzip -k wordpress-db-2026-08-19.sql

Do typowego backupu zwykle wystarcza jednak sam plik:

wordpress-db-2026-08-19.sql.gz

Jak pobrać backup WordPressa przez SCP?

Po wykonaniu backupu powinniśmy mieć dwa pliki:

wordpress-files-2026-08-19.tar.gzwordpress-db-2026-08-19.sql.gz

Następnie można pobrać je na własny komputer.

Polecenie scp należy uruchomić lokalnie, np. w Windows PowerShell, a nie wewnątrz sesji SSH serwera.

Przykład:

scp-PPORTuser@serwer:~/domains/example.pl/wordpress-files-2026-08-19.tar.gz .

oraz:

scp-PPORTuser@serwer:~/domains/example.pl/wordpress-db-2026-08-19.sql.gz .

Kropka na końcu oznacza zapisanie pliku w aktualnym katalogu.

Można wcześniej przejść np. do:

cdD:\Backup\WordPress

i dopiero stamtąd wykonać scp.

Jak sprawdzić SHA-256 backupu po pobraniu?

Przy kilku gigabajtach danych warto upewnić się, że transfer zakończył się poprawnie.

Na serwerze obliczamy SHA-256:

sha256sum wordpress-files-2026-08-19.tar.gz

oraz:

sha256sum wordpress-db-2026-08-19.sql.gz

Na Windowsie:

Get-FileHash .\wordpress-files-2026-08-19.tar.gz-AlgorithmSHA256

i:

Get-FileHash .\wordpress-db-2026-08-19.sql.gz-AlgorithmSHA256

Jeżeli wartości są identyczne, pobrany plik jest bit po bicie taki sam jak plik znajdujący się na serwerze.

Wielkość liter nie ma znaczenia.

Hash:

4409A6EDD360D959...

jest równoważny:

4409a6edd360d959...

Czy backup zostawiać na serwerze?

Kopia znajdująca się wyłącznie na tym samym serwerze co strona nie powinna być jedynym backupem.

Jeżeli awarii ulegnie całe konto hostingowe, filesystem lub dostęp do serwera, można stracić jednocześnie stronę oraz jej kopię.

Dlatego po pobraniu i zweryfikowaniu archiwum warto przechowywać backup:

• na komputerze lokalnym,
• na dodatkowym dysku,
• na NAS-ie,
• w zewnętrznej chmurze.

Dopiero po upewnieniu się, że kopia lokalna jest poprawna, można usunąć duże archiwa z hostingu:

rm wordpress-files-2026-08-19.tar.gz

oraz:

rm wordpress-db-2026-08-19.sql.gz

Pozwala to odzyskać miejsce na koncie hostingowym.

Backup WordPress przez SSH czy FTP?

Przy niewielkiej stronie różnica może nie być ogromna, ale przy większych instalacjach SSH jest zdecydowanie wygodniejsze.

WordPress może składać się z dziesiątek lub nawet setek tysięcy plików. FTP musi wykonać osobną operację dla praktycznie każdego z nich.

W przypadku SSH tworzymy natomiast jedno archiwum:

public_html → jeden plik tar.gz

i pobieramy jeden duży plik przez SCP.

Jest to prostsze do kontrolowania, łatwiejsze do zweryfikowania i znacznie wygodniejsze przy późniejszym przechowywaniu backupu.

Do kompletu potrzebny jest tylko osobny dump bazy danych.

W praktyce dobry ręczny backup WordPressa może więc składać się z zaledwie dwóch plików:

wordpress-files-DATA.tar.gzwordpress-db-DATA.sql.gz

Jeżeli oba archiwa zostały sprawdzone, pobrane poza serwer i zweryfikowane za pomocą SHA-256, mamy pełną kopię potrzebną do późniejszego odtworzenia strony.