Backup serwera VPS: snapshot, kopia bazy i plików poza serwerem
Snapshot VPS-a zapisuje cały dysk serwera z danego dnia i tak samo go przywraca: w całości. To świetne zabezpieczenie na wypadek nieudanej aktualizacji systemu, ale słabe, gdy potrzebujesz jednego pliku albo bazy sprzed kilku godzin. Dlatego backup VPS warto zbudować na dwóch poziomach: snapshot od dostawcy plus własna kopia bazy i plików, trzymana poza serwerem.
Poniżej pokazujemy oba poziomy na przykładzie VPS-a z Debianem lub Ubuntu, serwerem WWW i bazą MariaDB.
Snapshot a kopia plików: co naprawdę odzyskasz
Snapshot to obraz całej maszyny. Przywracasz go, gdy serwer przestał działać po zmianie konfiguracji, aktualizacji jądra albo po włamaniu, po którym nie ufasz już niczemu na dysku.
Kopia plików i bazy działa inaczej. Z archiwum wyciągasz jeden katalog, jedną tabelę albo stary plik konfiguracyjny, a reszta serwera zostaje taka, jaka jest. Przykład: klient sklepu składa zamówienie o 14:00, a o 16:00 ktoś usuwa produkty. Cofnięcie całego serwera do snapshotu z nocy zabierze też to zamówienie.
W serwerach VPS RapidDC backup działa jako rozwiązanie hybrydowe: kopia powstaje na zewnętrznym storage’u, ale przywracasz wyłącznie cały obraz z danego dnia, bez pojedynczych plików. Tak to opisuje cennik i dlatego drugi poziom kopii jest potrzebny.
Krok 1. Dobierz plan snapshotów do tempa zmian
Plan backupu dokładasz przy zamówieniu VPS-a albo później do działającej usługi. Ceny netto (plus 23% VAT) z cennika RapidDC:
| Plan | Automatyczne snapshoty | Ręczne snapshoty | Przechowywane kopie | Odtworzenia w miesiącu | Cena netto |
|—|—|—|—|—|—|
| Standard | 1x w miesiącu | 1x w miesiącu | 1 | 1 | 9 zł/mies. |
| Plus | 1x w miesiącu | 2x w miesiącu | 2 | 4 | 14 zł/mies. |
| Extra | 4x w miesiącu | 5x w miesiącu | 8 | 10 | 27 zł/mies. |
| Mega | 4x w miesiącu | 10x w miesiącu | 10 | bez limitu | 45 zł/mies. |
Przy jednym backupie w miesiącu snapshot powstaje pierwszego dnia miesiąca, przy czterech w każdą niedzielę.
Jak wybrać? Jeśli na serwerze stoi środowisko testowe, które odtworzysz z repozytorium, wystarczy Standard. Sklep albo aplikacja z danymi klientów zmienia się codziennie, więc tu lepiej sprawdzi się Extra: cotygodniowy obraz i kilka ręcznych snapshotów przed większymi zmianami. Ręczny snapshot zrób zawsze przed aktualizacją systemu, zmianą wersji PHP czy migracją bazy.
Krok 2. Skrypt z kopią bazy i plików
Zaloguj się na serwer (jak połączyć się z VPS przez SSH) i utwórz plik /usr/local/bin/backup.sh:
#!/bin/bash
set -euo pipefail
DATA=$(date +%F)
KATALOG=/var/backups/serwer
mkdir -p "$KATALOG"
# baza danych: wszystkie bazy, spójny zrzut bez blokowania tabel InnoDB
mysqldump --single-transaction --routines --all-databases | gzip > "$KATALOG/baza-$DATA.sql.gz"
# pliki aplikacji i konfiguracja
tar -czf "$KATALOG/pliki-$DATA.tar.gz" /var/www /etc/nginx
# rotacja: usuń lokalne kopie starsze niż 7 dni
find "$KATALOG" -type f -mtime +7 -delete
Nadaj uprawnienia: chmod 700 /usr/local/bin/backup.sh. Na Debianie z MariaDB użytkownik root łączy się z bazą przez socket, więc skrypt uruchomiony jako root nie potrzebuje hasła. Na MySQL albo innym użytkowniku zapisz dane logowania w pliku ~/.my.cnf z uprawnieniami 600, nie w samym skrypcie.
Linia set -o pipefail ma znaczenie. Bez niej błąd mysqldump zostałby ukryty przez gzip i dostałbyś pusty, ale „udany” plik. Więcej o zrzutach i przywracaniu samej bazy znajdziesz we wpisie jak wykonać backup bazy danych i przywrócić kopię.
Uruchamiaj skrypt co noc przez cron (crontab -e):
30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
Krok 3. Wyślij kopię poza serwer
Kopia na tym samym dysku nie pomoże, gdy padnie cały VPS albo ktoś przejmie do niego dostęp. Potrzebujesz drugiej lokalizacji: innego serwera, NAS-a w biurze albo zewnętrznej przestrzeni dyskowej. Tę zasadę szerzej opisuje wpis o modelu backupu 3-2-1.
Najbezpieczniejszy wariant to kopia pobierana przez serwer zapasowy, a nie wysyłana przez VPS. Wtedy włamywacz na VPS-ie nie ma dostępu do archiwów. Na serwerze zapasowym:
ssh-keygen -t ed25519 -f ~/.ssh/vps_backup -N ""
ssh-copy-id -i ~/.ssh/vps_backup.pub root@ADRES_VPS
I wpis w cronie serwera zapasowego, godzinę po skrypcie na VPS-ie:
30 4 * * * rsync -a -e "ssh -i ~/.ssh/vps_backup" root@ADRES_VPS:/var/backups/serwer/ /backup/vps1/
rsync bez opcji --delete nie usuwa starszych archiwów po stronie zapasowej, więc tam trzymasz dłuższą historię. Ustaw na tym serwerze własną rotację, na przykład 30 dni, żeby dysk się nie zapełnił.
Krok 4. Sprawdź odtworzenie
Dopóki nie przywrócisz kopii, nie wiesz, czy działa. Raz w miesiącu weź najnowsze archiwa i odtwórz je na osobnej maszynie, na przykład na tanim VPS-ie testowym:
gunzip < baza-2026-09-17.sql.gz | mysql
mkdir -p /tmp/test && tar -xzf pliki-2026-09-17.tar.gz -C /tmp/test
Sprawdź, czy strona startuje, czy w bazie są wczorajsze rekordy i czy archiwum nie ma zerowego rozmiaru. Zajrzyj też do /var/log/backup.log: jeśli skrypt od tygodnia kończy się błędem, lepiej dowiedzieć się o tym teraz.
Podsumowanie
Snapshot chroni serwer jako całość, własna kopia chroni dane, a druga lokalizacja chroni obie przed awarią jednej maszyny. Cała konfiguracja to kilka kroków: plan snapshotów w panelu, skrypt z mysqldump i tar, cron, rsync na serwer zapasowy i comiesięczny test odtworzenia.
Szukasz serwera pod projekt z ważnymi danymi? Zobacz serwery VPS RapidDC: pełna wirtualizacja KVM i plany backupu do dobrania przy zamówieniu. Aktualne kody rabatowe znajdziesz na stronie promocji.
FAQ – najczęściej zadawane pytania o backup serwera VPS
Czy snapshot VPS-a wystarczy jako jedyny backup?
Wystarczy dla serwera, który w każdej chwili odtworzysz z repozytorium i nie trzyma danych klientów. Dla sklepu czy aplikacji dołóż kopię bazy i plików, bo snapshot przywraca tylko cały obraz z danego dnia, a zmiany od ostatniego snapshotu przepadają.
Jak często robić kopię bazy danych na VPS?
Tak często, ile danych możesz stracić bez szkody. Dla większości sklepów i aplikacji punktem wyjścia jest kopia co noc. Jeśli zamówienia albo rekordy spływają przez cały dzień, dodaj zrzut co kilka godzin, a przed każdą większą zmianą zrób ręczny snapshot.
Czy mogę trzymać kopie zapasowe na tym samym VPS-ie?
Jako kopię roboczą do szybkiego przywrócenia pliku tak. Jako jedyną kopię nie: awaria dysku, pomyłka z rm albo włamanie zabiorą serwer razem z archiwami. Przynajmniej jedna kopia musi leżeć na innej maszynie.
Czy z planu backupu RapidDC odzyskam pojedynczy plik?
Nie. Backup VPS w RapidDC to rozwiązanie hybrydowe, które przywraca cały obraz zapisany danego dnia. Pojedyncze pliki i tabele odzyskasz z własnej kopii, opisanej w krokach 2 i 3.
Jak sprawdzić, czy backup w ogóle działa?
Czytaj log skryptu i raz w miesiącu odtwórz kopię na osobnej maszynie. Sprawdź rozmiar archiwów, czy baza się importuje i czy zawiera świeże rekordy. Błąd znaleziony podczas testu kosztuje mniej niż ten sam błąd odkryty po awarii.
Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu RapidDC. Grafika ilustracyjna została wygenerowana przez AI.