Unix Sauvegarde incrémentale de données - Page 1

yop,

Sous Unix, existe-t-il un moyen simple de sauvegarder de façon incrémentale le contenu d'un répertoire avec les contraintes suivantes :

- Les fichiers peuvent être supprimés du dossier source mais doivent rester dans le dossier de destination
- Si un fichier est créé et entre en conflit avec l'un de ceux du dossier de destination (en gros, un fichier a été créé, sauvegardé, supprimé, puis un autre fichier de même nom a été créé et doit donc être sauvegardé à son tour), alors la nouvelle sauvegarde ne doit pas écraser l'ancienne (quitte à le renommer, par exemple si la 1ere sauvegarde est suffixée par ".0" et que la seconde qui était en conflit se retrouve avec un ".1", ça me va parfaitement)

Pour l'instant j'ai un script shell qui s'occupe de ça, mais quand les dossiers ont trop de fichiers ça a tendance à être super lent (plus d'une minute pour s'exécuter), et je me demandais si l'un des outils de base ne permettrait pas par hasard de faire ce genre d'opération ?

Merci

Nop, désolé, je n'en connais pas (et, à vrai dire, je trouve qu'une minute pour une sauvegarde incrémentale c'est relativement peu lorsque tu n'as pas un service dédié comme avec TiNA par exemple).

Rdiff ne permet pas ce genre de choses ?

./2 : le volume reste relativement faible, d'une part j'aurai probablement besoin de bien davantage plus tard, et d'autre part je sauvegarde plusieurs fois par jour donc une minute me semble beaucoup :/
./3 : la réponse à ce genre de question est précisément le but du topic ^^ j'ai lu le man de "rsync" sans trouver qui corresponde à ce que je cherche, peut-être que rdiff serait différent, j'en sais rien, mais je préfère demander ici et espérer que quelqu'un soit déjà tombé sur ce problème plutôt que de me taper la doc de tous les outils unix :]

[edit] j'avais oublié de préciser, mais l'idéal serait une solution qui fonctionne sur un unix "de base" sans rien installer ; rdiff ne conviendrait pas vraiment, par exemple.

ça ne correspond pas exactement à ce que tu demandes, mais ça permet de faire de l'historisation, sans être *trop* lent : quid d'un serveur SVN ?
c'est surtout adapté à du texte, et pas trop à du binaire... mais ça marche quand même...

(je sens venir le "ça me prend de la place en double en local, et en 56 versions sur le serveur", mais bon ; c'est ce que j'utilise pour mes document "importants")

C'est pas du tout adapté à mes besoins en fait : je n'ai pas besoin de versionning (pire : je n'en veux surtout pas, ça prendrait une place monstrueuse pour rien), et mes fichiers sont des binaires donc SVN conserverait des copies complètes pour chaque version, d'où une autre perte de place tout aussi monstrueuse. En plus de ça, ça ne colle pas avec le [edit] du ./4 puisque SVN n'est pas un outil disponible par défaut sur une distrib fraichement installée

TSM

hem, sinon je pense pas que des rsync et compagnie soient d'une grande aide (comme d'habitude tu as contraintes alabob)...

Zephyr (./6) :
je n'ai pas besoin de versionning (pire : je n'en veux surtout pas, ça prendrait une place monstrueuse pour rien)

Et pourtant, ça:

Zephyr (./1) :
- Si un fichier est créé et entre en conflit avec l'un de ceux du dossier de destination (en gros, un fichier a été créé, sauvegardé, supprimé, puis un autre fichier de même nom a été créé et doit donc être sauvegardé à son tour), alors la nouvelle sauvegarde ne doit pas écraser l'ancienne (quitte à le renommer, par exemple si la 1ere sauvegarde est suffixée par ".0" et que la seconde qui était en conflit se retrouve avec un ".1", ça me va parfaitement)

c'est du versioning...

et mes fichiers sont des binaires donc SVN conserverait des copies complètes pour chaque version, d'où une autre perte de place tout aussi monstrueuse.

Et la différence avec ce que tu proposes dans le message de départ, c'est quoi?

Pas con Un truc dans les spec de Zephyr 'échappe en effet...

Kevin Kofler (./8) :
c'est du versioning...

Il va te dire que c'Est pas pareil parce que le contenu des 2 fichiers est totalement different #bob#

effectivement ^^ (garder plusieurs versions d'un même fichier ne m'intéresse pas, c'est quand il s'agit de deux fichiers différents ayant le même nom que je veux garder les deux)

en fait il y a pas mal de contraintes qui font que SVN n'est pas une bonne solution dans mon cas, mais j'ai oublié d'en donner la plupart :

- je recherche une solution qui fonctionne sans installer d'outil supplémentaire sur le serveur (ça je l'ai déjà dit, 2 fois en plus)
- SVN ne me permettra ni d'accéder directement au fichiers de la copie, ni d'accéder simultanément à deux fichiers différents ayant eu le même nom, il faudrait "checkouter" à chaque fois (et donc dupliquer les données, sachant que j'en ai pour un paquet de gigas c'est pas génial)

Zephyr (./11) :
effectivement ^^ (garder plusieurs versions d'un même fichier ne m'intéresse pas, c'est quand il s'agit de deux fichiers différents ayant le même nom que je veux garder les deux)

Et tu fais la différence comment?

Tant que le fichier est le même (même date de création par exemple), même si son contenu change, je ne veux pas avoir l'évolution sauvegardée. En revanche si il est supprimé et qu'un nouveau fichier portant le même nom prend sa place, je veux le sauvegarder lui aussi.

faire une entete en comment avec un ID unique par fichier...

Bon, faute de mieux j'ai remplacé mon script shell par une version en perl, ça reste très basique mais ça va nettement plus vite (~1/10e de seconde pour traiter 10k+ fichiers, sans compter les cp) donc pour l'instant je reste là-dessus : http://www.mirari.fr/77FR

(mes skills en perl étant proches de zéro, si vous avez des optimisations qui peuvent faire gagner quelque chose de significatif, je prends ^^)

Tu peut pas t'en sortir avec dump/restore ?

(Desole de re-up un vieux topic j'avais pas vu la date :P)

dump/restore, c'est quand même antique^Wpourri, on a fait mieux depuis

genre ?
Pour moi ca rempli tres bien son role.

facile : dump c'est fait pour faire un backup de filesystem complet. Il est fait pour l'ext2... ça plante le décor je trouve

Pas faux pour le filesystem, j'avais zapper ca
<troll>
Apres pour le ext2 c'est juste que linux arrive pas a syncer le userland avec le kernelland
</troll>