Strategia backupu serwera root, która wytrzyma prawdziwą awarię

Lista kontrolna na pierwsze 30 minut kończy się archiwum tar katalogu /etc oraz stwierdzeniem, że to jeszcze nie jest kopia zapasowa, tylko kopia leżąca na tym samym dysku. Dokładnie w tym miejscu zaczyna się ten artykuł: jak zrobić z tego strategię, która przetrwa całkowitą utratę serwera.

Zdanie, wokół którego kręci się cała reszta: backup, z którego nigdy niczego nie przywrócono, nie jest backupem, tylko nadzieją. Wszystko inne służy temu, żeby zamienić tę nadzieję w sprawdzony fakt.

Wszystkie polecenia uruchamiasz jako root. Jako zwykły użytkownik poprzedzasz każde polecenie słowem sudo. Systemy odniesienia to Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS oraz Ubuntu 22.04 LTS. Tam, gdzie te cztery systemy się różnią, jest to wyraźnie zaznaczone.

Zanim cokolwiek zmienisz: droga powrotna

Sam backup psuje się rzadko. Groźne są czynności wokół niego: przywracanie, które nadpisuje działający system, repozytorium zapychające dysk systemowy, pliki kluczy podmieniające twój własny dostęp. Cztery punkty na początek.

1. Poznaj dostęp konsolowy, zanim będzie ci potrzebny

Przy serwerach root KVM oraz serwerach dedykowanych KernelHost konsolę VNC znajdziesz w panelu klienta. Nie zależy ona od stosu sieciowego systemu gościa i odpowiada nawet wtedy, gdy SSH milczy. To jest droga ratunkowa w sytuacji, gdy przywracanie nadpisało aktualny plik sshd_config albo authorized_keys starą wersją. Zaloguj się przez nią raz zawczasu i sprawdź, czy znasz hasło roota.

2. Nigdy nie przywracaj za pierwszym razem prosto do /

Pierwsze przywracanie zawsze trafia do pustego katalogu, na przykład /var/tmp/restore-test. Stamtąd porównujesz pliki i kopiujesz z powrotem wyłącznie to, czego naprawdę potrzebujesz. Wgranie danych wprost do / nadpisze także te pliki, które od czasu backupu zmieniły się z dobrego powodu.

3. Trzymaj otwartą drugą sesję

Dopóki pracujesz nad kluczami SSH albo nad plikiem authorized_keys na serwerze docelowym, obowiązuje ta sama zasada co przy budowaniu firewalla: zostaw otwarty drugi terminal z działającym połączeniem i zamknij go dopiero wtedy, gdy nowe połączenie zadziała.

4. Sprawdź miejsce, zanim repozytorium urośnie

df -h /
df -i /

O drugim wierszu większość zapomina: system plików potrafi się zapełnić także wtedy, gdy wolne są jeszcze gigabajty, mianowicie wtedy, gdy skończą się inody. Lokalne repozytorium zapychające dysk systemowy to jedna z najczęstszych awarii, które administrator funduje sobie sam. Dlatego miejsce docelowe leży tutaj od samego początku poza serwerem.

Reguła 3-2-1 zastosowana do pojedynczego serwera

• Trzy kopie. Dane produkcyjne to już pierwsza kopia. Potrzebujesz więc dwóch backupów, a nie jednego.
• Dwa różne miejsca składowania. Dwa katalogi na tym samym dysku to jedno miejsce, dwa dyski w tym samym RAID również: przypadkowe rm trafia w oba. RAID chroni przed awarią jednego nośnika i przed niczym więcej.
• Jedna kopia w innym miejscu. Nie ten sam serwer, nie to samo konto zarządzania, najlepiej też nie ta sama lokalizacja.

Potrzebne są dwa uzupełnienia. Po pierwsze, jedna kopia powinna leżeć tak, żeby sam serwer nie mógł jej skasować, bo kto przejmie twój serwer, znajdzie na nim dane dostępowe do miejsca docelowego. Po drugie, kopia liczy się dopiero wtedy, gdy została sprawdzona. Obraz systemu w tym samym panelu klienta jest wygodny, ale jako kopia w innym miejscu się nie liczy.

Ustal dodatkowo dwie liczby: ile godzin utraty danych jesteś w stanie przyjąć (to wyznacza odstęp między dwoma przebiegami) oraz jak długo może trwać przywracanie (to przesądza o dodatkowym obrazie systemu).

Co powinno trafić do backupu, a co nie

Najczęstszym błędem nie jest zabezpieczanie zbyt małej ilości danych, tylko zabezpieczanie wszystkiego. Kto zapisuje / bez żadnych wykluczeń, zabiera ze sobą cache pakietów, pliki tymczasowe i swap.

apt-mark showmanual > /root/lista-pakietow.txt
dpkg --get-selections > /root/wybor-pakietow.txt
wc -l /root/lista-pakietow.txt /root/wybor-pakietow.txt

apt-mark showmanual wypisuje wyłącznie pakiety zainstalowane świadomie, bez pociągniętych za nimi zależności: to ta krótka lista, której potrzebujesz przy odbudowie serwera.

Pliki, baza danych, obraz systemu: trzy metody, które się nie zastępują

Wynika z tego kolejność, a nie wybór. Najpierw serwer bazodanowy zapisuje dump, potem rusza backup plików, a katalog z danymi bazy pozostaje wykluczony. Kopia plików z /var/lib/mysql zrobiona podczas pracy bazy obejmuje różne tabele z różnych momentów. Czy da się ją wgrać z powrotem, dowiesz się w najmniej odpowiedniej chwili.

Plik z danymi dostępowymi, uprawnienia i pułapki samego dumpu opisuje Automatyczny backup baz danych MySQL i MariaDB. Ważny jest punkt styku: dumpy lądują w /var/backups/db, zostają tam dzień albo dwa, a za dłuższe przechowywanie odpowiada repozytorium. PostgreSQL zabezpieczasz poleceniem pg_dumpall jako użytkownik postgres.

restic czy Borg

Oba narzędzia dzielą pliki na bloki, identyczne bloki zapisują tylko raz, szyfrują dane i odkładają wersjonowane punkty przywracania. Oba są spakietowane we wszystkich czterech dystrybucjach. Różnica, która przesądza o wyborze, stoi w ostatnim wierszu.

Na magazynie, na którym niczego nie zainstalujesz, Borg odpada. Jeśli masz pod swoją administracją drugi serwer z Linuksem, za Borgiem przemawia tryb append-only.

Konfiguracja z restic

apt update
apt install -y restic
restic version

Sprawdź wynik, zanim założysz repozytorium: te cztery dystrybucje dostarczają bardzo różne wersje, a repozytorium założonego nowszą wersją nie zawsze da się otworzyć starszą.

Dostęp do serwera docelowego

Celem jest tutaj drugi serwer dostępny przez SSH. Klucz należy do roota, bo tylko root może odczytać wszystkie pliki, które mają trafić do backupu:

ssh-keygen -t ed25519 -N '' -f /root/.ssh/id_ed25519_backup -C 'backup srv01'
ssh-copy-id -i /root/.ssh/id_ed25519_backup.pub backup@203.0.113.50

cat > /root/.ssh/config <<'EOF'
Host cel-backupu
    HostName 203.0.113.50
    User backup
    IdentityFile /root/.ssh/id_ed25519_backup
    BatchMode yes
EOF
chmod 600 /root/.ssh/config

Kontrola skuteczności: ssh cel-backupu true przechodzi bez żadnego wyniku i bez pytań. Pierwsze w ogóle połączenie pyta o klucz hosta: odpowiedz na to teraz, a nie później w usłudze, która nie ma na kogo czekać.

Hasło i repozytorium

install -d -m 700 /etc/restic
head -c 32 /dev/urandom | base64 | tr -d '\n' > /etc/restic/repo.pass
chmod 600 /etc/restic/repo.pass

cat > /etc/restic/env <<'EOF'
RESTIC_REPOSITORY=sftp:cel-backupu:/srv/backup/srv01
RESTIC_PASSWORD_FILE=/etc/restic/repo.pass
EOF
chmod 600 /etc/restic/env

Ten plik nadaje się tak samo dla shella, jak i dla systemd. W shellu:

set -a; . /etc/restic/env; set +a
restic init

Kontrola skuteczności: restic cat config wypisuje krótką strukturę JSON z identyfikatorem repozytorium. Jeśli pojawia się pytanie Is there a repository at the following location?, to albo ścieżka się nie zgadza, albo restic init nigdy nie zostało uruchomione.

Pierwszy przebieg

cat > /etc/restic/excludes.txt <<'EOF'
/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/var/lib/apt/lists
/var/lib/mysql
/swapfile
EOF

restic backup / --one-file-system --exclude-file=/etc/restic/excludes.txt --exclude-caches --tag system

--one-file-system trzyma backup na głównym systemie plików i nie zabiera podmontowanych zasobów sieciowych. --exclude-caches pomija katalogi, które same oznaczyły się jako cache. Wykluczenie /var/lib/mysql to realizacja poprzedniego rozdziału.

Kontrola skuteczności: przebieg kończy się wierszem w rodzaju snapshot 0a1b2c3d saved. Potem:

restic snapshots
restic stats latest

Na liście widnieją moment wykonania, nazwa maszyny oraz ścieżki. Jeśli restic stats latest pokazuje nieoczekiwanie mały rozmiar, jakieś wykluczenie sięga za daleko.

To samo z Borgiem

apt install -y borgbackup
borg --version
export BORG_REPO='ssh://backup@203.0.113.50/./srv01'
borg init --encryption=repokey-blake2

borg create --stats --compression zstd ::'system-{now}' /etc /var/www /home /var/backups
borg list
borg info

Wszystkie cztery dystrybucje dostarczają wersję z serii 1.x. Borg musi być obecny po obu stronach, a wersja po stronie celu nie powinna być starsza niż ta na serwerze. Prowadź osobne repozytorium dla każdego serwera: oszczędzi ci to ograniczania sprzątania wyłącznie do archiwów tego jednego serwera i pozwoli na osobne klucze dostępowe.

Kontrola skuteczności: borg list pokazuje archiwum ze znacznikiem czasu, a borg info rozmiar przed deduplikacją i po niej.

Okres przechowywania: dłuższy, niż zakłada większość

Okres przechowywania nie zależy od tego, jak długo chcesz trzymać dane, tylko od tego, ile czasu mija, zanim szkoda zostanie zauważona. Skasowany katalog widać tego samego dnia, uszkodzoną tabelę często dopiero po tygodniach. Kto przechowuje kopie przez siedem dni, ten przez siedem dni zabezpieczał także samą szkodę.

restic forget --dry-run --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Przebieg próbny pokazuje, które punkty przywracania zniknęłyby. Bez --prune znikają wyłącznie odwołania, a miejsce pozostaje zajęte. W Borgu jest to od wersji 1.2 dwuetapowe, a zapomniane drugie polecenie tłumaczy większość repozytoriów, które nie chcą się kurczyć:

borg prune --list --dry-run --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg compact

Kontrola skuteczności: restic snapshots względnie borg list pokazuje oczekiwane stopniowanie, a zajęte miejsce na serwerze docelowym maleje.

Szyfrowanie i klucz, którego potem nikt już nie ma

Oba narzędzia szyfrują dane jeszcze przed opuszczeniem serwera. Serwer docelowy widzi wyłącznie nieczytelne bloki i dopiero to czyni obcy magazyn akceptowalnym. Cena jest jednoznaczna: bez hasła względnie klucza dane są bezpowrotnie stracone. Nie ma żadnego tylnego wejścia.

Wynikają z tego dwie zasady. Po pierwsze, hasło powinno leżeć w drugim miejscu, zwykle w menedżerze haseł. Hasło, które leży wyłącznie w /etc/restic/repo.pass, przepada razem z serwerem, a razem z nim przepada backup. Po drugie, przy Borgu z trybem repokey wyeksportuj klucz i odłóż go poza serwerem, bo w tym trybie leży on w samym repozytorium:

borg key export ::

Kontrola skuteczności: uruchom na innym komputerze restic snapshots, używając hasła z menedżera haseł. Hasło, którego nigdy nie użyłeś z innego miejsca, pozostaje niepotwierdzone.

Zabezpieczenie celu przed skasowaniem

Napastnik z uprawnieniami roota ma dostęp także do zapisanego hasła oraz do klucza do serwera docelowego. Może więc skasować backup, zanim zaszyfruje dane produkcyjne. Dlatego potrzebne jest miejsce składowania, które przyjmuje nowe punkty przywracania, ale nie pozwala niczego kasować. Przy Borgu ustawisz to w pliku authorized_keys użytkownika backupu na serwerze docelowym:

command="borg serve --append-only --restrict-to-path /srv/backup/srv01",restrict ssh-ed25519 AAAA... backup srv01

Klucz przyjmuje odtąd wyłącznie backupy i to tylko w tej jednej ścieżce. Licz się z tym, że prune wprawdzie przebiegnie, ale nie zwolni miejsca, bo kasowanie po stronie celu nie zostanie wykonane. Sprzątanie robisz tam, gdzie serwer nie ma dostępu. Przy restic tę rolę przejmuje serwer REST w trybie append-only albo magazyn obiektowy z wersjonowaniem. Sam dostęp SFTP tego nie zapewnia.

Automatyzacja timerem systemd

Timer jest lepszym wyborem niż cronjob, bo zapisuje wynik do journala, nadrabia pominięte przebiegi i może rozrzucić moment startu. O budowie unitów: Tworzenie własnej usługi systemd.

cat > /etc/systemd/system/backup.service <<'EOF'
[Unit]
Description=Codzienny backup przez restic
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
Nice=10
IOSchedulingClass=idle
ExecStart=/usr/bin/restic backup / --one-file-system --exclude-file=/etc/restic/excludes.txt --exclude-caches --tag system
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF

cat > /etc/systemd/system/backup.timer <<'EOF'
[Unit]
Description=Uruchamia codzienny backup

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now backup.timer
systemd-analyze calendar '*-*-* 02:30:00'

Kilka wierszy ExecStart w unicie typu oneshot wykonuje się po kolei, a niepowodzenie przerywa cały łańcuch. Sprzątanie rusza więc dopiero po udanym backupie. Jeśli celem jest podmontowany system plików, potrzebne jest przed tym zabezpieczenie, inaczej przebieg niepostrzeżenie zapisze dane do pustego punktu montowania:

ExecStartPre=/usr/bin/mountpoint -q /mnt/backup

Kontrola skuteczności:

systemctl start backup.service
systemctl list-timers backup.timer
journalctl -u backup.service -n 50 --no-pager

systemctl list-timers musi wskazać najbliższy czas startu. Jeśli nic tam nie stoi, timer nie jest włączony. Najważniejszy punkt zostaje na koniec: przebieg, który po cichu przestaje działać, to typowy sposób, w jaki backup zawodzi. Sprawdzaj systemctl is-failed backup.service albo dopisz jako ostatni wiersz ExecStart wywołanie zewnętrznej usługi nadzorującej, która podniesie alarm, gdy codzienny znak życia nie dotrze.

Testowanie przywracania

Mały test, co miesiąc, pięć minut

mkdir -p /var/tmp/restore-test
restic restore latest --target /var/tmp/restore-test --include /etc/ssh/sshd_config
diff /etc/ssh/sshd_config /var/tmp/restore-test/etc/ssh/sshd_config && echo "identyczne"

Z Borgiem analogicznie, przy czym zapisuje on ścieżki bez wiodącego ukośnika:

cd /var/tmp/restore-test
borg extract --list ::system-2026-09-03T02:30:00 etc/ssh/sshd_config

Sprawdź dodatkowo integralność repozytorium. Drugi wiersz w każdym z bloków odczytuje dane z powrotem i przelicza sumy kontrolne, przy restic tylko dla części danych, żeby przebieg nie trwał godzinami:

restic check
restic check --read-data-subset=1/7

borg check
borg check --verify-data

Kontrola skuteczności: restic check kończy się komunikatem no errors were found, a borg check bez żadnego komunikatu o błędzie. Repozytorium sprawdzane tylko raz w roku mogło być uszkodzone przez jedenaście miesięcy.

Duży test, raz w roku

Mały test dowodzi, że pliki dają się odczytać. Nie dowodzi, że ponownie uruchomisz usługę. Do tego potrzebny jest pełny przebieg na drugim, pustym serwerze: instalacja systemu bazowego, wgranie listy pakietów, podłączenie repozytorium, ściągnięcie danych, wczytanie dumpu, start usług. Zmierz czas. Ta liczba to twój rzeczywisty czas przywracania, z doświadczenia wielokrotność szacowanego.

Zanotuj, czego zabrakło. To prawie zawsze te same rzeczy: plik spoza zabezpieczanych ścieżek, usługa z konfiguracją w /opt, certyfikat bez klucza konta, baza danych bez użytkowników i uprawnień. Ta lista jest właściwym efektem tego testu.

Typowe błędy i ich rozwiązania

Host key verification failed. Usługa działa jako root, a root nigdy nie potwierdził klucza hosta serwera docelowego. Wykonaj raz ręcznie ssh cel-backupu true albo ssh-keyscan -H 203.0.113.50 >> /root/.ssh/known_hosts. W konsoli działa, w timerze nie: to prawie zawsze ten błąd.

Permission denied (publickey). Zły użytkownik, zły klucz albo złe uprawnienia po stronie celu: .ssh potrzebuje 700, authorized_keys 600, a oba należą do użytkownika docelowego.

Is there a repository at the following location? restic nie znajduje struktury repozytorium: zła ścieżka, nigdy nieuruchomione restic init albo chwilowo nieosiągalny serwer docelowy.

Fatal: wrong password or no key found Plik z hasłem nie pasuje do repozytorium, najczęściej dlatego, że został wygenerowany od nowa już po założeniu repozytorium. Sprawdź poleceniem cat -A /etc/restic/repo.pass, czy nie wkradła się tam spacja.

repository is already locked exclusively by Przerwany przebieg zostawił po sobie blokadę. Najpierw upewnij się, że nic już nie działa, potem uruchom restic unlock. Przy Borgu komunikat brzmi Failed to create/acquire the lock z dopiskiem (timeout), a polecenie to borg break-lock. Oba są ryzykowne, dopóki jakiś przebieg jednak trwa.

Warning: The repository at location ... was previously located at ... Adres repozytorium się zmienił, a Borg dopytuje interaktywnie. W unicie polecenie czeka wtedy na odpowiedź, która nigdy nie nadejdzie. Gdy już sprawdzisz, że chodzi o to samo repozytorium, wpisz BORG_RELOCATED_REPO_ACCESS_IS_OK=yes do pliku ze zmiennymi środowiskowymi.

No space left on device po stronie celu. Albo sprzątanie w ogóle nie działa, albo działa bez --prune względnie bez borg compact. Jeśli natomiast to dump zapełnił główny system plików, dalej pomoże Pełny dysk w Linuksie: jak zwolnić miejsce.

Przebieg zgłasza sukces, ale nie zabezpiecza prawie niczego. Jakieś wykluczenie sięga za daleko albo ścieżka jest źle zapisana. Porównaj restic stats latest z wartością z dnia poprzedniego. Backup nagle mniejszy o rzędy wielkości to alarm, a nie sukces.

Różnice między dystrybucjami

• Nazwy pakietów są takie same na wszystkich czterech systemach: restic oraz borgbackup. Dostarczane wersje już nie.
• Zapis logów: Debian 13 i wiele instalacji Debiana 12 nie zawierają rsysloga. Wynik przebiegu znajdziesz tam wyłącznie w journalu, czyli przez journalctl -u backup.service. Na Ubuntu 22.04 oraz 24.04 dochodzi dodatkowo zapis w /var/log.
• Montowanie punktów przywracania: restic mount oraz borg mount potrzebują pakietu fuse3. Gdy go brakuje, polecenie przerywa pracę z informacją o brakującym fusermount3. Droga bez FUSE to restic restore względnie borg extract.
• Narzędzie bazodanowe: Debian dostarcza wyłącznie MariaDB, a narzędzie nazywa się tam mariadb-dump, przy czym mysqldump jest do niego dowiązaniem. Na Ubuntu może działać także MySQL 8, gdzie istnieje wyłącznie mysqldump.

Kontrola końcowa

Strategia jest gotowa wtedy, gdy potrafisz udowodnić tych siedem punktów poleceniem, a nie przypuszczeniem:

1. restic snapshots albo borg list pokazuje punkt przywracania z dzisiejszej nocy.
2. systemctl list-timers backup.timer wskazuje najbliższy czas startu.
3. restic check albo borg check nie zgłasza żadnego błędu.
4. Pojedynczy plik dał się w tym miesiącu przywrócić i był potem identyczny z oryginałem.
5. Stopniowanie odpowiada zaplanowanemu okresowi przechowywania, a repozytorium nie rośnie w nieskończoność.
6. Hasło leży w drugim miejscu i użyłeś go już stamtąd co najmniej raz.
7. Co najmniej jedno miejsce składowania przyjmuje backupy tak, że serwer nie może ich skasować.

Bez punktu czwartego masz przypuszczenie. Bez punktu szóstego zaszyfrowane śmieci. Bez punktu siódmego backup, który nie przetrwa dokładnie tego ataku, przy którym jest najpilniej potrzebny.