Installer BorgBackup sur un NAS

Posté par  . Édité par ZeroHeure, theojouedubanjo, palm123, Xavier Teyssier, Davy Defaud, Ysabeau et tankey. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
38
30
avr.
2020
Administration système

Borg est un outil de sauvegardes pour les systèmes UNIX/Linux, écrit en Python et activement développé (Borg est un fork d’Attic qui n’évolue plus). Borg cherche à fournir une solution efficace et sécurisée : la déduplication et la compression des blocs de données réduisent la place occupée par la sauvegarde, et le chiffrement protège et authentifie les données. La restauration est réalisable facilement et ne nécessite pas d’avoir les droits administrateur (montage de la sauvegarde par un utilisateur via FUSE).

Logo de BorgBackup

Cet article est une présentation de Borg autour d’un cas pratique. Il explique pas‐à‐pas comment installer et configurer le logiciel Borg sur un NAS pour effectuer des sauvegardes en mode client‐serveur via SSH. L’exemple donné se base sur un NAS Synology, mais est facilement transposable à n’importe quel autre serveur de stockage réseau.

Sommaire

Introduction

Inutile d’insister sur l’importance de réaliser des sauvegardes : que ce soit pour se prémunir de la perte accidentelle de fichiers (destruction, écrasement), d’acte de malveillance (rançongiciel) ou plus pragmatiquement pour retrouver une ancienne version d’un document. Comme le dit l’adage : « il y a deux types d’utilisateurs : ceux qui ont déjà perdu des données, et ceux qui vont en perdre ».

Le cas de figure typique auquel répond ce tutoriel est vaste : offrir pour soi‑même, mais aussi pour des amis ou la famille un espace de stockage permettant une sauvegarde régulière et sécurisée d’un ordinateur quelconque. On sauvegarde un répertoire, un point de montage ou tout un disque. En effet, la démocratisation de la fibre permet de mettre à disposition une telle ressource, et par conséquent de réaliser des sauvegardes hors site (ce qui protège contre le vol ou les incendies…) en passant par Internet, sans que ça prenne des heures.

Dans mon cas, j’ai pu réaliser une sauvegarde initiale d’un dossier de 7 Go en moins de quatre minutes (une fois les données compressées et dédupliquées il n’y avait plus que 4,73 Go), sachant que les sauvegardes suivantes du même répertoire ne prennent généralement que trente secondes (350 Mo dédupliqués).

Au niveau local, le client Borg suffit pour déposer les sauvegardes à travers un serveur de fichiers réseau tels que CIFS ou NFS. Mais dès que l’on veut le faire sur une machine hors réseau local, on est obligé de passer par le protocole SSH, par exemple en SSHFS ou encore SFTP.
Une bien meilleure approche consiste à utiliser BorgBackup à travers SSH en installant la partie serveur sur une machine distante, ce qui offre l’avantage d’avoir un contrôle plus fin à travers les options de borg serve : gestion des quotas, mode en écriture seule (--append-only) interdisant les destructions/prune des anciennes sauvegardes, restriction à un dépôt unique ou à un répertoire, et plus généralement le fait que l’on n’a pas besoin de mettre à disposition un accès complet à un partage comme on le ferait via SSHFS.

Un autre bénéfice du mode client‑serveur, c’est de permettre une opération de vérification de l’intégrité des sauvegardes (borg check) directement par le serveur, ce qui évite un fort trafic réseau si la vérification des blocs de données chiffrés devait se faire par le client qui est le seul à connaître la clé de chiffrement des données.

Il faut cependant avoir à l’esprit que les performances sont moindres lorsque l’on utilise le protocole SSH (66 % en moyenne d’après un test avec borg benchmark par rapport à un montage NFS v4).

Les avantages de BorgBackup sont multiples :

  • les sauvegardes sont sécurisées en ce sens où les données sont authentifiées et chiffrées (on peut se permettre de stocker ses sauvegardes chez un hébergeur en qui l’on n’a pas nécessairement confiance, une personne qui accéderait aux fichiers sauvegardés ne pourra rien en faire, dès lors qu’on a choisi un mot de passe solide) ;
  • la sauvegarde à travers le réseau utilise le protocole SSH, lui aussi réputé comme étant très sûr et sécurisé en plus d’être largement répandu ;
  • la place prise par la sauvegarde est optimisée : les données sont compressées (si on le désire) avec un algorithme plus ou moins efficace selon qu’on privilégie la rapidité de la compression sur le gain de place — pour autant que les données le permettent. Pour les blocs de données identiques, une déduplication va se faire, ce qui permet encore un gain de place, mais surtout lors de sauvegardes régulières qui sont de facto incrémentales.

Installation et configuration

Le but de ce tutoriel est d’installer le serveur de Borg sur un NAS Synology afin d’y déposer des sauvegardes depuis Internet ou le réseau local. Il faut bien sûr posséder un serveur de stockage (NAS) sur lequel on a les droits d’administrateur et le NAS doit être accessible en SSH.

Dans l’explication qui suit, on fait référence à deux machines :

  • NAS : c’est le serveur de stockage qui va héberger toutes les sauvegardes ;
  • Client : c’est une machine à partir de laquelle on va effectuer les sauvegardes, ça peut être un ordinateur sous GNU/Linux, FreeBSD ou encore sous macOS (voir les différentes façons de l’installer).

Installation sur NAS

Pour cet article, on utilise un NAS Synology. Il faut activer les paquets « Communauté » (section Community) depuis le centre de paquets, pour ensuite installer le paquet Borg, ce qui permet d’avoir le binaire du serveur qui tourne sur le NAS. Enfin, il faut créer un compte et un groupe dédiés pour faire tourner la partie serveur de Borg (par exemple borg-backup). Il faut aussi créer un répertoire NetBackup pour les sauvegardes, auquel on donne à l’utilisateur et au groupe dédiés un accès total (lecture et écriture).

Afin de pouvoir se connecter via SSH à ce compte, il est nécessaire sur un NAS Synology de l’affecter au groupe « administrators » :

borg-backup admin

Après tout cela, on se connecte au compte nouvellement créé sur le serveur de stockage et on s’assure que Borg est bien installé (on notera que, contrairement aux paquets fournis par l’éditeur, les paquets « Communautaires » (SynoCommunity) sont installés dans /usr/local/bin au lieu de /usr/bin) :

borg-backup@nas:~$ which borg
/usr/local/bin/borg

Installation sur Client

Borg est disponible pour la plupart des distributions et sur les divers BSD. Faites cependant attention d’utiliser la même version côté Client et côté NAS. Au besoin, téléchargez des binaires prêts à l’emploi ou bien installez via pip.

Créer une clé SSH sur Client

On va avoir besoin de créer une clé SSH depuis un compte root si l’on a besoin de sauvegarder des fichiers nécessitants des droits administrateur, ou bien depuis un compte utilisateur standard si c’est seulement son propre compte que l’on veut sauvegarder.

Prenons le cas où c’est l’utilisateur root qui fait une sauvegarde de plusieurs répertoires comme /etc et /home. On génère la clé SSH (on part du principe que le répertoire /root/.ssh existe sinon il faut le créer et positionner les droits à 0700) :

ssh-keygen -t ed25519 -f ~/.ssh/id_borg-backup

La commande ci‑dessus a pour effet de créer une paire de clés publique et privée spécifique avec l’algorithme Ed25519 permettant de se connecter au serveur de stockage. Si votre NAS ne gère pas l’Ed25519, vous pouvez choisir n’importe quel autre type de clé (RSA, ECDSA), la sécurisation de la session SSH n’étant pas cruciale du fait que Borg gère l’authentification et le chiffrement des sauvegardes.

Voici la configuration que j’ai dû rajouter pour que l’utilisateur root depuis la machine Client puisse accéder au serveur de stockage NAS (nas.local) avec la clé nouvellement créée :

client:~# cat ~/.ssh/config
Host nas.local
  User borg-backup
  IdentityFile ~/.ssh/id_borg-backup
  # on fait tourner ssh sur un port différent
  Port 2222
  # on gagne un peu de performances en désactivant la compression
  Compression no
  # https://borgbackup.readthedocs.io/en/stable/usage/serve.html
  ServerAliveInterval 10
  ServerAliveCountMax 30

Comme on a spécifié le nom du compte à utiliser et le port dans le fichier de configuration SSH, l’URL du dépôt s’écrit nas.local:/chemin/vers/le/dépôt. Si l’on préfère spécifier les paramètres de connexion dans l’URL, on écrit : borg-backup@nas.local:2222/chemin/vers/le/dépôt.

Il ne reste plus qu’à copier la clé publique de l’utilisateur root sur le serveur :

client:~# ssh-copy-id -i ~/.ssh/id_borg-backup.pub nas.local

Une fois la clé copiée, il est possible de se connecter sans avoir besoin de taper le mot de passe.

Mise en œuvre sur NAS : configurer ssh en mode restreint

Le chemin d’accès à Borg est /usr/local/bin sur NAS, alors que le binaire se trouve généralement sous /usr/bin. En se connectant via un accès SSH non restreint, le client borg va tenter de lancer un borg serve avec un chemin d’accès différent, ce qui va renvoyer l’erreur suivante :

Remote: sh: borg: command not found Connection closed by remote host. Is borg working on the server?

Plutôt que de chercher à avoir deux chemins d’accès identiques (certains sites vont proposer de contourner le problème en créant un lien symbolique), la bonne pratique est de spécifier le paramètre command du côté serveur dans le fichier authorized_keys, ce qui aura comme avantage supplémentaire de limiter la session SSH à la partie serveur (RPC) de Borg.

Se connecter en tant que borg-backup pour configurer le côté serveur en écoute d’OpenSSH, sur lequel le client va se connecter :

borg-backup@nas:~$ mkdir .ssh
borg-backup@nas:~$ chmod 700 .ssh
borg-backup@nas:~$ vi ~/.ssh/authorized_keys

Si la clé publique (~/.ssh/id_borg-backup.pub) n’est pas déjà présente, il faut la rajouter ; la clé doit ressembler à :

ssh-ed25519 AAAAC3Nza...P0S27t root@client

(il faut bien sûr copier la clé publique générée depuis le poste client)

Dernière étape, sécuriser les accès SSH de l’utilisateur root (sur Client) en leur restreignant les accès sur le serveur de stockage. Cette opération a pour objectif que les utilisateurs effectuant les sauvegardes et ayant un compte sur nas.local puissent uniquement faire des sauvegardes Borg à travers leur accès SSH.

Voici à quoi ressemble le fichier authorized_keys une fois les modifications effectuées :

borg-backup@nas:~$ cat .ssh/authorized_keys 
ssh-ed25519 AAAAC3Nza...BW09/R7Bm cyril@client
command="/usr/local/bin/borg serve --restrict-to-path /volume1/NetBackup/chezmoi/",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc ssh-ed25519 AAAAC3Nza...P0S27t root@client
command="/usr/local/bin/borg serve --restrict-to-repository /volume1/NetBackup/copain/ --storage-quota 128G",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc ssh-ed25519 AAAAC3Nza...SRW55E user@client2

Quelques explications s’imposent :

  • la première ligne, qui contient uniquement la clé cyril@client, permet de se connecter sur le NAS depuis un compte utilisateur pour effectuer la configuration ;
  • la partie command="..." que l’on rajoute sur les deux lignes suivantes permet de limiter la session SSH à une commande borg serve qui interagira avec la partie cliente lancée depuis les postes à sauvegarder ;
  • les options de restriction SSH après la commande no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc sont pour éviter des redirections de ports/X11 ou d’agent au sein de la session SSH (normalement on n’a pas tout ça sur le serveur de stockage, mais c’est une bonne pratique de sécurité de limiter les fonctionnalités d’OpenSSH à uniquement la communication client‐serveur du logiciel Borg) ;
  • il faut indiquer le chemin complet pour la commande borg serve ;
  • l’option --restrict-to-path permet à l’utilisateur root sur Client de créer plusieurs sauvegardes sous le dépôt qui lui est attribué, tandis que --restrict-to-repository limite l’utilisateur user@client2 à ne pouvoir faire la sauvegarde que dans le dépôt/répertoire spécifié et pas les sous‑répertoires ;
  • l’option --storage-quota impose un quota disque (c’est aussi possible d’avoir une limitation à l’initialisation, mais vu que c’est l’utilisateur distant qui effectue la création du dépôt, c’est plus sûr de le forcer sur le serveur de stockage).

N. B. — Il y avait un bogue, corrigé avec la version 1.1.8 (la version installée par défaut sur Synology et QNAP à l’heure où ces lignes sont écrites est la 1.1.7), qui permettait à un client de contourner le quota supposé être imposé par le serveur.

Mise en œuvre sur Client

On stocke le mot de passe en clair dans le fichier ~/.borg/passphrase :

umask 077
mkdir ~/.borg
vi ~/.borg/passphrase
[création d’une clé secrète si possible de façon totalement aléatoire]

Puis, on définit une variable d’environnement pour ne pas avoir à retaper le mot de passe :

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

Afin de pouvoir accéder et déchiffrer les sauvegardes sur le serveur, il faut s’assurer de copier la clé (mot de passe Borg) autre part que sur l’ordinateur qui déclenche les sauvegardes en cas de perte ou dysfonctionnement de ce dernier (la copier dans un endroit sécurisé).

On initialise avec le mode repokey-blake2 qui permet d’avoir une sauvegarde chiffrée et authentifiée avec AES :

borg init --encryption=repokey-blake2
'nas.local:/volume1/NetBackup/chezmoi/{hostname}'

Et pour vérifier que le dépôt est créé :

borg info 'nas.local:/volume1/NetBackup/chezmoi/{hostname}'

Cas d’un Client distant

Lorsque l’on fait une sauvegarde depuis Internet, à moins de rajouter une entrée dans le fichier /etc/hosts, on ne peut pas utiliser nas.local car c’est le nom pleinement qualifié (FQDN) de la machine qui héberge le dépôt qui doit être utilisé.

Petit mémo :

  • refaire la configuration client SSH ;
  • régénérer la clé depuis le compte utilisateur ;
  • la copier sur NAS comme précédemment ;
  • ne pas oublier de changer le fichier ~/.ssh/config sur NAS ;
  • initialiser borg init --encryption=repokey-blake2 'nas.example.com:/volume1/NetBackup/chezmoi/{hostname}'.

Exemples

Voici un exemple de script qui sauvegarde régulièrement les répertoires /etc, /var et /home :

#!/usr/bin/env bash

set -e

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

export BORG_PASSPHRASE="`cat ~root/.borg/passphrase`"
BORG_REPOSITORY="nas.local:/volume1/NetBackup/chezmoi/{hostname}"
BORG_ARCHIVE=${BORG_REPOSITORY}::{now:%Y-%m-%d}

borg create \
        --verbose --stats \
        $BORG_ARCHIVE \
        /etc /var /home \
        --exclude-caches \
        --exclude-nodump \
        --exclude /home/cyril/tmp \
        --noatime \
>> ${LOG_PATH} 2>&1

# Nettoyage des anciennes sauvegardes
# On conserve :
# - une archive par jour les 7 derniers jours ;
# - une archive par semaine pour les 6 dernières semaines ;
# - une archive par mois pour les 8 derniers mois.

borg prune --verbose \
        $BORG_REPOSITORY \
        --keep-daily=7 \
        --keep-weekly=6 \
        --keep-monthly=8 \
>> ${LOG_PATH} 2>&1

Il ne vous reste plus qu’à lancer vos sauvegardes régulièrement en copiant le script dans le répertoire /etc/cron.daily/ puis attendre d’en avoir besoin, en ayant cependant pris soin de les avoir testées pour s’assurer que l’on est en mesure de récupérer les données depuis un nouvel ordinateur (copiez la clé dans un endroit sûr ! ;-)).

La récupération peut se faire depuis n’importe quelle machine, y compris depuis un compte utilisateur normal, pourvu qu’il possède ces deux éléments :

  • une clé SSH permettant de se connecter au NAS (au processus borg serve) ;
  • la clé de chiffrement (ici repokey-blake2) pour s’authentifier et déchiffrer les données sauvegardées.

Si les deux conditions sont réunies, voici comment on peut monter un dépôt Borg distant sur un répertoire quelconque :

$ export BORG_PASSPHRASE="`cat ~/.borg/passphrase`"
$ borg list nas.local:/volume1/NetBackup/chezmoi/client | tail -n 2
2020-04-16                           Thu, 2020-04-16 06:58:43 [2f3824...f6e]
2020-04-17                           Fri, 2020-04-17 07:39:03 [ed3b98...c79]
$ mkdir /tmp/localborg/
$ borg mount nas.local:/volume1/NetBackup/chezmoi/client::2020-04-16 /tmp/localborg
$ cat /tmp/localborg/etc/issue.net
Debian GNU/Linux bullseye/sid
$ umount /tmp/localborg

Aller plus loin

  • # Super

    Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

    Pile au moment où j'en avais besoin, ton article tombe.

    Je devais justement testé Borg pour savoir ce qu'il avait dans le ventre et voir le fonctionnement réel.

    Du coup je sais ce que je vais faire pendant le WE…

    Merci

    • [^] # Re: Super

      Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

      Borg est sans conteste LA solution à mettre en place pour qui cherche une sauvegarde cryptée.

      C'est important de désactiver la compression au niveau ssh, les données chiffrées sont quasi incompressibles si le chiffrage est bon, inutile donc de ralentir le transfert pour rien (vu que les processeurs de NAS sont rarement très véloces).

      • [^] # Re: Super

        Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

        Il me semble que la compression est désactivée par défaut et qu'elle s'active avec l'option -C, est ce que je me trompe?

        Un LUG en Lorraine : https://enunclic-cappel.fr

        • [^] # Re: Super

          Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

          Ça dépend de ta config, mais en général oui elle est désactivée.

          Après c'est un bon point de le rappeler car certains ont pu prendre l'habitude de l'activer justement.

  • # `borg mount`++

    Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

    On peut même faire un peu plus rigolo en utilisant borg mount sans le ::2020-04-16 final, histoire d'avoir sous la main toutes les sauvegardes incrémentales, et de pouvoir se balader dans chacune jusqu'à trouver celle(s) qui nous intéresse(nt). :)

    Debian Consultant @ DEBAMAX

  • # Petit retour d'expérience

    Posté par  . Évalué à 3 (+2/-0).

    J'ai mis en place borg il y a quelques mois. Assez rapidement, le truc c'est retrouvé corrompu au delà de tout réparation prise en charge par l'outil.
    Du coup, je suis revenu à un plus simple script rsync incrémental.

    • [^] # Re: Petit retour d'expérience

      Posté par  . Évalué à 2 (+1/-0).

      On ne peut pas comparer borg et rsync pour des sauvegardes hors site sur une machine qu'on ne gère pas, surtout si les données sauvegardées sont sensibles, sans compter l'avantage de la compression et déduplication.

      Sinon, pour se prémunir de telles mésaventures a priori très rares (je n'ai jamais entendu parlé de pertes irrécupérables), la seule chose à faire c'est de lancer un "borg check" après chaque sauvegarde, ça garantie qu'il n'y a pas eu de corruption et que la sauvegarde pourra être utilisée.

      voici une page qui détaille bien la façon de s'en sortir dans ce genre de situation

      https://blog.garamotte.net/posts/2020/04/18/fr-repair-a-damaged-borg-repository.html

      • [^] # Re: Petit retour d'expérience

        Posté par  . Évalué à 1 (+0/-0).

        Oui, je vois. Après… rsync fait une sorte de déduplication, au niveau du fichier, et s'il ne bouge pas. Mais oui, je comprend bien que c'est pas une solution universelle. En l'occurence, pour moi, borg c'était overkill.

  • # Un GUI ou rien

    Posté par  (site Web personnel) . Évalué à 6 (+5/-0).

    J'ai utilisé plusieurs solutions de backup : fait maison à base de rsync, du propriétaire (Arcserve) et actuellement j'utilise BackupPC au boulot.

    Mais en fait peut importe la solution. Je suis arrivé à la conclusion qu'il faut obligatoirement une interface graphique lors de la restauration.

    Toute les opérations de restaurations sont délicates car souvent réalisées dans un contexte d'urgence et de pression de la part des utilisateurs/clients, donc pas le droit à l'erreur. Sauf à avoir de gros problèmes d'infra ou des utilisateurs/clients plus que maladroit c'est aussi une opération que vous n'allez pas réaliser tout les jours donc vous n'aurez pas forcément toutes les commandes entêtes (oui il y a moyen de faire une petite doc qui ne sera pas maintenu à jour ;) ).

    L'intérêt d'un GUI, lorsqu'il est bien construit (Arcserve est un très mauvais exemple) comme celui de BackupPC, une opération de restauration ce résume en 4 étapes :
    - connexion au serveur en https avec mon navigateur soit depuis mon poste ou alors directement depuis celui de l'utilisateur demandant la restauration;
    - sélection du serveur gérant le ou les fichiers à restaurer;
    - sélection du jour de sauvegarde;
    - trouver le ou les fichiers/dossiers.

    Le tout de façon intuitive et clair. Ensuite je peux choisir de télécharger les fichiers/dossiers à restaurer ou les envoyer en lieu et place de la source. Honnêtement depuis que j'utilise se système je transpire bien moins lorsqu'on me demande fouiller dans les sauvegardes.

    Born to Kill EndUser !

    • [^] # Re: Un GUI ou rien

      Posté par  . Évalué à 5 (+4/-0).

      Oui, je suis d'accord et c'est ce qui m'a freiné pendant longtemps pour passer à Borg.

      J'aime bien BackupPc que j'utilise aussi au boulot (en passe d'être changé), mais son interface web n'est pas folichonne et ça ne fait que de la déduplication via des liens (hardlinks) du système de fichier, donc limité à 65000 sur de l'ext4.

      Mais le fait d'avoir 1 commande mount en userland que l'on peut probablement intégré avec un script d'une ligne ou en autofs, ça veut dire qu'en terme de GUI il n'y a pas mieux que l'outil qu'on utilise tous les jours (gestionnaire de fichiers de son choix) pour naviguer et récupérer n'importe quels documents à partir de toutes les sauvegardes présentes (voir le commentaire de Cyril Brulebois indiquant le montage de l'ensemble des sauvegardes).

      Enfin, il y a des efforts pour proposer une interface web pour des postes Mac ou Linux (pas testé)
      https://github.com/borgbase/vorta

      • [^] # Re: Un GUI ou rien

        Posté par  . Évalué à 4 (+2/-0).

        Bonjour.
        J'utilise actuellement vorta sur une Linux mint à la maison. Je l'ai trouvé par hasard en cherchant un logiciel de sauvegarde, mon disque de données donnant des signes de fatigue.

        Le gestionnaire de logiciels m'a proposé vorta (en flatpack)

        J'ai pu faire une sauvegarde complète de mon home sur un DD externe et la restaurer sans aucune difficulté.

        Je suis donc actuellement en train de me bricoler une sauvegarde en continu, incrémentale de mon home et je me heurte à un seul obstacle pour l'instant : par l'interface de vorta, je ne vois pas mon lecteur réseau (un disque externe connecté à une raspberry pi partagé par samba).
        L'idéal à ce stade serait effectivement de paramétrer la sauvegarde une fois pour toute directement avec borg et de pouvoir profiter du gui pour monter, explorer et restaurer les sauvegardes.
        Du coup, je suis d'accord pour dire que ce billet tombe à point.

        Il se prend pour Napoléon, son état empire.

      • [^] # Re: Un GUI ou rien

        Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

        J'aime bien BackupPc que j'utilise aussi au boulot (en passe d'être changé), mais son interface web n'est pas folichonne et ça ne fait que de la déduplication via des liens (hardlinks) du système de fichier, donc limité à 65000 sur de l'ext4.

        Il me semble que BackupPC n'utilise plus la dedup via des hardlink

        BackupPC provides many additional features, such as compressed storage, deduplicating any matching files (rather than just files with the same name), and storing special files without root privileges. But these other programs provide simple, effective and fast solutions and are definitely worthy of consideration.

        https://backuppc.github.io/backuppc/BackupPC.html

        Mais le fait d'avoir 1 commande mount en userland que l'on peut probablement intégré avec un script d'une ligne ou en autofs

        Cela veut dire que ton parc est uniquement en Linux mais bien souvent en entreprise le poste utilisateur est en Windows.

        Le truc qui manque à BackupPC est une API ou un moyen de communiquer avec des outils externe de type supervision ou métrique. Il y a moyen de bricoler mais rien de bien extra pour le moment.

        Born to Kill EndUser !

        • [^] # Re: Un GUI ou rien

          Posté par  . Évalué à 2 (+1/-0).

          Il me semble que BackupPC n'utilise plus la dedup via des hardlink

          BackupPC provides many additional features, such as compressed storage, deduplicating any matching files (rather than just files with the same name), and storing special files without root privileges. But these other programs provide simple, effective and fast solutions and are definitely worthy of consideration.
          

          https://backuppc.github.io/backuppc/BackupPC.html

          c'est seulement à partir de la version 4 que le système n'utilise plus les liens (harlinks), sachant que la conversion ne pouvant pas se faire facilement, les liens resteront pour les backups initiés en v3 (hardlinks will still remain for any legacy V3 backups)
          L'autre truc c'est que la v4 n'est pas encore largement présente dans les distro
          https://repology.org/project/backuppc/versions
          -> quelques rares 4.3.2 et encore une solide présence de la 3.3.2

          Mais le fait d'avoir 1 commande mount en userland que l'on peut probablement intégré avec un script d'une ligne ou en autofs

          Cela veut dire que ton parc est uniquement en Linux mais bien souvent en entreprise le poste utilisateur est en Windows.

          Oui, c'est vrai que le portage Windows est un point faible de Borg
          L'article ne le mentionne pas, mais BorgBackup permet de stocker presque tous les attributs du système sauvegardé (à quelques rares exceptions), et que par conséquent pour Windows c'est compliqué d'avoir un stockage des attributs NTFS sans un port natif
          Il y a quand même des efforts pour un portage Cygwin si c'est seulement pour faire une sauvegarde sans les attributs

          Le truc qui manque à BackupPC est une API ou un moyen de communiquer avec des outils externe de type supervision ou métrique. Il y a moyen de bricoler mais rien de bien extra pour le moment.

          Oui, le fait que la sauvegarde est initiée par le client, ça serait bienvenu d'avoir un système permettant au serveur d'orchestrer (sérier) les sauvegardes ainsi que de permettre une métrologie

          Ça reste un bon système pour des sauvegardes perso hors-site faciles à mettre en place et tout aussi simple à récupérer (montage en userland d'une sauvegarde incrémentale spécifique comme si c'était une complète)

    • [^] # Re: Un GUI ou rien

      Posté par  . Évalué à 4 (+4/-0). Dernière modification le 01/05/20 à 09:57.

      C'est amusant, mais moi qui fait des backups à grand coup de "rsync -avv --delete --backup --backup-dir=…", ce que j'apprécierais, c'est une GUI qui fasse l'inverse :)

      Une GUI qui m'offre d'abord la possibilité de choisir le fichier/dossier à restaurer et qui proposerait seulement ensuite, les différentes versions/états (et donc dates) de ces fichiers/dossiers.

      je ne sais pas si BorgBackup ou BackupPC permettent ce genre de chose, mais c'est une option qui pourrait me faire changer d'outil.

      Edit : cela dit, j'approuve qu'une des choses les plus importantes à mes yeux, c'est bien "comment je restore" !

      • [^] # Re: Un GUI ou rien

        Posté par  . Évalué à 0 (+1/-1).

        Pour BackupPc, il est possible assez facilement de remonter dans le temps pour un fichier par l'interface web qui n'est pas des plus sexy.
        Mais cela c'est peut-être améliorer avec la v4.
        Un problème que j'avais rencontré avec BackupPc, c'était les fichiers ouverts sur PC qui n'étaient pas sauvegardés. Le shadow copy n'était pas possible à l'époque , il y a au moins 5 ans.
        Sinon on peut faire des choses sympa, comme réveiller les ordis pour faire la sauvegarde et les éteindre à la fin de la sauvegarde
        Ce que j'appréciais aussi dans BackupPc, c'était la taille des sauvegardes biens compressées.
        Maintenant j'utilise les outils proposés dans mon cas par Qnap qui font d'excellents nas. Jamais compris d'ailleurs pourquoi Synology avait une telle réputation en France.

  • # kopia

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 01/05/20 à 18:25.

    Un nouveau venu, pas encore stabilisé mais prometteur :
    https://github.com/kopia/kopia

    Il fait deduplication, cryptage et compression comme borg.
    En plus de borg il permet de sauvegarder dans le cloud (s3 etc) et y a une UI en option.
    Le dev est très actif, c'est un projet qui avance bien.

    • [^] # Re: kopia

      Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

      Ça a l'air plutôt pas mal, même si je ne sais pas si j'oserais utiliser un logiciel aussi jeune pour du backup. En doublon, peut-être…

  • # Taille et Archive

    Posté par  . Évalué à 3 (+1/-0).

    On avait utilisé Borg pour un projet, sur le papier, c'est très intéressant, en pratique, c'est autre chose. Son plus gros défaut (à l'époque, je ne sais pas si cela existe encore), c'est qu'il fallait le double d'espace disque pour créer l'archive chiffrée. Un véritable problème quand tu veux faire du backup sur des grosses données. La seule solution possible aurait été de monter le FS distant pour stocker directement l'archive avant l'upload. Après, peut-être que cela a changé avec le temps, en tout cas, à l'époque, Borg a été recalé à cause de ce souci.

    • [^] # Re: Taille et Archive

      Posté par  . Évalué à 2 (+0/-0).

      A priori, il y a maintenant des avancées sur les remotes backups:
      - https://borgbackup.readthedocs.io/en/stable/quickstart.html#automating-backups
      - https://borgbackup.readthedocs.io/en/stable/quickstart.html#remote-repositories
      A tester de nouveau, en espérant qu'il ne construise pas des fichiers locaux temporaires ou non

    • [^] # Re: Taille et Archive

      Posté par  . Évalué à 3 (+2/-0).

      Je ne sais pas quand ni pour quelle raison les sauvegardes chiffrées nécessitaient d'avoir le double de l'espace disque.

      Mais dans mon cas, et avec une version récente de Borg je n'ai pas ce problème :

      Je sauvegarde /home (environ 116,5Go) + /etc (71Mo) et /var (16G)

      La sauvegarde initiale faisait 106Go (probablement parce que /var ne prenait que 31Mo du fait que j'avais l'option --one-file-system et que /home était plus petit).

      La dernière sauvegarde fait 17,4Go :

      ------------------------------------------------------------------------------
                             Original size      Compressed size    Deduplicated size
      This archive:               17.42 GB              8.54 GB            416.10 MB
      All archives:                1.22 TB            909.71 GB            134.37 GB
      
                             Unique chunks         Total chunks
      Chunk index:                  945648              7518275

      et l'espace pris sur mon NAS des 17 sauvegardes fait 127Go (commande du -sh)

      tandis que mon cache local (~/.cache/borg) qui permet de garder des informations sur ce qui a été sauvegardé et ne faire transiter que les différences fait 176Mo (soit 1/720 de l'espace pris par les sauvegardes)

      J'imagine qu'ils ont optimisé l'espace ou corrigé le problème.

  • # ne pas utiliser l'option --exclude-if-present

    Posté par  . Évalué à 4 (+3/-0).

    Il faut utiliser l'option --exclude-if-present avec prudence au risque d'exclure tous les répertoires qui contiennent un tel fichier ou répertoire (tag).

    Dans le script mentionné et si on a un répertoire /home/<username>/.thumbnails, cette option a comme conséquence d'exclure tout le répertoire $HOME que l'on cherche justement à sauvegarder
    …ce qui n'est probablement pas le but recherché

    désolé pour cette erreur grossière

  • # Commentaire supprimé

    Posté par  . Évalué à 0 (+0/-0). Dernière modification le 19/05/20 à 18:41.

    Ce commentaire a été supprimé par l’équipe de modération.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.