Le blog de Genma
Vous êtes ici : Accueil » Informatique & Internet » GNU/Linux, Logiciels Libres » Soucis rencontrés avec Borg

Soucis rencontrés avec Borg

D 25 mars 2019     H 09:00     A Genma     C 6 messages   Logo Tipee

TAGS : Planet Libre Sauvegarde BorgBackup

J’utilise Borg en production depuis quelques mois maintenant et voici donc un retour d’expérience. Je n’ai pas de métrique /temps pour une volumétrie donnée de sauvegarde, je verrai pour faire ça dans un prochain billet je pense. Dans le présent billet je voudrais me concentrer sur les soucis que j’ai pu rencontré avec Borg. Par soucis c’est un bien grand mot. J’ai rencontré différents types d’erreur sans conséquences et pour lesquelles j’ai toujours pu avoir une résolution.

Borg est un logiciel fiable et de qualité, cela faisait partie de mes critères de test et de choix qui ont fait que j’ai d’abord utilisé Borg à titre personnel avant de passer à un usage en production.

Les messages de Borg dans le cas d’erreur sont assez explicites et parlant. Voici les quelques erreurs rencontrées et leurs résolutions.

Problème de lock -Failed to create/acquire the lock

borg create  -v --stats /Backup/Dossier_borg/::Projets_<span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+ZGF0ZSArJVktJW0tJWQtJUg6JW06JVM8L2NvZGU+"></span> /Projets/ 
Failed to create/acquire the lock /root/.cache/borg/4f59d52b3ca46decce6e3dedee7a057b64300a49f827629abff259af2bfbe297/lock.exclusive (timeout).

Problème rencontré La sauvegarde Borg refuse de se lancer sur un dossier. Le message parle d’un problème d’un fichier .lock en indiquant le chemin concerné par le lock.

Cause Lorsque Borg lance une sauvegarde sur un dossier, il crée un fichier .lock dans l’espace de sauvegarde qu’il utilise pour ses données. Si le processus Borg a été coupé / interrompu (lancement à travers SSH et perte de réseau ; interruption manuelle de la sauvegarde en cours...)

Résolution On supprime le fichier .lock et le dossier lock à l’endroit indiqué dans le message d’erreur. Et on relance la sauvegarde qui peut alors correctement se dérouler.

Qui des interruptions de Borg ?

Si on lance une sauvegarde Borg à travers SSH et que l’on a une coupure réseau, Borg est capable de reprendre là où il s’était arrêté.

Le nom de la sauvegarde prend alors une extension ".checkpoint" dans son nom, ce qui permet de savoir facilement que cette sauvegarde est incomplète / non achevée. A la relance suivante, si le nom est indentique, Borg repart et finalise cette sauvegarde. Si le nom est différent (dans mon cas je fais des sauvegardes avec un nom de la forme YYY-MM-DD-HH:MM), Borg conserve la sauvegarde avec un .checkpoint dans son nom.

Autres cas

Problème rencontré

Warning: The repository at location ssh://user@machine/Backup/Projet was previously located at ssh://user@machine2/Backup2/Projet
Do you want to continue? [yN] y
Cache is newer than repository - this is either an attack or unsafe (multiple repos with same ID)

Cause

Sur un espace de stockage avec un seul disque, j’ai eu un soucis de perte du disque. Par sécurité, selon la règles des 3-2-1, je fais une deuxième sauvegarde Borg identique sur un autre espace. J’ai donc récupéré les données sauvegardées également avec Borg sur un autre espace. Un Rsync, assez long.

Résolution

Pour que Borg retrouve ses petits, j’ai relancé Borg sur cet espace. Borg indique que l’espace de sauvegarde a changé de chemin, on valide. Et les sauvegardes suivantes se poursuivent en utilisant ce nouvel espace et les données des sauvegardes précédentes.

Cela nous montre qu’un espace de sauvegarde Borg peut être lui même sauvegardé par copie intégrale / déplacé, Borg se débrouillera et fera juste un warning quand on lance l’usage des données de cet espace de sauvegarde.

Conclusion

J’espère que ce retour sera utile à d’autres. N’hésitez pas à laisser en commentaire votre propre expérience de soucis rencontrés dans les usages de Borg. Merci à vous.

6 Messages

  • Je crois que tu n’as pas terminé ta phrase dans le cas du lock (au niveau des causes) :
    Si le processus Borg a été coupé / interrompu ([...])


  • Bonne idée de lister les résolutions aux problèmes rencontrés :)

    Par contre, pour le lock, il y a bien mieux (plus simple et sûr) que supprimer des éléments à la main : la commande "borg break-lock".

    Il est aussi possible de configurer le mode serveur de borg (commande "borg serve" dans le fichier authorized_keys) pour éviter cette erreur dans la plupart des cas : en cas de coupure réseau, le serveur se débrouille pour nettoyer de son coté et laisser le repo dans un état propre (incluant éventuellement l’archive checkpoint).

    Enfin, j’ajouterais que le lock a une utilité bien définie : éviter de lancer plusieurs traitements en parallèle sur un même repo Borg. Avant de débloquer manuellement, il convient de toujours vérifier qu’une sauvegarde n’est pas en cours, ou que le repo n’est pas monté dans un répertoire, par exemple.


  • Il me semble que ’l’entreprise dont tu ne peux plus dire le nom’ apparaît dans le host de tes commandes :-)


  • Salut, j’aurais bien complété avec mon expérience, mais BorgBackup est tellement fiable que je n’ai jamais rencontré de problèmes avec. Je l’utilise en mode serveur (borg serve) dans un container sur un dédié et c’est aussi des containers qui s’occupe de lancer les sauvegardes (home, vps, etc). En passant, j’utilise zstd et non lz4 pour la compression.

    J’avais conseillé BorgBackup a une petite boite d’hébergement web qui utilisait rsync. Ils sont passé de 24h à 4h pour l’intégralité des sauvegardes.


  • Sur Archlinux - qui fonctionne en rolling-release - il y a conflit, et pseudo-bug, avec le paquet récent python-msgpack 0.6.0-1, ce qui empêche les fonctions borg mount et borg extract
    J’ai posté sur le Wiki les contournements possibles


  • J’ai régulièrement des soucis avec ce message la :
    Warning: The repository at location ssh://user@machine/Backup/Projet was previously located at ssh://user@machine2/Backup2/Projet

    Mais comme c’est dans un process automatique (merci YunoHost) je ne peux pas répondre oui.
    C’est du au fait que j’ai des liens symboliques dans tous les sens sur mon serveur et que j’ai du mal configurer un truc.
    Enfin bref, ça m’embêtais.

    Jusqu’à il y a 5 minutes, je faisais comme indiqué ici, mais je viens de découvrir qu’on peut forcer le "yes" via la variable d’environnement BORG_RELOCATED_REPO_ACCESS_IS_OK

    En la mettant à yes, ça passe tout seul :-)