systeme de backup local

Le
Jean-Michel OLTRA
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 ?

Merci de donner vos avis.


--
jm
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Daniel Huhardeaux
Le #26397429
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
JF Straeten
Le #26397456
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.
Jean-Michel OLTRA
Le #26397867
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
Pierre Chevalier
Le #26397905
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/
Sébastien Dinot
Le #26397959
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 !
Jean-Michel OLTRA
Le #26398391
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
Publicité
Poster une réponse
Anonyme