Jak wykonać szybki backup WP-CLI

Szybki i bezpieczny backup WordPressa nie musi być skomplikowany, jeśli wykorzystasz moc wiersza poleceń. WP-CLI pozwala wykonać eksport bazy, spakować pliki i wynieść kopię poza serwer w kilka minut, bez klikania w panelu. W tym poradniku przejdziesz przez konkretne kroki: od przygotowania środowiska, przez ekspresowy zrzut baza danych, aż po kopiowanie katalogu wp-content, automatyzację i szybkie odtwarzanie. Instrukcje działają zarówno na hostingu współdzielonym, jak i na własnym VPS.

Wymagania i przygotowanie środowiska

Sprawdzenie dostępu i wersji WP-CLI

Zaloguj się na serwer przez SSH i upewnij się, że WP-CLI jest dostępne w systemie. Jeśli host nie oferuje globalnej instalacji, możesz uruchomić je lokalnie z pliku phar.

• wp –info — sprawdzisz wersję, ścieżki i interpreter PHP.
• wp core is-installed — upewnisz się, że polecenia odpalasz w katalogu instancji WordPressa.
• Jeśli polecenie wp nie działa, pobierz plik wp-cli.phar i uruchamiaj: php wp-cli.phar.

Uprawnienia i miejsce na dysku

Backup wymaga dostępu do plików WordPressa oraz do bazy MySQL/MariaDB skonfigurowanej w wp-config.php. Sprawdź wolne miejsce i uprawnienia zapisu, by uniknąć przerwania operacji:

• df -h — ile miejsca pozostało na partycji.
• du -sh wp-content — orientacyjny rozmiar plików witryny.
• Docelowy folder kopii (np. backups/) powinien mieć prawa zapisu dla Twojego użytkownika.

Struktura katalogów WordPress

Minimalny zakres plików do zachowania to katalog wp-content/ (zwłaszcza uploads/), ponieważ zawiera media, motywy i wtyczki. Sam core WordPressa i paczki wtyczek można odtworzyć, lecz media są unikalne. Przemyśl, czy chcesz także kopię pliku wp-config.php (przydatne przy pełnym odtwarzaniu) oraz plików konfiguracyjnych serwera (.htaccess, web.config).

Plik wp-cli.yml i aliasy SSH

Konfiguracja WP-CLI w wp-cli.yml ułatwia skracanie komend i uruchamianie ich z dowolnego katalogu. W tym pliku możesz też zdefiniować aliasy do zdalnych środowisk, aby wykonywać backup bezpośrednio na produkcji lub stagingu. Przykładowo:

• Alias lokalny: zdefiniuj path: /var/www/strona.
• Alias zdalny: @prod wskazujący na host i katalog docelowy, tak aby używać wp @prod db export.

Aliasami zredukujesz literówki i zminimalizujesz ryzyko pomyłek przy pracy na środowiskach.

Ekspresowy backup bazy danych

Prosty i szybki eksport

WP-CLI udostępnia polecenie eksportu, które wewnętrznie korzysta z mysqldump (lub odpowiednich narzędzi). To najszybsza droga do spójnego zrzutu, zwłaszcza z opcją pojedynczej transakcji.

• wp db export backups/db-$(date +%F_%H%M).sql –add-drop-table –single-transaction

Parametr –single-transaction ogranicza blokady i poprawia spójność przy InnoDB. Opcja –add-drop-table doda czyszczenie tabel podczas przywracania. Jeśli chcesz maksymalnie ograniczyć obciążenie, rozważ flagi dumpa: –quick, –skip-lock-tables (ostrożnie w środowiskach z intensywnym zapisem).

Kompresja w locie i oszczędność miejsca

Komendy systemowe można łączyć potokami, aby skompresować zrzut bez zapisywania dużego pliku tymczasowego. Najprościej użyć gzip w trybie strumieniowym:

• wp db export – | gzip -1 > backups/db-$(date +%F_%H%M).sql.gz

Poziom -1 przyspiesza kompresję kosztem mniejszego zysku pojemności — idealny dla kopii „na już”. Jeśli masz czas, możesz użyć gzip -9 lub alternatywnie pigz (wielowątkowa wersja gzip) na serwerach z większą liczbą rdzeni.

Datownik, rotacja i porządek

Systematyzuj pliki przez konsekwentne nazewnictwo i ustaw retencję, aby nie zapchać dysku. Proste reguły:

• Nazwa: db-YYYY-MM-DD_HHMM.sql.gz pozwala sortować kopie chronologicznie.
• Rotacja 7 dni: find backups/ -name 'db-*.sql.gz’ -mtime +7 -delete.
• Osobny folder dla bazy i plików, np. backups/db i backups/files, ułatwia automatyzację.

Kontrola jakości zrzutu i weryfikacja

Po wykonaniu zrzutu sprawdź integralność i spójność:

• gunzip -t backups/db-*.sql.gz — test archiwum bez rozpakowywania.
• wp db check — szybka kontrola kondycji tabel w środowisku źródłowym.
• Migawkowe przywrócenie na środowisku testowym: wp db import i przegląd kilku kluczowych ekranów w panelu.

Jeśli baza ma tabele tymczasowe lub zalew logów, rozważ wykluczenia (mysqldump: –ignore-table) dla tabel cache, aby przyspieszyć i zredukować rozmiar kopii.

Bezpieczne szyfrowanie dumpa

Przenosisz dane poza serwer? Zaszyfruj plik, zwłaszcza gdy backup ląduje w chmurze lub na zewnętrznym hostingu:

• Symetrycznie: gpg -c backups/db-*.sql.gz i usuń jawny plik po weryfikacji: shred -u.
• Asymetrycznie: gpg –encrypt -r NAZWA_KLUCZA backups/db-*.sql.gz — wygodne, gdy zespół ma klucze publiczne.
• Alternatywnie: openssl enc -aes-256-cbc -pbkdf2 -salt -in plik -out plik.enc.

Pamiętaj, by hasła/klucze przechowywać poza repozytorium i udostępniać je tylko uprawnionym osobom.

Szybkie kopiowanie plików

Co naprawdę warto archiwizować

Największy udział w rozmiarze backupu mają media w wp-content/uploads. Dodatkowo zabezpiecz:

• wp-content/themes i wp-content/plugins — wersjonowalne, ale czasem zawierają niestandardowe modyfikacje.
• wp-content/mu-plugins — wtyczki „must-use”, często krytyczne.
• wp-config.php oraz ewentualnie pliki Nginx/Apache (.htaccess, nginx.conf fragmenty).

Nie kopiuj folderów cache czy logów, gdy nie są potrzebne. Wykluczenia przyspieszają operację i zmniejszają rozmiar.

Tar z kompresją dla natychmiastowego efektu

Prosty, szybki pakiet wszystkich kluczowych katalogów w jeden plik:

• tar –exclude=’cache/*’ –exclude=’*.log’ -czf backups/files-$(date +%F_%H%M).tar.gz wp-content

Zachowanie względnych ścieżek ułatwia przywracanie w innym katalogu. Jeżeli dostępny jest pigz, przyspieszysz kompresję wielowątkowo:

• tar –exclude=’cache/*’ –exclude=’*.log’ -I 'pigz -1′ -cf backups/files-$(date +%F_%H%M).tar.gz wp-content

W przypadku bardzo dużych uploadów rozważ podział na części: split -b 2G plik.tar.gz plik.tar.gz.part-, co ułatwi wysyłkę na magazyny z limitami rozmiaru pliku.

rsync i backup inkrementalny

Dla najszybszych, codziennych kopii przydaje się rsync z linkami twardymi. Dzięki temu przechowujesz wiele „migawek” bez duplikowania niezmienionych plików:

• Pełna kopia bazowa: rsync -a –delete –exclude=’cache/’ –exclude=’*.log’ wp-content/ backups/snapshots/base/
• Migawka z link-dest: rsync -a –delete –link-dest=../base –exclude=’cache/’ wp-content/ backups/snapshots/$(date +%F_%H%M)/

Taka strategia pozwala błyskawicznie odtwarzać dowolną migawkę, a codzienne przebiegi zmieniają tylko różnice. Na zdalny serwer użyj tej samej techniki przez SSH: rsync -az -e ssh.

Jednowierszowiec: baza + pliki

Gdy liczy się czas, możesz wykonać całość w trzech komendach, które łatwo wkleić w terminal:

• mkdir -p backups/{db,files}
• wp db export – | gzip -1 > backups/db/db-$(date +%F_%H%M).sql.gz
• tar –exclude=’cache/*’ –exclude=’*.log’ -czf backups/files/files-$(date +%F_%H%M).tar.gz wp-content

Po zakończeniu warto sprawdzić sumy: sha256sum backups/**/* i zapisać je w pliku kontrolnym. Dzięki temu łatwo wykryjesz przypadkowe uszkodzenia.

Automatyzacja, zdalne kopie i odtwarzanie

Skrypt bash do użycia od ręki

Utwórz prosty skrypt, który zadba o katalogi, datowniki i wykluczenia. Przykładowa sekwencja kroków:

• Utwórz katalogi: mkdir -p backups/{db,files,logs}.
• Wyeksportuj bazę z kompresją: wp db export – | gzip -1 > backups/db/db-$(date +%F_%H%M).sql.gz.
• Spakuj pliki: tar –exclude=’cache/*’ –exclude=’*.log’ -czf backups/files/files-$(date +%F_%H%M).tar.gz wp-content.
• Rotuj starsze niż 14 dni: find backups -type f -mtime +14 -delete.
• Opcjonalnie zaszyfruj: gpg -c backups/db/db-*.sql.gz i gpg -c backups/files/files-*.tar.gz.
• Zapisz log: każdą komendę przekieruj z 2>&1 | tee -a backups/logs/backup-$(date +%F).log.

Tę listę kroków wkładasz do pliku wykonywalnego i odpalasz na żądanie lub cyklicznie.

Harmonogram w cronie i polityka retencji

Cron zapewnia, że kopia powstaje nawet, gdy o niej zapomnisz. Kilka praktyk:

• Dzienny szybki backup w nocy: 0 2 * * * /ścieżka/backup.sh.
• Tygodniowa pełna kompresja: 0 3 * * 0 /ścieżka/backup-pełny.sh.
• Retencja: dziennie trzymaj 7 dni, tygodnie — 5, miesiące — 3. Ustal to przez warunki w skrypcie lub osobne zadania find.

Jeśli zrzut ma iść poza serwer, dodaj kroki wysyłki po udanym utworzeniu archiwów i weryfikacji sum kontrolnych.

Zdalna wysyłka: rsync, SCP, rclone, S3

Trzymanie kopii tylko lokalnie nie jest bezpieczne. Wynoś je poza maszynę w sposób szybki i powtarzalny:

• Na inny serwer: rsync -az –partial –progress backups/ user@host:/ścieżka/kopie/.
• Prosto przez SSH: scp backups/db/*.gz user@host:/ścieżka/db/.
• Do chmury: rclone copy backups remote:bucket/nazwa-projektu/$(date +%F) — z obsługą dostawców S3/B2/Dropbox/Google Drive.
• W razie ograniczeń: podziel pliki (split), a po stronie celu połącz (cat part-* > oryginał).

Przechowuj poświadczenia w zmiennych środowiskowych lub w menedżerze tajemnic. Nigdy nie zapisuj kluczy dostępowych bezpośrednio w repozytorium.

Odtwarzanie w minutach

Gdy musisz szybko odtworzyć witrynę, trzymaj się prostej procedury:

• Rozpakuj pliki: tar -xzf backups/files/files-YYYY-MM-DD_HHMM.tar.gz -C /ścieżka/do/instancji.
• Przywróć bazę: jeśli masz plik .sql.gz, odpakuj (gunzip) i wykonaj wp db import backups/db/db-YYYY-MM-DD_HHMM.sql.
• Jeśli domena/ścieżka się zmienia: wp search-replace STARA_Domena NOWA_Domena –all-tables –precise.
• Przepłucz cache: wp cache flush lub czyszczenie wtyczki cache.

Drobne różnice środowisk (wersje PHP, rozszerzenia) mogą wymagać reinstalacji zależności wtyczek lub sprawdzenia uprawnień katalogów (find . -type d -exec chmod 755 {} \;, find . -type f -exec chmod 644 {} \;).

Szybkie kopie na produkcji bez przestoju

Chcąc zminimalizować wpływ backupu na użytkowników:

• Dump z –single-transaction skraca blokady tabel.
• Włącz tymczasowo tryb konserwacji tylko na czas newralgicznych operacji plikowych: wp maintenance-mode activate i po chwili wp maintenance-mode deactivate.
• Użyj wykluczeń przy tar/rsync, aby pominąć szybkozmienne foldery cache i logi.
• Na wielordzeniowych maszynach stosuj wielowątkową kompresję (pigz), aby skrócić czas CPU.

Praktyczne aliasy i skróty WP-CLI

Alias środowiska produkcyjnego pozwala wykonywać backup z lokalnej maszyny, bez ręcznego logowania przez SSH. Po zdefiniowaniu @prod w wp-cli.yml:

• Zrzut bazy z lokalnej konsoli: wp @prod db export – | gzip -1 > backups/prod-db-$(date +%F_%H%M).sql.gz.
• Lista wtyczek i wersji do audytu przed odtwarzaniem: wp @prod plugin list –format=json i zapis do pliku kontrolnego.

Takie podejście porządkuje pracę zespołu i redukuje ryzyko nadpisania złego środowiska.

Checklist przed ważną zmianą

Przed aktualizacją WordPressa, motywów lub wtyczek zrób szybki snapshot:

• Gotowy folder backups/ i wolne miejsce sprawdzone (df -h).
• Ekspresowy dump bazy z datownikiem i weryfikacją (gunzip -t po kompresji).
• Archiwum wp-content z wykluczeniami cache.
• Kopia wp-config.php i ewentualnych plików serwera.
• Notatka z wersją PHP i listą wtyczek (wp plugin list), co pomaga przy ewentualnym rollbacku.

Minimalny zestaw do błyskawicznej migracja na inną maszynę

Gdy celem jest przeniesienie strony „tu i teraz” bez kompletnej rekonstrukcji środowiska:

• Eksport bazy: wp db export – | gzip -1 > db.sql.gz.
• Pakiet plików: tar -czf files.tar.gz wp-content.
• Transfer: scp db.sql.gz files.tar.gz user@nowy-host:/var/www/nowa-strona/.
• Odtworzenie: rozpakowanie plików, wp db import, a na koniec wp search-replace dla domeny.

To podejście jest proste i szybkie, a później możesz doszlifować konfigurację (np. menedżery cache, CDN, trwałe obiekty).

Najczęstsze pułapki i jak ich uniknąć

• Brak miejsca na dysku — przed startem sprawdź df -h i rozważ kompresję w locie.
• Niepełne uprawnienia — uruchamiaj komendy z użytkownika, który zarządza plikami WWW.
• Ogromne tabele logów — ignoruj je na etapie dumpa (–ignore-table), o ile nie są krytyczne.
• Zapomniany test przywracania — przynajmniej raz w miesiącu odtwórz kopię na izolowanym środowisku.
• Hasła w skryptach — używaj zmiennych środowiskowych i ogranicz dostęp do plików kluczy.

Dobre praktyki operacyjne

Udokumentuj proces w README w repo serwera lub w notatkach SRE. Ustal odpowiedzialność: kto tworzy kopie, kto testuje przywracanie i jak zgłaszać incydenty. Przechowuj co najmniej jedną kopię offline lub w innej strefie dostępności. Regularnie sprawdzaj integralność przez sumy kontrolne i losowe przywracanie. Dzięki temu, gdy nadejdzie potrzeba, zadziałasz pewnie i szybko.

Podsumowując kroki do szybkiego backupu z WP-CLI, które warto mieć w zasięgu jednej ręki: eksport bazy z kompresją i datownikiem, archiwizacja wp-content z wykluczeniami, opcjonalne szyfrowanie i transfer poza serwer, a następnie codzienna automatyzacja z jasną polityką retencji. Te elementy wystarczą, by w kilka minut zabezpieczyć stronę przed skutkami awarii i błędnych aktualizacji, a równocześnie skrócić przestoje do minimum dzięki przemyślanej procedurze i praktycznym skrótom WP-CLI.