Kopie zapasowe z restic

Moduł 8: Kopie zapasowe i monitorowanie · Czas czytania: 12 min

Cel lekcji: Po tej lekcji będą Państwo potrafili za pomocą restic tworzyć szyfrowane kopie zapasowe w magazynie poza serwerem, usuwać stare wersje według harmonogramu przechowywania, weryfikować kopię i przywracać pliki, a także uruchamiać cały proces automatycznie.

Kluczowe pojęcia: restic, repozytorium, init, hasło (plik z hasłem), backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, deduplikacja, append-only, timer systemd

Dlaczego restic?

Programów do kopii zapasowych jest wiele. restic to dobry wybór dla własnego serwera, ponieważ:

• szyfruje wszystko, zanim dane opuszczą serwer; magazyn widzi tylko nieczytelne bloki;
• stosuje deduplikację: plik, który się nie zmienił, nie jest zapisywany ponownie, więc codzienne kopie zajmują mało miejsca;
• obsługuje wiele rodzajów magazynów: katalog, inny serwer przez SFTP, magazyn zgodny z S3, własny rest-server;
• jest jednym programem, dostępnym w repozytorium pakietów Debiana i Ubuntu (apt install restic).

Alternatywą o podobnych cechach jest BorgBackup. Zasady z tej lekcji obowiązują również tam.

Pojęcia

• Repozytorium: miejsce, w którym restic przechowuje kopie zapasowe. Zawsze poza serwerem, którego kopię Państwo tworzą.
• Snapshot: jedna kopia zapasowa z jednego momentu. (Uwaga: to coś innego niż snapshot u Państwa dostawcy, o którym mowa w lekcji 8.1.)
• Hasło: każde repozytorium ma hasło, którym wszystko jest szyfrowane. Dokumentacja restic jasno to podkreśla: kto utraci hasło, ten bezpowrotnie traci dane.

Tworzenie repozytorium

Załóżmy, że mają Państwo serwer magazynowy backup.example.net, do którego mają Państwo dostęp przez SFTP za pomocą klucza, jako użytkownik web1. Najpierw prosimy utworzyć na serwerze plik z hasłem (i zapisać to samo hasło w menedżerze haseł, lekcja 8.1):

root@web1:~# install -m 600 /dev/null /root/.restic-wachtwoord
root@web1:~# openssl rand -base64 32 > /root/.restic-wachtwoord
root@web1:~# export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
root@web1:~# export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
root@web1:~# restic init
created restic repository 5f1a9c2e3b at sftp:web1@backup.example.net:/srv/restic/web1

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Dzięki zmiennym środowiskowym RESTIC_REPOSITORY i RESTIC_PASSWORD_FILE nie trzeba za każdym razem wpisywać opcji -r i --password-file.

Tworzenie kopii zapasowej

Najpierw zrzut bazy danych (lekcja 8.1), potem kopia zapasowa:

root@web1:~# restic backup /etc /var/www /opt /var/backups/db \
    --exclude /var/www/*/cache --tag dagelijks
repository 5f1a9c2e opened (version 2, compression level auto)
...
Files:        8421 new,     0 changed,     0 unmodified
Dirs:         1203 new,     0 changed,     0 unmodified
Added to the repository: 612.338 MiB (402.117 MiB stored)

processed 8421 files, 1.204 GiB in 0:41
snapshot 3c7e91d4 saved

Następnego dnia kopia jest znacznie szybsza: trafia do niej tylko to, co się zmieniło.

root@web1:~# restic snapshots
ID        Time                 Host  Tags       Paths
-----------------------------------------------------------------------
3c7e91d4  2026-11-08 03:10:02  web1  dagelijks  /etc /opt /var/backups/db /var/www
a18f0b77  2026-11-09 03:10:05  web1  dagelijks  /etc /opt /var/backups/db /var/www
-----------------------------------------------------------------------
2 snapshots

Porządkowanie: forget i prune

Codziennie jeden snapshot więcej oznacza po roku 365 snapshotów. Poleceniem forget określają Państwo, które z nich zachować, za pomocą harmonogramu przechowywania:

root@web1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Tak działa harmonogram:

• --keep-daily 7: spośród ostatnich siedmiu dni, w których istnieje snapshot, zachowaj najnowszy z każdego dnia;
• --keep-weekly 4: to samo dla ostatnich czterech tygodni (od poniedziałku do niedzieli);
• --keep-monthly 6: to samo dla ostatnich sześciu miesięcy.

Snapshot zostaje, jeśli spełnia co najmniej jedną z reguł. Wszystko, co nie spełnia żadnej reguły, zostaje zapomniane. Nowy harmonogram prosimy najpierw wypróbować z --dry-run: zobaczą Państwo, co zostałoby usunięte, bez wprowadzania żadnych zmian.

Ważna różnica: forget usuwa jedynie odwołanie do snapshotu. Dane pozostają w repozytorium, dopóki prune nie usunie bloków, których nie używa już żaden snapshot. Opcja --prune przy forget robi to za jednym razem. Prune zajmuje czas i blokuje repozytorium, dlatego nie należy go planować w tym samym czasie co kopii zapasowej.

Weryfikacja: check

Kopię zapasową, która po cichu uległa uszkodzeniu, zauważą Państwo dopiero przy przywracaniu. Prosimy regularnie zlecać restic sprawdzenie repozytorium:

root@web1:~# restic check
...
no errors were found
root@web1:~# restic check --read-data-subset=5%

Samo check sprawdza strukturę. Z --read-data-subset program faktycznie odczytuje też część danych i sprawdza ich zawartość. Warto robić to na przykład co tydzień dla kilku procent danych; w ten sposób po pewnym czasie wszystko zostanie raz odczytane.

Przywracanie: restore i mount

Przywracamy do osobnego katalogu, nigdy od razu na oryginał:

root@web1:~# restic restore latest --target /tmp/terug --include /etc/nginx
restoring snapshot a18f0b77 of [/etc /opt /var/backups/db /var/www] at 2026-11-09 03:10:05 ...
Summary: Restored 41 files/dirs (88.104 KiB) in 0:00
root@web1:~# diff -r /tmp/terug/etc/nginx /etc/nginx && echo gelijk
gelijk

latest to najnowszy snapshot; można też użyć identyfikatora (restic restore 3c7e91d4 ...). Za pomocą restic mount /mnt/restic (wymaga FUSE) widzą Państwo wszystkie snapshoty jako katalogi, mogą je przeglądać i kopiować pojedyncze pliki. Zakończenie: Ctrl+C.

Bazę danych przywraca się, odzyskując zrzut i importując go, na przykład gunzip < alles.sql.gz | mariadb.

Automatycznie, każdej nocy

Prosimy utworzyć skrypt i timer systemd (lekcja 6.3). Skrypt:

#!/bin/sh
# /usr/local/sbin/backup.sh
set -eu
export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles.sql.gz
restic backup /etc /var/www /opt /var/backups/db --tag dagelijks
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Do tego .service z Type=oneshot i ExecStart=/usr/local/sbin/backup.sh oraz .timer z OnCalendar=*-*-* 03:10:00 i Persistent=true. set -eu sprawia, że skrypt zatrzymuje się przy pierwszym błędzie, dzięki czemu systemd uznaje uruchomienie za nieudane. Prosimy podłączyć do tego powiadomienie (lekcja 8.3), w przeciwnym razie nieudana kopia zapasowa przejdzie niezauważona.

Przeciw ransomware: append-only

W powyższym skrypcie sam serwer może również usuwać kopie zapasowe (forget i prune). Jeśli atakujący przejmie serwer, on także będzie to mógł zrobić. Są dwa sposoby, aby temu zapobiec:

• rest-server w trybie append-only: na serwerze magazynowym uruchamiają Państwo własny rest-server restic z opcją --append-only. Serwer WWW może wtedy dodawać kopie zapasowe, ale niczego nie może usunąć. Porządkowanie (forget --prune) wykonują Państwo z innej, dobrze zabezpieczonej maszyny z pełnymi uprawnieniami.
• Magazyn z wersjonowaniem lub blokadą obiektów u dostawcy S3, dzięki czemu usunięte obiekty można jeszcze przez pewien czas odzyskać.

Warto pamiętać o subtelnej pułapce, o której wspomina sama dokumentacja restic: atakujący, który dodaje fałszywe snapshoty, może sprawić, że harmonogram taki jak --keep-weekly zapomni prawdziwe snapshoty. Z --keep-within (na przykład --keep-within 30d) zostaje wszystko z danego okresu, fałszywe czy prawdziwe.

Podsumowanie

• restic szyfruje, deduplikuje i może zapisywać do wielu rodzajów magazynów poza serwerem; utrata hasła oznacza utratę wszystkiego.
• init tworzy repozytorium, backup tworzy snapshot, snapshots je wyświetla.
• forget z --keep-* określa, co Państwo zachowują; dopiero prune (lub --prune) faktycznie usuwa dane. Najpierw próba z --dry-run.
• check (z --read-data-subset) weryfikuje, restore --target przywraca do osobnego katalogu, mount pozwala przeglądać.
• Prosimy zautomatyzować proces timerem i powiadomieniem oraz trzymać co najmniej jedno repozytorium poza zasięgiem serwera (append-only).

Quiz

Zadanie

Zadanie Z8.2: Co zostaje po forget? W przykładowym pliku restic-snapshots.txt znajduje się lista snapshotów i harmonogram przechowywania. Prosimy ustalić, które snapshoty zostaną po restic forget z tym harmonogramem. Program porównuje wynik ze stałym kluczem.

Zadanie O8.2: Test przywracania. Prosimy utworzyć na własnym serwerze repozytorium restic poza serwerem, wykonać kopię zapasową /etc i swoich danych, a następnie przywrócić jeden katalog do /tmp/terug. Prosimy porównać wynik za pomocą diff, zanotować, ile to trwało, i odpowiedzieć, gdzie poza serwerem przechowywane są Państwa hasło i dane dostępowe do magazynu.

Przeczytaj więcej

• Strategia kopii zapasowych: zasada 3-2-1 dla Państwa firmy
• Dokumentacja restic, Preparing a new repository: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• Dokumentacja restic, Removing backup snapshots (forget i prune): https://restic.readthedocs.io/en/stable/060_forget.html
• Dokumentacja restic, Restoring from backup: https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only): https://github.com/restic/rest-server