Récupération données / disque qui devient très lent après quelques secondes

Support Debian
Tags: #<Tag:0x00007f50b0d4a280>
#1

salut, j’essaie de récupérer des données sur un disque de 2 To (partition exfat).

le disque devient systématiquement très lent (~40 kb/s) au bout de quelques secondes de lecture.

avec rsync j’ai remarqué que la lecture de certains fichiers entraînait ce comportement (je peux les exclure un par un mais il va vite y en avoir des milliers).
en ce moment j’utilise ddrescue, mais il devient très lent au bout de quelques secondes. l’option --min-read-rate ne semble rien donner :
j’ai essayé --min-read-rate=10485760 et --min-read-rate=10M sans jamais avoir de slow reads ni de secteur skippé ou quoi que ce soit… (pas sûr de super bien comprendre l’outil ceci dit)

en gros pour le moment je lance ddrescue, il tourne à plus de 100Mo puis ralentit au bout de quelques secondes. je débranche, rebranche et recommence.
au bout d’une vingtaine de minutes de cette activité passionnante j’ai récupéré presque 20 Go, soit un peu plus de 1% du disque.
ça fonctionne mieux qu’avec rsync mais je ne peux pas choisir le contenu intéressant en priorité.

quelqu’un aurait une idée pour éviter une usure prématuré de mon port usb et de mes espoirs de mener une vie palpitante ? il ne suffit malheureusement pas de relancer ddrescue… je suppose que je ne peux pas écrire un script qui déconnecte - reconnecte le disque au delà du démontage - montage (vu qu’il n’est même pas monté pour un usage avec ddrescue) ?

// edit :
j’ai oublié de préciser que c’est un disque dur 2,5" à plateau, externe, USB 3. je l’ai ouvert mais il ne dispose pas de port SATA. en tout cas pas de possibilité évidente de déconnecter le disque et son contrôleur de l’interface USB (tout est sur le même circuit - c’est la première fois que je vois ça).

#2

Bsr, nous avons toujours utilisé rsync pour les backups - que ca soit avec ligne de commande ou dans les scripts et nous n’avons jamais constaté de gros problèmes (eg: BDD de plus de 50-80go). Par contre le tableau que vous brossez de votre disque me laisse à penser que je sauvegarderais le contenu et j’achèterais un ssd.

edit:

Jamais encore vu ca

#3

euh, oui merci pour l’info.

j’ai pas précisé le contexte mais j’essaie de récup les données d’un copain qui n’a pas fait de sauvegarde.
ce qui ne change rien à ma question… bref…

j’ai trouvé une solution.
il est possible de déconnecter et reconnecter un port USB depuis la ligne de commande : Learning how to disable specific USB devices by their ports in Linux | MigueLeonardOrtiz
je viens de tester et ça marche !
dans mon cas :

echo '5-2' > /sys/bus/usb/drivers/usb/bind
echo '5-2' > /sys/bus/usb/drivers/usb/unbind

ça va être sale mais j’ai plus qu’à écrire le script !
(je laisse ouvert quelques heures avant de marquer résolu au cas où quelqu’un aurait une solution plus propre)

#4

non malheureusement ça ne marche pas le premier test a dû être trompeur : je pense qu’il faut vraiment éteindre et rallumer le disque pour qu’il retrouve un débit correct…

donc à moins de trouver un script pour couper l’alim du port USB, je vois pas trop de solution logicielle.

je vais peut-être tenter un bidouillage de l’alim USB en bricolant le câble, pour gérer l’alim avec un arduino…

#5

on n’a probablement jamais vu non plus quelqu’un passer 10 heures de sa vie à débrancher / rebrancher un disque USB toutes les 30 secondes…

je dois probablement préciser que c’est évidemment une manière de parler, je ne compte pas faire ça !

#6

Avec ddrescue tu peut- tenter d’exclure dans un premier temps tous ce qui est potentiellement endommagé avec l’option -n et ne pas oublier d’optimiser la taille de bloc.

Pour Rsync par contre faut se méfier il index avant la copie et dans le cas ou tu tombe sur des dossier remplit de tous petit fichiers ça va plomber la vitesse de copie.

#7

C’était assez souvent le cas avec des anciens modèle de qualité moyenne ou moins.
Quand à récupérer les données, si dessus il y a eu des ecritures dans de mauvaises conditions il est possibles que les données ne soient pas récupérables.
Les symptomes sont ceux que l’ont trouve sur des disques à secteurs defectueux mais pas suffisament pour etre marqué comme defectueux.
Mais l’(interface elle-même peut être defectueuse.

#8

non les données sont nickel, de ce que je vois quand je monte le fichier img. et j’ai lu 2 3 trucs y a aucun soucis.

j’ai écrit ce script pour faire tourner ddrescue à l’infini, en le relançant, que le disque soit branché ou pas (ddrescue crashe évidemment quand je débranche l’usb) :

#!/bin/bash

until ddrescue --min-read-rate=10M /dev/sdb2 /media/kro/fatcap/LOLO/lolo.img /media/kro/fatcap/LOLO/lolo.log; do
    echo "ddrescue died with exit code $?. Respawning..." >&2
    sleep 1
done

echo "it's never done !"

après avoir tenté un truc beaucoup plus compliqué…

donc j’ai plus qu’à débrancher / rebrancher, mais bon :confused: avec tous mes essais j’en suis bientôt à 5%, j’ai dû le faire plus de 100 fois :roll_eyes:

j’ai sacrifié un câble, essayé de l’alimenter avec un arduino mais ça ne fonctionne pas. l’arduino envoie bien 5v, qu’il coupe 2 sec toute les 30 sec, mais je pense que l’alim est pas assez puissante ou je sais pas quoi, le disque ne s’allume pas. et je n’ai pas de relais qui convienne sous la main (j’en ai un pour du 220 mais c’est du solid state pas mécanique, je suppose que ça laisse pas passer 5V continu)
et puis le truc est capricieux, le disque ne démarre pas quand je fais passer l’alim 5v de l’ordi dans des pinces croco, alors que direct par le câble (de 30 cm) c’est ok !

j’ai demandé au copain si il pouvait pas racheter exactement le même modèle. je soupçonne une panne du contrôleur plutôt que du disque.

#9

bon je viens d’acheter celui-ci dans le magasin du coin :

et ça marche !
il coupe mécaniquement la connexion du +5v (le fil rouge) dans le câble USB 3, ce qui a pour effet d’éteindre et rallumer le disque à intervalles réguliers.

le script tourne à l’infini derrière et ça marche environ 50% du temps (le temps de remonter le disque).
j’en ai pour 4h selon ddrescue donc environ 8h j’imagine. je marquerai résolu quand j’aurai fini… :crossed_fingers: