Tuto : Sauvegarde Linux simple, duplicable et sans prise de tête – avec Borg + Borgmatic

[nam1962]

Vous utilisez Arch, EndeavourOS, CachyOS, Manjaro, Debian stable/testing, Xubuntu (idéal sans Snap) ?
Voici un tuto pour sauvegarder votre système et vos données proprement, sans Snap, sans interface foutraque, et avec une vraie maîtrise de vos fichiers.😎

Mise à jour août 2026 : ce tuto a été entièrement repris à partir de la configuration que j’utilise réellement. Le principe est simple : Borg + Borgmatic sauvegarde /home sur un disque externe, tandis que Timeshift ou Snapper s’occupe du retour arrière système.

Le principe

Je veux une sauvegarde qui coche quelques cases assez basiques :

• mes fichiers sont chez moi ;
• le disque de sauvegarde peut rester débranché le reste du temps ;
• pas de cloud commercial ;
• pas d’interface compliquée ;
• pas de format propriétaire ;
• une configuration lisible que je peux recopier sur une autre machine ;
• et surtout : savoir restaurer mes fichiers le jour où j’en ai besoin.

Pour ça, le couple Borg + Borgmatic fait très bien le boulot.

Borg s’occupe de la sauvegarde proprement dite, avec déduplication, compression, historique et vérification.

Borgmatic lui fournit une configuration YAML lisible et évite de se fabriquer des lignes de commande Borg longues comme un dimanche sans sauvegarde.

Bref :

Timeshift / Snapper = retour arrière du système
Borg + Borgmatic    = sauvegarde de /home

Pré-requis

Il faut :

• un disque externe, de préférence en ext4 ;
• un peu de place dessus, évidemment ;
• un terminal ;
• Borg ;
• Borgmatic.

Dans les exemples, mon disque porte le label :

backup

et il est monté sous :

/run/media/votreuser/backup

Remplacez évidemment votreuser par votre nom d’utilisateur.

Le point important est que le chemin indiqué dans Borgmatic corresponde réellement au point de montage du disque.

Un petit :

lsblk -f

permet de vérifier tout ça avant de commencer.

1. Installer Borg et Borgmatic

Arch, EndeavourOS, CachyOS, Manjaro et dérivées

sudo pacman -S borg borgmatic

Debian, Ubuntu, Xubuntu et dérivées

sudo apt install borgbackup borgmatic

On peut vérifier les versions :

borg --version
borgmatic --version

2. Créer le dossier de configuration

mkdir -p ~/.config/borgmatic

3. Une configuration Borgmatic simple

Voici la configuration sur laquelle je suis arrivé. On peut créer le fichier directement :

cat > ~/.config/borgmatic/config.yaml <<'EOF'
source_directories:
  - /home/votreuser

exclude_patterns:
  - '*/.cache/**'
  - '*/.local/share/Trash/**'
  - '*/.Trash*/**'
  - '*/node_modules/**'
  - '*/.npm/**'
  - '*/.thumbnails/**'
  - '*/.mozilla/firefox/**/cache2/**'
  - '*/.config/google-chrome/*/Cache/**'
  - '*/.config/chromium/*/Cache/**'
  - '**/*~'

repositories:
  - path: /run/media/votreuser/backup/borgbackup
    label: backup_main

compression: zstd,3

keep_secondly: 3
keep_weekly: 2
keep_monthly: 1

checks:
  - name: repository
    frequency: 2 weeks
  - name: archives
    frequency: 1 month
EOF

Et c’est déjà presque tout.

Sur ma machine en ext4, Timeshift s’occupe du retour arrière système. Sur une machine Btrfs, Snapper remplit ce rôle.

Borgmatic reste ainsi une vraie sauvegarde des données utilisateur, sans mélanger plusieurs fonctions.

Les exclusions

Le principe n’est pas d’écrire cinquante exclusions « au cas où ».

J’écarte surtout ce qui est recréable et inutile dans une sauvegarde :

• caches ;
• corbeilles ;
• node_modules ;
• cache npm ;
• caches des navigateurs ;
• fichiers temporaires se terminant par ~.

Adaptez cette liste à votre machine.

Ne recopiez pas une exclusion sans savoir ce qu’elle enlève.

4. La rétention et le pruning

J’utilise :

keep_secondly: 3
keep_weekly: 2
keep_monthly: 1

keep_secondly: 3 peut sembler bizarre dans une sauvegarde hebdomadaire. C’est pourtant celui que j’utilise avec Borgmatic 2.1.6 pour garantir les trois dernières archives.

À cela s’ajoutent :

keep_weekly: 2
keep_monthly: 1

Cela donne quelques points plus anciens sans laisser les sauvegardes s’accumuler indéfiniment.

Borg déduplique les données. Plusieurs archives ne signifient donc pas plusieurs copies complètes de /home.

Avant de laisser Borg supprimer quoi que ce soit, j’ai commencé par un dry-run :

borgmatic prune --dry-run --list

Cette commande montre les archives qui seraient gardées et celles qui seraient supprimées.

On lit le résultat.

Et seulement quand il correspond bien à ce que l’on veut :

borgmatic prune

Dans mon cas, le dry-run a d’abord confirmé que les archives présentes étaient bien conservées par la nouvelle politique. Le vrai prune a ensuite été exécuté sans suppression inattendue.

Après le prune :

borgmatic compact

prune enlève les archives devenues inutiles selon la politique de rétention.

compact récupère ensuite réellement dans le dépôt l’espace qui n’est plus utilisé.

C’est le couple que j’utilise.

5. Les vérifications

Les checks Borg peuvent prendre du temps sur un gros dépôt.

Au départ je les faisais trop souvent. J’ai donc fini par régler :

checks:
  - name: repository
    frequency: 2 weeks
  - name: archives
    frequency: 1 month

Le dépôt est contrôlé toutes les deux semaines, les archives une fois par mois.

Il n’y a pas de check « en retard » qui s’empilerait. Si Borgmatic saute celui du dimanche parce qu’il n’est pas encore dû, il ne fera pas deux fois plus de travail la fois suivante.

C’est simplement beaucoup moins lourd que de tout revérifier chaque semaine.

Le cycle complet a été testé avec une vraie archive, puis prune, compact et check, sans erreur.

6. Vérifier le YAML

Avant de lancer quoi que ce soit :

borgmatic config validate

S’il ne trouve rien à redire, on continue.

En cas d’erreur, on corrige d’abord le YAML.

Pas la peine de lancer une vraie sauvegarde avec une configuration bancale.

7. Le dépôt Borg

Mon dépôt est ici :

/run/media/votreuser/backup/borgbackup

Dans mon installation actuelle, ce dépôt n’est pas chiffré.

Je ne vais pas ajouter ici une procédure de chiffrement que je n’utilise pas.

Pour un dépôt existant, on indique simplement son chemin dans :

repositories:
  - path: /run/media/votreuser/backup/borgbackup
    label: backup_main

Si vous partez réellement de zéro, l’initialisation du dépôt est donc la seule partie à adapter à votre propre installation avant de poursuivre.

8. Faire un premier essai

On commence par un dry-run :

borgmatic create --dry-run

Le dry-run est notre ami.

On regarde ce que Borgmatic compte faire avant de lui demander de le faire réellement.

Puis on lance la vraie création :

borgmatic create

Cette fois Borg crée réellement une archive.

Selon la taille de votre /home, la première sauvegarde peut être longue.

Les suivantes profitent de la déduplication de Borg et ne recopient pas inutilement tout ce qui est déjà présent dans le dépôt.

9. Vérifier la sauvegarde

Une sauvegarde n’est pas réussie parce qu’un script affiche « Sauvegarde terminée ».

J’ai précisément eu ce cas dans mon ancienne installation : un message de succès pouvait s’afficher alors que Borg avait échoué.

Maintenant je vérifie le résultat réel.

L’archive doit être présente dans le dépôt, Borg doit pouvoir en lire les informations, et les contrôles ne doivent pas signaler d’erreur.

C’est ainsi que les sauvegardes actuelles ont été validées.

10. Le cycle de maintenance

Une fois la configuration vérifiée et la politique de rétention comprise, mon cycle Borgmatic est donc très classique :

create
prune
compact
check

Avec deux nuances importantes :

• le pruning suit exactement keep_secondly: 3, keep_weekly: 2, keep_monthly: 1 ;
• les checks ne tournent que lorsqu’ils sont dus, grâce aux fréquences définies dans le YAML.

Ce n’est pas la peine de compacter ou vérifier frénétiquement le dépôt juste pour avoir l’impression de mieux sauvegarder.

11. Mon fonctionnement : sauvegarde manuelle

J’avais autrefois cherché à déclencher automatiquement la sauvegarde au branchement du disque.

J’ai abandonné cette solution.

Aujourd’hui mon fonctionnement est beaucoup plus simple :

1. le disque externe reste normalement débranché ;
2. je le branche pour la sauvegarde ;
3. je vérifie qu’il est bien monté ;
4. je lance la sauvegarde ;
5. je laisse le cycle se terminer ;
6. je démonte le disque ;
7. je le range.

Un rappel hebdomadaire dans l’agenda me suffit largement.

Chez moi, c’est le dimanche à 17 h. Le fichier peut être créé directement :

cat > sauvegardes_dimanche_17h.ics <<'EOF'
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//dolys.fr//Sauvegardes dimanche//FR
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
UID:sauvegardes-dimanche-17h-20260823@dolys.fr
DTSTAMP:20260820T153000Z
DTSTART:20260823T170000
RRULE:FREQ=WEEKLY;BYDAY=SU
SUMMARY:Sauvegarde Borg + Vykar
DESCRIPTION:Brancher le disque de sauvegarde, verifier le montage, lancer Borg/Borgmatic puis Vykar, laisser terminer, demonter et ranger le disque.
END:VEVENT
END:VCALENDAR
EOF

Il suffit ensuite d’importer sauvegardes_dimanche_17h.ics dans Thunderbird ou un autre agenda.

Pas de règle udev, pas de déclencheurs concurrents, pas de service caché dont j’ai oublié l’existence six mois plus tard.

12. Un garde-fou très simple

Si vous utilisez toujours le même disque, notez son UUID :

lsblk -f

Avant une sauvegarde, je vérifie :

• que le disque est bien monté ;
• qu’il s’agit du bon disque ;
• que le point de montage est bien celui défini dans config.yaml.

Le but est d’éviter un grand classique : le disque n’est pas monté et un programme commence tranquillement à remplir un simple répertoire local portant le même nom.

KISS ne veut pas dire « sans contrôle ».

13. Sauvegarder avec Thunderbird ouvert

Je lance mes sauvegardes avec Thunderbird et les autres applications ouverts.

Je ne ferme pas mes applications avant chaque Borg.

Thunderbird peut par exemple produire ce genre d’avertissement sur son index pendant une sauvegarde :

global-messages-db.sqlite: file changed while we backed it up
global-messages-db.sqlite-journal: No such file or directory

Dans mon cas, cela n’a pas empêché la création d’une archive valide ni les contrôles suivants.

Je n’exclus donc pas spécialement global-messages-db.sqlite pour avoir une sortie artificiellement propre.

Je veux pouvoir lancer ma sauvegarde pendant que j’utilise normalement la machine.

14. Timeshift ou Snapper

Pour installer Timeshift :

Arch, EndeavourOS, Manjaro et dérivées

sudo pacman -S timeshift

Debian, Ubuntu, Xubuntu et dérivées

sudo apt update
sudo apt install timeshift

Ils servent à revenir rapidement à un état antérieur du système.

Une mise à jour qui casse quelque chose ou une mauvaise manipulation : hop, retour arrière.

Sur ma machine ext4, j’utilise Timeshift.

Je l’ai ramené à trois snapshots hebdomadaires. Le point important est le tag W : auparavant mes snapshots manuels étaient créés en O pour On-demand et échappaient donc à la rétention Weekly.

La commande utilisée maintenant dans /usr/local/bin/timeshift-auto-root.sh est :

timeshift --create --scripted --tags W

Et Timeshift est réglé pour conserver trois Weekly, sans Monthly, Daily, Hourly ni Boot. Les anciens O sont simplement remplacés au fil des semaines par les nouveaux W.

Sur une machine Btrfs, Snapper remplit ce rôle.

Borg met mes données /home sur le disque externe et en conserve plusieurs versions.

Un snapshot situé sur le même disque que le système ne remplace pas une sauvegarde externe.

Chez moi, le disque de sauvegarde reste donc débranché en dehors des sauvegardes.

Conclusion

Au final, chacun fait son boulot et je sais où sont mes sauvegardes. Le disque externe retourne dans son coin une fois le travail terminé.

Le fichier important reste :

~/.config/borgmatic/config.yaml

Il reste lisible et facile à recopier sur une autre machine.

Une sauvegarde que je pige.

PS, j’utilise aussi Vykar

Vykar s’installe avec le script officiel :

curl -fsSL https://vykar.borgbase.com/install.sh | sh

Puis :

vykar --version
vykar config

vykar config génère son fichier de configuration de départ, qu’on adapte ensuite au dépôt et au /home à sauvegarder.

J’utilise aussi Vykar en parallèle sur le même principe : sauvegarde de /home sur le disque externe, compression Zstd et une rétention courte.

Ma rétention actuelle est :

retention:
  keep_last: 3
  keep_monthly: 2

Le dépôt Vykar est séparé de Borg :

/run/media/votreuser/backup/vykar

Je garde les deux pour une raison simple : ceinture et bretelles en sauvegarde, c’est malin : un logiciel peut bugger, deux c’est plus rare.

Un jeune site que j'aime bien, la ferrari du T-shirt ...bio en plus : GoudronBlanc

[Auteur]

Articles