Ne procrastinez plus vos sauvegardes grâce à Borg

Magazine
Marque
Linux Pratique
Numéro
98
|
Mois de parution
novembre 2016
|
Domaines


Résumé

Vous êtes frustrés par des sauvegardes interminables, fastidieuses à restaurer ? Vous considérez que ça n'est pas à un humain de jongler avec les sauvegardes « complètes » et « différentielles » ? Alors le logiciel Borg peut vous intéresser, tant pour sauvegarder un PC qu'un serveur.


Body

1. Petit tour des logiques de sauvegarde

1.1 La copie manuelle

C'est la sauvegarde « du pauvre » : on copie ses documents manuellement sur un support externe.

- Avantages : c'est simplissime.

- Inconvénient : il faut y penser, et on risque donc d'oublier au moment fatal, gestion fastidieuse.

1.2 Les sauvegardes incrémentales par archives tar

Certainement le mode de sauvegarde le plus répandu. Ces sauvegardes sont généralement automatiques et récurrentes (ex. : quotidiennes).

Toutes les n sauvegardes, on enregistre une image complète de tous les fichiers (on parle de sauvegarde full ou master). Les autres sauvegardes sont différentielles : elles ne contiennent que les fichiers ayant changé depuis la dernière sauvegarde full, afin d'économiser de la place.

- Solutions : backup-manager, bacula, backuppc, duplicity...

- Avantages : relativement compactes, les archives peuvent être chiffrées, manipulation avec les outils standards d'archivage (tar).

- Inconvénients : la restauration et la recherche dans les sauvegardes sont fastidieuses (il faut jongler avec les archives), la création d'une nouvelle archive complète est coûteuse en temps et en ressources.

1.3 Les sauvegardes basées sur la synchronisation de fichiers

Le principe est simple : elles utilisent généralement l'outil rsync (ou l’un de ses dérivés) afin de synchroniser le/les dossiers à sauvegarder vers un autre dossier (pouvant être distant).

- Solutions : rdiff-backup, scripts maison à base de rsync...

- Avantages : performant sur à peu près toutes les opérations (sauvegarde, restauration), utilisation transparente de SSH pour le stockage distant, peu d'espace disque requis.

- Inconvénients : moins évident de gérer différents « points de sauvegarde » temporels comme avec les backups différentiels, ni de chiffrer/compresser les sauvegardes.

1.4 Les sauvegardes basées sur la déduplication

La déduplication est le fait d'identifier les blocs de données identiques, pour ne les stocker qu'une seule fois. On limite ainsi l'espace disque occupé. C'est un fonctionnement interne au système de stockage des sauvegardes, et transparent pour l'utilisateur (à la restauration, on aura bel et bien deux fichiers distincts). La déduplication prend tout son sens pour le stockage de sauvegardes, qui contiennent par essence beaucoup de données identiques (entre la sauvegarde du lundi et celle du mardi, la plupart de mes fichiers sont inchangés).

Solutions : Attic, Borg, Obnam...

Avantages : efficace en stockage (et en bande passante), chiffrement et compression aisés et performants.

Inconvénients : la consommation en RAM plus importante (il faut y stocker l'index des blocs), format de stockage « opaque » (pas de simples fichiers ou archives).

2. Borg à la rescousse

Note : Borg est un fork du logiciel Attic. Le fork a été initié par des contributeurs regrettant que la faible disponibilité de jborg (l'auteur original) et sa volonté de garder un contrôle personnel sur la base de code freinaient le développement d'Attic. Depuis le fork en mai 2015, 21 versions de Borg sont parues (aucune pour Attic), apportant les contributions d'une cinquantaine de personnes. Ce bilan de santé me fait pencher en faveur de Borg plutôt que d'Attic.

2.1 Présentation succincte

Borg est un logiciel libre (licence BSD) en ligne de commandes proposant une sauvegarde basée sur la déduplication.

Il permet de sauvegarder un ou des dossiers vers des « archives Borg » qui peuvent être soit locales (ex. : disque externe), soit distantes.

Fonctionnalités notables :

- déduplication efficace ;

- chiffrement (optionnel, activé par défaut) ;

- compression (optionnelle, désactivée par défaut) ;

- restauration aisée (archive montable comme une clef USB).

Borg constitue, pour mes besoins et à ma connaissance, la meilleure option en termes de simplicité, de confidentialité et de performances à ce jour.

2.2 Vocabulaire

Les fichiers à sauvegarder sont tronçonnés en blocs de taille limitée, le système leur attribue un identifiant unique (hash).

Un dépôt est un espace de stockage contenant des « blocs » et des archives. Un dépôt est matérialisé par un dossier et référencé par son chemin, par exemple /mnt/sauvegarde/mamachine pour un dépôt local ou user@host:/mnt/sauvegarde/mamachine pour un dépôt distant. On peut choisir de chiffrer un dépôt.

Une archive représente un ou plusieurs dossiers sauvegardés à une date/heure donnée ; elle est contenue dans un dépôt, et est référencée par un chemin type <dépôt>::<nom archive>. Par exemple, si je nomme mes sauvegardes par date au sein du dépôt /mnt/sauvegarde/mamachine, mon archive pourra s'appeler /mnt/sauvegarde/mamachine::2016-05-04. On peut choisir de compresser une archive (et donc les blocs auxquels elle fait référence).

L'archive ne contient pas les blocs, mais référence leurs hash (identifiants uniques) au sein du dépôt.

Pour résumer, chaque opération de sauvegarde (par exemple quotidienne) crée une nouvelle archive et stocke le contenu des nouveaux blocs (nouveaux fichiers ou parties modifiées) au sein du dépôt.

2.3 Installation

Un paquet borgbackup est disponible dans les backports [BPO] de Debian ou directement dans Ubuntu 16.04. Dans ces deux cas, apt install borgbackup fera l'affaire.

Si la documentation [DOC] ne mentionne pas de paquets dédiés à votre distribution, il reste la méthode universelle :

# pip install borgbackup

Quelle que soit l'opération (sauvegarde, montage, restauration…), on appellera toujours la commande borg en utilisant ses différentes sous-commandes (borg create, borg mount, borg extract…). En cas de saine curiosité, borg --help ou borg <sous-commande> --help sont vos amis.

2.4 Utilisation locale

Nous allons ici sauvegarder un dossier local : /home/jdoe dans un autre dossier local : /mnt/sauvegarde/. Il est bien sûr possible que ce dossier local soit une clef USB, un montage SshFS, NFS… Cet aspect est laissé à la compétence du lecteur.

Première étape : initialiser un dépôt vide :

# borg init /mnt/sauvegarde/borg_repo

Le système vous demande une phrase de passe :

Enter new passphrase:

Enter same passphrase again:

Do you want your passphrase to be displayed for verification? [yN]:

Cette phrase de passe sert à déverrouiller la clef chiffrant/déchiffrant (clef symétrique) les sauvegardes du dépôt.

Nous allons ensuite sauvegarder une première archive dans ce dépôt (les options --stats et --info nous permettent de savoir en détail ce qui s'est passé), la phrase de passe choisie précédemment va vous être demandée.

# borg create --info --stats /mnt/sauvegarde/borg_repo::lundi /home/jdoe/

Enter passphrase for key /mnt/sauvegarde/borg_repo:

------------------------------------------------------------------------------

Archive name: lundi

Archive fingerprint: 4cc91816b246b817970f76655eec9b692a58e929bb92d05542998a407bd87b4a

Time (start): Fri, 2016-05-20 18:22:14

Time (end): Fri, 2016-05-20 18:22:25

Duration: 10.83 seconds

Number of files: 100

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

This archive: 269.18 MB 269.19 MB 253.34 MB

All archives: 269.18 MB 269.19 MB 253.34 MB

 

Unique chunks Total chunks

Chunk index: 173 182

------------------------------------------------------------------------------

Le dossier sauvegardé contient 100 photos, la différence entre Compressed size et Deduplicated size laisse à supposer qu'il y ait probablement plusieurs fichiers identiques dans mon dossier, et que Borg les a dédupliqués.

Compression

Par défaut, aucune compression n'est activée, l'option --compression <algo> de la commande borg create permet de sélectionner un algorithme de compression parmi les suivants :

 

 

Force de la compression

Vitesse de compression

lz4

faible

rapide

zlib,N

intermédiaire

intermédiaire

lzma,N

forte

lente

N est la force de la compression entre 0 et 9 (9 est le plus efficace, mais le plus lent). Il n'y a pas de degré de compression idéal, cela dépend des situations et demande quelques essais et ajustements (attention toutefois, changer de compression obligera à retransférer tous les fichiers, modifiés ou non).

Si vous choisissez de compresser, gardez un œil sur d'éventuels ralentissements prolongés de la machine sauvegardée (notamment pour un poste de travail, qui est sauvegardé en même temps qu'il est utilisé), ils pourraient signifier une compression trop forte. Par exemple, sur un de mes serveurs, les sauvegardes sont envoyées via d'une connexion ADSL (lente), et le processeur de la machine n'est occupé à aucune autre tâche au moment d'effectuer les sauvegardes (la nuit) : j'utilise donc la compression la plus forte : lzma,9.

Si nous recréons une nouvelle archive immédiatement (aucun changement sur les fichiers sauvegardés), nous pouvons constater que celle-ci s'opère instantanément (0.11s) avec un surcoût en stockage quasiment nul :

# borg create --info --stats /mnt/sauvegarde/borg_repo::mardi /home/jdoe/

Enter passphrase for key /mnt/sauvegarde/borg_repo:

------------------------------------------------------------------------------

Archive name: mardi

Archive fingerprint: 54ca4a2d9993680b1abe25c1068eff4f712db966f4307d5027bdc5123f8bbde3

Time (start): Fri, 2016-05-20 18:24:46

Time (end): Fri, 2016-05-20 18:24:46

Duration: 0.11 seconds

Number of files: 100

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

This archive: 269.18 MB 269.19 MB 17.59 kB

All archives: 538.35 MB 538.37 MB 253.35 MB

 

Unique chunks Total chunks

Chunk index: 175 364

Modifions ensuite quelques fichiers (j'ai ajouté 10 photos et en ai supprimé 2), puis refaisons une sauvegarde :

# borg create --info --stats /mnt/sauvegarde/borg_repo::mercredi /home/jdoe/

Enter passphrase for key /mnt/sauvegarde/borg_repo:

------------------------------------------------------------------------------

Archive name: mercredi

Archive fingerprint: 48a57e48f5cf79d554edf699e59d39b295533599ffb7fb90ce0712d06fdaa08c

Time (start): Fri, 2016-05-20 18:29:37

Time (end): Fri, 2016-05-20 18:29:37

Duration: 0.32 seconds

Number of files: 108

------------------------------------------------------------------------------

Original size Compressed size Deduplicated size

This archive: 274.13 MB 274.13 MB 7.90 MB

All archives: 812.48 MB 812.50 MB 261.26 MB

 

Unique chunks Total chunks

Chunk index: 190 555

------------------------------------------------------------------------------

 

Seuls les 7.90 MB de données nouvelles ont été copiés ; cela reste très rapide.

2.5 Restauration de sauvegardes

Borg propose une approche originale pour visualiser ou restaurer une archive : en les montant comme on le ferait avec une clef USB. Il devient alors aisé d’explorer le contenu d'une archive de sauvegarde et d'en restaurer certains fichiers par simple copie.

Montons une des archives :

# mkdir /mnt/borg_archive

# borg mount /mnt/sauvegarde/borg_repo::mercredi /mnt/borg_archive

 

Il suffit ensuite de copier un fichier pour le restaurer depuis une archive :

# cp /mnt/borg_archive/home/jdoe/Images/DSCN7725.JPG /home/jdoe/Images/

 

Une fois nos opérations de sauvetage accomplies, il nous suffit de démonter l'archive.

# umount /mnt/borg_archive

 

Pour information, il existe également une commande borg extract qui permet de restaurer tout ou partie d'une archive sans la monter, utilisez borg extract --help pour en savoir plus.

Faut-il faire ses sauvegardes en root ?

Pour sauvegarder le /home d'un utilisateur en particulier, mieux vaut que ça soit l’utilisateur en question qui fasse lui-même ses sauvegardes. Pour sauvegarder tout le système ou bien des répertoires aux propriétaires divers, le faire en root reste la solution la moins complexe (et celle exposée ici). Une autre solution est d'utiliser un utilisateur unix dédié et des ACL autorisant la lecture seule sur tous les fichiers.

2.6 Utilisation distante

Il est souvent judicieux lorsque la connectivité le permet de déporter ses sauvegardes sur un autre lieu, qui n'est pas soumis aux mêmes aléas (incendie, vol…). Borg offre de sauvegarder sur n'importe quel volume monté, local ou distant (SSHFS, NFS, samba…). Une fois le système de fichiers distant monté, la procédure est strictement la même que pour une sauvegarde locale.

Cependant, Borg sait manipuler « nativement » une connexion SSH : notre machine à sauvegarder « pousse » ses sauvegardes, via une connexion SSH, sur une autre machine sur laquelle Borg est également installé. Cette méthode est plus performante. Les commandes borg à utiliser sont similaires.

Il est à noter que les sauvegardes étant chiffrables, il n'y a pas besoin d'avoir une confiance infinie dans le serveur accueillant les sauvegardes puisqu'il ne peut les lire (la passphrase qui déverrouille la sauvegarde ne quitte jamais le client).

Pour cet exemple :

- babasse est la machine à sauvegarder, le client ;

- nas est la machine accueillant les sauvegardes, le serveur.

2.6.1 Préparation du client (babasse)

S’il n'y a pas encore de clef SSH associée à l'utilisateur root, il faut en générer une :

root@babasse # ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

52:fa:b0:99:0e:0e:54:e2:2b:44:af:e9:cf:e1:79:16 root@nas

Vous pouvez accepter l'emplacement de stockage de la clef par défaut, et laisser une phrase de passe vide (sinon il sera compliqué d'automatiser les sauvegardes).

2.6.2 Préparation du serveur (nas)

Commencer par installer Borg (voir début de l'article) et openssh-server si ça n'est pas déjà le cas.

Il est préférable de créer un utilisateur dédié aux sauvegardes :

root@nas # useradd borg --create-home --home-dir /var/lib/borg-backups/

 

Vous pouvez changer /var/lib/borg-backups pour n'importe quel emplacement où vous êtes susceptible d'avoir suffisamment d'espace disque.

Cet utilisateur n'a pas de mot de passe, nous nous y connecterons uniquement avec une clef SSH ; autorisons d'ailleurs la clef précédemment créée :

root@nas # mkdir /var/lib/borg-backups/.ssh

root@nas # cat >> /var/lib/borg-backups/.ssh/authorized_keys

Copier/coller le contenu du fichier du fichier de clef publique (située sur dans /root/.ssh/id_rsa.pub) dans ce terminal, et presser [Ctrl]+[D] pour valider.

Le fichier /var/lib/borg-backups/.ssh/authorized_keys devrait ressembler à quelque chose comme ça :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD0BJAd6IDkJxw2etlizm8SxL+6XQVwln02Pw7uadlQMSp/xVToC+2mb7KIMVZIVySPUG+ceD4ZqXlPInh+BnqDDWHCjpKYMdHEx6T+Fx61gjHVLL3P6+CVVIQKbi1PmzfUZ+PSvtGxd/fRWRO5qxXCeT4cguL30ee6WAwKx2L9aaM+D5FsliXcY0AL91lqXMkG7XjyexDYE5kg6rx0sKly5YJmGe6K5r+OPF4cw44y67/aktJGm9bltpl7RIvOQB3vko5VWA+h7801kEPIaahIrir2FuCCLQF2Tzu+4Uxz0NsghK+ilqv+BwOL39cNNbYOEXYpZM7dN3or9R46Y5Yp root@babasse

 

2.6.3 Sauvegardons !

La sauvegarde est très similaire à une sauvegarde locale, sauf qu'on utilise un nom de dépôt distant :

root@babasse # borg init borg@nas.example.com:/var/lib/borg-backups/babasse

root@babasse # borg create borg@nas.example.com:/var/lib/borg-backups/babasse::2016-05-23 /home/jdoe

De même, le montage d'une archive se fait de manière transparente à travers le réseau :

root@babasse # borg mount borg@nas.example.com:/var/lib/borg-backups/babasse::2016-05-23

 

Magique, non ?

Sécurité

Il est possible de sécuriser davantage l'accès distant, voir la documentation officielle [SEC].

2.7 Automatisation

Nous utilisons la configuration par défaut de cron, qui s'arrange pour que les scripts placés dans /etc/cron.daily soient exécutés quotidiennement.

Puisque les sauvegardes sont poussées, l'automatisation est à configurer sur le client uniquement.

Jusqu'ici, Borg nous demandait la phrase de passe à chaque opération. À des fins d'automatisation, il nous faut désormais la stocker dans un fichier :

root@babasse # mkdir /root/.borg

root@babasse # cat > /root/.borg/passphrase

monmotdepasse

 

([Ctrl]+[D] pour valider)

…et la protéger des autres utilisateurs de la machine :

root@babasse # chmod 700 /root/.borg/passphrase

 

Je vous propose ensuite un script de sauvegarde (notez l'usage de borg prune pour supprimer les archives trop anciennes). Cette version est fonctionnelle, mais simplifiée et commentée, une version plus réaliste [SC2] est disponible en ligne, ainsi qu'un exemple de script gérant en sus la sauvegarde (dump) d'un annuaire LDAP et d'une base MySQL [SC1]).

root@babasse # cat > /etc/cron.daily/borg-backup

#!/bin/sh

#

# Script de sauvegarde.

#

# Envoie les sauvegardes sur un serveur distant, via le programme Borg.

# Les sauvegardes sont chiffrées

#

 

set -e

 

BACKUP_DATE=`date +%Y-%m-%d`

LOG_PATH=/var/log/borg-backup.log

 

export BORG_PASSPHRASE="`cat ~root/.borg/passphrase`"

BORG_REPOSITORY=borg@nas.example.com:/var/lib/borg-backups/babasse

BORG_ARCHIVE=${BORG_REPOSITORY}::${BACKUP_DATE}

 

borg create \

-v --stats --compression lzma,9 \

$BORG_ARCHIVE \

/etc /var/mail /home \

>> ${LOG_PATH} 2>&1

 

# Nettoyage des anciens backups

# On conserve

# - une archive par jour les 7 derniers jours,

# - une archive par semaine pour les 4 dernières semaines,

# - une archive par mois pour les 6 derniers mois.

 

borg prune -v $BORG_REPOSITORY \

--keep-daily=7 \

--keep-weekly=4 \

--keep-monthly=6 \

>> ${LOG_PATH} 2>&1

 

[Ctrl]+[D] pour valider, puis rendre le script exécutable :

# chmod 775 /etc/cron.daily/borg-backup

2.7.1 Cron et ordinateur personnel

Un ordinateur personnel n'est pas forcément allumé 24h/24, il est donc peu pertinent de demander à un script de s'exécuter à la même heure tous les jours. Aussi, il convient d'installer anacron, qui s'arrangera pour exécuter les scripts contenus dans /etc/cron.d/daily quotidiennement, en rattrapant « intelligemment » la tâche plus tard si l'ordinateur était éteint à l'heure configurée (si l'ordinateur était éteint une semaine complète, l'exécution ne sera rattrapée qu'une fois).

# apt install anacron

 

Aucune configuration supplémentaire n'est nécessaire.

Par ailleurs, notons que Borg saura reprendre proprement s’il est interrompu.

3. Avant de partir…

Nous avons pu survoler l'usage de Borg, et en aborder les points principaux ; voilà qui est suffisant pour mettre à l'abri efficacement vos données de l'inévitable crash disque (ou erreur humaine) qui vous arrivera forcément tôt ou tard, et pouvoir gérer la restauration ce jour venu.

Nous pourrions croire qu'une interface graphique manque à ce tableau, notamment dans le cadre d'une utilisation sur le poste de travail. Ça n'est en pas tout à fait exact : BorgWeb [GUI], développé par la même équipe offre une interface web agréable pour gérer et naviguer vos sauvegardes Borg sans ligne de commandes. Cela ne remplace toutefois pas une vraie intégration au bureau comme backintime peut le proposer (notifications, planification sans éditer une crontab…). La généralisation des sauvegardes pour tous passe à mon sens par l'existence de ces interfaces conviviales et intégrées.

Notez enfin qu'il peut être de bon ton de tester automatiquement l'état de votre dernière sauvegarde  (via des scripts maison ou via un logiciel type nagios/shinken) : il serait dommage de vous apercevoir le jour fatal que votre sauvegarde la plus récente date de six mois en arrière à cause d'un bug quelconque…

Références

[DOC] https://borgbackup.readthedocs.io/

[SC2] https://code.crapouillou.net/snippets/2

[SC1] https://code.crapouillou.net/snippets/1

[SEC] https://borgbackup.readthedocs.io/en/stable/quickstart.html#remote-repositories

[GUI] https://borgweb.readthedocs.io/

 

Sur le même sujet

Apprenez à utiliser kubeadm

Magazine
Marque
GNU/Linux Magazine
Numéro
236
|
Mois de parution
avril 2020
|
Domaines
Résumé

Combien de fois m'avez-vous entendu dire « nous allons utiliser kubeadm pour faire ceci ou faire cela », et puis boum, un kubeadm init plus tard, tout est prêt ? Souvent ? Très souvent ? Trop souvent ? Alors pour une fois, pourquoi ne pas consacrer un article entier à ce merveilleux projet ?

Le DevOps dans le monde réel

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

Cela fait environ cinq ans que les demandes de « DevOps » sont de plus en plus nombreuses dans le milieu professionnel. Souvent, lors des entretiens, on s'aperçoit que chaque client, ou presque, a sa propre définition du mot. Nous allons essayer de donner ici notre vision, tirée de notre expérience de terrain, de cette fonction.

KeeRest : mettez du DevOps dans votre KeePass

Magazine
Marque
MISC
Numéro
108
|
Mois de parution
mars 2020
|
Domaines
Résumé

Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.

LXC : les options avancées utiles en production

Magazine
Marque
Linux Pratique
Numéro
118
|
Mois de parution
mars 2020
|
Domaines
Résumé

La présentation de LXC faite dans le précédent numéro [1] nous a permis de mettre en œuvre les fonctionnalités de base et de créer rapidement des conteneurs fonctionnels. Cependant, les capacités de LXC ne s’arrêtent pas là et nous allons pouvoir étudier ici plusieurs options bien utiles en production.

Les alternatives à Git

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Dans le petit monde des gestionnaires de versions concurrentes, il n'existe pas que Git. D'autres projets permettent également de conserver les différentes versions d'un code et cet article permettra d'en faire un petit tour d'horizon.

Git, un tour d’horizon

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
107
|
Mois de parution
mars 2020
|
Domaines
Résumé

Le vocabulaire et les concepts-clés de Git ayant été définis dans le précédent article, nous allons maintenant nous intéresser à la manière dont les concepts présentés se réalisent à l’aide des commandes de l’outil. Bref, passons à la pratique !

Par le même auteur

Ne procrastinez plus vos sauvegardes grâce à Borg

Magazine
Marque
Linux Pratique
Numéro
98
|
Mois de parution
novembre 2016
|
Domaines
Résumé

Vous êtes frustrés par des sauvegardes interminables, fastidieuses à restaurer ? Vous considérez que ça n'est pas à un humain de jongler avec les sauvegardes « complètes » et « différentielles » ? Alors le logiciel Borg peut vous intéresser, tant pour sauvegarder un PC qu'un serveur.