J’étais malheureusement totalement passé à côté, mais Restic 0.14.0 est sortie au mois d’Août, avec une nouveauté de taille :
We’re very pleased to present you restic 0.14.0! This is a great release which introduces a new repository version that adds the most requested feature: compression!
La compression !!!!!
Ils expliquent également comment faire la migration des repos actuels vers cette nouvelle fonctionnalité, nous allons donc tester ceci.
Mise à jour de restic
Malgré que restic soit un simple binaire, il est intégré depuis la 0.9.4, la possibilité d’upgrade son binaire :
$ sudo restic self-update
[sudo] Mot de passe de xataz :
writing restic to /usr/local/bin/restic
find latest release of restic at GitHub
latest version is 0.14.0
download SHA256SUMS
download SHA256SUMS.asc
GPG signature verification succeeded
download restic_0.14.0_linux_amd64.bz2
downloaded restic_0.14.0_linux_amd64.bz2
saved 21749760 bytes in /usr/local/bin/restic
successfully updated restic to version 0.14.0
On vérifie la version :
$ restic version
restic 0.14.0 compiled with go1.19 on linux/amd64
C’est good, nous pouvons passer à la suite.
Activation de la compression
Mon installation
Sans entrer dans les détails, j’ai un petit script qui me permets de gérer mes sauvegardes, je passe en paramètre le fichier qui contient la configuration de mon repo, et qui a pour format :
export RESTIC_REPOSITORY=rest:http://192.168.1.200:43000:/backups/etc
export RESTIC_PASSWORD=SuperPasswordDeLaMortQuiTue
export BACKUP_PATHS="/etc"
export BACKUP_EXCLUDES=""
export BACKUP_TAGS="etc"
export RETENTION_DAYS=7
export RETENTION_WEEKS=4
export RETENTION_MONTHS=6
export RETENTION_YEARS=3
export DISCORD_NOTIFY=yes
export DISCORD_NOTIFY_WEBHOOK=https://discordapp.com/api/webhooks/0000000000000000000/XXXXXXXXXXxxxxxxxxxXXXXXXXXXXXXxxxxxxxxxxxxxxxxx
## Monitoring configuration
export METRICS=yes
export METRICS_URI="http://victoriametrics.docker:8428/write?db="
export METRICS_DB="saves"
Celui-ci effectue ma sauvegarde sur le repository rest:http://192.168.1.200:43000:/backups/etc, qui est en réalité un google drive exposé via rclone.
Donc pour utiliser cette configuration, il suffit de la sourcer :
$ source /opt/backups/config/etc
$
Nous pouvons donc vérifier si je suis bien connecté au repository en faisant un stats par exemple :
$ restic stats
repository XXXXXXXX opened (repository version 1) successfully, password is correct
scanning...
Stats in restore-size mode:
Snapshots processed: 13
Total File Count: 16266
Total Size: 30.491 MiB
Migration vers un repository en v2
Suite commentaire de dbkblk, j’ai effectué une modification pour bien compresser ce qui ne l’était pas.
Avant de commencer, et pour pouvoir tester la différence, je commence par un prune :
$ restic prune
repository XXXXXXXX opened (repository version 1) successfully, password is correct
loading indexes...
loading all snapshots...
finding data that is still in use for 13 snapshots
[0:00] 100.00% 13 / 13 snapshots
searching used packs...
collecting packs for deletion and repacking
[0:05] 100.00% 35 / 35 packs processed
to repack: 490 blobs / 3.438 MiB
this removes: 28 blobs / 142.805 KiB
to delete: 2 blobs / 58.206 KiB
total prune: 30 blobs / 201.011 KiB
remaining: 906 blobs / 4.943 MiB
unused size after prune: 37 B (0.00% of remaining size)
repacking packs
[0:05] 100.00% 33 / 33 packs repacked
rebuilding index
[0:01] 100.00% 3 / 3 packs processed
deleting obsolete index files
[0:00] 100.00% 1 / 1 files deleted
removing 34 old packs
[0:06] 100.00% 34 / 34 files deleted
done
Et je refais un stats :
$ restic stats --mode raw-data
repository XXXXXXX opened (repository version 1) successfully, password is correct
scanning...
Stats in raw-data mode:
Snapshots processed: 13
Total Blob Count: 905
Total Size: 4.943 MiB
Nous pouvons maintenant attaquer la migration :
$ restic migrate upgrade_repo_v2
repository XXXXXXX opened (repository version 1) successfully, password is correct
checking repository integrity...
using temporary cache in /tmp/restic-check-cache-2184471460
repository XXXXXXX opened (repository version 1) successfully, password is correct
created new cache in /tmp/restic-check-cache-2184471460
load indexes
check all packs
check snapshots, trees and blobs
[0:03] 100.00% 13 / 13 snapshots
no errors were found
applying migration upgrade_repo_v2...
migration upgrade_repo_v2: success
Et dans la documentation, il est indiqué de faire un prune :
$ restic prune --repack-uncompressed
repository XXXXXXXX opened (repository version 2) successfully, password is correct
loading indexes...
loading all snapshots...
finding data that is still in use for 13 snapshots
[0:00] 100.00% 13 / 13 snapshots
searching used packs...
collecting packs for deletion and repacking
[0:03] 100.00% 3 / 3 packs processed
to repack: 356 blobs / 1.375 MiB
this removes: 0 blobs / 0 B
to delete: 0 blobs / 0 B
total prune: 0 blobs / 0 B
remaining: 906 blobs / 4.943 MiB
unused size after prune: 37 B (0.00% of remaining size)
repacking packs
[0:01] 100.00% 1 / 1 packs repacked
rebuilding index
[0:02] 100.00% 3 / 3 packs processed
deleting obsolete index files
[0:00] 100.00% 1 / 1 files deleted
removing 1 old packs
[0:00] 100.00% 1 / 1 files deleted
done
Puis nous pouvons vérifier la taille du repository :
$ restic stats --mode raw-data
repository XXXXXXX opened (repository version 2) successfully, password is correct
scanning...
Stats in raw-data mode:
Snapshots processed: 13
Total Blob Count: 905
Total Size: 1.232 MiB
Nous sommes donc passés de 4.943 MiB à 1.232 MiB, ce qui est vraiment pas mal. Le repository n’est cependant pas représentatif, car vraiment léger, et ce n’est que du texte, mais cela n’a pris que quelques secondes.
Et sur des repositories un peu plus gros
J’ai un repository qui est passé de 28.096 GiB à 11.931 GiB, celui-ci est la sauvegarde des données de mes conteneurs docker, donc y’a de tout. Le résultat est vraiment pas mal, et le traitement n’a duré cet fois-ci un peu plus d’une heure.
Pour mon dernier repository, principalement composé de photos, il a fallu beaucoup, mais vraiment beaucoup de temps. Un peu moins de 25h, pour traiter les 703.476 GiB.
Je vous laisse seul juge de l’efficacité de la compression, car le repository est passé à 631.426 GiB, soit un gain d’environ 10%. Ce n’est vraiment pas fou, mais ça ne m’étonne pas vraiment, car ce sont principalement des images, elles-mêmes déjà compressées.
Conclusion
C’est la fonctionnalité qu’il manquait à restic pour beaucoup, qui ne permettait pas de devenir le remplaçant de borg. Nous n’avons cependant pas de choix sur la méthode de compression, cela semble être sur zstd, ce qui entre nous, est certainement la meilleure. Je n’ai pas voulu utiliser la méthode de compression max, car je ne veux pas que mes sauvegardes soient trop longues.
Cependant après quelques tests, la compression est très relative en fonction du type de donnée, ce n’est pas lié à l’implémentation de restic, mais bien aux limites de la compression, car compresser un fichier déjà lui-même dans un format compressé, ça ne donnera pas grand-chose.
Grâce au commentaire de dbkblk, j’ai recompressé mes repositories, et j’ai gagné pas mal d’espace.