Gérer ses back-up avec Borgmatic

Depuis quelques années, j'ai mis en place un NAS à la maison, sur lequel j'auto-héberge beaucoup d'éléments, que cela soit du service pour ma famille et moi (la gestion des photos par exemple, ou un NextCloud, ce blog, etc.) ou du stockage pur et dur (documents administratifs entre autres).

Mais aucune sauvegarde. Du moins, aucun vrai back-up complet, réfléchi et sûr. Jusque là, je jonglais avec les photos aussi sur Google Photos, le NextCloud et les documents étaient synchronisés via rsync sur mon VPS OVH. Mais je peux maintenant me passer définitivement de Google sur les photos (c'était le but) donc quel intérêt d'avoir encore des éléments là-bas ? Et mon VPS OVH dépanne mais n'a plus de place disponible et il n'était pas prévu pour ça à la base...

Bref, vous l'avez compris : il était temps que je me bouge un peu. Surtout que les sauvegardes, c'est important. C'est toujours le truc que personne ne fait et où l'on fini par s'en mordre les doigts. Je ne raconterai pas le nombre d'histoires et témoignages que nous avons eu, dans nos entourages proches ou moins proches, ou même sur Internet, sur des données perdues et non-sauvegardées alors qu'elles étaient très importantes.

Donc hop, on se bouge et on met en place des sauvegardes !

3, 2, 1... Sauvegardez !

Avant de sauvegarder sans trop réfléchir, il faut se poser quelques minutes et s'interroger sur sa stratégie de sauvegarde. Une stratégie ? Pour sauvegarder ? Mais pourquoi ?

Il faut en fait répondre à plusieurs questions : quels éléments sauvegarder ? Tous les combien de temps ? Faut-il les compresser pour gagner de la place ? Faudra-t-il faire le ménage (autrement dit, combien de temps de sauvegardes garde-je) ? Est-ce que je veux une sauvegarde à l'identique de mon état actuel des documents ou est-ce que je veux pouvoir récupérer un fichier supprimé par mégarde ?

Je ne vais pas vous dire comment répondre à ces questions, mais je vais vous expliquer ce que j'ai mis en place. Cela permettra peut-être d'ajouter de l'eau à votre moulin de la réflexion.

Au niveau stratégie globale, je me suis donné comme but la fameuse 3-2-1 :

• 3 copies de vos données ;
• stockées sur au moins 2 supports différents ;
• et dans au moins 1 endroit hors-site.

Pour ma part, j'ai mes copies des données (en fonction des données) chez certains Cloud (Proton Drive, mon NextCloud...) et c'est à peu près tout. Bref, je ne suis pas encore parfaitement au clair sur les 3 copies.

Les données copiées le sont sur au moins 2 supports différents : les disques dur de mon NAS, les disques durs de mes hébergeurs Cloud et les disques durs de mon service de stockage en ligne (Borgbase, j'y reviens plus loin).

Et donc, hormis mon NAS, tout est hors-site. Mon NAS étant effectivement dans mon garage, avec mon PC fixe : si ma maison crame, les 2 sont définitivement irrécupérables.

Mise en place avec BorgBackup, Borgmatic et Borgbase

Pour mettre cela en place, j'ai opté pour des outils connus et reconnus, mais que je n'avais jamais essayé : BorgBackup et Borgmatic.

BorgBackup, ou Borg pour faire plus court, est un outil de gestion de sauvegarde, en ligne de commande, basé sur la création de dépôt de sauvegarde. Ces dépôts et les sauvegardes peuvent être compressées et chiffrées. Borg est également libre et open-source et dispose d'une très grande communauté. Il a enfin le bon goût d'être multi-plateforme (Linux, MacOS, FreeBSD, mais plus compliqué sous Windows...).

Il est accompagné par Borgmatic, qui est un logiciel de gestion de sauvegarde, basé sur Borg et qui utilise des fichiers de configuration simples et pratiques, afin de back-up facilement vos données, vos bases de données, etc.

Le fonctionnement est assez simple et peut se résumer comme suit :

• avec Borg, on va créer un dépôt qui va accueillir les sauvegardes : ce dépôt peut être mis n'importe où (sur votre machine, sur un serveur de votre réseau local ou même à distance sur un serveur dont vous disposez ou chez des prestataires dédiés). Le dépôt a donc un rôle de serveur.
• avec Borg (ou Borgmatic), on va demander à créer des sauvegardes, souvent à intervalles réguliers, qui vont être envoyées vers un ou plusieurs dépôts dont nous avons parlé précédemment. Ici, nous sommes plutôt dans un rôle de client.

Mais tu nous aurais pas parlé d'un troisième larron : BorgAcide ? BorgBase ?!

Et si, BorgBase !

Vous l'avez compris, l'objectif pour moi est sauvegarder les données de mon NAS et aussi de mon VPS OVH et de les envoyer vers un dépôt BorgBackup. Mais ce dépôt doit être distant pour que cela fasse mon back-up off-site. Cet espace distant doit avoir de l'espace disque disponible, et facilement extensible au fur et à mesure que mes back-up vont prendre de la place. Hors de question de faire reposer ça sur mon VPS OVH qui a une capacité limitée.

J'ai donc cherché un prestataire en ligne proposant des espaces de stockage. Outre rsync.net, j'ai également regardé - et choisi - borgbase. Les critères principaux étant le prix (un tout petit peu moins cher que rsync.net pour mon usage) et surtout, la simplicité.

Étape 1 : installer Borg & Borgmatic

On commence donc par installer BorgBackup et Borgmatic sur les machines que l'on souhaite sauvegarder (ou qui ont des éléments à sauvegarder). Dans mon cas, mon NAS Qnap et mon VPS OVH sous ArchLinux.

Sur ArchLinux

En suivant le guide d'installation de Borg et celui de Borgmatic, on voit que tout est dans les dépôts. Donc une petite commande d'installation et c'est terminé :

sudo pacman -Syu borg borgmatic

Sur le NAS Qnap

Sur mon NAS, c'est un peu plus délicat. En effet, ce dernier tourne sous une distribution maison à base Linux, mais je n'ai pas la main sur le gestionnaire de paquet.

J'ai trouvé un dépôt Qnap custom avec certains logiciels, dont Borgmatic, mais je n'étais pas sûr de la provenance ni de la gestion des logiciels à moyen et long terme.

J'ai donc opté pour un système que je connais mieux : Docker. Borgmatic est disponible sous ce format : https://github.com/borgmatic-collective/docker-borgmatic. Il embarque directement Borg dans l'image également, ce qui me permet de n'utiliser qu'un seul conteneur.

J'ai donc créé un fichier docker-compose dédié avec un montage de volumes minimal pour l'instant. Je l'ai modifié et ajouté des volumes, mais nous verrons cela dans les étapes d'après.

Voici le fichier de base :

services:
  borgmatic:
    image: ghcr.io/borgmatic-collective/borgmatic:2.0.7
    container_name: borgmatic
    volumes:
      - ${VOLUME_SOURCE}:/mnt/source:ro            # backup source
      - ${VOLUME_ETC_BORGMATIC}:/etc/borgmatic.d/  # borgmatic config file(s) + crontab.txt
      - ${VOLUME_BORG_CONFIG}:/root/.config/borg   # config and keyfiles
      - ${VOLUME_SSH}:/root/.ssh                # ssh key for remote repositories
      - ${VOLUME_BORG_CACHE}:/root/.cache/borg     # checksums used for deduplication
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=${TZ}
      - DOCKERCLI=${DOCKERCLI}

Ce service tourne sans problème sur le NAS Qnap via un petit docker compose up -d.

À noter que vous pouvez également télécharger directement les binaires de Borg pour les installer.

Passons maintenant à l'étape d'après !

Étape 2 : créer un ou plusieurs dépôts sur BorgBase

Maintenant que les éléments essentiels sont installés sur les 2 machines à sauvegarder (le NAS et le VPS, si vous suivez bien), il faut créer les dépôts dans lesquels les sauvegardes seront envoyés vers notre site distant géré par BorgBase.

Pour ce faire, il faut se rendre sur le site de BorgBase et se créer un compte. Il existe un compte gratuit vous donnant droit à deux dépôts de sauvegarde et 10 Go d'espace.

J'ai utilisé ces 10 Go d'espace gratuit pour tester une première fois le workflow complet de sauvegarde avec quelques fichiers en tests dans un dépôt dédié au test.

Puis, j'ai opté pour le plan "Small", qui inclus 250 Go d'espace. Je me doutais bien que la sauvegarde complète de mes données ferait plus de 10 Go, et j'ai besoin de deux dépôts (pour l'instant) pour le NAS et le VPS. Mais je pense également sauvegarder les ordinateurs que nous utilisons au quotidien dans la famille, ce qui m'amènerait probablement à 5 dépôts.

Une fois inscrit, avant de créer un dépôt, vous pouvez ajouter vos clefs SSH dans l'onglet "SSH KEYS".

Ensuite, dans l'onglet "REPOSITORIES", vous pouvez suivre les étapes pour créer un dépôt et remplir les formulaires :

Il vous faut choisir les éléments suivants :

• un nom pour votre dépôt ;
• la région de localisation de votre dépôt (Europe ou États-Unis d'Amérique) : EU pour moi, pour des raisons évidentes de souveraineté des données ;
• le format (Borg, pour ma part) ;
• la partie "Access" vous demande d'indiquer les clefs SSH (que vous aurez préalablement ajouté dans l'onglet "SSH KEYS") qui auront accès au dépôt et les droits correspondants (tous les droits ou seulement en lecture) ;
• vous pouvez activer ou désactiver le monitoring, vous permettant d'être alerté par e-mail en cas de problème sur vos sauvegardes ;
• la compression ("compaction" en Anglais) côté BorgBase qui va permettre de nettoyer votre dépôt au fur et à mesure des sauvegardes ou une sur une période choisie ;
• et enfin des paramètres avancés pour autoriser un accès SFTP, une limite de stockage, etc.

Une fois que le dépôt est créé, direction l'étape d'après : écrire notre configuration BorgMatic et lancer une première sauvegarde !

Étape 3 : écrire sa configuration Borgmatic

L'objectif est maintenant de créer la configuration que va utiliser Borgmatic sur chacune de nos machines "clientes" pour créer les sauvergardes et les envoyer vers les dépôts BorgBase correspondants.

Créer une première configuration

Une bonne ressource est évidemment la documentation sur comment créer des backups avec Borgmatic.

Une bonne pratique peut être de générer une configuration d'exemple dans le dossier où vous allez ranger votre configuration Borgmatic (pour ma part, d'après le docker-compose affiché plus haut, cela sera dans le dossier que j'ai mis en variable d'environnement dans ${VOLUME_ETC_BORGMATIC}).

Pour la générer, voici la commande :

borgmatic config generate

Cela vous génère un fichier yaml, que vous pouvez maintenant personnaliser à votre convenance, en vous référant toujours à la documentation.

Voici un exemple de configuration assez simple :

borg_config_directory: /home/toto/.config/borgmatic

# List of source directories to backup.
source_directories:
    - /home/toto/backup/

# Paths of local or remote repositories to backup to.
repositories:
    - path: ssh://toto.repo.test.org/./repo
      label: "Backup de mon VPS"

encryption_passphrase: MyPassphrase
compression: auto,zstd
archive_name_format: "{hostname}-{now:%Y-%m-%dT%H:%M:%S.%f}"

# Number of times to retry a failing backup before giving up.
retries: 5
retry_wait: 5

keep_daily: 7
keep_weekly: 4
keep_monthly: 6

# Don't read whole repo each time
skip_actions:
    - check

# Restrict the number of checked archives to the last n. Applies only
# to the "archives" check. Defaults to checking all archives.
check_last: 3

# List of checks to run to validate your backups.
checks:
    - name: repository
    - name: archives
      frequency: 2 weeks

commands:
    - before: action
      when: [create]
      run: [/home/toto/backup/borg/before.sh]
    - after: action
      when: [create]
      run: [/home/toto/backup/borg/after.sh]

# Configuration for a monitoring integration with Uptime Kuma using
# the Push monitor type.
# See more information here: https://uptime.kuma.pet
uptime_kuma:
    # Uptime Kuma push URL without query string (do not include the
    # question mark or anything after it).
    push_url: https://toto.fr/api/push/blabla

    # List of one or more monitoring states to push for: "start",
    # "finish", and/or "fail". Defaults to pushing for all
    # states.
    states:
        - start
        - finish
        # - fail

On y retrouve la liste des dossiers à sauvegarder, le path SSH d'accès au dépôt, une passphrase pour chiffrer les sauvegardes et d'autres éléments dont les scripts à lancer avant et après la sauvegarde (nous y reviendrons). Il est aussi possible d'ajouter une intégration avec un outil de monitoring (ici Uptime-Kuma) afin d'avoir un statut sur la bonne réalisation de vos sauvegardes.

Si vous modifiez la configuration, vous pouvez vérifier sa bonne validité avec la commande suivante :

borgmatic config validate

Étape 4 : initialiser le dépôt avec la configuration

Maintenant que vous avez une configuration borgmatic valide pour votre client (la machine à sauvegarder, rappelez-vous !), vous pouvez essayer d'initialiser votre dépôt de sauvegarde. Le tutoriel de BorgBase est là pour vous aider, si besoin.

Sur la machine à sauvegarder, vous pouvez donc lancer cette commande pour initialiser le dépôt de sauvegarde (à condition d'avoir mis votre fichier de configuration borgmatic au bon endroit).

borgmatic init -e repokey-blake2

Vous pouvez aussi lancer votre première sauvegarde avec la commande suivante :

borgmatic create

Étape 5 : sauvegarder les différents services essentiels

Stratégie côté VPS

Pour faire une sauvegarde complète de mon VPS, je veux sauvegarder les éléments suivants :

• les fichiers de configuration de mon serveur ;
• le service Gitea qui contient mon dépôt privé de code source.

Backup les fichiers de configuration

Pour sauvegarder les fichiers de configuration, j'ai simplement ajouté tous les dossiers dans la liste des source_directories de la configuration Borgmatic.

J'y ai mis notamment les règles de firewall, les fichiers de configuration des différents services (nginx par exemple).

Simple. Basique.

Backup Gitea

Pour réaliser une sauvegarde de Gitea, je me suis tourné vers les recommandations de leur documentation. Celle-ci nous indique qu'il existe une commande dump qui réalise un back-up complet de Gitea.

Ainsi, Gitea va back-up trois éléments :

• les fichiers,
• la base de données,
• et les dépôts git.

Il est cependant indiqué qu'il est aussi possible de faire un dump de la base de données à côté pour avoir le format de dump plus habituel que le ZIP fourni par Gitea pour restaurer la BDD.

Mais, les fichiers étant mouvants, il faut arrêter l'instance Gitea avant d'effectuer la sauvegarde. C'est ce qui est écrit dans la documentation en mise-en-garde.

To ensure the consistency of the Gitea instance, it must be shutdown during backup.

Mon service Gitea tourne dans un conteneur Docker. C'est donc problématique je trouve, si l'on doit arrêter le conteneur pour lancer une commande gitea au sein du conteneur...

Je pense que le plus simple pour moi est donc :

1. d'arrêter le conteneur Gitea ;
2. de copier le contenu du volume monté dans lequel il y a la configuration et les dépôts git ;
3. de faire un dump de la base de données ;
4. de placer ce dump dans un dossier que l'on a indiqué comme à sauvegarder à Borgmatic ;
5. de redémarrer le tout à la fin du back-up.

Cela peut être mis dans un petit script bash, que l'on pourra lancer avant la création du back-up par Borgmatic. Voici le script, sobrement appelé before.sh :

#!/bin/bash
set -e
source /home/toto/.env
docker stop gitea
docker exec -t sql-db mysqldump --no-tablespaces -u gitea -p"$GITEA_MYSQL_DB_PWD" gitea > /home/toto/backup/borg/dumps/gitea-db.sql

Pour le lancer avant le back-up automatiquement par Borgmatic, il faut utiliser les propriétés commands du fichier de configuration de Borgmatic que vous avez créé plus haut :

commands:
    - before: action
      when: [create]
      run: [/home/toto/backup/borg/before.sh]
    - after: action
      when: [create]
      run: [/home/toto/backup/borg/after.sh]

On n'oubliera pas de créer un script after.sh (notez toujours l'originalité du nom) qui contient le redémarrage du conteneur Gitea :

#!/bin/bash
set -e
docker start gitea

Et voilà le travail ! Tout ce que l'on veut sauvegarder est bien intégré dans le fichier de configuration Borgmatic. Il restera à faire tourner Borgmatic en tâche récurrente à l'aide d'un cron : nous le verrons dans les dernières étapes.

Stratégie côté NAS

Pour mon NAS, il y a plusieurs éléments que je souhaite sauvegarder. Je ne les détaillerai pas tous ici, mais pour vous donner les deux plus importants : Nextcloud et Immich.

Backup NextCloud

La méthode est toujours la même : que disent les textes ?

En nous renseignant, il est donc indiqué qu'il y a 4 éléments principaux à sauvegarder :

1. le dossier contenant la configuration ;
2. le dossier contenant les données ;
3. le dossier contenant le thème ;
4. la base de données.

Mon NextCloud tourne également dans un conteneur Docker ainsi que sa base de données. Les mêmes principes que Gitea s'appliquent ici : il faut arrêter le conteneur principal Nextcloud avant de toucher aux fichiers des volumes pour éviter les risques de corruption.

Vous connaissez le principe donc : un petit script before.sh qui arrête le conteneur Nextcloud et fait un export de la base de données et place ledit export dans un dossier qui sera sauvegardé par Borgmatic, puis un script after.sh qui redémarre le conteneur.

Et on ajoute ces deux scripts dans le fichier de configuration de borgmatic ! Cela permettra à Borgmatic de backup le tout !

Seul problème sur le NAS : Borgmatic s'exécute dans un conteneur Docker aussi ! Pour qu'il puisse sauvegarder les fichiers de Nextcloud et le dump de la base de données, il ne faut pas oublier de monter ces emplacements en volume dans le conteneur côté Borgmatic ! Pour plus de sûreté, je les ai mis en read-only dans mon fichier docker-compose.yml.

Backup Immich

Place maintenant à la sauvegarde des données de mon service Immich, qui gère l'ensemble de mes photos à la place de Google Photos.

Idem, que disent les textes ? En gros, qu'il faut sauvegarder deux éléments :

• les fichiers d'Immich (notamment les photos) ;
• la base de données.

Pour éviter les risques de corruption, cela signifie également arrêter le conteneur d'Immich et faire un dump de la base de données, puis redémarrer le conteneur.

On peut donc ajouter ces actions dans nos scripts before.sh et after.sh. Il ne faut pas oublier non plus d'ajouter les volumes correspondants dans le fichier de configuration de Borgmatic et de les ajouter en volume montés dans le docker-compose du Borgmatic.

Voici donc le script before.sh pour l'exemple, avec l'arrêt d'Immich et les backup de base de données pour NextCloud et Immich. À noter que je n'arrête pas le conteneur NextCloud complètement : je le passe en mode maintenance (que j'enlève dans le script after.sh évidemment).

#!/bin/bash
set -e
docker stop immich_server 
docker exec -t immich_postgres pg_dumpall --clean --if-exists --username=XXXX | gzip > "/mnt/dump/dump-immich.sql.gz"
docker exec -u www-data -t nextcloud php occ maintenance:mode --on
docker exec -t mariadb mariadb-dump --single-transaction --default-character-set=utf8mb4 -u nextcloud -p'Blablabla' nextcloud > /mnt/dump/nextcloud-sqlbkp_`date +"%Y%m%d"`.bak

Étape 6 : tester la sauvegarde

Cette avant-dernière étape est facultative mais vous permet de tester votre configuration. Il vous suffit de lancer une sauvegarde manuellement et de voir ainsi qu'il n'y pas d'erreur. Vous pouvez ensuite vérifier l'état de votre dépôt sur BorgBase à la fin de la sauvegarde et voir que tout fonctionne comme il faut.

Pour ce faire, vous pouvez lancer la commande suivante :

borgmatic --verbosity -1 --syslog-verbosity 1

Cela fonctionne aussi avec borgmatic create normalement.

Étape 7 : automatiser la sauvegarde

Enfin, dernière étape couverte par ce billet de blog : l'automatisation de votre sauvegarde. C'est (presque) l'étape la plus simple : maintenant que l'on a la commande à lancer, il suffit de la mettre dans un cron pour qu'elle se lance à intervales réguliers. Ici, par exemple, à 3h du matin tous les jours.

0 3 * * * /usr/bin/borgmatic --verbosity -1 --syslog-verbosity 1

Pourquoi ai-je écrit "presque" ? Car sur le VPS, un coup de crontab -e et hop, l'entrée est ajoutée dans la crontab. Et tout roule.

Mais sur le NAS Qnap, il faut éditer manuellement le fichier crontab, qui n'est pas au même endroit que sous les autres distributions. Il est sous /etc/config/crontab pour information. Et il faut le recharger avec la commande sudo /etc/init.d/crond.sh ensuite.

Et surtout, il faut refaire cette manipulation à chaque mise-à-jour du firmware du NAS, car il écrase la crontab. Je n'ai pas encore trouvé comment conserver ce paramétrage en particulier ou un autre moyen... Si vous avez trouvé le truc, je suis preneur !

Étape 8 : tester vos sauvegardes !

Et oui, j'ai bien écrit que seulement 7 étapes étaient couvertes dans ce billet, mais il vous faut quand même réaliser cette 8ème étape : tester vos sauvegardes !

Rien n'est plus dur que d'être tué une première fois par la perte de ses données, puis une deuxième fois - annihilant l'espoir naissant que l'idée d'avoir fait des sauvegarde avait fait ressurgir - quand vos sauvegardes ne peuvent pas être restaurées car corrompues ou ayant des problèmes.

Je ne couvre pas cette étape car c'est un processus assez complexe à mettre en place pour ma part, d'une part manuellement puis après de façon automatisée, et je travaille encore dessus... Demain. Promis, ça fait parti des bonnes résolutions 2026 !

Bonnes sauvegardes à toutes et tous !