Praktyczna strategia kopii zapasowych VPS (reguła 3-2-1)

Napisane przez zespół ApexVPS • Ostatnia aktualizacja: lipiec 2026 • 7 min czytania

Niezawodna strategia kopii zapasowych VPS to różnica między pięciominutowym odzyskaniem a bardzo złym tygodniem. Serwery zawodzą, dyski ulegają uszkodzeniu, wdrożenia idą źle, a jedna błędnie wpisana komenda może wyczyścić katalog. Centrum edukacyjne Cloudflare i większość zespołów infrastrukturalnych wskazuje na tę samą prostą zasadę: regułę 3-2-1. Ten przewodnik pokazuje, jak zastosować ją na prawdziwym serwerze wirtualnym, jakich narzędzi użyć oraz jak zaplanować i przetestować wszystko, aby przywracanie danych faktycznie zadziałało, gdy będzie potrzebne.

Co oznacza reguła 3-2-1

Reguła 3-2-1 to wieloletnia zasada tworzenia kopii zapasowych, która pozostaje aktualna niezależnie od tego, gdzie mieszka Twój serwer:

Na VPS zwykle oznacza to Twój działający serwer, lokalne repozytorium kopii zapasowych oraz zaszyfrowaną kopię wysyłaną do zdalnego magazynu w innej lokalizacji. Chodzi o redundancję bez jednego wspólnego punktu awarii.

Co należy archiwizować na VPS

Tworzenie kopii całego dysku blok po bloku jest kosztowne i powolne. Dobry plan kopii zapasowych obejmuje trzy rzeczy, które są naprawdę trudne do odtworzenia.

Dane aplikacji i pliki

Przesłane pliki, katalogi główne witryn, woluminy kontenerów i wszystko, co generują użytkownicy. Typowe ścieżki to /var/www, /srv, /home oraz katalog wolumenów Dockera. Jeśli samodzielnie hostujesz aplikacje, takie jak serwer plików lub wiki, tutaj znajdują się Twoje niezastąpione treści — zobacz nasz przewodnik po uruchamianiu VPS do samodzielnego hostowania, aby dowiedzieć się, jak zwykle rozmieszczone są te katalogi.

Bazy danych

Nigdy nie kopiuj plików bazy danych, gdy usługa działa — możesz przechwycić niekompletny, uszkodzony stan. Zamiast tego wyeksportuj spójny zrzut. Dla MySQL lub MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

Flaga --single-transaction daje spójny snapshot tabel InnoDB bez ich blokowania. Dla PostgreSQL użyj natomiast pg_dump:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

Konfiguracja systemu i usług

Pliki, które czynią Twój serwer Twoim: /etc (nginx, jednostki systemd, cron, konfiguracja SSH), listy pakietów, certyfikaty TLS i reguły zapory. Odtwarzanie ich z pamięci po awarii to dokładnie ta żmudna praca, której kopie zapasowe mają uniknąć.

Wybór narzędzi do tworzenia kopii zapasowych

Trzy narzędzia pokrywają prawie wszystkie przypadki VPS. Wybierz w zależności od tego, jak bardzo cenisz deduplikację i szyfrowanie.

restic — szyfrowane, deduplikowane snapshoty

restic to nowoczesne, pojedyncze narzędzie do tworzenia kopii zapasowych, które domyślnie szyfruje i deduplikuje. Zainicjalizuj repozytorium raz, a następnie uruchamiaj kopie zapasowe:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — deduplikujące archiwa

BorgBackup oferuje podobną deduplikację i kompresję przy nieco innym przepływie pracy:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — proste lustrzane kopiowanie plików

Gdy potrzebujesz szybkiego lustra plików na innym hoście, rsync przez SSH jest trudne do pobicia:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

Flagi -aAX zachowują uprawnienia, ACL i rozszerzone atrybuty; --delete utrzymuje lustro w synchronizacji ze źródłem. Sam rsync nie przechowuje historii wersji, dlatego wiele zespołów łączy go z restic lub borg.

Automatyzacja harmonogramu za pomocą crona

Kopia zapasowa, o której trzeba pamiętać, to kopia, której nie będzie. Umieść kroki w skrypcie, nadaj mu uprawnienia do wykonywania i zaplanuj go w cronie. Edytuj crontab za pomocą:

crontab -e

Następnie dodaj linie takie jak te:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Rejestruj dane wyjściowe i spraw, aby skrypt kończył się kodem niezerowym w przypadku błędu, aby można było podłączyć go do funkcji monitorowania i alertów dostępnych w Twoim planie. Cicha awaria kopii zapasowej jest gorsza niż brak kopii, ponieważ daje poczucie bezpieczeństwa.

Zachowaj prawdziwą kopię poza lokalizacją

"1" w zasadzie 3-2-1 to część, którą większość ludzi pomija. Kopia zapasowa przechowywana na tym samym serwerze, który chroni, znika wraz z tym serwerem. Wyślij zaszyfrowaną kopię gdzieś niezależnie — do magazynu obiektów, zdalnego serwera SFTP lub innego dostawcy. restic i borg zapisują bezpośrednio do zdalnych repozytoriów, na przykład przez SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Ponieważ restic i borg szyfrują dane przed opuszczeniem Twojego VPS, zdalny host nigdy nie widzi Twoich danych jawnych. Przycinaj stare snapshoty według polityki, aby pamięć nie rosła w nieskończoność:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Testuj swoje przywracanie — za każdym razem

Nietestowana kopia zapasowa to plotka. Zaplanuj okresowe przywracanie do tymczasowej lokalizacji i potwierdź, że pliki i bazy danych wracają w nienaruszonym stanie:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Jeśli przywracanie się powiedzie, a dane będą się zgadzać, masz strategię. Jeśli nie, właśnie dowiedziałeś się tego we wtorek po południu, zamiast podczas prawdziwej awarii.

Migawki to jedna warstwa, nie cała strategia

Każdy plan ApexVPS obejmuje automatyczne kopie zapasowe — codzienne migawki w Starter Pro i godzinne w Business — i są one naprawdę przydatne do szybkich przywracań po złym wdrożeniu lub przypadkowym usunięciu. Ale bądź ze sobą szczery, czym są: wygodną pierwszą warstwą, która znajduje się na naszej platformie. Nie zastępują one offsite'owej, niezależnie zweryfikowanej kopii, której wymaga reguła 3-2-1. Traktuj migawki platformy jako szybki lokalny punkt przywracania i uruchom własną pracę restic lub borg, aby spełnić części reguły dotyczące offsite i testowania przywracania. Takie warstwowe podejście odróżnia optymistyczną konfigurację od odpornej, niezależnie od tego, czy hostujesz aplikacje takie jak Nextcloud, czy prowadzisz produkcyjną bazę danych.

Lista kontrolna strategii kopii zapasowych VPS

Składając wszystko w całość, kompletna strategia kopii zapasowych dla serwera wirtualnego wygląda tak. Przejdź przez nią raz, zaskryptuj ją i pozwól cronowi ją kontynuować:

Wykonaj te sześć rzeczy, a reguła 3-2-1 przestanie być teorią, a stanie się nawykiem, na którym może polegać Twoja infrastruktura. Godzina konfiguracji na początku to nic w porównaniu z kosztem odkrycia w trakcie awarii, że Twoja jedyna kopia znajdowała się na dysku, który właśnie padł.

Potrzebujesz serwera, który w pełni kontrolujesz, aby to uruchomić? ApexVPS daje Ci pełny dostęp root, pamięć NVMe i dedykowane zasoby w 39 centrach danych — z płatnością tylko kryptowalutą, bez karty i bez KYC. Porównaj dedykowane plany VPS →

Często zadawane pytania

Czy migawki dostawcy liczą się jako strategia kopii zapasowych?

Migawki to jedna przydatna warstwa, ale nie kompletna strategia. Nasze codzienne i godzinne migawki chronią przed większością krótkoterminowych błędów, ale znajdują się na tej samej platformie co Twój serwer. Pełna strategia 3-2-1 nadal wymaga niezależnej, offsite'owej kopii, którą kontrolujesz, oraz przywracań, które faktycznie przetestowałeś.

Jak często należy wykonywać kopie zapasowe VPS?

Dopasuj częstotliwość do ilości danych, których utratę możesz sobie pozwolić. Pliki statyczne i konfiguracje można archiwizować codziennie, a aktywne bazy danych często uzasadniają zrzuty co godzinę. Użyj crona, aby zautomatyzować harmonogram, aby kopie zapasowe nigdy nie zależały od pamiętania o ich uruchomieniu.

Jakie jest najlepsze narzędzie do kopii zapasowych VPS?

restic i BorgBackup są doskonałe: deduplikują, kompresują i szyfrują kopie oraz obsługują repozytoria offsite. rsync nadaje się do prostego mirrorowania plików, a mysqldump lub pg_dump obsługują eksport baz danych. Wiele konfiguracji łączy zrzut bazy danych z uruchomieniem restic lub borg.

Skąd mam wiedzieć, że moje kopie zapasowe faktycznie działają?

Testuj przywracanie zgodnie z harmonogramem. Przywróć do tymczasowego katalogu, zweryfikuj zawartość plików i sumy kontrolne oraz zaimportuj zrzut bazy danych do testowej bazy. Kopia, której nigdy nie przywróciłeś, to tylko optymistyczne przypuszczenie, a nie plan odzyskiwania.