J'ai toujours beaucoup de sauvegardes de mes photos. Dans la mesure du
possible, j'essaie de garder les anciennes quand j'en fais de
nouvelles. Parfois ça sert.
Voilà l'histoire...
en Juillet dernier je décide de passer toutes mes galettes sur disque
dur. *deux* disques durs identiques, pour en mettre un chez ma mère à
250km de chez moi, mais où je suis souvent en ce moment, pour le
préserver.
Pour ça il faut déjà faire un disque. Pas de problème.
Achat d'un deuxième disque (usb), synchronisation des disques. Aller
retour à Montpellier, photos... je me retrouve avec deux disques,
aucun tout à fait identique à l'autre.
Il y a une solution à ce problème, qui se nomme "unison", un rsync
symétrique, qui s'occupe d'avoir source et destination identique...
sauf que
le nouveau disque décède brutalement sans prévenir en cours de copie.
Pas de souci visible sur le moment, retour en garantie, échange fait,
copie vers le nouveau disque...
et, par hasard, je constate que quelques milliers de fichiers ont une
longueur nulle (taille zéro). Le nom existe, mais il n'y a pas de
photo dans le fichier!!
ça n'est pas si simple à gérer. Ca se voit avec "find . -empty". Le
souci, c'est que c'est le cas *sur les deux disques*. Il semble
qu'unison ai eu des soucis avec le disque dur au moment où il est
tombé en panne :-(
Le principal inconvénient d'un disque dur c'est qu'on peut y écrire,
il est donc difficile d’empêcher toute écriture accidentelle.
Heureusement, j'ai toujours mes galettes! Je suis donc en train de
reconstituer mes données.
Le titre français, très mauvais, était "Soleil vert"
Soylent green, c'est la marque de l'aliment standard à base de vieux (humains, tués et) recyclés.
je m'en doutais, mais dans "soleil vert", on ne sait pas trop où en est la nature. Dans "Silent Running"
http://fr.wikipedia.org/wiki/Silent_Running
on décide d'abandonner à l'espace les derniers arbres vivants...
jdd
Philippe Weill
Le 10/12/2012 21:06, Pierre a écrit :
J'ai trop eu de problèmes (au travail) avec des disques de serveurs travaillant en "miroir" pour avoir banni à titre personnel ce genre de "sauvegarde". Les erreurs du disque maître ont en effet une fâcheuse tendance à se répercuter sur l'esclave suivant le type de crash (fichiers à zéro ou inexploitables). J'effectue donc de disque à disque des sauvegardes différentielles, ça fonctionne très bien même avec une antique commande dos du type xcopy ou équivalente (avec les inters qui vont bien, le tout inséré dans un batch) .
miroir et sauvegarde sont deux fonctions bien différentes ;-)
voir les options backup de rsync et unison
Le 10/12/2012 21:06, Pierre a écrit :
J'ai trop eu de problèmes (au travail) avec des disques de serveurs
travaillant en "miroir" pour avoir banni à titre personnel ce genre de
"sauvegarde". Les erreurs du disque maître ont en effet une fâcheuse
tendance à se répercuter sur l'esclave suivant le type de crash (fichiers à
zéro ou inexploitables). J'effectue donc de disque à disque des sauvegardes
différentielles, ça fonctionne très bien même avec une antique commande dos
du type xcopy ou équivalente (avec les inters qui vont bien, le tout inséré
dans un batch) .
miroir et sauvegarde sont deux fonctions bien différentes ;-)
J'ai trop eu de problèmes (au travail) avec des disques de serveurs travaillant en "miroir" pour avoir banni à titre personnel ce genre de "sauvegarde". Les erreurs du disque maître ont en effet une fâcheuse tendance à se répercuter sur l'esclave suivant le type de crash (fichiers à zéro ou inexploitables). J'effectue donc de disque à disque des sauvegardes différentielles, ça fonctionne très bien même avec une antique commande dos du type xcopy ou équivalente (avec les inters qui vont bien, le tout inséré dans un batch) .
miroir et sauvegarde sont deux fonctions bien différentes ;-)
voir les options backup de rsync et unison
Jacques DASSIÉ
jdanield a couché sur son écran :
Le 10/12/2012 19:28, Jacques DASSIÉ a écrit :
Avec deux disques identiques, une solution extrêmement fiable consiste à cloner le premier sur le second.
ben c'est comme ça que j'ai eu mes problèmes, quand un des disques a commencé à lâcher, il a envoyé des fichiers vides...
Car bien sûr, tu n'avais pas effectué la vieille commande : CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec n'importe quel programme... Une prudence élémentaire.
Par contre, mes clones ne sont pas à des kilomètres mais dans le même ordinateur principal et dans d'autres ordinateurs en réseau wifi.
pas grand usage en cas d'incendie ou de vol
Tu oublies tremblement de terre, révolutions, tsunamis, guerre atomique... et je dois en omettre !
Ça fait un quart de siècle que je sauvegarde en ce sens et j'ai déjà eu un incendie... qui n'a pas touché toutes les pièces à la fois ! Mais, particulièrement obtus et obstiné, je persiste...
Bonnes sauvegardes.
-- Jacques DASSIÉ http://archaero.com/
jdanield a couché sur son écran :
Le 10/12/2012 19:28, Jacques DASSIÉ a écrit :
Avec deux disques identiques, une solution extrêmement fiable consiste
à cloner le premier sur le second.
ben c'est comme ça que j'ai eu mes problèmes, quand un des disques a commencé
à lâcher, il a envoyé des fichiers vides...
Car bien sûr, tu n'avais pas effectué la vieille commande :
CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec
n'importe quel programme... Une prudence élémentaire.
Par contre, mes clones ne sont pas à des kilomètres mais dans le même
ordinateur principal et dans d'autres ordinateurs en réseau wifi.
pas grand usage en cas d'incendie ou de vol
Tu oublies tremblement de terre, révolutions, tsunamis, guerre
atomique... et je dois en omettre !
Ça fait un quart de siècle que je sauvegarde en ce sens et j'ai déjà eu
un incendie... qui n'a pas touché toutes les pièces à la fois !
Mais, particulièrement obtus et obstiné, je persiste...
Avec deux disques identiques, une solution extrêmement fiable consiste à cloner le premier sur le second.
ben c'est comme ça que j'ai eu mes problèmes, quand un des disques a commencé à lâcher, il a envoyé des fichiers vides...
Car bien sûr, tu n'avais pas effectué la vieille commande : CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec n'importe quel programme... Une prudence élémentaire.
Par contre, mes clones ne sont pas à des kilomètres mais dans le même ordinateur principal et dans d'autres ordinateurs en réseau wifi.
pas grand usage en cas d'incendie ou de vol
Tu oublies tremblement de terre, révolutions, tsunamis, guerre atomique... et je dois en omettre !
Ça fait un quart de siècle que je sauvegarde en ce sens et j'ai déjà eu un incendie... qui n'a pas touché toutes les pièces à la fois ! Mais, particulièrement obtus et obstiné, je persiste...
Bonnes sauvegardes.
-- Jacques DASSIÉ http://archaero.com/
Olivier B.
On Mon, 10 Dec 2012 17:38:31 +0100, jdanield wrote:
Il y a une solution à ce problème, qui se nomme "unison", un rsync symétrique, qui s'occupe d'avoir source et destination identique... sauf que
le nouveau disque décède brutalement sans prévenir en cours de copie.
Pas de souci visible sur le moment, retour en garantie, échange fait, copie vers le nouveau disque...
et, par hasard, je constate que quelques milliers de fichiers ont une longueur nulle (taille zéro). Le nom existe, mais il n'y a pas de photo dans le fichier!!
Si j'ai bien compris tu as pourri, ta source via ta destination de sauvegarde, tout cela parceque tu fais une synchro à double sens, en conclusion la méthode est très mauvaise :-)
Perso je fais des mise à jour via robocopy, seul les fichiers plus réscents de la sources sont copiés vers d'autres espaces de stockage, en cas de probleme d'intégrité on esquinte pas tout, en cas de suppression de fichiers sur la source, ils restent sur la destination.
Certes cela a un effet cumulatif, mais:
- je le contraind à sa plus petite valeur en traitant differement un dossier "a_trier" duquel sont supprimé tout ce qui n'a pas passé la "controle qualité" - mieux vaut regretter de trop sauvegarder que d'avoir à regretter de ne l'avoir pas assez fait un jour !
Ensuite je me méfie comme la peste des focntions RAID5 grand public, dans les cas "pas de chance" ou deux disques déconnent gentiment, par exemple en passant offline de temps en temps mais sans altérer les data, j'ai déjà vu des cas de resync malheureuses avec altération irremeddiables du contenu, je prefere donc, à la maison, stocker sur du jbod.
-- pas de turlututu. apres l'@robase
On Mon, 10 Dec 2012 17:38:31 +0100, jdanield <jdd@dodin.org> wrote:
Il y a une solution à ce problème, qui se nomme "unison", un rsync
symétrique, qui s'occupe d'avoir source et destination identique...
sauf que
le nouveau disque décède brutalement sans prévenir en cours de copie.
Pas de souci visible sur le moment, retour en garantie, échange fait,
copie vers le nouveau disque...
et, par hasard, je constate que quelques milliers de fichiers ont une
longueur nulle (taille zéro). Le nom existe, mais il n'y a pas de
photo dans le fichier!!
Si j'ai bien compris tu as pourri, ta source via ta destination de
sauvegarde, tout cela parceque tu fais une synchro à double sens, en
conclusion la méthode est très mauvaise :-)
Perso je fais des mise à jour via robocopy, seul les fichiers plus
réscents de la sources sont copiés vers d'autres espaces de stockage,
en cas de probleme d'intégrité on esquinte pas tout, en cas de
suppression de fichiers sur la source, ils restent sur la destination.
Certes cela a un effet cumulatif, mais:
- je le contraind à sa plus petite valeur en traitant differement un
dossier "a_trier" duquel sont supprimé tout ce qui n'a pas passé la
"controle qualité"
- mieux vaut regretter de trop sauvegarder que d'avoir à regretter de
ne l'avoir pas assez fait un jour !
Ensuite je me méfie comme la peste des focntions RAID5 grand public,
dans les cas "pas de chance" ou deux disques déconnent gentiment, par
exemple en passant offline de temps en temps mais sans altérer les
data, j'ai déjà vu des cas de resync malheureuses avec altération
irremeddiables du contenu, je prefere donc, à la maison, stocker sur
du jbod.
On Mon, 10 Dec 2012 17:38:31 +0100, jdanield wrote:
Il y a une solution à ce problème, qui se nomme "unison", un rsync symétrique, qui s'occupe d'avoir source et destination identique... sauf que
le nouveau disque décède brutalement sans prévenir en cours de copie.
Pas de souci visible sur le moment, retour en garantie, échange fait, copie vers le nouveau disque...
et, par hasard, je constate que quelques milliers de fichiers ont une longueur nulle (taille zéro). Le nom existe, mais il n'y a pas de photo dans le fichier!!
Si j'ai bien compris tu as pourri, ta source via ta destination de sauvegarde, tout cela parceque tu fais une synchro à double sens, en conclusion la méthode est très mauvaise :-)
Perso je fais des mise à jour via robocopy, seul les fichiers plus réscents de la sources sont copiés vers d'autres espaces de stockage, en cas de probleme d'intégrité on esquinte pas tout, en cas de suppression de fichiers sur la source, ils restent sur la destination.
Certes cela a un effet cumulatif, mais:
- je le contraind à sa plus petite valeur en traitant differement un dossier "a_trier" duquel sont supprimé tout ce qui n'a pas passé la "controle qualité" - mieux vaut regretter de trop sauvegarder que d'avoir à regretter de ne l'avoir pas assez fait un jour !
Ensuite je me méfie comme la peste des focntions RAID5 grand public, dans les cas "pas de chance" ou deux disques déconnent gentiment, par exemple en passant offline de temps en temps mais sans altérer les data, j'ai déjà vu des cas de resync malheureuses avec altération irremeddiables du contenu, je prefere donc, à la maison, stocker sur du jbod.
-- pas de turlututu. apres l'@robase
Olivier B.
On Mon, 10 Dec 2012 21:06:51 +0100, "Pierre" <unposteur[nospam]@free.fr> wrote:
J'ai trop eu de problèmes (au travail) avec des disques de serveurs travaillant en "miroir" pour avoir banni à titre personnel ce genre de "sauvegarde".
pas la meme experience
Les erreurs du disque maître ont en effet une fâcheuse tendance à se répercuter sur l'esclave suivant le type de crash (fichiers à zéro ou inexploitables).
ha...oui mais non, un bon controleur raid ne copie les données du maitre vers son mirroir que lors de la resynch, ensuite il duplique copie les données écrites par le systeme, donc dans le cas que tu évoque: - soit ton controleur ne respecte pas ce que je viens de dire et il est totalement pourri - soit tu étais en resynch - soit c'est ton OS qui a généré les fichiers incoherents, et le fait que le mirroir les ait dupliqué est une réaction normale et tout à fait normale.
Je penche pour la derniere hyothese
J'effectue donc de disque à disque des sauvegardes différentielles, ça fonctionne très bien même avec une antique commande dos du type xcopy ou équivalente (avec les inters qui vont bien, le tout inséré dans un batch) .
je prefere largement robocopy
-- pas de turlututu. apres l'@robase
On Mon, 10 Dec 2012 21:06:51 +0100, "Pierre"
<unposteur[nospam]@free.fr> wrote:
J'ai trop eu de problèmes (au travail) avec des disques de serveurs
travaillant en "miroir" pour avoir banni à titre personnel ce genre de
"sauvegarde".
pas la meme experience
Les erreurs du disque maître ont en effet une fâcheuse
tendance à se répercuter sur l'esclave suivant le type de crash (fichiers à
zéro ou inexploitables).
ha...oui mais non, un bon controleur raid ne copie les données du
maitre vers son mirroir que lors de la resynch, ensuite il duplique
copie les données écrites par le systeme, donc dans le cas que tu
évoque:
- soit ton controleur ne respecte pas ce que je viens de dire et il
est totalement pourri
- soit tu étais en resynch
- soit c'est ton OS qui a généré les fichiers incoherents, et le fait
que le mirroir les ait dupliqué est une réaction normale et tout à
fait normale.
Je penche pour la derniere hyothese
J'effectue donc de disque à disque des sauvegardes
différentielles, ça fonctionne très bien même avec une antique commande dos
du type xcopy ou équivalente (avec les inters qui vont bien, le tout inséré
dans un batch) .
On Mon, 10 Dec 2012 21:06:51 +0100, "Pierre" <unposteur[nospam]@free.fr> wrote:
J'ai trop eu de problèmes (au travail) avec des disques de serveurs travaillant en "miroir" pour avoir banni à titre personnel ce genre de "sauvegarde".
pas la meme experience
Les erreurs du disque maître ont en effet une fâcheuse tendance à se répercuter sur l'esclave suivant le type de crash (fichiers à zéro ou inexploitables).
ha...oui mais non, un bon controleur raid ne copie les données du maitre vers son mirroir que lors de la resynch, ensuite il duplique copie les données écrites par le systeme, donc dans le cas que tu évoque: - soit ton controleur ne respecte pas ce que je viens de dire et il est totalement pourri - soit tu étais en resynch - soit c'est ton OS qui a généré les fichiers incoherents, et le fait que le mirroir les ait dupliqué est une réaction normale et tout à fait normale.
Je penche pour la derniere hyothese
J'effectue donc de disque à disque des sauvegardes différentielles, ça fonctionne très bien même avec une antique commande dos du type xcopy ou équivalente (avec les inters qui vont bien, le tout inséré dans un batch) .
je prefere largement robocopy
-- pas de turlututu. apres l'@robase
Olivier B.
On Mon, 10 Dec 2012 19:28:44 +0100, Jacques DASSIÉ wrote:
Par contre, mes clones ne sont pas à des kilomètres mais dans le même ordinateur principal et dans d'autres ordinateurs en réseau wifi.
donc en cas de vol ou incendie, tu perds tout ?
-- pas de turlututu. apres l'@robase
On Mon, 10 Dec 2012 19:28:44 +0100, Jacques DASSIÉ
<jacques.dassie@free.fr> wrote:
Par contre, mes clones ne sont pas à des kilomètres mais dans le même
ordinateur principal et dans d'autres ordinateurs en réseau wifi.
On Mon, 10 Dec 2012 19:28:44 +0100, Jacques DASSIÉ wrote:
Par contre, mes clones ne sont pas à des kilomètres mais dans le même ordinateur principal et dans d'autres ordinateurs en réseau wifi.
donc en cas de vol ou incendie, tu perds tout ?
-- pas de turlututu. apres l'@robase
sebastienmarty
Jacques DASSIÉ wrote:
Car bien sûr, tu n'avais pas effectué la vieille commande : CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec n'importe quel programme... Une prudence élémentaire.
Si ton DD décide de mourir en plein milieu d'une copie, ce n'est pas un CHKDSK qui te sauvera.
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
Jacques DASSIÉ <jacques.dassie@free.fr> wrote:
Car bien sûr, tu n'avais pas effectué la vieille commande :
CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec
n'importe quel programme... Une prudence élémentaire.
Si ton DD décide de mourir en plein milieu d'une copie, ce n'est pas un
CHKDSK qui te sauvera.
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
Car bien sûr, tu n'avais pas effectué la vieille commande : CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec n'importe quel programme... Une prudence élémentaire.
Si ton DD décide de mourir en plein milieu d'une copie, ce n'est pas un CHKDSK qui te sauvera.
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
MELMOTH
Ce cher mammifère du nom de Jacques DASSIÉ nous susurrait, le mardi 11/12/2012, dans nos oreilles grandes ouvertes mais un peu sales tout de même, et dans le message <50c6d1d3$0$1939$, les doux mélismes suivants :
-- Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui accroît sa science accroît sa douleur. [Ecclésiaste, 1-18] MELMOTH - souffrant
Ce cher mammifère du nom de Jacques DASSIÉ nous susurrait, le mardi
11/12/2012, dans nos oreilles grandes ouvertes mais un peu sales tout
de même, et dans le message <50c6d1d3$0$1939$426a74cc@news.free.fr>,
les doux mélismes suivants :
--
Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui
accroît sa science accroît sa douleur.
[Ecclésiaste, 1-18]
MELMOTH - souffrant
Ce cher mammifère du nom de Jacques DASSIÉ nous susurrait, le mardi 11/12/2012, dans nos oreilles grandes ouvertes mais un peu sales tout de même, et dans le message <50c6d1d3$0$1939$, les doux mélismes suivants :
-- Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui accroît sa science accroît sa douleur. [Ecclésiaste, 1-18] MELMOTH - souffrant
jdanield
Le 11/12/2012 08:34, Jacques DASSIÉ a écrit :
Car bien sûr, tu n'avais pas effectué la vieille commande : CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec n'importe quel programme... Une prudence élémentaire.
souvent le vrai moyen de tuer un disque... en plus je suis sous Linux, pas de chkdsk (d'ailleurs ca ne s'utilise plus depuis le DOS...°
surtout le disque a commencé à lâcher *en cours* de copie. 1To, c'est long à copier :-(
Mais, particulièrement obtus et obstiné, je persiste...
l'assurance n'est chère qu'avant l'accident... j'ai connu des gens qui avaient tout perdu (vol, suivi de saccage des lieux et début d'incendie)
jdd
Le 11/12/2012 08:34, Jacques DASSIÉ a écrit :
Car bien sûr, tu n'avais pas effectué la vieille commande :
CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec
n'importe quel programme... Une prudence élémentaire.
souvent le vrai moyen de tuer un disque... en plus je suis sous Linux,
pas de chkdsk (d'ailleurs ca ne s'utilise plus depuis le DOS...°
surtout le disque a commencé à lâcher *en cours* de copie. 1To, c'est
long à copier :-(
Mais, particulièrement obtus et obstiné, je persiste...
l'assurance n'est chère qu'avant l'accident... j'ai connu des gens qui
avaient tout perdu (vol, suivi de saccage des lieux et début d'incendie)
Car bien sûr, tu n'avais pas effectué la vieille commande : CHKDSK (lettre:) /F, à faire avant n'importe quel clonage, avec n'importe quel programme... Une prudence élémentaire.
souvent le vrai moyen de tuer un disque... en plus je suis sous Linux, pas de chkdsk (d'ailleurs ca ne s'utilise plus depuis le DOS...°
surtout le disque a commencé à lâcher *en cours* de copie. 1To, c'est long à copier :-(
Mais, particulièrement obtus et obstiné, je persiste...
l'assurance n'est chère qu'avant l'accident... j'ai connu des gens qui avaient tout perdu (vol, suivi de saccage des lieux et début d'incendie)
