Kopie zapasowe WordPress na Storage Server: instrukcja z WPvivid

Kopia zapasowa, która leży na tym samym serwerze co strona, nie jest kopią zapasową. Gdy dysk zostanie wyczyszczony, dostęp przejęty albo instalacja zaszyfrowana, przepada razem z nią. Dopiero kopia na odrębnej pamięci jest prawdziwym zabezpieczeniem.

Ta instrukcja pokazuje najszybszą drogę do celu: darmowa wtyczka, która zapisuje WordPress przez SFTP na Storage Server, z harmonogramem i regułą przechowywania. Konfiguracja zajmuje kwadrans.

Dlaczego WPvivid

Wybór jest w jednym punkcie zaskakująco mały. Rzecz, o którą tu chodzi, to szyfrowany transfer w darmowej wersji:

Zwykły FTP przesyła dane dostępowe i treści bez szyfrowania. Dla kopii zapasowej, która zawiera całą bazę danych wraz z tabelą użytkowników, nie jest to dobry pomysł. WPvivid jest tym samym oczywistym wyborem, ma ponad 900.000 aktywnych instalacji i był ostatnio aktualizowany we wrześniu 2026.

Krok 1: założenie subkonta na pamięci

W panelu klienta, przy swoim Storage Serverze, załóż osobne subkonto na kopie zapasowe, z katalogiem startowym /backup/wordpress. To ważniejsze, niż brzmi: dane dostępowe wylądują zaraz w bazie danych WordPress, a kto je tam znajdzie, nie powinien móc nimi dosięgnąć niczego poza tym jednym katalogiem.

W tym samym kroku sprawdź w „Ustawieniach dostępu” dwa przełączniki:

• SSH / SFTP / SCP / rsync musi być udostępniony.
• Dostępność zewnętrzna musi być włączona, bo inaczej twój serwer WWW nie dosięgnie pamięci przez internet.

W nowo zamówionych serwerach oba są aktywne. Zapisz sobie nazwę hosta i nazwę użytkownika, przykłady w tym artykule używają poniższych wartości:

Krok 2: sprawdź osiągalność, zanim cokolwiek skonfigurujesz

To oszczędza później dużo szukania. Jeśli masz dostęp do powłoki na serwerze WWW:

timeout 5 bash -c '</dev/tcp/u123456.storage.kernelhost.net/23' && echo "Port 23 osiągalny"

Bez dostępu do powłoki umieszczasz plik pruefen.php w katalogu strony, wywołujesz go raz i potem znowu usuwasz:

<?php
$f = @fsockopen('u123456.storage.kernelhost.net', 23, $e, $t, 5);
echo $f ? 'Port 23 osiągalny' : 'brak połączenia: ' . $t;

Jeśli połączenie nie dochodzi do skutku, twój hostingodawca blokuje połączenia wychodzące na tym porcie. Na hostingu współdzielonym to nierzadkie. Zostaje wtedy albo pytanie do hostingodawcy, albo droga przez WebDAV, która biegnie na porcie 443.

Krok 3: instalacja wtyczki i wpisanie celu

W zapleczu WordPress, w Wtyczki, Dodaj nową, wyszukaj WPvivid Backup & Migration, zainstaluj i włącz. Potem po lewej pojawia się pozycja menu WPvivid Backup.

Tam przejdź na kartę Remote Storage i wybierz SFTP. Pola wypełniasz tak:

Przyciskiem Test and Add wtyczka sprawdza połączenie, zanim je zapisze. Jeśli to się nie uda, w dziewięciu z dziesięciu przypadków błędny jest albo port, albo wyłączona jest dostępność zewnętrzna.

Krok 4: pierwsza kopia ręcznie

Na karcie Backup & Restore wybierasz Database + Files (WordPress Files), a jako cel Send backup to remote storage z właśnie założonym wpisem. Potem Backup Now.

Pierwszy przebieg trwa, zależnie od rozmiaru, kilka minut. Zostaw przy tym okno przeglądarki otwarte, wtyczka steruje postępem przez powtarzane wywołania.

Krok 5: harmonogram i przechowywanie

Na karcie Schedule włączasz harmonogram. Sprawdziło się:

Ustaw godzinę na nocne pory twoich głównych odwiedzających. Przechowywanie ustawiasz w Settings, tam jest też przełącznik, czy stare kopie mają być usuwane również na zdalnej pamięci. Włącz go, bo inaczej pamięć z czasem się zapełni.

Zwróć przy tym uwagę: snapshoty Storage Servera są dodatkową warstwą i działają niezależnie od tego. W zależności od pakietu do dyspozycji jest 10, 20, 30 albo 40 snapshotów ręcznych, a do tego tyle samo automatycznych.

Krok 6: sprawdź, czy kopia jest coś warta

Ten krok jest pomijany najczęściej, a jest najważniejszy. Zobacz, co faktycznie leży na pamięci:

sftp -P 23 u123456-sub3@u123456.storage.kernelhost.net
sftp> ls -l
sftp> bye

Zwróć uwagę na dwie rzeczy: rozmiar pliku musi być wiarygodny, i musi być obecne zarówno archiwum bazy danych, jak i archiwum plików. Archiwum o kilku kilobajtach to niepowodzenie, nie sukces.

A potem właściwy test: wgraj tę kopię raz na instalacji testowej. Nigdy niesprawdzona kopia zapasowa to przypuszczenie.

Przywracanie i haczyk

W darmowej wersji kopii leżącej na zdalnej pamięci nie da się odtworzyć bezpośrednio, przywracanie zdalnych kopii należy do wersji płatnej. Wolna droga działa mimo to i trwa tylko kilka minut dłużej:

1. Ściągnij archiwum z pamięci przez SFTP.
2. We wtyczce w Backup & Restore otwórz obszar Upload i wgraj archiwum.
3. Wgrana kopia pojawia się na liście i stamtąd da się ją przywrócić.

Wlicz to obejście w swój plan awaryjny. Kto w razie awarii pierwszy raz zauważa, że po drodze stoi jeszcze pobieranie, traci niepotrzebnie czas.

Gdzie ta droga się kończy

Każda wtyczka do kopii zapasowych pracuje wewnątrz PHP i natrafia tym samym na granice czasu i pamięci. Od kilku gigabajtów całkowitego rozmiaru staje się to mozolne, a przy bardzo dużych bibliotekach mediów przebieg w którymś momencie się przerywa.

Wtedy lepszą drogą jest rsync albo BorgBackup, oba wprost z harmonogramu na serwerze i oba dostępne na pamięci natywnie:

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub3@u123456.storage.kernelhost.net:/dateien/

To przesyła tylko zmiany i nie zna granic PHP. Zakłada jednak własny serwer z dostępem do powłoki. Więcej o tej drodze znajdziesz w Storage Server na własną stronę internetową.

Które jeszcze części WordPress da się przenieść na pamięć, czyli biblioteka mediów i pliki do pobrania, i gdzie przy tym leżą granice, opisuje Storage Server razem z WordPress.

Cztery najczęstsze błędy

• Port 22 zamiast 23. Wtyczka proponuje 22, nasza pamięć słucha na 23.
• Wyłączona dostępność zewnętrzna. Wtedy test z panelu klienta się udaje, ale nie z serwera WWW.
• Konto główne zamiast subkonta. Dane dostępowe leżą potem w bazie danych strony. Przy koncie głównym wisi na nich wszystko.
• Stare kopie nigdy nie są usuwane. Bez włączonej reguły przechowywania dla zdalnej pamięci miejsce się zapełnia, a w którymś momencie kopia po cichu zawodzi.

Który pakiet pasuje

Na kopie zapasowe jednej strony WordPress Storage-1 z 1 TB za 9,99 euro wystarcza bardzo długo. Dla orientacji: średnia strona o całkowitym rozmiarze 5 GB zajmuje przy dziesięciu przechowywanych kopiach około 50 GB, czyli pięć procent pakietu.

Wszystkie Storage Servery stoją w Niemczech, pozwalają na maksymalnie 100 subkont, obsługują poza SFTP także SMB, WebDAV, rsync i BorgBackup i obywają się bez opłaty aktywacyjnej. Rozliczenie jest w modelu PrePaid bez minimalnego okresu, możesz więc zacząć od małego i rosnąć, gdy dojdzie więcej stron.