info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
rsync-backup
0 views
Skip to first unread message
Marc SCHAEFER
Dec 11, 2022, 8:13:19 AM12/11/22
to
Bonjour,
j'utilise une vieille recette pour les sauvegardes servant à permettre
aux utilisateurs de restaurer eux-mêmes rapidement des fichiers,
sur des filesystems ext4, par exemple:
schaefer@shakotay:~$ rm .Sig
schaefer@shakotay:~$ setdate 2022-12-11.
2022-12-11.06-55-33 2022-12-11.13-07-50
schaefer@shakotay:~$ setdate 2022-12-11.13-07-50
schaefer@shakotay:~$ bkp diff .Sig
--- .Sig 1970-01-01 01:00:00.000000000 +0100
+++ /backup/backup.2022-12-11.13-07-50//data/home/schaefer/.Sig 2022-11-13 13:15:42.518993239 +0100
@@ -0,0 +1,2 @@
+Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
+je ne verrai pas votre réponse.
schaefer@shakotay:~$ bkp cp .Sig
schaefer@shakotay:~$ ls -la .Sig
-rw-r--r-- 1 schaefer schaefer 104 Nov 13 13:15 .Sig
schaefer@shakotay:~$ bkp diff .Sig
Actuellement, c'est implémenté par un simple rsync suivi d'un `cp -al'
implémentant les répertoires d'historiques (ici p.ex.
2022-12-11.13-07-50). C'était un peu la solution standard en l'an 2000.
Une autre solution serait de faire des snapshots LVM, mais quand j'avais
testé cela il y a fort longtemps cela avait un coût de performance et
bien sûr un coût d'espace disque: si l'on dépassait l'espace alloué au
snapshot en différences, le snapshot devenait invalide. Alors que le `cp
-al' prenait certes un peu de temps, mais ensuite aucune perte de
performance (allocation des inodes et c'est tout).
Avec btrfs, on peut faire des snapshots:
root@reliand:~/scripts# mkfs.btrfs -f -L btrfs-data /dev/big-test/nsa-logs
root@reliand:~/scripts# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/big--test-nsa--logs 100T 17M 100T 1% /mnt
root@reliand:~/scripts# date > /mnt/projects/toto
root@reliand:~/scripts# mkdir /mnt/.snapshots
root@reliand:~/scripts# btrfs subvolume snapshot /mnt /mnt/.snapshots/$(date --iso)
root@reliand:~/scripts# date > /mnt/projects/toto
root@reliand:~/scripts# diff -r /mnt /mnt/.snapshots/$(date --iso)
diff -r /mnt/projects/toto /mnt/.snapshots/2022-12-11/projects/toto
1c1
< Sun Dec 11 13:58:52 CET 2022
---
> Sun Dec 11 13:57:44 CET 2022
Only in /mnt/.snapshots: 2022-12-11
Bien sûr que les modifications subséquentes de l'original ont un coût
(espace disque), mais puis-je supposer que le coût de performance sera
plus bas qu'avec LVM ou non? Sauf erreur, par défaut, les différences
sont stockées dans un seul set dans le volume de base, pas par
snapshot, semble-t-il.
Avec btrfs, la solution du `cp -al' semble bien moins performante
qu'avec ext4.
--
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse.
j'utilise une vieille recette pour les sauvegardes servant à permettre
aux utilisateurs de restaurer eux-mêmes rapidement des fichiers,
sur des filesystems ext4, par exemple:
schaefer@shakotay:~$ rm .Sig
schaefer@shakotay:~$ setdate 2022-12-11.
2022-12-11.06-55-33 2022-12-11.13-07-50
schaefer@shakotay:~$ setdate 2022-12-11.13-07-50
schaefer@shakotay:~$ bkp diff .Sig
--- .Sig 1970-01-01 01:00:00.000000000 +0100
+++ /backup/backup.2022-12-11.13-07-50//data/home/schaefer/.Sig 2022-11-13 13:15:42.518993239 +0100
@@ -0,0 +1,2 @@
+Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
+je ne verrai pas votre réponse.
schaefer@shakotay:~$ bkp cp .Sig
schaefer@shakotay:~$ ls -la .Sig
-rw-r--r-- 1 schaefer schaefer 104 Nov 13 13:15 .Sig
schaefer@shakotay:~$ bkp diff .Sig
Actuellement, c'est implémenté par un simple rsync suivi d'un `cp -al'
implémentant les répertoires d'historiques (ici p.ex.
2022-12-11.13-07-50). C'était un peu la solution standard en l'an 2000.
Une autre solution serait de faire des snapshots LVM, mais quand j'avais
testé cela il y a fort longtemps cela avait un coût de performance et
bien sûr un coût d'espace disque: si l'on dépassait l'espace alloué au
snapshot en différences, le snapshot devenait invalide. Alors que le `cp
-al' prenait certes un peu de temps, mais ensuite aucune perte de
performance (allocation des inodes et c'est tout).
Avec btrfs, on peut faire des snapshots:
root@reliand:~/scripts# mkfs.btrfs -f -L btrfs-data /dev/big-test/nsa-logs
root@reliand:~/scripts# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/big--test-nsa--logs 100T 17M 100T 1% /mnt
root@reliand:~/scripts# date > /mnt/projects/toto
root@reliand:~/scripts# mkdir /mnt/.snapshots
root@reliand:~/scripts# btrfs subvolume snapshot /mnt /mnt/.snapshots/$(date --iso)
root@reliand:~/scripts# date > /mnt/projects/toto
root@reliand:~/scripts# diff -r /mnt /mnt/.snapshots/$(date --iso)
diff -r /mnt/projects/toto /mnt/.snapshots/2022-12-11/projects/toto
1c1
< Sun Dec 11 13:58:52 CET 2022
---
> Sun Dec 11 13:57:44 CET 2022
Only in /mnt/.snapshots: 2022-12-11
Bien sûr que les modifications subséquentes de l'original ont un coût
(espace disque), mais puis-je supposer que le coût de performance sera
plus bas qu'avec LVM ou non? Sauf erreur, par défaut, les différences
sont stockées dans un seul set dans le volume de base, pas par
snapshot, semble-t-il.
Avec btrfs, la solution du `cp -al' semble bien moins performante
qu'avec ext4.
--
Attention: limitez le nombre de lignes de citation à l'essentiel, sinon
je ne verrai pas votre réponse.
Doug713705
Dec 20, 2022, 2:44:19 PM12/20/22
to
Le 11-12-2022, Marc SCHAEFER nous expliquait dans
fr.comp.os.linux.configuration
(<tn4l1c$ka0$1...@shakotay.alphanet.ch>) :
> Bonjour,
Bonjour
> j'utilise une vieille recette pour les sauvegardes servant à permettre
> aux utilisateurs de restaurer eux-mêmes rapidement des fichiers,
> sur des filesystems ext4, par exemple:
[SNIP considération techniques autour des snapshots LVM/btrfs]
> Bien sûr que les modifications subséquentes de l'original ont un coût
> (espace disque), mais puis-je supposer que le coût de performance sera
> plus bas qu'avec LVM ou non? Sauf erreur, par défaut, les différences
> sont stockées dans un seul set dans le volume de base, pas par
> snapshot, semble-t-il.
>
> Avec btrfs, la solution du `cp -al' semble bien moins performante
> qu'avec ext4.
>
Pas re réponse directe à la question mais si tu en es à modifier ta
méthode de sauvegarde tu peux peut-être regarder du coté de BorgBackup
et de Vorta (une GUI pour BorgBackup).
https://www.borgbackup.org/
https://github.com/borgbase/vorta
Personnellement, depuis que je joue avec Borg je ne retournerai pas
sur mes vieux scripts rsync, ne serait-ce que pour la déduplication et
le versionnement qui font respectivement gagner de grandes quantités
d'espace disque et permettent à l'utilisateur de récupérer n'importe
quelle version de ses fichiers.
--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La môme kaléïdoscope
fr.comp.os.linux.configuration
(<tn4l1c$ka0$1...@shakotay.alphanet.ch>) :
> Bonjour,
Bonjour
> j'utilise une vieille recette pour les sauvegardes servant à permettre
> aux utilisateurs de restaurer eux-mêmes rapidement des fichiers,
> sur des filesystems ext4, par exemple:
> Bien sûr que les modifications subséquentes de l'original ont un coût
> (espace disque), mais puis-je supposer que le coût de performance sera
> plus bas qu'avec LVM ou non? Sauf erreur, par défaut, les différences
> sont stockées dans un seul set dans le volume de base, pas par
> snapshot, semble-t-il.
>
> Avec btrfs, la solution du `cp -al' semble bien moins performante
> qu'avec ext4.
>
méthode de sauvegarde tu peux peut-être regarder du coté de BorgBackup
et de Vorta (une GUI pour BorgBackup).
https://www.borgbackup.org/
https://github.com/borgbase/vorta
Personnellement, depuis que je joue avec Borg je ne retournerai pas
sur mes vieux scripts rsync, ne serait-ce que pour la déduplication et
le versionnement qui font respectivement gagner de grandes quantités
d'espace disque et permettent à l'utilisateur de récupérer n'importe
quelle version de ses fichiers.
--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La môme kaléïdoscope
scha...@alphanet.ch
Dec 21, 2022, 3:10:23 AM12/21/22
to
Doug713705 <doug.l...@free.fr> wrote:
> https://www.borgbackup.org/
Intéressant. D'après Wikipedia c'est un fork d'Attic [1]. Donc
Borgbackup, écrit en python, utilise des hashes pour déduplifier,
représente aussi l'historique des méta-datas, de la compression,
et possède un fs-fuse pour monter. Ca m'embête un peu que
cela soit écrit en Python, mais au moins c'est pas en PHP :)
Entre-temps, j'ai fait quelques progrès avec btrfs et cela marche pas
mal du tout à une performance semble-t-il similaire.
Je pourrais donc, pour ma fonctionnalité de restauration de petits
fichiers effacés par l'utilisateur, soit aller en direction de btrfs et
utiliser des snapshots montés ro ça aura exactement le même effet), soit
utiliser BorgBackup et adapter mes scripts `bkp' pour que l'utilisateur
final puisse l'utiliser de la manière actuelle.
Je vais y réfléchir, merci du pointeur.
[1] https://en.wikipedia.org/wiki/Attic_(backup_software)
> https://www.borgbackup.org/
Intéressant. D'après Wikipedia c'est un fork d'Attic [1]. Donc
Borgbackup, écrit en python, utilise des hashes pour déduplifier,
représente aussi l'historique des méta-datas, de la compression,
et possède un fs-fuse pour monter. Ca m'embête un peu que
cela soit écrit en Python, mais au moins c'est pas en PHP :)
Entre-temps, j'ai fait quelques progrès avec btrfs et cela marche pas
mal du tout à une performance semble-t-il similaire.
Je pourrais donc, pour ma fonctionnalité de restauration de petits
fichiers effacés par l'utilisateur, soit aller en direction de btrfs et
utiliser des snapshots montés ro ça aura exactement le même effet), soit
utiliser BorgBackup et adapter mes scripts `bkp' pour que l'utilisateur
final puisse l'utiliser de la manière actuelle.
Je vais y réfléchir, merci du pointeur.
[1] https://en.wikipedia.org/wiki/Attic_(backup_software)
Doug713705
Dec 21, 2022, 7:44:47 AM12/21/22
to
Le 21-12-2022, scha...@alphanet.ch nous expliquait dans
fr.comp.os.linux.configuration
(<tnuf1d$prk$3...@shakotay.alphanet.ch>) :
> Doug713705 <doug.l...@free.fr> wrote:
>> https://www.borgbackup.org/
>
> Intéressant. D'après Wikipedia c'est un fork d'Attic [1]. Donc
> Borgbackup, écrit en python, utilise des hashes pour déduplifier,
> représente aussi l'historique des méta-datas, de la compression,
> et possède un fs-fuse pour monter. Ca m'embête un peu que
> cela soit écrit en Python, mais au moins c'est pas en PHP :)
>
> Entre-temps, j'ai fait quelques progrès avec btrfs et cela marche pas
> mal du tout à une performance semble-t-il similaire.
>
> Je pourrais donc, pour ma fonctionnalité de restauration de petits
> fichiers effacés par l'utilisateur, soit aller en direction de btrfs et
> utiliser des snapshots montés ro ça aura exactement le même effet), soit
> utiliser BorgBackup et adapter mes scripts `bkp' pour que l'utilisateur
> final puisse l'utiliser de la manière actuelle.
L'intérêt de BorgBackup par rapport à un snapshot du FS réside dans le
fait que la sauvegarde est déportée du poste à sauvegarder mais reste
accessible via le réseau. Ça me semble plus sécurisant que d'avoir la
sauvegarde sur le même poste.
Par ailleurs il est écrit partout dans la littérature sur le sujet que
d'utiliser les snapshots comme une solution de sauvegarde est une erreur
fondamentale.
Il me semble tout à fait raisonnable de faire un snapshots avant une
grosse modification mais la durée de vie d'un snapshot ne devraitt pas
excéder le temps de l'intervention. Enfin, si tu pars sur l'idée d'un
snaphot roulant (i.e un snapshot par jour remplacé tous les jours), cela
gèrera pas plusieurs version d'un même fichier.
Typiquement BorgBackup permet de définir des politiques de rétention du
type "une sauvegarde par jour sur une semaine, une par semaine sur un
mois, une par mois sur un an" qui permettra de revenir sur un nombre
conséquent de version. C'est évidemment parfaitement adaptable à
n'importe quel cas.
Bref, plus de souplesse, plus de sécurité et franchement simple à
mettre en oeuvre.
Pour le coté Python, c'est une affaire de goût. Pour ma part je gère
très bien le Python donc ça ne me pose pas de problème mais ne
supportant pas moi même d'autres langages (coucou Ruby, JS, etc) je peux
comprendre que le gestionnaire de module puisse rebuter. Chacun ses
préférences.
> Je vais y réfléchir, merci du pointeur.
>
> [1] https://en.wikipedia.org/wiki/Attic_(backup_software)
De rien.
fr.comp.os.linux.configuration
(<tnuf1d$prk$3...@shakotay.alphanet.ch>) :
> Doug713705 <doug.l...@free.fr> wrote:
>> https://www.borgbackup.org/
>
> Intéressant. D'après Wikipedia c'est un fork d'Attic [1]. Donc
> Borgbackup, écrit en python, utilise des hashes pour déduplifier,
> représente aussi l'historique des méta-datas, de la compression,
> et possède un fs-fuse pour monter. Ca m'embête un peu que
> cela soit écrit en Python, mais au moins c'est pas en PHP :)
>
> Entre-temps, j'ai fait quelques progrès avec btrfs et cela marche pas
> mal du tout à une performance semble-t-il similaire.
>
> Je pourrais donc, pour ma fonctionnalité de restauration de petits
> fichiers effacés par l'utilisateur, soit aller en direction de btrfs et
> utiliser des snapshots montés ro ça aura exactement le même effet), soit
> utiliser BorgBackup et adapter mes scripts `bkp' pour que l'utilisateur
> final puisse l'utiliser de la manière actuelle.
fait que la sauvegarde est déportée du poste à sauvegarder mais reste
accessible via le réseau. Ça me semble plus sécurisant que d'avoir la
sauvegarde sur le même poste.
Par ailleurs il est écrit partout dans la littérature sur le sujet que
d'utiliser les snapshots comme une solution de sauvegarde est une erreur
fondamentale.
Il me semble tout à fait raisonnable de faire un snapshots avant une
grosse modification mais la durée de vie d'un snapshot ne devraitt pas
excéder le temps de l'intervention. Enfin, si tu pars sur l'idée d'un
snaphot roulant (i.e un snapshot par jour remplacé tous les jours), cela
gèrera pas plusieurs version d'un même fichier.
Typiquement BorgBackup permet de définir des politiques de rétention du
type "une sauvegarde par jour sur une semaine, une par semaine sur un
mois, une par mois sur un an" qui permettra de revenir sur un nombre
conséquent de version. C'est évidemment parfaitement adaptable à
n'importe quel cas.
Bref, plus de souplesse, plus de sécurité et franchement simple à
mettre en oeuvre.
Pour le coté Python, c'est une affaire de goût. Pour ma part je gère
très bien le Python donc ça ne me pose pas de problème mais ne
supportant pas moi même d'autres langages (coucou Ruby, JS, etc) je peux
comprendre que le gestionnaire de module puisse rebuter. Chacun ses
préférences.
> Je vais y réfléchir, merci du pointeur.
>
> [1] https://en.wikipedia.org/wiki/Attic_(backup_software)
scha...@alphanet.ch
Dec 21, 2022, 9:20:48 AM12/21/22
to
Doug713705 <doug.l...@free.fr> wrote:
> L'intérêt de BorgBackup par rapport à un snapshot du FS réside dans le
> fait que la sauvegarde est déportée du poste à sauvegarder mais reste
> accessible via le réseau. Ça me semble plus sécurisant que d'avoir la
> sauvegarde sur le même poste.
Ah, je parlais d'un rsync puis d'un snapshot, ce qui combine
> L'intérêt de BorgBackup par rapport à un snapshot du FS réside dans le
> fait que la sauvegarde est déportée du poste à sauvegarder mais reste
> accessible via le réseau. Ça me semble plus sécurisant que d'avoir la
> sauvegarde sur le même poste.
historisation des méta-données et des données, et une déduplification
d'origine.
> Par ailleurs il est écrit partout dans la littérature sur le sujet que
> d'utiliser les snapshots comme une solution de sauvegarde est une erreur
> fondamentale.
facilement restaurer des fichiers effacés. Il y a d'autres sauvegardes
selon l'adage "pas un seul outil, pas un seul chemin", y compris hors
site.
Ici, typiquement je fais:
rsync + cp -al avec historique de 2 mois, 3 sauvegardes par jour
ceci est pour facilement, par l'utilisateur non root, restaurer
des anciennes versions facilement avec mon outil "bkp"
c'est fait sur un autre disque que l'array de données
rsync + cp -al journalier hors site avec 9 disques en rotation
hebdomadaire, historique d'au moins 2 mois, souvent il y a la place
pour plus de 6 mois.
ceci c'est pour des comparaisons d'intégrité ou pour
restaurer rapidement en cas de crash total
sauvegarde tar une fois par mois, hors site, conservation sur
environ 10 ans, parfois plus, sur divers média (cassettes, clés
USB, disques-dur)
ceci c'est pour l'historisation à long terme, et aussi pour
la restauration en cas de crash total ou la comparaison
à plus long terme
incrémental une fois par jour, à distance, basé sur le tar
Ca veut dire qu'il y a au moins une sauvegarde par jour à distance, puis
beaucoup plus sur site.
La combinaison d'outils différents et de médias différents est à mon
avis une bonne chose.
Christophe PEREZ
Dec 22, 2022, 2:10:06 PM12/22/22
to
Le 20 Dec 2022 19:44:17 GMT, Doug713705 a écrit :
> si tu en es à modifier ta méthode de sauvegarde
Juste pour apporter une info à ceux qui ne connaîtraient pas, moi j'utilise
> si tu en es à modifier ta méthode de sauvegarde
bacula (https://www.bacula.org/). Un peu complexe à mettre en oeuvre (pour
moi) parce que très paramétrable, mais quand ça tourne, on n'y touche plus
pendant des années. Ça prend en charge tous mes besoins, et ça m'a fait
abandonner tout mon système de scripts persos précédents. Je crois que j'y
suis passé en 2015.
JKB
Dec 22, 2022, 5:12:03 PM12/22/22
to
avoir des disques qui décoiffent (volumes d'archivage et base de
données). Ça fonctionne bien depuis que j'ai viré les NAS en NFS
pour les mettre en iSCSI.
JKB
--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.
Doug713705
Dec 22, 2022, 9:11:01 PM12/22/22
to
Le 22-12-2022, Christophe PEREZ nous expliquait dans
fr.comp.os.linux.configuration
(<to29fi$e9u$1...@vmserveur.novazur.fr>) :
Jamais réussi à aller au bout du paramétrage tellement c'est horrible à
configurer. Pourtant j'étais et suis encore particulièrement intéressé
par Bacula mais la facilité de mise en oeuvre de BorgBackup + Vorta pour un
résultat équivalent m'a fait abandonner l'idée d'avoir un Bacula.
fr.comp.os.linux.configuration
(<to29fi$e9u$1...@vmserveur.novazur.fr>) :
configurer. Pourtant j'étais et suis encore particulièrement intéressé
par Bacula mais la facilité de mise en oeuvre de BorgBackup + Vorta pour un
résultat équivalent m'a fait abandonner l'idée d'avoir un Bacula.
Doug713705
Dec 22, 2022, 9:12:09 PM12/22/22
to
(<tnv4nv$tnm$1...@shakotay.alphanet.ch>) :
> Ca veut dire qu'il y a au moins une sauvegarde par jour à distance, puis
> beaucoup plus sur site.
>
> La combinaison d'outils différents et de médias différents est à mon
> avis une bonne chose.
Je me disais aussi que venant de ta part il était étonnant que tu
n'utilises que qelques scripts maison :)
> Ca veut dire qu'il y a au moins une sauvegarde par jour à distance, puis
> beaucoup plus sur site.
>
> La combinaison d'outils différents et de médias différents est à mon
> avis une bonne chose.
n'utilises que qelques scripts maison :)
scha...@alphanet.ch
Dec 23, 2022, 2:46:38 AM12/23/22
to
Doug713705 <doug.l...@free.fr> wrote:
>> La combinaison d'outils différents et de médias différents est à mon
>> avis une bonne chose.
>
> Je me disais aussi que venant de ta part il était étonnant que tu
> n'utilises que qelques scripts maison :)
Il y a bien longtemps je faisais partie de l'équipe Amanda, où j'avais
>> La combinaison d'outils différents et de médias différents est à mon
>> avis une bonne chose.
>
> Je me disais aussi que venant de ta part il était étonnant que tu
> n'utilises que qelques scripts maison :)
développé un support amélioré pour des autochangeurs et un mode
économique utilisant au mieux la capacité du média (~2000).
J'ai aussi testé bakula, mais je suis revenu aux outils de base (tar,
rsync, cp -al, snapshots LVM/ext4) il y a environ 15 ans.
Comme je vais tout redéployer autrement bientôt, c'est l'occasion
d'adapter les choses :)
JKB
Dec 23, 2022, 3:22:19 AM12/23/22
to
Le 23-12-2022, Doug713705 <doug.l...@free.fr> a écrit :
> Le 22-12-2022, Christophe PEREZ nous expliquait dans
> fr.comp.os.linux.configuration
> (<to29fi$e9u$1...@vmserveur.novazur.fr>) :
>
>> Le 20 Dec 2022 19:44:17 GMT, Doug713705 a écrit :
>>
>>> si tu en es à modifier ta méthode de sauvegarde
>>
>> Juste pour apporter une info à ceux qui ne connaîtraient pas, moi j'utilise
>> bacula (https://www.bacula.org/). Un peu complexe à mettre en oeuvre (pour
>> moi) parce que très paramétrable, mais quand ça tourne, on n'y touche plus
>> pendant des années. Ça prend en charge tous mes besoins, et ça m'a fait
>> abandonner tout mon système de scripts persos précédents. Je crois que j'y
>> suis passé en 2015.
>
> Jamais réussi à aller au bout du paramétrage tellement c'est horrible à
> configurer. Pourtant j'étais et suis encore particulièrement intéressé
> par Bacula mais la facilité de mise en oeuvre de BorgBackup + Vorta pour un
> résultat équivalent m'a fait abandonner l'idée d'avoir un Bacula.
Le problème de bacula, ce sont les "clefs" entre les différents
> Le 22-12-2022, Christophe PEREZ nous expliquait dans
> fr.comp.os.linux.configuration
> (<to29fi$e9u$1...@vmserveur.novazur.fr>) :
>
>> Le 20 Dec 2022 19:44:17 GMT, Doug713705 a écrit :
>>
>>> si tu en es à modifier ta méthode de sauvegarde
>>
>> Juste pour apporter une info à ceux qui ne connaîtraient pas, moi j'utilise
>> bacula (https://www.bacula.org/). Un peu complexe à mettre en oeuvre (pour
>> moi) parce que très paramétrable, mais quand ça tourne, on n'y touche plus
>> pendant des années. Ça prend en charge tous mes besoins, et ça m'a fait
>> abandonner tout mon système de scripts persos précédents. Je crois que j'y
>> suis passé en 2015.
>
> Jamais réussi à aller au bout du paramétrage tellement c'est horrible à
> configurer. Pourtant j'étais et suis encore particulièrement intéressé
> par Bacula mais la facilité de mise en oeuvre de BorgBackup + Vorta pour un
> résultat équivalent m'a fait abandonner l'idée d'avoir un Bacula.
services. C'est extrêmement mal expliqué dans la documentation (et
il y a des erreurs dans les fumeux "tutos" du web). Il faut
commencer par comprendre qui parle avec quoi avant de réussir à le
configurer.
Une fois que tu as compris qui parle avec quoi et quelles sont les
clefs à partager, il n'y a qu'un seul fichier de configuration
(simple) par composant :
- bacula-dir ;
- bacula-sd ;
- bacula-fd.
Et tout se laisse oublier.
Christophe PEREZ
Dec 23, 2022, 11:24:54 AM12/23/22
to
Le 23 Dec 2022 02:10:59 GMT, Doug713705 a écrit :
> Jamais réussi à aller au bout du paramétrage tellement c'est horrible à
> configurer.
Ça, j'en conviens, quand on part de 0.
> Jamais réussi à aller au bout du paramétrage tellement c'est horrible à
> configurer.
Après, quand ça fonctionne, et qu'on a compris quelques principes de base,
ça va, mais on évite les révolutions :D
Le truc, c'est que ça semble très puissant. On peut vraiment faire beaucoup
de choses avec, de façon très détaillée, alors forcément, ça rend la chose
plus complexe. Et ce qu'on trouve sur le net n'est pas toujours simple à
appréhender (en particulier sur les notions de durée de rétention des
sauvegardes).
Mais par exemple, l'ajout d'une machine à sauvegarder, est d'une simplicité
enfantine.
> Pourtant j'étais et suis encore particulièrement intéressé
> par Bacula mais la facilité de mise en oeuvre de BorgBackup + Vorta
> pour un résultat équivalent m'a fait abandonner l'idée d'avoir un
> Bacula.
ne suis pas prêt d'en changer ;)
Mais si jamais tu te lances, et que je peux apporter mes maigres
connaissances, ça sera avec plaisir.
Christophe PEREZ
Dec 23, 2022, 11:35:36 AM12/23/22
to
Le 23 Dec 2022 08:22:17 GMT, JKB a écrit :
> Le problème de bacula, ce sont les "clefs" entre les différents
> services.
Ouh ! Si c'est le seul problème qui s'est posé à toi, tu as bien de la
> Le problème de bacula, ce sont les "clefs" entre les différents
> services.
chance, ou tu es particulièrement doué ;)
Ça fait effectivement partie de la complexité de bacula, mais je trouve que
c'est très loin d'être le plus compliqué.
Surtout que ça, quand c'est configuré une fois, ça ne change plus jamais.
Donc on peut tâtonner au début, et quand ça marche, c'est définitivement
réglé.
> C'est extrêmement mal expliqué dans la documentation (et
> il y a des erreurs dans les fumeux "tutos" du web).
Perso, je ne sais plus de quoi j'étais parti, mais il me semble que c'était
une exemple de config, que j'ai adapté à mon cas jusqu'à ce que j'ai le
résultat souhaité.
JKB
Dec 23, 2022, 12:38:22 PM12/23/22
to
Le 23-12-2022, Christophe PEREZ <ch...@novazur.fr> a écrit :
> Le 23 Dec 2022 08:22:17 GMT, JKB a écrit :
>
>> Le problème de bacula, ce sont les "clefs" entre les différents
>> services.
>
> Ouh ! Si c'est le seul problème qui s'est posé à toi, tu as bien de la
> chance, ou tu es particulièrement doué ;)
Je ne sais pas si je suis particulièrement doué, mais c'est le seul
> Le 23 Dec 2022 08:22:17 GMT, JKB a écrit :
>
>> Le problème de bacula, ce sont les "clefs" entre les différents
>> services.
>
> Ouh ! Si c'est le seul problème qui s'est posé à toi, tu as bien de la
> chance, ou tu es particulièrement doué ;)
problème que j'ai eu.
> Ça fait effectivement partie de la complexité de bacula, mais je trouve que
> c'est très loin d'être le plus compliqué.
> Surtout que ça, quand c'est configuré une fois, ça ne change plus jamais.
> Donc on peut tâtonner au début, et quand ça marche, c'est définitivement
> réglé.
>
>> C'est extrêmement mal expliqué dans la documentation (et
>> il y a des erreurs dans les fumeux "tutos" du web).
>
> Ça c'est un doux euphémisme.
>
> Perso, je ne sais plus de quoi j'étais parti, mais il me semble que c'était
> une exemple de config, que j'ai adapté à mon cas jusqu'à ce que j'ai le
> résultat souhaité.
je suis parti du paquet source dans pkgsrc et j'ai commencé par lire
la doc pour la configuration. Je n'ai pas essayé de bodouillé à
partir de fichieres préexistants.
0 new messages