Kopie zapasowe VPS: co archiwizujemy my i jak zrobić własne

Kopiami zapasowymi VPS zarządzamy my, a w strefie klienta możesz z nich przywrócić cały dysk. Dla pojedynczych plików, baz danych i kopii poza naszą infrastrukturą konfigurujesz własne kopie zapasowe. Pokażemy jedno i drugie.

Automatyczne kopie zapasowe StormHost#

Kopie zapasowe VPS tworzymy automatycznie. Znajdziesz je w strefie klienta: Moje usługi › Twój VPS › zakładka Kopie zapasowe.

• Przy każdej kopii lista pokazuje Utworzono (data i godzina), Rozmiar i Magazyn, w którym jest przechowywana.
• Kopii nie da się utworzyć ręcznie z strefy klienta. Przed ryzykowną zmianą (aktualizacja systemu, duża zmiana konfiguracji) zrób własną kopię zgodnie z resztą tego poradnika.
• Jeśli widzisz „Jeden z magazynów kopii zapasowych teraz nie odpowiada — lista może być niepełna”, część kopii jest tymczasowo niedostępna. Spróbuj później albo skontaktuj się z nami.
• Członek współdzielonej usługi widzi kopie tylko z uprawnieniem Kopie zapasowe i przywracanie.

Przywracanie całego VPS#

1. W zakładce Kopie zapasowe znajdź kopię po dacie w kolumnie Utworzono.
2. Kliknij Przywróć.
3. Przeczytaj ostrzeżenie i potwierdź je, przesuwając suwak („Przesuń, aby przywrócić”).
4. Poczekaj na zakończenie. Podczas przywracania VPS jest wyłączony i zablokowany, a konsola się nie połączy.
5. Po przywróceniu uruchom VPS (jeśli nie wystartuje sam) i sprawdź swoje usługi.

Pełne przywracanie czy pojedyncze pliki?#

Zasada 3-⁠2-⁠1#

Sprawdzona zasada kopii zapasowych: 3 kopie danych, w 2 różnych miejscach lub typach nośników, z czego 1 poza główną infrastrukturą.

Dla VPS oznacza to:

1. Dane na VPS (kopia pierwotna).
2. Nasze automatyczne kopie zapasowe (druga kopia, poza Twoim VPS).
3. Twoja własna kopia gdzie indziej: domowy NAS, inny serwer, chmura (trzecia kopia, poza naszą infrastrukturą).

Trzecia kopia chroni Cię nawet wtedy, gdy przywracanie w strefie klienta nie pomoże: potrzebujesz starszego stanu, jednego pliku albo chcesz się przenieść.

Co archiwizować#

Skrypt kopii zapasowej#

Skrypt codziennie eksportuje wszystkie bazy danych, pakuje ważne katalogi i usuwa kopie starsze niż 7 dni.

1. Utwórz plik skryptu:

   nano /usr/local/sbin/zaloha.sh

2. Wklej zawartość:

   #!/bin/bash
   set -euo pipefail
   umask 077
   
   CIL=/var/backups/vps
   DNES=$(date +%F)
   UCHOVAT_DNI=7
   
   mkdir -p "$CIL"
   
   # 1) bazy danych (tylko jeśli zainstalowano MariaDB/MySQL)
   if command -v mariadb-dump >/dev/null 2>&1; then
     mariadb-dump --single-transaction --routines --events --all-databases | gzip > "$CIL/db-$DNES.sql.gz"
   fi
   
   # 2) pliki
   tar -czf "$CIL/soubory-$DNES.tar.gz" --ignore-failed-read /etc /home /root /var/www /opt /srv || [ $? -eq 1 ]
   
   # 3) usuwanie starych kopii
   find "$CIL" -type f -name '*.gz' -mtime +"$UCHOVAT_DNI" -delete
   
   echo "$(date '+%F %T') kopia zapasowa gotowa"

3. Zapisz (Ctrl+O, Enter), zamknij (Ctrl+X) i nadaj uprawnienie do wykonywania:

   chmod 700 /usr/local/sbin/zaloha.sh

   • chmod 700 – tylko root może czytać i uruchamiać skrypt.

Co robi skrypt:

4. Wypróbuj skrypt ręcznie:

   /usr/local/sbin/zaloha.sh
   ls -lh /var/backups/vps

   Zobaczysz kopia zapasowa gotowa oraz pliki db-….sql.gz i soubory-….tar.gz. Komunikat tar: Removing leading '/' from member names jest normalny: ścieżki są zapisywane w archiwum bez początkowego ukośnika.

Automatyczne uruchamianie przez cron#

1. Upewnij się, że cron jest zainstalowany (jeśli już jest, nic się nie stanie):

   apt -y install cron

2. Otwórz crontab roota:

   crontab -e

   Przy pierwszym uruchomieniu wybierz edytor nano.

3. Dodaj tę linię na końcu:

   30 3 * * * /usr/local/sbin/zaloha.sh >> /var/log/zaloha.log 2>&1

4. Zapisz i zamknij edytor. Zobaczysz crontab: installing new crontab.

Linia crontaba ma pięć pól czasu i polecenie:

Więcej przykładów czasu:

Czasy odnoszą się do strefy czasowej VPS (timedatectl). Kopie zaplanuj na porę, gdy serwer ma najmniejszy ruch.

Kopiowanie poza VPS#

Przygotowanie dostępu SSH do serwera docelowego#

Wysyłaj kopie na inny serwer (domowy NAS z SSH, inny VPS). W przykładach serwer docelowy ma adres IP 198.51.100.25; użyj adresu własnego serwera.

Na serwerze docelowym (Ubuntu lub Debian, zalogowany jako root) utwórz użytkownika i katalog, do którego może pisać:

adduser zaloha
mkdir -p /srv/zalohy
chown zaloha:zaloha /srv/zalohy
chmod 700 /srv/zalohy

• adduser zaloha – tworzy użytkownika zaloha. Pyta o hasło (będzie potrzebne w kroku 2 niżej) i o opcjonalne dane, które możesz pominąć klawiszem Enter.
• mkdir -p /srv/zalohy – katalog kopii.
• chown zaloha:zaloha – katalog należy do użytkownika zaloha, aby mógł tam pisać. Bez tego zarówno rsync, jak i restic kończą się Permission denied.
• chmod 700 – nikt inny nie ma dostępu do katalogu.

Logowanie hasłem musi być na serwerze docelowym dozwolone przynajmniej do przesłania klucza (krok 2). Na NAS-ie postępuj według jego instrukcji (użytkownik, folder udostępniony, włączone SSH).

Następnie na archiwizowanym VPS:

1. Utwórz klucz SSH bez hasła, używany tylko do kopii zapasowych:

   ssh-keygen -t ed25519 -f /root/.ssh/zaloha -N "" -C "zaloha-vps"

   • -t ed25519 – nowoczesny typ klucza.
   • -f /root/.ssh/zaloha – gdzie zapisać klucz (tworzy zaloha i zaloha.pub).
   • -N "" – bez hasła klucza, aby cron mógł go używać bez Ciebie.
   • -C "zaloha-vps" – etykieta klucza.

2. Prześlij klucz publiczny na serwer docelowy (wpiszesz hasło użytkownika zaloha na serwerze docelowym):

   ssh-copy-id -i /root/.ssh/zaloha.pub [email protected]

   Przy pierwszym połączeniu SSH pyta Are you sure you want to continue connecting (yes/no/[fingerprint])?. Wpisz yes: odcisk serwera docelowego zapisze się w /root/.ssh/known_hosts, a cron nie będzie już pytany.

3. Utwórz skrót połączenia. Otwórz nano /root/.ssh/config i dodaj:

   Host zalohy
       HostName 198.51.100.25
       User zaloha
       IdentityFile /root/.ssh/zaloha

   • Host zalohy – skrót, którego użyjesz zamiast adresu.
   • HostName – adres IP lub domena serwera docelowego.
   • User – użytkownik na serwerze docelowym.
   • IdentityFile – klucz używany do logowania.

4. Przetestuj połączenie: ssh zalohy musi zalogować bez hasła. Wyloguj się przez exit.

Szczegóły pracy z kluczami: Klucz SSH.

rsync#

rsync kopiuje tylko zmienione pliki, więc jest szybki nawet przy dużych kopiach. Musi być zainstalowany po obu stronach (apt -y install rsync).

rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/

• -a – tryb archiwalny: kopiuje rekurencyjnie i zachowuje uprawnienia, czasy i dowiązania.
• -z – kompresuje dane podczas transferu.
• /var/backups/vps/ – co kopiować. Ukośnik na końcu oznacza „zawartość katalogu”, nie sam katalog.
• zalohy:/srv/zalohy/vps1/ – cel: skrót z ~/.ssh/config i katalog na serwerze docelowym.

Dodaj transfer jako ostatnią linię zaloha.sh albo do crontaba godzinę po kopii:

30 4 * * * rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/ >> /var/log/zaloha.log 2>&1

restic (dla zaawansowanych)#

restic przechowuje kopie zaszyfrowane i z deduplikacją: powtarzające się dane są zapisywane tylko raz, więc możesz trzymać dziesiątki dziennych wersji przy małym zużyciu miejsca. Potrafi archiwizować na serwer SFTP, jak i do chmury.

1. Zainstaluj restic: apt -y install restic.

2. Utwórz plik z hasłem repozytorium i ogranicz jego uprawnienia:

   nano /root/.restic-heslo
   chmod 600 /root/.restic-heslo

   Wpisz do pliku długie losowe hasło (generator haseł).

3. Utwórz repozytorium na serwerze docelowym:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo init

   • -r sftp:zalohy:/srv/zalohy/restic-vps1 – repozytorium przez SFTP; zalohy to skrót z ~/.ssh/config.
   • --password-file – plik z hasłem, aby restic nie pytał (wymagane dla crona).
   • init – tworzy nowe puste repozytorium. Zobaczysz created restic repository ….

4. Zarchiwizuj (to polecenie możesz umieścić w skrypcie zamiast archiwum tar; eksport bazy zostaw):

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo backup /etc /home /root /var/www /opt /srv /var/backups/vps

5. Usuwaj stare wersje według polityki:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

   • forget – usuwa wersje (snapshoty), których polityka nie zachowuje.
   • --keep-daily 7 – zachowuje najnowszą wersję z każdego z ostatnich 7 dni, które mają kopię.
   • --keep-weekly 4, --keep-monthly 6 – dodatkowo jedną wersję na tydzień przez 4 tygodnie i jedną na miesiąc przez 6 miesięcy.
   • --prune – od razu usuwa dane, do których nie odwołuje się już żadna wersja (zwalnia miejsce).

Przydatne polecenia:

Alternatywą dla restic jest BorgBackup (dokumentacja (otwiera się w nowym oknie)), działający na podobnej zasadzie.

Test przywracania#

Kopia, której nigdy nie próbowano przywrócić, to tylko nadzieja. Testuj ją od czasu do czasu:

1. Wypisz zawartość archiwum: tar -tzf /var/backups/vps/soubory-2026-10-01.tar.gz | head.

2. Rozpakuj pojedynczy plik do katalogu tymczasowego:

   mkdir -p /tmp/obnova
   tar -xzf /var/backups/vps/soubory-2026-10-01.tar.gz -C /tmp/obnova etc/nginx/nginx.conf

   • -x – rozpakuj, -z – format gzip, -f – z pliku.
   • -C /tmp/obnova – dokąd rozpakować (aby nie nadpisać działającego pliku).
   • etc/nginx/nginx.conf – co rozpakować (ścieżka bez początkowego ukośnika).

3. Sprawdź eksport bazy: zcat /var/backups/vps/db-2026-10-01.sql.gz | head -n 20 musi pokazać początek eksportu SQL.

4. Pełny test (przywrócenie bazy, uruchomienie aplikacji) zrób na osobnym testowym VPS, nie na produkcyjnym.

Weryfikacja#

• Rano po pierwszej nocy: tail /var/log/zaloha.log zawiera linię kopia zapasowa gotowa.
• ls -lh /var/backups/vps pokazuje nowe pliki z dzisiejszą datą i sensownym rozmiarem (nie 0 bajtów).
• Serwer docelowy ma te same pliki (rsync) albo restic snapshots pokazuje dzisiejszą wersję.

Rozwiązywanie problemów#

Cron nie uruchomił skryptu#

Sprawdź, czy cron działa i co zapisał do logu:

systemctl status cron
journalctl -u cron -n 50

Częste przyczyny: w crontabie brakuje pełnej ścieżki do skryptu, skrypt nie jest wykonywalny (chmod 700) albo edytowano crontab innego użytkownika niż root (crontab -l go wypisuje).

mariadb-dump: Got error: 1045: "Access denied for user …"#

Skrypt nie działa jako root albo root bazy używa hasła zamiast unix socketu. Uruchamiaj skrypt z crontaba roota. Jeśli root ma hasło do bazy, zapisz je w /root/.my.cnf, skąd mariadb-dump czyta je automatycznie:

[client]
user=root
password=<HASLO_ROOT_BAZY_DANYCH>

• [client] – grupa opcji dla wszystkich programów klienckich MariaDB (mariadb, mariadb-dump).
• user, password – dane logowania. Zamiast <HASLO_ROOT_BAZY_DANYCH> wstaw hasło użytkownika bazy root (bez nawiasów ostrych).

Zabezpiecz plik przez chmod 600 /root/.my.cnf, aby nikt inny nie mógł odczytać hasła.

Kopia ma 0 bajtów albo jest podejrzanie mała#

Skrypt zakończył się w połowie. Uruchom go ręcznie i przeczytaj błąd. Dzięki set -euo pipefail błąd eksportu nie przejdzie niezauważony.

Permission denied (publickey) przy rsync lub restic#

Serwer docelowy nie przyjął klucza. Przetestuj ssh zalohy. Jeśli pyta o hasło albo się nie udaje, prześlij klucz ponownie (ssh-copy-id) i sprawdź, czy IdentityFile w /root/.ssh/config wskazuje właściwy plik.

restic: Fatal: wrong password or no key found#

Hasło w /root/.restic-heslo nie pasuje do repozytorium. Sprawdź, czy plik nie zawiera zbędnej spacji ani innego hasła.

restic: Fatal: unable to open config file … Is there a repository at the following location?#

Pod podaną ścieżką nie ma repozytorium (literówka w ścieżce albo nie uruchomiono init).

Dysk się zapełnia#

Kopie nie są usuwane albo są za duże. Sprawdź, czy krok find … -delete się wykonuje, zmniejsz UCHOVAT_DNI i pomiń katalogi z dużymi danymi, które archiwizujesz inaczej.

Dalsza lektura#

• restic: dokumentacja (otwiera się w nowym oknie)
• BorgBackup: dokumentacja (otwiera się w nowym oknie)
• rsync: strona podręcznika (otwiera się w nowym oknie)
• crontab(5): format crontaba (otwiera się w nowym oknie)
• MariaDB: mariadb-dump (otwiera się w nowym oknie)