MacBook Pro DDI saturé, récupérer données

[DaftCloud]

Salut !

Je poste ce message après avoir lu multitude de pages concernant le problème mais sans avoir vraiment de réponse à mon problème.

J'ai comme un abruti laisser mon DDI de 500 Go se remplir jusqu'à arriver à saturation. Mon MacBook Pro a ainsi planté (il date de 2010) et je n'ai pas pu rebooter sur mon DDI. J'ai ainsi installé l'os sur un DDE de 500Go afin de voir si je pouvais récupérer les données de mon disque dur interne mais celui ci ne monte pas (et forcément, "comme un abruti", je n'avais pas sauvegardé mes données ailleurs ce qui est 100% ma faute etc haha). J'ai tenté une réparation du DDI avec l'utilitaire de disques du mac mais impossible de le réparer. J'ai donc acheté DiskWarrior et Datarescue pour espérer récupérer mes données mais là DiskWarrior stagne à l'étape 5 où s'accumulent les disk malfunctions (speed reduced by disk malfunctions à 6000 actuellement)

D'où mes interrogations :
- Dois je laisser DIskWarrior tourner malgréces disk malfunctions ?
- Ai je encore une chance de récupérer mes données ou cela semble t'il compromis ?
- Est ce que je peux tenter de cloner mon DD avec data rescue ou diskwarrior sur un autre DDE de 1To pour essayer de booster le clone afin de récupérer le conten du DDI ? (Sachant qu'à ce propose je n'y connais rien du tout)

Merci d'avance pour vos éclaircissements !!

DaftCloud

 

[bompi]

Laisse tourner encore pendant un moment (tant que le disque interne tient encore).
Au vu des erreurs, je pense que c'est râpé pour cloner le disque interne.

 

[DaftCloud]

D'accord merci Bompi ! Selon toi je devrais attendre combien de temps avant d'estimer que DW n'arrangera pas mon souci ? Merci !

 

[bompi]

Difficile à dire : disons que tant que ça progresse, même lentement, il vaut mieux poursuivre.

 

[DaftCloud]

Okay merci pour tes réponses c'est sympa !
Et donc oui à ton avis créer une image du disque dur sur un autre avec plus d'espace ça changera rien ?

 

[Membre supprimé 1060554]

------ [erreur]

 

[Membre supprimé 1060554]

créer une image du disque dur sur un autre avec plus d'espace ça changera rien ?

Je prends un petit relai à bompi. En réponse directe à ta question : je pense que non.

C'est la partition concernée (qui consiste une tranche d'espace logique du disque) qu'il s'agirait de cloner.

Cette partition est constituée d'une série de blocs logiques (de 512 octets) de tel n° à tel °. La distribution de ces blocs est grosso modo la suivante : sur la série des premiers blocs (en-tête de la partition) > résident des fichiers spéciaux qui sont ceux du système de fichiers.

Ces fichiers recèlent des informations logiques sur tout le reste des blocs de la partitions > qui le décrivent comme un volume de fichiers (organisés en dossiers) recherchables > lisibles > éditables > supprimables.

Il y a ainsi les fichiers d'information de démarrage du système fe fichiers > d'informations sur le volume montable sur la partition > le fichier bitmap d'allocation des blocs occupés ou libres > le fichier des attributs étendus (permettant de gérer les mauvais blocs par fichier) > le fichier du catalogue B-tree comportant l'ensemble des adresses d'allocation aux fichiers de blocs logiques (contigus ou chaînés).

C'est le noyau opérateur (ou kernel) du Système démarré > qui charge les informations du système de fichiers d'en-tête d'une partition > procède à leur probation > et en cas de validation opère le montage du volume sur la partition en_kernel.

Si le système de fichiers qui décrit l'espace de la partition comme un volume logique comporte des erreurs cruciales > le kernel désapprouve ce dispositif logique > et n'opère pas le montage du volume. C'est ton cas.

Simple conjecture de ma part : la saturation intégrale des blocs logiques de la partition en allocations à des fichiers > a pu (et dû) affecter le fichier bitmap du système de fichiers : celui qui gère la répartition des blocs marqués occupés et des blocs marqués libres. Il ne doit plus y avoir que des blocs marqués occupés dans ce fichier bitmap.

En conséquence : le kernel doit > à la probation du système de fichiers > évaluer le volume décrit comme bloqué en allocations > et rejeter le montage du volume.

Dans ces conditions de volume impossible à monter par le kernel > « imager » cette tranche du disque dans l'espace d'un volume externe de vaste contenance > ne pourrait que répéter l'alignement actuel des blocs de la partition > soit dans une image-disque dmg > soit directement aux blocs de réception de la partition de destination.

En clonage intégral par blocs > les blocs initiaux portant les fichiers descripteurs du système de fichiers source > seraient clonés sur les blocs initiaux de la partition destination > ce qui imagerait exactement sur la partition de destination le fichier bitmap saturé > et donc impossibiliserait en écho un montage en volume des blocs de cette partition.

Il serait toujours possible (en utilisant un utilitaire de clonage en ligne de commande comme dd = data_doubler) > de demander l'échappement (skipping) des blocs de données initiaux de la partition source > mais ce skipping ne porte jamais sur les blocs d'en-tête du système de fichiers > de sorte qu'il y aurait malgré tout clonage du système de fichiers défecteux sur les blocs d'en-tête de la partition destinataire. Impossibilisant le montage d'un volume par le kernel sur la partition de destination > en écho de l'impossibilité de la source.

Pourquoi donc ne peut-on pas échapper au clonage les blocs préliminaires du système de fichiers bloqué ? - c'est que cette opération clonerait sur la destination > juste en-dessous des blocs du système de fichiers d'accueil > des alignements de blocs de données sans correspondance avec la description d'un volume par le système de fichiers d'accueil. Ce qui impossibiliserait encore plus radicalement le montage d'un volume de données.​

Je pense que tu devrais essayer le logiciel de récupération de données «Data Rescue» > pour voir s'il est capable de récupérer des fichiers après scan des blocs de ta partition.

 

[bompi]

Ton problème semble double : d'une part le manque de place, d'autre part la panne technique qui pointe le bout du nez. Le seul problème de saturation du disque devrait se régler simplement en montant le disque en question depuis un système viable [quand la situation n'est pas trop désespérée, un simple redémarrage, suivi d'un second démarrage avec vidage des caches permet de retomber sur ses octets].
Mais là, le système de fichier est apparemment corrompu et il y a des secteurs défectueux : ça commence à faire beaucoup.

En admettant que tu n'aies pas de problèmes de copie, donc que les mauvais secteurs puissent être évités, tu pourrais tenter une copie de bas niveau sur un disque plus grand puis tenter l'augmentation de la partition sur ce disque et, enfin, de faire de l'espace.

• copie de bas niveau : c'est une copie "physique" des blocs de données ; on ne s'intéresse pas au système de fichiers mais on copie le contenu des secteurs de la partition dans une autre partition, qui aura in fine la même taille ;
• pour augmenter la taille de la partition, je crains que l'utilitaire de disque ne soit réticent car il va chercher à corriger la corruption du système de fichiers de prime abord et ne pas y parvenir parce que le disque est plein à craquer ; dans ce cas, on peut tenter plusieurs fois cette réparation en espérant que ça marche ou on peut essayer de le faire depuis un autre système d'exploitation, comme Linux (je le concède : ça devient un peu compliqué mais Linux peut aider)
• une fois la taille augmentée et le système de fichiers corrigé, on peut le monter et virer les choses inutiles puis cloner à rebours, le cas échéant.

Ça risque de te demander de la bidouille.