Différences

Ci-dessous, les différences entre deux révisions de la page.

--- ddrescue [Le 03/10/2018, 18:43]
L'Africain ancienne révision (Le 23/09/2018, 20:18) restaurée
+++ ddrescue [Le 26/03/2019, 15:28]
37.164.81.34 eme bloc a zzéro perme[ddrescue par des exemples]
@@ Ligne 78: / Ligne 78: @@
 =====Utilisation=====
+Si le disque usagé est un disque assez classique, il peut être équipé de pas mal de partitions **dont une seule contient les données de l'utilisateur.**
+Dans un tel contexte, il ne faut dupliquer que cette partition. Dans l'ensemble cette partition est "moins abîmée" que les partitions contenant les O.S.  Il est alors inutile de vouloir dupliquer le disque entier.
 ====Fonctionnement de base====
@@ Ligne 136: / Ligne 138: @@
 Use sparse writes for **output file**. (The blocks of zeros are not actually allocated on disc). May save a lot of disc space in some cases. Not all systems support this.
+=== récupération d'un RAID1 ===
+Si votre [[tutoriel:raid1_logiciel_sur_installation_existante|RAID-1]] est devenu inutilisable car les deux disques sont en mauvais état, ddrescue est capable de récupérer les secteurs en bon état du premier disque et d'aller chercher les secteurs en mauvais état sur le second disque.
 ==== ddrescue par des exemples ====
 Ce sous-chapitre est écrit par un 'débutant' de ddrescue le 31/12/2015. Merci à ceux qui connaissent bien l'outil de faire les corrections qu'ils jugeront nécessaire.
-D'abord, il faut déterminer si la  technique  "sauvetage des partitions" est  possible.   Si oui, c'est la solution à privilégier car on peut fabriquer les partitions de duplication de taille identique sur d'autres supports avec l'application  [[:gnome-disk-utility|Disques]] en fournissant la taille exacte de chaque partition en précisant que l'unité est le **Kio**. Cela sous-entend que la commande " **sudo fdisk -l** "    a pu fonctionné. il suffit de diviser par deux, le nombre de secteurs indiqués.
+D'abord, il faut déterminer si la  technique  "sauvetage des partitions" est  possible.   Si oui, c'est la solution à privilégier car on peut fabriquer les partitions de duplication de taille identique sur d'autres supports avec l'application  [[:gnome-disk-utility|Disques]] en fournissant la taille exacte de chaque partition en précisant que l'unité est le **Kio**. Cela sous-entend que la commande " **sudo fdisk -l** "    a pu fonctionner. Il suffit de diviser par deux, le nombre de secteurs indiqués.
 === Sauvegarde du disque interne "sda" sur un disque externe "sde" avec une liveusb__PERSISTANTE__ ===
 La taille du secteur est de 512 bytes.
@@ Ligne 181: / Ligne 187: @@
 == Copier dans un fichier. ==
 sudo ddrescue  -b 512  --sparse   --log-rates=/mnt/rescueRate.log      /dev/disk/by-id/ata-MAXTOR_STM3160215A_9RA8V0BK-part1       /mnt/disk.img          /mnt/rescue.map
+===== Remarques concernant le forçage en écriture des secteurs qui n'ont pas pu être copiés. =====
+Ces secteurs du  support de sortie contiennent donc des informations sans rapport avec le support d'entrée.
+Lire de telles données peut donc se révéler problématique si elles sont accidentellement de même [[https://www.cgsecurity.org/wiki/Formats_de_fichier_r%C3%A9cup%C3%A9r%C3%A9s_par_PhotoRec|type de format]] puisque les logiciels de lecture vont alors pouvoir lire normalement les fichiers.
+Pour un film, ce n'est pas très grave. Personne  ne verra qu'un paquet de 512 bytes est remplacé par une autre animation.
+Pour une image, cela pourrait être visible avec une petite zone sans rapport avec le dessin.
+Pour une musique, les experts pourraient entendre une fausse note.
+Pour un document du style word,   on pourra s'apercevoir que 512 octets ne sont pas dans la même langue  ou qu'ils sont sans rapport avec l'histoire racontée.
+Pour un document du style  excel, il va être plus difficile de s'apercevoir que les chiffres ne sont pas valables. Si par malheur cela concerne le tableau final.......
+Pour toutes ses raisons, il est tentant de mettre des données fictives (des zéros ou autre chose) dans ces secteurs. Cependant c'est à double tranchant pour les logiciels car ceux-ci pourraient ne plus lire le fichier abîmé. __Il faudrait alors utiliser la version moins un du fichier  qui est très certainement inexistante.
+__
+A titre d'exemple avec le visionneur d'images.    Mettre  16 blocs  à zéro à partir du bloc 100  provoque l'erreur  suivante
+//"Erreur fatale de lecture du fichier d'image XXXX.png     IDAT.CRC error//". Mais en mettre seulement 8 permet l'ouverture du fichier avec seulement l'affichage du début.
+Il est fort probable que chaque logiciel de lecture dispose de sa propre logique.
 ==== Connaître les fichiers stockés dans une partition EXT4 impactés par les blocs défectueux. ====