Opublikowane w przez Tomasz

Jak zrobić sensowny backup WordPressa: pliki, baza danych i test odtworzenia

Backup WordPressa to nie jest tylko kliknięcie wtyczki i nadzieja, że „jakoś będzie”. Jeśli strona ma znaczenie dla firmy, trzeba mieć kopię plików, kopię bazy danych i przynajmniej prosty test odtworzenia.

Najgorszy moment na sprawdzanie backupu jest wtedy, kiedy strona już nie działa.

Dla kogo jest ten wpis

Ten wpis jest dla administratora albo właściciela małej firmy, który ma WordPressa na hostingu, VPS-ie albo własnym serwerze i chce mieć kopię, z której naprawdę da się wrócić.

Nie opisuję tutaj konkretnej wtyczki. Chodzi o podstawy, które warto rozumieć niezależnie od narzędzia.

Co trzeba skopiować

WordPress składa się głównie z dwóch rzeczy:

  1. Plików strony.
  2. Bazy danych.

Same pliki nie wystarczą. Sama baza też nie wystarczy.

W plikach masz między innymi:

wp-content/uploads
wp-content/themes
wp-content/plugins
wp-config.php

W bazie danych masz wpisy, strony, ustawienia, użytkowników, konfigurację wtyczek i sporo danych, których nie widać jako zwykłych plików.

Backup bazy danych

Jeśli WordPress korzysta z MySQL albo MariaDB, najprostszy backup można zrobić przez mysqldump.

Przykład:

mysqldump -u USER -p NAZWA_BAZY > wordpress-db.sql

W praktyce lepiej dodać datę do nazwy pliku:

mysqldump -u USER -p NAZWA_BAZY > wordpress-db-$(date +%F).sql

Jeśli baza jest większa, warto od razu skompresować wynik:

mysqldump -u USER -p NAZWA_BAZY | gzip > wordpress-db-$(date +%F).sql.gz

Hasła nie warto wpisywać na stałe w skrypcie, jeśli plik może przeczytać ktoś niepowołany. Lepiej użyć bezpiecznej konfiguracji po stronie systemu albo ograniczyć uprawnienia pliku ze skryptem.

Backup plików WordPressa

Pliki można skopiować na przykład przez rsync.

Przykład lokalny:

rsync -a /var/www/html/ /backup/wordpress-files/

Przykład z katalogiem zawierającym datę:

rsync -a /var/www/html/ /backup/wordpress-files-$(date +%F)/

Jeżeli backup ma iść na inny serwer lub NAS po SSH:

rsync -a /var/www/html/ backup-user@backup-server:/backup/wordpress/

Warto zwrócić uwagę na wp-content/uploads, bo tam często jest najwięcej danych. Motyw i wtyczki zwykle da się pobrać ponownie, ale uploadów klienta już niekoniecznie.

Prosty skrypt backupu

Przykład prostego skryptu:

#!/bin/bash

set -e

DATE=$(date +%F)
BACKUP_DIR="/backup/wordpress-$DATE"
WP_DIR="/var/www/html"
DB_NAME="NAZWA_BAZY"
DB_USER="USER"

mkdir -p "$BACKUP_DIR"

mysqldump -u "$DB_USER" -p "$DB_NAME" | gzip > "$BACKUP_DIR/database.sql.gz"

rsync -a "$WP_DIR/" "$BACKUP_DIR/files/"

echo "Backup zapisany w: $BACKUP_DIR"

To jest tylko punkt wyjścia. W produkcji trzeba jeszcze przemyśleć rotację kopii, miejsce na dysku, logowanie błędów i wysyłkę backupu poza serwer.

Backup na tym samym serwerze to za mało

Częsty błąd: backup jest robiony na tym samym VPS-ie, na którym działa strona.

To lepsze niż nic, ale nie rozwiązuje problemu awarii dysku, usunięcia maszyny, zaszyfrowania danych albo błędu administratora. Sensowna kopia powinna trafić poza serwer produkcyjny.

Może to być:

  • drugi serwer,
  • NAS,
  • storage S3-compatible,
  • zewnętrzna usługa backupu,
  • inna lokalizacja u dostawcy.

Test odtworzenia

Backup bez testu odtworzenia to bardziej deklaracja niż zabezpieczenie.

Minimalny test może wyglądać tak:

  1. Przygotuj katalog testowy albo osobną maszynę.
  2. Wgraj pliki WordPressa z backupu.
  3. Odtwórz bazę danych.
  4. Popraw dane połączenia w wp-config.php.
  5. Sprawdź, czy strona startuje.
  6. Sprawdź logowanie do panelu.
  7. Wejdź w kilka wpisów i stron.
  8. Sprawdź media z uploads.

Odtworzenie bazy z pliku .sql.gz:

gunzip < database.sql.gz | mysql -u USER -p NAZWA_BAZY

Jeśli domena testowa jest inna niż produkcyjna, mogą dojść problemy z adresami URL w bazie. Wtedy trzeba użyć narzędzia, które poprawnie obsługuje serializowane dane WordPressa. Zwykłe sed na dumpie bazy może coś popsuć.

Na co uważać

Nie trzymaj jedynej kopii backupu publicznie dostępnej przez WWW. Katalog typu:

https://domena.pl/backup/

to proszenie się o problem.

Nie zostawiaj dumpów bazy w katalogu strony:

/var/www/html/backup.sql

W bazie mogą być hashe haseł, adresy e-mail, dane klientów i konfiguracje wtyczek.

Uważaj też na miejsce na dysku. Backup, który zapełni partycję produkcyjną, może zatrzymać stronę szybciej niż sama awaria WordPressa.

Jak często robić backup

To zależy od strony.

Jeśli blog dostaje nowy wpis raz w miesiącu, backup dzienny może być wystarczający. Jeśli to sklep albo strona z formularzami, trzeba myśleć inaczej.

Praktyczne pytanie brzmi:

Ile danych możesz stracić bez większego problemu?

Jeśli odpowiedź brzmi „maksymalnie jeden dzień”, backup raz w tygodniu nie wystarczy.

Prosta checklista

Przy WordPressie sprawdziłbym minimum:

  • czy backup obejmuje bazę danych,
  • czy backup obejmuje wp-content/uploads,
  • czy kopia trafia poza serwer produkcyjny,
  • czy stare kopie są usuwane według zasad,
  • czy błędy backupu są gdzieś widoczne,
  • czy da się odtworzyć stronę z kopii,
  • czy ktoś wie, gdzie te kopie są,
  • czy dostęp do backupów jest ograniczony.

Podsumowanie

Dobry backup WordPressa to nie tylko plik ZIP z katalogiem strony. Potrzebujesz plików, bazy danych i procedury odtworzenia.

Najważniejsze są trzy rzeczy:

  1. Kopia musi być kompletna.
  2. Kopia musi być poza serwerem produkcyjnym.
  3. Kopię trzeba czasem odtworzyć testowo.

Bez tego backup może wyglądać dobrze tylko do pierwszej awarii.

☕ Postaw mi kawę