Je désire remplacer mon système de sauvegarde actuellement basé sur
backup-manager (j'ai bien l'impression qu'il me fait n'importe quoi).
C'est pour du backup uniquement local, sur la même machine. Backups de
répertoires, mais également de bases de données mysql et postgresql. En
ligne de commande (pas forcément exclusivement, mais l'interface
graphique ne m'intéresse pas).
En regardant les archives de la liste, j'ai pu lire :
- luckybackup
- rsnapshot
- backuppc (mais j'ai déjà eu à l'utiliser, et je n'accroche pas)
En consultant le ouèbe, notamment
https://wiki.archlinux.org/index.php/Synchronization_and_backup_programs
j'ai rajouté Borgbackup et Duplicity à ma liste, ainsi que les
applications utilisant ceux ci (duply, deja-dup et backupninja).
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel Huhardeaux
Le 05/05/2016 06:58, Jean-Michel OLTRA a écrit :
Bonjour,
Bonjour
Je désire remplacer mon système de sauvegarde actuellement basé sur backup-manager (j'ai bien l'impression qu'il me fait n'importe quoi).
C'est pour du backup uniquement local, sur la même machine. Backups de répertoires, mais également de bases de données mysql et postgresql. En ligne de commande (pas forcément exclusivement, mais l'interface graphique ne m'intéresse pas).
En regardant les archives de la liste, j'ai pu lire :
- luckybackup - rsnapshot - backuppc (mais j'ai déjà eu à l'utiliser, et je n'accroche pas)
En consultant le ouèbe, notamment https://wiki.archlinux.org/index.php/Synchronization_and_backup_programs j'ai rajouté Borgbackup et Duplicity à ma liste, ainsi que les applications utilisant ceux ci (duply, deja-dup et backupninja).
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
deja-dup pour la sauvegarde de mon portable. Pas de base de donnée, que des répertoires. Fait bien son boulot.
-- Daniel
Le 05/05/2016 06:58, Jean-Michel OLTRA a écrit :
Bonjour,
Bonjour
Je désire remplacer mon système de sauvegarde actuellement basé sur
backup-manager (j'ai bien l'impression qu'il me fait n'importe quoi).
C'est pour du backup uniquement local, sur la même machine. Backups de
répertoires, mais également de bases de données mysql et postgresql. En
ligne de commande (pas forcément exclusivement, mais l'interface
graphique ne m'intéresse pas).
En regardant les archives de la liste, j'ai pu lire :
- luckybackup
- rsnapshot
- backuppc (mais j'ai déjà eu à l'utiliser, et je n'accroche pas)
En consultant le ouèbe, notamment
https://wiki.archlinux.org/index.php/Synchronization_and_backup_programs
j'ai rajouté Borgbackup et Duplicity à ma liste, ainsi que les
applications utilisant ceux ci (duply, deja-dup et backupninja).
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
deja-dup pour la sauvegarde de mon portable. Pas de base de donnée, que
des répertoires. Fait bien son boulot.
Je désire remplacer mon système de sauvegarde actuellement basé sur backup-manager (j'ai bien l'impression qu'il me fait n'importe quoi).
C'est pour du backup uniquement local, sur la même machine. Backups de répertoires, mais également de bases de données mysql et postgresql. En ligne de commande (pas forcément exclusivement, mais l'interface graphique ne m'intéresse pas).
En regardant les archives de la liste, j'ai pu lire :
- luckybackup - rsnapshot - backuppc (mais j'ai déjà eu à l'utiliser, et je n'accroche pas)
En consultant le ouèbe, notamment https://wiki.archlinux.org/index.php/Synchronization_and_backup_programs j'ai rajouté Borgbackup et Duplicity à ma liste, ainsi que les applications utilisant ceux ci (duply, deja-dup et backupninja).
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
deja-dup pour la sauvegarde de mon portable. Pas de base de donnée, que des répertoires. Fait bien son boulot.
-- Daniel
JF Straeten
LO,
On Thu, May 05, 2016 at 06:58:47AM +0200, Jean-Michel OLTRA wrote:
[...]
- rsnapshot
[...]
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Oui, avec, et grand même ;-)
Ses intérêts majeurs sont, imho, que :
- chaque backup apparaît comme étant l'arborescence sauvegardée complète (grâce à des liens durs pour ne pas consommer d'espace si les fichiers n'ont pas changé) ;
Très pratique si des users neuneus sont susceptibles de devoir restaurer eux-mêmes : un montage en RO de ce répertoire et tout le monde a accès au dernier backup de ses fichiers. (Et plus si nécessité : ça fournit un historique aussi, il suffit de remonter dans le temps.)
- ce sont les fichiers tels quels dans le backup, copiés par rsync (pas de format particulier) ;
- une fois le fonctionnement compris, c'est assez facile à mettre en ½uvre ;
- ça utilise des outils de base : Perl (rsnapshot étant un programme Perl) et rsync, impossibles à ne pas trouver et éprouvés.
N'hésite pas si tu veux un exemple de config.
Sinon, il y a aussi (notamment) dar et obnam que je n'ai pas vu dans ta liste, avec des fonctionnalités intéressantes pour obnam notamment de déduplication de fichiers identiques, si je me souviens bien, mais j'ai toujours un cas de conscience à l'idée de reposer sur un système de backup qui ajoute une couche de complexité avec un format d'archive particulier.
C'est moins simple que les fichiers tels quels, et donc plus porteur d'emmerdes en cas de restauration, ne fut-ce que pour trouver la bonne version du soft pour lire l'archive, voire une archive corrompue (et ce n'est pas rarissime : Steve a rapporté avoir eu le coup cette semaine, avec une archive TGZ qui est pourtant un format qui ne date pas d'hier...)
Hih,
--
JFS.
LO,
On Thu, May 05, 2016 at 06:58:47AM +0200, Jean-Michel OLTRA wrote:
[...]
- rsnapshot
[...]
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Oui, avec, et grand même ;-)
Ses intérêts majeurs sont, imho, que :
- chaque backup apparaît comme étant l'arborescence sauvegardée
complète (grâce à des liens durs pour ne pas consommer d'espace si
les fichiers n'ont pas changé) ;
Très pratique si des users neuneus sont susceptibles de devoir
restaurer eux-mêmes : un montage en RO de ce répertoire et tout le
monde a accès au dernier backup de ses fichiers. (Et plus si
nécessité : ça fournit un historique aussi, il suffit de remonter
dans le temps.)
- ce sont les fichiers tels quels dans le backup, copiés par rsync
(pas de format particulier) ;
- une fois le fonctionnement compris, c'est assez facile à mettre en
½uvre ;
- ça utilise des outils de base : Perl (rsnapshot étant un programme
Perl) et rsync, impossibles à ne pas trouver et éprouvés.
N'hésite pas si tu veux un exemple de config.
Sinon, il y a aussi (notamment) dar et obnam que je n'ai pas vu dans
ta liste, avec des fonctionnalités intéressantes pour obnam notamment
de déduplication de fichiers identiques, si je me souviens bien, mais
j'ai toujours un cas de conscience à l'idée de reposer sur un système
de backup qui ajoute une couche de complexité avec un format d'archive
particulier.
C'est moins simple que les fichiers tels quels, et donc plus porteur
d'emmerdes en cas de restauration, ne fut-ce que pour trouver la bonne
version du soft pour lire l'archive, voire une archive corrompue (et
ce n'est pas rarissime : Steve a rapporté avoir eu le coup cette
semaine, avec une archive TGZ qui est pourtant un format qui ne date
pas d'hier...)
On Thu, May 05, 2016 at 06:58:47AM +0200, Jean-Michel OLTRA wrote:
[...]
- rsnapshot
[...]
Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Oui, avec, et grand même ;-)
Ses intérêts majeurs sont, imho, que :
- chaque backup apparaît comme étant l'arborescence sauvegardée complète (grâce à des liens durs pour ne pas consommer d'espace si les fichiers n'ont pas changé) ;
Très pratique si des users neuneus sont susceptibles de devoir restaurer eux-mêmes : un montage en RO de ce répertoire et tout le monde a accès au dernier backup de ses fichiers. (Et plus si nécessité : ça fournit un historique aussi, il suffit de remonter dans le temps.)
- ce sont les fichiers tels quels dans le backup, copiés par rsync (pas de format particulier) ;
- une fois le fonctionnement compris, c'est assez facile à mettre en ½uvre ;
- ça utilise des outils de base : Perl (rsnapshot étant un programme Perl) et rsync, impossibles à ne pas trouver et éprouvés.
N'hésite pas si tu veux un exemple de config.
Sinon, il y a aussi (notamment) dar et obnam que je n'ai pas vu dans ta liste, avec des fonctionnalités intéressantes pour obnam notamment de déduplication de fichiers identiques, si je me souviens bien, mais j'ai toujours un cas de conscience à l'idée de reposer sur un système de backup qui ajoute une couche de complexité avec un format d'archive particulier.
C'est moins simple que les fichiers tels quels, et donc plus porteur d'emmerdes en cas de restauration, ne fut-ce que pour trouver la bonne version du soft pour lire l'archive, voire une archive corrompue (et ce n'est pas rarissime : Steve a rapporté avoir eu le coup cette semaine, avec une archive TGZ qui est pourtant un format qui ne date pas d'hier...)
Hih,
--
JFS.
Jean-Michel OLTRA
Bonjour,
Le jeudi 05 mai 2016, JF Straeten a écrit...
> - rsnapshot
> Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Oui, avec, et grand même ;-)
Pour le coup, je l'ai mis en place. Je vais voir ce que ça donne. Merci pour l'avis favorable.
Sinon, il y a aussi (notamment) dar et obnam que je n'ai pas vu dans ta liste, avec des fonctionnalités intéressantes pour obnam notamment de déduplication de fichiers identiques, si je me souviens bien, mais j'ai toujours un cas de conscience à l'idée de reposer sur un système de backup qui ajoute une couche de complexité avec un format d'archive particulier.
C'est moins simple que les fichiers tels quels, et donc plus porteur d'emmerdes en cas de restauration, ne fut-ce que pour trouver la bonne version du soft pour lire l'archive, voire une archive corrompue (et ce n'est pas rarissime : Steve a rapporté avoir eu le coup cette semaine, avec une archive TGZ qui est pourtant un format qui ne date pas d'hier...)
J'avais plus ou moins écarté Borgbackup pour cette raison, car il semble fonctionner de manière identique à Obnam (et le site indique que l'application est en développement). Pourtant, cette déduplication de fichier semble séduisante. Il faudra l'essayer…
-- jm
Bonjour,
Le jeudi 05 mai 2016, JF Straeten a écrit...
> - rsnapshot
> Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Oui, avec, et grand même ;-)
Pour le coup, je l'ai mis en place. Je vais voir ce que ça donne. Merci
pour l'avis favorable.
Sinon, il y a aussi (notamment) dar et obnam que je n'ai pas vu dans
ta liste, avec des fonctionnalités intéressantes pour obnam notamment
de déduplication de fichiers identiques, si je me souviens bien, mais
j'ai toujours un cas de conscience à l'idée de reposer sur un système
de backup qui ajoute une couche de complexité avec un format d'archive
particulier.
C'est moins simple que les fichiers tels quels, et donc plus porteur
d'emmerdes en cas de restauration, ne fut-ce que pour trouver la bonne
version du soft pour lire l'archive, voire une archive corrompue (et
ce n'est pas rarissime : Steve a rapporté avoir eu le coup cette
semaine, avec une archive TGZ qui est pourtant un format qui ne date
pas d'hier...)
J'avais plus ou moins écarté Borgbackup pour cette raison, car il semble
fonctionner de manière identique à Obnam (et le site indique que
l'application est en développement). Pourtant, cette déduplication
de fichier semble séduisante. Il faudra l'essayer…
> Vous utilisez ces choses là avec bonheur (ou pas) ? Autre chose ?
Oui, avec, et grand même ;-)
Pour le coup, je l'ai mis en place. Je vais voir ce que ça donne. Merci pour l'avis favorable.
Sinon, il y a aussi (notamment) dar et obnam que je n'ai pas vu dans ta liste, avec des fonctionnalités intéressantes pour obnam notamment de déduplication de fichiers identiques, si je me souviens bien, mais j'ai toujours un cas de conscience à l'idée de reposer sur un système de backup qui ajoute une couche de complexité avec un format d'archive particulier.
C'est moins simple que les fichiers tels quels, et donc plus porteur d'emmerdes en cas de restauration, ne fut-ce que pour trouver la bonne version du soft pour lire l'archive, voire une archive corrompue (et ce n'est pas rarissime : Steve a rapporté avoir eu le coup cette semaine, avec une archive TGZ qui est pourtant un format qui ne date pas d'hier...)
J'avais plus ou moins écarté Borgbackup pour cette raison, car il semble fonctionner de manière identique à Obnam (et le site indique que l'application est en développement). Pourtant, cette déduplication de fichier semble séduisante. Il faudra l'essayer…
-- jm
Pierre Chevalier
Bonsoir,
(pardon pour le doublon, Jean-Michel: j'avais *encore* commis la bévue d'oublier de répondre à tous, mea culpa...)
Le 05/05/2016 06:58, Jean-Michel OLTRA a écrit :
C'est pour du backup uniquement local, sur la même machine. Backups de répertoires, mais également de bases de données mysql et postgresql.
Pour postgresql, il y avait une conf à ce sujet au dernier PgDay de Paris (http://www.pgday.paris/) présentée par Magnus Hagander, excusez du peu.
Ce que j'en ai retenu (je n'ai pas trouvé sa présentation), c'est qu'il faut utiliser pg_basebackup (http://www.postgresql.org/docs/9.5/static/app-pgbasebackup.html). J'utilisais un bon vieux rsync pour sauvegarder tout mon disque, pensant bêtement que ça fonctionnerait tout bien. Hélas, j'ai eu un crash de SSD qui m'a contraint à tout restaurer. Mon cluster postgresql s'était évanoui, hélas. Magnus nous a, en gros, expliqué ce qu'il fallait ne pas faire. Et il y a BEAUCOUP de choses à ne pas faire!
Ah! en cherchant un peu plus sur la Toile, je viens de trouver un résumé un peu plus précis que mes vagues souvenirs: http://sismicfr.github.io/blog/2016/04/10/pgday-2016/
PostgreSQL Backup the modern ways - Magnus HAGANDER
Une conférence donnée par le président de PostgreSQL Europe, c’est quand même la classe, et en particulier sur les backups.
Après une légère introduction sur l’importance de tester ses backups (sous peine d’avoir des surprises ...), Magnus nous montre les différents moyens pour générer les backups, en passant par pg_dump (trop lent pour la restauration (et surtout aucun « PITR ») et pg_basebackup (qui est le moyen conseillé par Magnus).
Ce que nous retiendrons : pg_basebackup doit être utilisé pour plusieurs raisons: c’est un moyen sûr qui utilise le protocole de réplication, sauvegarde sur l’ensemble de l’instance et a une gestion des erreurs.
Très important, toujours utiliser -x ou -X pour inclure xlog ...
Outils à regarder : Barman, pgBackRest.
Sinon, pour tout le reste, un petite ligne rsync fignolée me sauvegarde tout tranquillou. Mais pas d'archivage, que de la sauvegarde. Pour de l'archivage, je fais de la copie bête d'une sauvegarde.
Merci de donner vos avis.
Voilà, 2 rien!
À+ Pierre -- Pierre Chevalier Mesté Duran 32100 Condom Tél : 09 75 27 45 62 - 06 37 80 33 64 http://pierremariechevalier.free.fr/ Logiciels Libres dans le Gers: http://gnusquetaires.org/
Bonsoir,
(pardon pour le doublon, Jean-Michel: j'avais *encore* commis la bévue
d'oublier de répondre à tous, mea culpa...)
Le 05/05/2016 06:58, Jean-Michel OLTRA a écrit :
C'est pour du backup uniquement local, sur la même machine.
Backups de répertoires, mais également de bases de données
mysql et postgresql.
Pour postgresql, il y avait une conf à ce sujet au dernier PgDay de
Paris (http://www.pgday.paris/) présentée par Magnus Hagander, excusez
du peu.
Ce que j'en ai retenu (je n'ai pas trouvé sa présentation), c'est qu'il
faut utiliser pg_basebackup
(http://www.postgresql.org/docs/9.5/static/app-pgbasebackup.html).
J'utilisais un bon vieux rsync pour sauvegarder tout mon disque, pensant
bêtement que ça fonctionnerait tout bien. Hélas, j'ai eu un crash de SSD
qui m'a contraint à tout restaurer. Mon cluster postgresql s'était
évanoui, hélas. Magnus nous a, en gros, expliqué ce qu'il fallait ne pas
faire. Et il y a BEAUCOUP de choses à ne pas faire!
Ah! en cherchant un peu plus sur la Toile, je viens de trouver un résumé
un peu plus précis que mes vagues souvenirs:
http://sismicfr.github.io/blog/2016/04/10/pgday-2016/
PostgreSQL Backup the modern ways - Magnus HAGANDER
Une conférence donnée par le président de PostgreSQL Europe,
c’est quand même la classe, et en particulier sur les backups.
Après une légère introduction sur l’importance de tester ses
backups (sous peine d’avoir des surprises ...), Magnus nous
montre les différents moyens pour générer les backups, en
passant par pg_dump (trop lent pour la restauration (et
surtout aucun « PITR ») et pg_basebackup (qui est le moyen
conseillé par Magnus).
Ce que nous retiendrons :
pg_basebackup doit être utilisé pour plusieurs raisons: c’est
un moyen sûr qui utilise le protocole de réplication,
sauvegarde sur l’ensemble de l’instance et a une gestion des
erreurs.
Très important, toujours utiliser -x ou -X pour inclure xlog
...
Outils à regarder : Barman, pgBackRest.
Sinon, pour tout le reste, un petite ligne rsync fignolée me sauvegarde
tout tranquillou. Mais pas d'archivage, que de la sauvegarde. Pour de
l'archivage, je fais de la copie bête d'une sauvegarde.
Merci de donner vos avis.
Voilà, 2 rien!
À+
Pierre
--
Pierre Chevalier Mesté Duran 32100 Condom
Tél : 09 75 27 45 62 - 06 37 80 33 64
http://pierremariechevalier.free.fr/
Logiciels Libres dans le Gers: http://gnusquetaires.org/
(pardon pour le doublon, Jean-Michel: j'avais *encore* commis la bévue d'oublier de répondre à tous, mea culpa...)
Le 05/05/2016 06:58, Jean-Michel OLTRA a écrit :
C'est pour du backup uniquement local, sur la même machine. Backups de répertoires, mais également de bases de données mysql et postgresql.
Pour postgresql, il y avait une conf à ce sujet au dernier PgDay de Paris (http://www.pgday.paris/) présentée par Magnus Hagander, excusez du peu.
Ce que j'en ai retenu (je n'ai pas trouvé sa présentation), c'est qu'il faut utiliser pg_basebackup (http://www.postgresql.org/docs/9.5/static/app-pgbasebackup.html). J'utilisais un bon vieux rsync pour sauvegarder tout mon disque, pensant bêtement que ça fonctionnerait tout bien. Hélas, j'ai eu un crash de SSD qui m'a contraint à tout restaurer. Mon cluster postgresql s'était évanoui, hélas. Magnus nous a, en gros, expliqué ce qu'il fallait ne pas faire. Et il y a BEAUCOUP de choses à ne pas faire!
Ah! en cherchant un peu plus sur la Toile, je viens de trouver un résumé un peu plus précis que mes vagues souvenirs: http://sismicfr.github.io/blog/2016/04/10/pgday-2016/
PostgreSQL Backup the modern ways - Magnus HAGANDER
Une conférence donnée par le président de PostgreSQL Europe, c’est quand même la classe, et en particulier sur les backups.
Après une légère introduction sur l’importance de tester ses backups (sous peine d’avoir des surprises ...), Magnus nous montre les différents moyens pour générer les backups, en passant par pg_dump (trop lent pour la restauration (et surtout aucun « PITR ») et pg_basebackup (qui est le moyen conseillé par Magnus).
Ce que nous retiendrons : pg_basebackup doit être utilisé pour plusieurs raisons: c’est un moyen sûr qui utilise le protocole de réplication, sauvegarde sur l’ensemble de l’instance et a une gestion des erreurs.
Très important, toujours utiliser -x ou -X pour inclure xlog ...
Outils à regarder : Barman, pgBackRest.
Sinon, pour tout le reste, un petite ligne rsync fignolée me sauvegarde tout tranquillou. Mais pas d'archivage, que de la sauvegarde. Pour de l'archivage, je fais de la copie bête d'une sauvegarde.
Merci de donner vos avis.
Voilà, 2 rien!
À+ Pierre -- Pierre Chevalier Mesté Duran 32100 Condom Tél : 09 75 27 45 62 - 06 37 80 33 64 http://pierremariechevalier.free.fr/ Logiciels Libres dans le Gers: http://gnusquetaires.org/
Sébastien Dinot
JF Straeten a écrit :
Sinon, il y a aussi (notamment) dar et obnam
J'ai longtemps utilisé dar qui fonctionne bien et propose des options fort intéressantes (découpage de la sauvegardes en tranches de taille arbitraire que l'on peut par exemple graver sur des DVD, redondance d'information pour pallier la corruption locale du fichier). Mais j'ai opté il y a quelques années pour rdiff-backup car l'approche différentielle est bien plus efficace que l'approche incrémentale, surtout lorsqu'on doit sauvegarder de gros fichiers qui évoluent marginalement (dump d'une base de données mais aussi, plus ponctuellement, ajout de méta-données à des images).
J'ai évalué obnam pendant quelques semaines fin 2014 : l'outil semblait prometteur mais il s'est révélé atrocement lent, du moins lorsqu'on l'utilise pour de la sauvegarde distante, ce qui était mon cas. Totalement inenvisageable dans mon cas d'utilisation !
J'ai évalué aussi un temps Attic (logiciel dont Borgbackup est un fork). Il s'est avéré très performant, y compris à distance mais il a quelques défauts qui ont fait que je n'ai toujours pas migré :
* peu de contributeurs (lâcher un outil non maintenu mais éprouvé pour un outil à peine maintenu et encore jeune, ce n'est pas une bonne idée) ;
* la déduplication engendre une sauvegarde opaque : impossible de récupérer la moindre version des données si l'outil bogue (une raison de plus d'opter pour un outil très bien maintenu).
De manière accessoire, les statistiques renvoyées sont complètement incompréhensibles et certaines commandes manquent à l'appel (des requêtes que l'on souhaiterait faire sur l'ensemble de l'historique ne sont possibles que sur un incrément donné).
Sébastien
-- Sébastien Dinot, http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
JF Straeten a écrit :
Sinon, il y a aussi (notamment) dar et obnam
J'ai longtemps utilisé dar qui fonctionne bien et propose des options
fort intéressantes (découpage de la sauvegardes en tranches de taille
arbitraire que l'on peut par exemple graver sur des DVD, redondance
d'information pour pallier la corruption locale du fichier). Mais j'ai
opté il y a quelques années pour rdiff-backup car l'approche
différentielle est bien plus efficace que l'approche incrémentale,
surtout lorsqu'on doit sauvegarder de gros fichiers qui évoluent
marginalement (dump d'une base de données mais aussi, plus
ponctuellement, ajout de méta-données à des images).
J'ai évalué obnam pendant quelques semaines fin 2014 : l'outil semblait
prometteur mais il s'est révélé atrocement lent, du moins lorsqu'on
l'utilise pour de la sauvegarde distante, ce qui était mon cas.
Totalement inenvisageable dans mon cas d'utilisation !
J'ai évalué aussi un temps Attic (logiciel dont Borgbackup est un fork).
Il s'est avéré très performant, y compris à distance mais il a quelques
défauts qui ont fait que je n'ai toujours pas migré :
* peu de contributeurs (lâcher un outil non maintenu mais éprouvé pour
un outil à peine maintenu et encore jeune, ce n'est pas une bonne
idée) ;
* la déduplication engendre une sauvegarde opaque : impossible de
récupérer la moindre version des données si l'outil bogue (une raison
de plus d'opter pour un outil très bien maintenu).
De manière accessoire, les statistiques renvoyées sont complètement
incompréhensibles et certaines commandes manquent à l'appel (des
requêtes que l'on souhaiterait faire sur l'ensemble de l'historique ne
sont possibles que sur un incrément donné).
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
J'ai longtemps utilisé dar qui fonctionne bien et propose des options fort intéressantes (découpage de la sauvegardes en tranches de taille arbitraire que l'on peut par exemple graver sur des DVD, redondance d'information pour pallier la corruption locale du fichier). Mais j'ai opté il y a quelques années pour rdiff-backup car l'approche différentielle est bien plus efficace que l'approche incrémentale, surtout lorsqu'on doit sauvegarder de gros fichiers qui évoluent marginalement (dump d'une base de données mais aussi, plus ponctuellement, ajout de méta-données à des images).
J'ai évalué obnam pendant quelques semaines fin 2014 : l'outil semblait prometteur mais il s'est révélé atrocement lent, du moins lorsqu'on l'utilise pour de la sauvegarde distante, ce qui était mon cas. Totalement inenvisageable dans mon cas d'utilisation !
J'ai évalué aussi un temps Attic (logiciel dont Borgbackup est un fork). Il s'est avéré très performant, y compris à distance mais il a quelques défauts qui ont fait que je n'ai toujours pas migré :
* peu de contributeurs (lâcher un outil non maintenu mais éprouvé pour un outil à peine maintenu et encore jeune, ce n'est pas une bonne idée) ;
* la déduplication engendre une sauvegarde opaque : impossible de récupérer la moindre version des données si l'outil bogue (une raison de plus d'opter pour un outil très bien maintenu).
De manière accessoire, les statistiques renvoyées sont complètement incompréhensibles et certaines commandes manquent à l'appel (des requêtes que l'on souhaiterait faire sur l'ensemble de l'historique ne sont possibles que sur un incrément donné).
Sébastien
-- Sébastien Dinot, http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Jean-Michel OLTRA
Bonjour,
Le lundi 09 mai 2016, Sébastien Dinot a écrit...
> Sinon, il y a aussi (notamment) dar et obnam
Finalement, j'ai mis rsnapshot et dar en route.
Les archives dar sont plus opaques que les sauvegardes rsnapshot. Je n'ai pas encore fait de test de restauration pour dar. Pour rsnapshot, c'est trivial. Rsnapshot semble utiliser plus de place, à contenu équivalent.
La mise en place de rsnapshot est rapide, celle de dar demande des scripts pour les différentes sauvegardes (la complète et les incrémentales).
A suivre. Encore merci pour les retours.
-- jm
Bonjour,
Le lundi 09 mai 2016, Sébastien Dinot a écrit...
> Sinon, il y a aussi (notamment) dar et obnam
Finalement, j'ai mis rsnapshot et dar en route.
Les archives dar sont plus opaques que les sauvegardes rsnapshot. Je
n'ai pas encore fait de test de restauration pour dar. Pour rsnapshot,
c'est trivial. Rsnapshot semble utiliser plus de place, à contenu
équivalent.
La mise en place de rsnapshot est rapide, celle de dar demande des
scripts pour les différentes sauvegardes (la complète et les
incrémentales).
Les archives dar sont plus opaques que les sauvegardes rsnapshot. Je n'ai pas encore fait de test de restauration pour dar. Pour rsnapshot, c'est trivial. Rsnapshot semble utiliser plus de place, à contenu équivalent.
La mise en place de rsnapshot est rapide, celle de dar demande des scripts pour les différentes sauvegardes (la complète et les incrémentales).
