Merci pour ce lien vers un très bon tuto, bien documenté et clairement présenté. Je voulais m'essayer à utiliser BorgBackup depuis un moment, cela sera peut-être l'article qui me permettra de m'y mettre enfin !
J'attends la suite avec impatience pour en savoir plus sur la sauvegarde sur un serveur distant en particulier :)
Bonjour et merci pour la découverte de cet outil que je suis en train de tester.
J'ai toutefois quelques questions qui me tarabustent et comme j'ai la possibilité d'avoir une oreille et des réponses, je saute sur l'opportunité :
- tout ne semble pas si confidentiel que cela car :
--- il y a des données dans $HOME/.config/borg qu'il faut protéger des indiscrets (c.f. lien doc officielle)
--- il y a également le cache qu'il faut protéger (c.f. lien doc officielle)
- la documentation indique qu'il est possible de changer la passphrase, mais le texte est ambigu : changing the passphrase after passphrase and borg key got compromised does not protect future (nor past) backups to the same repository ; qu'est-ce que cela signifie ? (c.f. lien doc officielle)
- est-il possible d'avoir une sorte de version statique du programme ? Car le fait que le logiciel soit en python me rend un peu nerveux pour ce qui est de la conservation sur la durée (sans même parler de la peur de mettre à jour).
PS : j'ai eu des difficultés à utiliser Markdown (pourtant je l'utilise souvent) alors j'ai utilisé des traits d'union
changing the passphrase after passphrase and borg key got compromised does not protect future (nor past) backups to the same repository ; qu'est-ce que cela signifie ?
Il est dit que si la phrase de passe et la clé sont volés, changer la phrase de passe ne protège pas les données qui ont été chiffrées avec cette clé, dans le passé comme le futur. Le et est très important.
Il y a trois éléments à considérer ici :
la phrase de passe qui protège la clé.
la clé qui protège les données.
les données.
La phrase de passe sert à protéger la clé (c'est la clé de la clé, quoi). Si la phrase est volée sans que la clé soit volée, on peut changer cette phrase, la clé sera protégée par une nouvelle phrase de passe. C'est rapide et simple, et les données restent protégée par la clé. Youpi.
Si la clé est volée sans ce passe, les données sont encore relativement à l'abri, sauf si le voleur arrive à trouver le passe plus tard, et a accès aux données chiffrées. Changer la phrase de passe ne permet pas de garantir que la clé ne sera jamais décryptée à un moment ou un autre. Si la phrase était balèze1 le risque n'est pas forcément énorme.
Par contre, si la clé ET la phrase sont volées, changer la phrase de passe ne sert à rien, car même avec une nouvelle passphrase, la clé reste la même, et le voleur en a donc une version déchiffrée qui lui permet d'aller lire les données.
Donc dans ce dernier cas, il faut changer la clé.
Et c'est là que c'est embêtant, car pour changer la clé de données existantes, il faut déchiffrer les données avec l'ancienne clé, et les chiffrer de nouveau avec la nouvelle clé, et ça c'est beaucoup plus long ! De plus, je ne sais pas si Borg sait faire ça facilement.
Enfin c'est ce que j'ai compris.
Exemple: "blague a part la convergence taupiere ne permet plus de lire des poemes aux toilettes comme autrefois". ↩
tout ne semble pas si confidentiel que cela car :
--- il y a des données dans $HOME/.config/borg qu'il faut protéger des indiscrets (c.f. lien doc officielle)
--- il y a également le cache qu'il faut protéger (c.f. lien doc officielle)
Pour le dossier ~/.config/borg/security, il contient quelques métadonnées sur les dépôts (notamment le nonce) qui permettent de se rendre compte d'une tentative de modification du dépôt distant, mais rien d'extrêmement sensible non plus.
Le dossier ~/.config/borg/keys est quant à lui un peu plus sensible car il peut contenir les clefs (chiffrées) des dépôts, mais seulement si on utilise l'option --encryption keyfile lors de la création du dépôt. Si on utilise --encryption repokey, cette clef est stockée directement dans le dépôt lui-même et pas dans le home.
Pour le cache, il contient uniquement quelques métadonnées mais de toute façon, si un attaquant a accès à ces dossiers (que ce soit la config ou le cache), c'est qu'il a déjà accès aux données de la machine ; il n'a donc pas besoin d'accéder aux sauvegardes pour récupérer les données. Les risques sont donc plutôt minimes.
la documentation indique qu'il est possible de changer la passphrase, mais le texte est ambigu : changing the passphrase after passphrase and borg key got compromised does not protect future (nor past) backups to the same repository ; qu'est-ce que cela signifie ? (c.f. lien doc officielle)
Bon bah @cg à déjà fait une réponse très complète à ce sujet :D
est-il possible d'avoir une sorte de version statique du programme ? Car le fait que le logiciel soit en python me rend un peu nerveux pour ce qui est de la conservation sur la durée (sans même parler de la peur de mettre à jour).
J'ai la chance d'être développeur Python, du coup c'est un écosystème que je connais bien et ça ne me fait pas spécialement peur, surtout que le logiciel est dispo dans les dépôts officiels de la plupart des distro :)
Mais effectivement, il existe des versions standalone, comme l'indique la documentation officielle :
En ce qui concerne les données de ~/.config/borg, je vais jouer avec la variable BORG_BASE_DIR.
Sur ce point on sent l'orientation du logiciel : seules les données de la sauvegarde sont protégées ; grosso modo on se protège contre le voleur de disques, ou les indiscrétions des clouds, etc.
En ce qui concerne python, c'est vraiment une question d'expérience ; je connais C/C++/etc mais pas python et chaque changement me cause un « trauma » (dernier en date la quasi-obligation par Debian d'utiliser des environnements isolés pour installer des programmes externes python) ; alors qu'avec une version statique, je sais que j'arriverai toujours à m'en sortir même dans 10 ans.
Merci pour l'info concernant la version statique : cela me permet d'utiliser et de garder à côté des sauvegardes l'outil qui sait les manipuler :-)
Pour ma part, pour le moment, c'est surtout la dé-duplication en mode « facile » qui m'intéresse.
Je suis en train de chercher comment réaliser la tâche suivante :
synchroniser une arborescence de type :
->A
->B
->C
->D
suppression d'une partie de l'arborescence car je considère que seule la sauvegarde peut la conserver ; cela donnerait :
->C
->D
je rajoute des données à l'arborescence ; cela donnerait :
->C
->E
->D
synchroniser à nouveau mais en considérant que ->A et A->B sont toujours présents
Et l'outil ne semble pas permettre de faire cela ; je me trompe ?
PS : en fait je désire sauvegarder une arborescence, mais n'en utiliser qu'une partie au quotidien : si le besoin s'en fait sentir alors je peux sortir ce qui figure dans la sauvegarde et que j'avais retiré
Je suis pas sûr d'avoir tout comprit, mais il faut voir un dépôt Borg comme une suite d'archives successives (ou comme un dépôt Git pour les développeurs).
Si A et B sont présent sur le système lors d'une backup, ils seront conservés dans l'archive créée à ce moment là.
Si après on les supprimes du disque et qu'on refait une sauvegarde, ils seront absents de l'archive nouvellement créée, mais ils seront toujours dans l'archive précédente. Ils resteront donc dans le dépôt tant que l'archive qui les contient n'est pas supprimée (il suffit donc de la conserver et de faire attention lors de l'utilisation de la commande borg prune).
Disons que je cherche à faire de l'archivage également ; avec git, il est possible de modifier plusieurs parties du dépôt et de ne commiter/push que ce que l'on veut voir sur le serveur.
En fait Borg impose d'avoir un backup exactement identique à l'original, un peu comme les snapshot au niveau des systèmes de fichier, ou encore comme un seafile qui fonctionnerait en local (avec les précautions d'usage du fait d'être des outils différents évidemment).
C'est dommage mais c'est un choix qui se comprend.
# Très bon article, merci !
Posté par Matthieu (site web personnel) . Évalué à 5.
Merci pour ce lien vers un très bon tuto, bien documenté et clairement présenté. Je voulais m'essayer à utiliser BorgBackup depuis un moment, cela sera peut-être l'article qui me permettra de m'y mettre enfin !
J'attends la suite avec impatience pour en savoir plus sur la sauvegarde sur un serveur distant en particulier :)
[^] # Re: Très bon article, merci !
Posté par FLOZz (site web personnel) . Évalué à 4.
Ravi que ça te plaise !
Là j'ai déjà écrit la moitié du second article, je pense le sortir aux alentours du 16 octobre :)
# Quelques questions
Posté par lem__mel . Évalué à 4.
Bonjour et merci pour la découverte de cet outil que je suis en train de tester.
J'ai toutefois quelques questions qui me tarabustent et comme j'ai la possibilité d'avoir une oreille et des réponses, je saute sur l'opportunité :
- tout ne semble pas si confidentiel que cela car :
--- il y a des données dans $HOME/.config/borg qu'il faut protéger des indiscrets (c.f. lien doc officielle)
--- il y a également le cache qu'il faut protéger (c.f. lien doc officielle)
- la documentation indique qu'il est possible de changer la passphrase, mais le texte est ambigu : changing the passphrase after passphrase and borg key got compromised does not protect future (nor past) backups to the same repository ; qu'est-ce que cela signifie ? (c.f. lien doc officielle)
- est-il possible d'avoir une sorte de version statique du programme ? Car le fait que le logiciel soit en python me rend un peu nerveux pour ce qui est de la conservation sur la durée (sans même parler de la peur de mettre à jour).
PS : j'ai eu des difficultés à utiliser Markdown (pourtant je l'utilise souvent) alors j'ai utilisé des traits d'union
[^] # Re: Quelques questions
Posté par cg . Évalué à 6.
Il est dit que si la phrase de passe et la clé sont volés, changer la phrase de passe ne protège pas les données qui ont été chiffrées avec cette clé, dans le passé comme le futur. Le et est très important.
Il y a trois éléments à considérer ici :
La phrase de passe sert à protéger la clé (c'est la clé de la clé, quoi). Si la phrase est volée sans que la clé soit volée, on peut changer cette phrase, la clé sera protégée par une nouvelle phrase de passe. C'est rapide et simple, et les données restent protégée par la clé. Youpi.
Si la clé est volée sans ce passe, les données sont encore relativement à l'abri, sauf si le voleur arrive à trouver le passe plus tard, et a accès aux données chiffrées. Changer la phrase de passe ne permet pas de garantir que la clé ne sera jamais décryptée à un moment ou un autre. Si la phrase était balèze1 le risque n'est pas forcément énorme.
Par contre, si la clé ET la phrase sont volées, changer la phrase de passe ne sert à rien, car même avec une nouvelle passphrase, la clé reste la même, et le voleur en a donc une version déchiffrée qui lui permet d'aller lire les données.
Donc dans ce dernier cas, il faut changer la clé.
Et c'est là que c'est embêtant, car pour changer la clé de données existantes, il faut déchiffrer les données avec l'ancienne clé, et les chiffrer de nouveau avec la nouvelle clé, et ça c'est beaucoup plus long ! De plus, je ne sais pas si Borg sait faire ça facilement.
Enfin c'est ce que j'ai compris.
Exemple: "blague a part la convergence taupiere ne permet plus de lire des poemes aux toilettes comme autrefois". ↩
[^] # Re: Quelques questions
Posté par cg . Évalué à 3.
Bémol : ça ne sert à rien pour les sauvegardes existantes. Ça reste utile pour celles à venir.
[^] # Re: Quelques questions
Posté par lem__mel . Évalué à 3.
C'est ce que j'avais compris mais j'ai eu un doute car je ne voyais pas l'intérêt de ce paragraphe : quand la clef est compromise, tout est perdu.
Je suppose que la documentation se voulait pédagogique.
Merci pour la réponse !
[^] # Re: Quelques questions
Posté par FLOZz (site web personnel) . Évalué à 4.
Pour le dossier
~/.config/borg/security, il contient quelques métadonnées sur les dépôts (notamment le nonce) qui permettent de se rendre compte d'une tentative de modification du dépôt distant, mais rien d'extrêmement sensible non plus.Le dossier
~/.config/borg/keysest quant à lui un peu plus sensible car il peut contenir les clefs (chiffrées) des dépôts, mais seulement si on utilise l'option--encryption keyfilelors de la création du dépôt. Si on utilise--encryption repokey, cette clef est stockée directement dans le dépôt lui-même et pas dans le home.Pour le cache, il contient uniquement quelques métadonnées mais de toute façon, si un attaquant a accès à ces dossiers (que ce soit la config ou le cache), c'est qu'il a déjà accès aux données de la machine ; il n'a donc pas besoin d'accéder aux sauvegardes pour récupérer les données. Les risques sont donc plutôt minimes.
Bon bah @cg à déjà fait une réponse très complète à ce sujet :D
J'ai la chance d'être développeur Python, du coup c'est un écosystème que je connais bien et ça ne me fait pas spécialement peur, surtout que le logiciel est dispo dans les dépôts officiels de la plupart des distro :)
Mais effectivement, il existe des versions standalone, comme l'indique la documentation officielle :
Elles peuvent être téléchargées sur GitHub:
[^] # Re: Quelques questions
Posté par lem__mel . Évalué à 3.
En ce qui concerne les données de
~/.config/borg, je vais jouer avec la variable BORG_BASE_DIR.Sur ce point on sent l'orientation du logiciel : seules les données de la sauvegarde sont protégées ; grosso modo on se protège contre le voleur de disques, ou les indiscrétions des clouds, etc.
En ce qui concerne python, c'est vraiment une question d'expérience ; je connais C/C++/etc mais pas python et chaque changement me cause un « trauma » (dernier en date la quasi-obligation par Debian d'utiliser des environnements isolés pour installer des programmes externes python) ; alors qu'avec une version statique, je sais que j'arriverai toujours à m'en sortir même dans 10 ans.
Merci pour l'info concernant la version statique : cela me permet d'utiliser et de garder à côté des sauvegardes l'outil qui sait les manipuler :-)
Pour ma part, pour le moment, c'est surtout la dé-duplication en mode « facile » qui m'intéresse.
# borgbackup peut-il ignorer des modifications ?
Posté par lem__mel . Évalué à 2.
Je suis en train de chercher comment réaliser la tâche suivante :
synchroniser une arborescence de type :
suppression d'une partie de l'arborescence car je considère que seule la sauvegarde peut la conserver ; cela donnerait :
je rajoute des données à l'arborescence ; cela donnerait :
synchroniser à nouveau mais en considérant que
->AetA->Bsont toujours présentsEt l'outil ne semble pas permettre de faire cela ; je me trompe ?
PS : en fait je désire sauvegarder une arborescence, mais n'en utiliser qu'une partie au quotidien : si le besoin s'en fait sentir alors je peux sortir ce qui figure dans la sauvegarde et que j'avais retiré
[^] # Re: borgbackup peut-il ignorer des modifications ?
Posté par FLOZz (site web personnel) . Évalué à 4.
Je suis pas sûr d'avoir tout comprit, mais il faut voir un dépôt Borg comme une suite d'archives successives (ou comme un dépôt Git pour les développeurs).
Si A et B sont présent sur le système lors d'une backup, ils seront conservés dans l'archive créée à ce moment là.
Si après on les supprimes du disque et qu'on refait une sauvegarde, ils seront absents de l'archive nouvellement créée, mais ils seront toujours dans l'archive précédente. Ils resteront donc dans le dépôt tant que l'archive qui les contient n'est pas supprimée (il suffit donc de la conserver et de faire attention lors de l'utilisation de la commande
borg prune).[^] # Re: borgbackup peut-il ignorer des modifications ?
Posté par lem__mel . Évalué à 1.
Disons que je cherche à faire de l'archivage également ; avec git, il est possible de modifier plusieurs parties du dépôt et de ne commiter/push que ce que l'on veut voir sur le serveur.
En fait Borg impose d'avoir un backup exactement identique à l'original, un peu comme les snapshot au niveau des systèmes de fichier, ou encore comme un seafile qui fonctionnerait en local (avec les précautions d'usage du fait d'être des outils différents évidemment).
C'est dommage mais c'est un choix qui se comprend.
En tout cas merci pour cette découverte.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.