Restic
Restic è un progetto opensource che ben incarna i buoni principi di un backup insite e offsite.
Un moderno software di backup che mette insieme diverse tecnologie per avere un backup sotto forma di snapshot con cifratura e deduplica.
Ho già parlato della deduplica con opendedup e credo che sia una funzione che non debba mai mancare in un qualsiasi sistema di backup.
Come funziona
Restic ha bisogno di un repository dove salvare i backup. Questo repo può essere locale oppure remoto (share, s3, ftp, ecc) e una volta inizializzato e scelta la password per sbloccare la chiave di cifratura (mi raccomando mettiamola da parte perché se la perdiamo non avremmo più accesso ai dati) potremo subito iniziare a backuppare i nostri dati.
L’installazione è molto semplice perché è contenuto nei repository di quasi tutte le distro (c’è anche per Mac e Windows ovviamente).
Pagina di installazione
Mani in pasta
Come prima cosa individuiamo uno spazio dove salvare i nostri backup. Nel mio caso utilizzerò un bucket S3. Inizializziamo il repository e scegliamo una password.
# restic -r s3:https://gateway.storjshare.io/restic/homebackup --verbose init
lanciamo il primo backup
# restic -r s3:https://gateway.storjshare.io/restic/homebackup --verbose backup /home
open repository
enter password for repository:
password is correct
lock repository
load index files
start scan
start backup
scan finished in 1.837s
processed 1.720 GiB in 0:12
Files: 5307 new, 0 changed, 0 unmodified
Dirs: 1867 new, 0 changed, 0 unmodified
Added: 1.200 GiB
snapshot eed8a836 saved
Al termine del backup avremo a disposizione il nostro primo snapshot.
# restic -r s3:https://gateway.storjshare.io/restic/homebackup snapshots
repository ....... opened successfully, password is correct
ID Time Host Tags Paths
------------------------------------------------------------------
eed8a836 2022-08-01 18:45:31 kate /home
------------------------------------------------------------------
1 snapshots
Snapshots
Una snapshot non è altro che la fotografia in quel preciso momento del path passato come argomento. Ogni snapshot viene etichettata con una sequenza di caratteri esadecimali che la identifica in modo univoco.
Quando restic rileva un file di cui è già stato eseguito il backup, sia nel backup corrente che in uno precedente, si assicura che il contenuto del file venga archiviato solo una volta nel repository. Questa operazione può essere molto onerosa sia in termini di tempo che di risorse e quindi restic sfrutta anche i metadati del file per determinare se quest’ultimo è rimasto invariato rispetto a un backup precedente. In tal caso, il file non viene scansionato.
Per ogni backup è possibile includere ed escludere dei file, percorsi, ecc. Ci sono molti parametri ma credo che i più interessanti siano
- –exclude
- –exclude-file
- –exclude-caches
- –files-from
come parametro a –exclude-file e –files-from va passato come argomento successivo il path ad un file di testo con un path, regex, ecc su ogni riga; le righe con # iniziale verranno ignorate.
eempio di –exclude-file file
.cache
# log vari
*.log
logs
esempio di –files-from file
/home
/opt/docker
# Anche la var lib va
/var/lib
Restic ha un comando diff che mostra la differenza tra due snapshot con una piccola statistica, lanciamo
# restic -r s3:https://gateway.storjshare.io/restic/homebackup diff ea657ce5 2ab627a6
password is correct
comparing snapshot ea657ce5 to 2ab627a6:
C /restic/cmd_diff.go
+ /restic/foo
C /restic/restic
Files: 0 new, 0 removed, 2 changed
Dirs: 1 new, 0 removed
Others: 0 new, 0 removed
Data Blobs: 14 new, 15 removed
Tree Blobs: 2 new, 1 removed
Added: 16.403 MiB
Removed: 16.402 MiB
Questi sono solo una minima parte dei comandi e nella documentazione ufficiale sono descritti tutti gli altri come ad esempio:
- taggare un backup
- leggere i dati da standard input
- variabili d’ambiente
- ecc
Restore
Per recuperare file e cartelle da uno snaphost e sufficiente indicare il codice esadecimale di quest’ultimo, il path da ripristinare e il percorso dove effettuare il restore
# restic -r s3:https://gateway.storjshare.io/restic/homebackup 79766175 --target /tmp/restore-home
enter password for repository:
restoring <Snapshot of [/home] at 2015-05-08 21:40:19.884408621 +0200 CEST> to /tmp/restore-home
in questo caso verrebbe processato tutto lo snapshot /home ma ovviamente è possibile ottenere specifici files o cartelle
# restic -r s3:https://gateway.storjshare.io/restic/homebackup 79766175 --path "/home/marvin/immagini/tux.svg" --target /tmp/restore-home
utilizzando la parola chiave latest al posto dell’id della snapshot verrà presa come valida l’ultima eseguita in ordine temporale
# restic -r s3:https://gateway.storjshare.io/restic/homebackup latest --path "/home/marvin/video/obs" --target /tmp/restore-home
è possibile anche montare una snaphot e leggere in contenuto comodamente dalla cli o file manager
# mkdir /mnt/restic
# restic -r s3:https://gateway.storjshare.io/restic/homebackup mount /mnt/restic
Anche per i restore vi rimando alla documentazione ufficiale .
Eliminare le snapshot
Ovviamente è possibile sfoltire le fila del nostro repository eliminando le snaphot che non ci interessano più
# restic -r s3:https://gateway.storjshare.io/restic/homebackup forget bdbd3439
enter password for repository:
removed snapshot bdbd3439
ora non ci resta che fare una vera pulizia dei dati
# restic -r s3:https://gateway.storjshare.io/restic/homebackup prune
enter password for repository:
repository 33002c5e opened successfully, password is correct
loading all snapshots...
loading indexes...
finding data that is still in use for 4 snapshots
[0:00] 100.00% 4 / 4 snapshots
searching used packs...
collecting packs for deletion and repacking
[0:00] 100.00% 5 / 5 packs processed
to repack: 69 blobs / 1.078 MiB
this removes: 67 blobs / 1.047 MiB
to delete: 7 blobs / 25.726 KiB
total prune: 74 blobs / 1.072 MiB
remaining: 16 blobs / 38.003 KiB
unused size after prune: 0 B (0.00% of remaining size)
repacking packs
[0:00] 100.00% 2 / 2 packs repacked
rebuilding index
[0:00] 100.00% 3 / 3 packs processed
deleting obsolete index files
[0:00] 100.00% 3 / 3 files deleted
removing 3 old packs
[0:00] 100.00% 3 / 3 files deleted
done
è possibile anche eseguire le due azioni in un unico comando
# restic -r s3:https://gateway.storjshare.io/restic/homebackup forget bdbd3439 --prune
Extra
Gestire le chiavi di cifratura
E’ possibile aggiungere una nuova chiave al repository di backup
# restic -r s3:https://gateway.storjshare.io/restic/homebackup key list
enter password for repository:
ID User Host Created
----------------------------------------------------------------------
*eb78040b username kate 2022-08-02 12:28:01
# restic -r s3:https://gateway.storjshare.io/restic/homebackup key add
enter password for repository:
enter password for new key:
enter password again:
saved new key as <Key of username@kate, created on 2022-08-02 15:22:00.346561567 +0200 CEST>
# restic -r s3:https://gateway.storjshare.io/restic/homebackup key list
enter password for repository:
ID User Host Created
----------------------------------------------------------------------
5c657874 username kate 2022-08-02 12:28:01
*eb78040b username kate 2022-08-02 15:22:00
Comodità di backup
Possiamo utilizzare le variabili d’ambiente per evitare di dover sempre inserire il percorso al repo oppure la password per la chiave di cifratura.
creiamo il file .restic-env nella home dell’utente con il quale lanciamo il backup
export RESTIC_REPOSITORY="s3:https://gateway.storjshare.io/restic/homebackup"
export RESTIC_PASSWORD=bella_password_forte
ora facciamo in modo di caricarlo alla login
# echo ". ~/.restic-env" >> .bashrc
nel mio caso utilizzando S3 come rerpository ho anche aggiunto le chiavi di accesso
export AWS_ACCESS_KEY_ID=chiave_S3
export AWS_SECRET_ACCESS_KEY=secret_chiave_S3
Backup automatico e rotation
Con due semplici cron possiamo dimenticarci del backup e avere i consumi/costi sotto controllo.
crontab -e
...
#Restic
05 00 * * * . /root/.bashrc && /usr/bin/restic forget --keep-daily 14 --prune
30 00 * * * . /root/.bashrc && /usr/bin/restic backup /opt/docker
Nell’esempio faremo un backup ogni notte a mezzanotte e mezza e terremo i backup degli ultimi 14 giorni.
Ho imposto il caricamento delle variabili d’ambiente per non dover gestire in più punti le chiavi d’accesso, il repository e la password e non ho reindirizzato l’output in /dev/null così da poter verificare la corretta esecuzione dal log di cron.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: