Backupuri cu restic

Modulul 8: Backupuri și monitorizare · Timp de citire: 12 minute

Obiectivul lecției: După această lecție veți putea face cu restic backupuri criptate pe un spațiu de stocare din afara serverului dumneavoastră, curăța versiunile vechi conform unei scheme de păstrare, verifica backupul și restaura fișiere, iar întregul proces va rula automat.

Noțiuni cheie: restic, repository, init, parolă (fișier de parolă), backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, deduplicare, append-only, timer systemd

De ce restic?

Există multe programe de backup. restic este o alegere bună pentru un server propriu, deoarece:

• criptează totul înainte ca datele să părăsească serverul; spațiul de stocare vede doar blocuri ilizibile;
• deduplică: un fișier care nu s-a modificat nu este salvat din nou, așa că backupurile zilnice ocupă puțin spațiu;
• cunoaște multe tipuri de stocare: un director, un alt server prin SFTP, stocare compatibilă S3, un rest-server propriu;
• este un singur program, disponibil în depozitul de pachete Debian și Ubuntu (apt install restic).

O alternativă cu proprietăți asemănătoare este BorgBackup. Principiile din această lecție se aplică și acolo.

Noțiunile

• Repository: locul în care restic stochează backupurile. Întotdeauna în afara serverului al cărui backup îl faceți.
• Snapshot: un backup la un anumit moment. (Atenție: este altceva decât snapshotul furnizorului dumneavoastră din lecția 8.1.)
• Parolă: fiecare repository are o parolă cu care se criptează totul. Documentația restic este clară în această privință: cine pierde parola pierde datele în mod irevocabil.

Crearea unui repository

Să presupunem că aveți un server de stocare backup.example.net la care aveți acces prin SFTP cu o cheie, ca utilizator web1. Creați mai întâi un fișier de parolă pe server (și păstrați aceeași parolă în managerul dumneavoastră de parole, lecția 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.

Cu variabilele de mediu RESTIC_REPOSITORY și RESTIC_PASSWORD_FILE nu mai trebuie să tastați de fiecare dată opțiunile -r și --password-file.

Realizarea unui backup

Mai întâi dumpul bazei de date (lecția 8.1), apoi backupul:

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

A doua zi backupul este mult mai rapid: se transferă doar ceea ce s-a modificat.

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

Curățarea: forget și prune

Un snapshot nou în fiecare zi înseamnă 365 de snapshoturi după un an. Cu forget stabiliți pe care le păstrați, folosind o schemă de păstrare:

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

Iată cum funcționează schema:

• --keep-daily 7: se iau în considerare ultimele șapte zile în care există un snapshot și se păstrează cel mai nou din fiecare zi;
• --keep-weekly 4: la fel pentru ultimele patru săptămâni (de luni până duminică);
• --keep-monthly 6: la fel pentru ultimele șase luni.

Un snapshot rămâne dacă îndeplinește cel puțin una dintre reguli. Tot ce nu îndeplinește nicio regulă este uitat. Încercați o schemă nouă mai întâi cu --dry-run: astfel vedeți ce ar dispărea, fără să se modifice nimic.

Diferență importantă: forget elimină doar referința la un snapshot. Datele rămân în repository până când prune curăță blocurile care nu mai sunt folosite de niciun snapshot. Opțiunea --prune la forget face ambele lucruri dintr-o dată. Prune durează și blochează repository-ul; de aceea nu îl programați în același timp cu backupul.

Verificarea: check

Un backup care se deteriorează pe nesimțite este descoperit abia la restaurare. Lăsați restic să verifice regulat repository-ul:

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

Simplul check verifică structura. Cu --read-data-subset citește efectiv înapoi o parte din date și verifică și conținutul. Faceți acest lucru, de exemplu, săptămânal, cu câteva procente; astfel, după o vreme, totul a fost citit cel puțin o dată.

Restaurarea: restore și mount

Restaurați într-un director separat, niciodată direct peste original:

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 este cel mai nou snapshot; puteți folosi și un ID (restic restore 3c7e91d4 ...). Cu restic mount /mnt/restic (necesită FUSE) vedeți toate snapshoturile ca directoare și puteți să le răsfoiți și să copiați fișiere individuale. Opriți cu Ctrl+C.

O bază de date o restaurați recuperând dumpul și importându-l, de exemplu gunzip < alles.sql.gz | mariadb.

Automat, în fiecare noapte

Creați un script și un timer systemd (lecția 6.3). Scriptul:

#!/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

Un .service cu Type=oneshot și ExecStart=/usr/local/sbin/backup.sh, și un .timer cu OnCalendar=*-*-* 03:10:00 și Persistent=true. set -eu face ca scriptul să se oprească la prima eroare, astfel încât systemd să considere rularea eșuată. Asociați o notificare (lecția 8.3), altfel nu veți observa un backup eșuat.

Împotriva ransomware: append-only

În scriptul de mai sus, serverul însuși poate și șterge backupul (forget și prune). Dacă un atacator preia serverul, poate face și el acest lucru. Există două modalități de a preveni acest lucru:

• rest-server în modul append-only: pe serverul de stocare rulați rest-server-ul propriu al restic cu opțiunea --append-only. Serverul web poate atunci adăuga backupuri, dar nu poate șterge nimic. Curățarea (forget --prune) o faceți de pe o altă mașină, bine securizată, cu drepturi complete.
• Stocare cu versionare sau blocare a obiectelor la un furnizor S3, astfel încât obiectele șterse să poată fi recuperate încă o perioadă.

Atenție la o capcană subtilă pe care o menționează chiar documentația restic: un atacator care adaugă snapshoturi false poate determina o schemă precum --keep-weekly să uite snapshoturi reale. Cu --keep-within (de exemplu --keep-within 30d) rămâne tot ce provine din acea perioadă, fals sau real.

Rezumat

• restic criptează, deduplică și poate salva pe multe tipuri de stocare din afara serverului dumneavoastră; parola pierdută înseamnă totul pierdut.
• init creează repository-ul, backup un snapshot, snapshots le afișează.
• forget cu --keep-* stabilește ce păstrați; abia prune (sau --prune) curăță efectiv datele. Încercați cu --dry-run.
• check (cu --read-data-subset) verifică, restore --target restaurează într-un director separat, mount vă permite să răsfoiți.
• Automatizați cu un timer și o notificare și păstrați cel puțin un repository în afara razei de acțiune a serverului (append-only).

Test (quiz)

Exercițiu

Exercițiul Z8.2: Ce rămâne după forget? În fișierul exemplu restic-snapshots.txt se află o listă de snapshoturi și o schemă de păstrare. Stabiliți ce snapshoturi rămân după restic forget cu acea schemă. Programul compară cu cheia fixă.

Exercițiul O8.2: Un test de restaurare. Creați pe propriul server un repository restic în afara serverului, faceți un backup pentru /etc și datele dumneavoastră, apoi restaurați un director în /tmp/terug. Comparați cu diff, notați cât a durat și răspundeți unde sunt păstrate, în afara serverului, parola și datele de acces la stocare.

Lecturi suplimentare

• Strategia de backup: regula 3-2-1 pentru propria dumneavoastră companie
• Documentația restic, Preparing a new repository: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• Documentația restic, Removing backup snapshots (forget și prune): https://restic.readthedocs.io/en/stable/060_forget.html
• Documentația restic, Restoring from backup: https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only): https://github.com/restic/rest-server