Réparer le kit répartiteur Time Machine qui ne se montera plus

J'ai foiré ma sauvegarde Time Machine d'une manière ou d'une autre. Je ne peux plus monter le fichier sparsebundle car j'obtiens une erreur indiquant qu'il n'y a pas de système de fichiers montable.

J'ai utilisé la commande hdiutil pour attacher le fichier sparsebundle:

hdiutil attach -nomount -readwrite flattop.sparsebundle

ce qui a donné les appareils / dev / suivants:

/dev/disk2              Apple_partition_scheme
/dev/disk2s1            Apple_partition_map
/dev/disk2s2            Apple_HFSX

Ensuite, j'ai exécuté la commande fsch_hfs pour vérifier le volume principal (/ dev / disk2s2):

fsck_hfs -drf /dev/disk2s2

Il en est résulté un avis indiquant que le volume des sauvegardes Time Machine est corrompu et doit être réparé:

Unable to open block device /dev/disk2s2: Permission deniedjournal_replay(/dev/disk2s2) returned 13
** /dev/rdisk2s2 (NO WRITE)
    Using cacheBlockSize=32K cacheTotalBlock=32768 cacheSize=1048576K.
   Executing fsck_hfs (version diskdev_cmds-540.1~34).
Non-empty journal:  start = 66310144, end = 94912512
   Journal need to be replayed but volume is read-only
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine Backups
** Checking extents overflow file.
   Unused node is not erased (node = 3568)
   Unused node is not erased (node = 3574)
   Unused node is not erased (node = 3575)
** Checking catalog file.
** The volume Time Machine Backups was found corrupt and needs to be repaired.
    volume type is pure HFS+ 
    primary MDB is at block 0 0x00 
    alternate MDB is at block 0 0x00 
    primary VHB is at block 2 0x02 
    alternate VHB is at block 2865568974 0xaacd1cce 
    sector size = 512 0x200 
    VolumeObject flags = 0x07 
    total sectors for volume = 2865568976 0xaacd1cd0 
    total sectors for embedded volume = 0 0x00 

Comme vous pouvez le voir, il y a également une erreur indiquant "Impossible d'ouvrir le périphérique de bloc / dev / disk2s2: l'autorisation refuséejournal_replay (/ dev / disk2s2) a renvoyé 13".

Je pensais que cela pouvait être dû au fait de ne pas exécuter la commande fsck_hfs en tant que su, alors je l'ai essayé avec sudo mais cela a eu le même résultat.

Mon fichier sparsebundle se trouve sur un Synology DS408 NAS et fonctionne sans problème depuis environ 2 ans :(

Quelqu'un a une idée comment aller plus loin?

Cordialement, Niels R.

MISE À JOUR: Comme je le soupçonnais en écrivant cette question, j'ai probablement un problème avec les autorisations de lecture / écriture. Je vois maintenant le volume apparaître dans l'utilitaire de disque et quand je clique sur "Vérifier" j'obtiens la sortie suivante:

Verifying volume “Time Machine Backups”
Checking file systemJournal need to be replayed but volume is read-only
Checking Journaled HFS Plus volume.
Detected a case-sensitive volume.
Checking extents overflow file.
Unused node is not erased (node = 3568)
Checking catalog file.
Keys out of order
The volume Time Machine Backups was found corrupt and needs to be repaired.
Error: This disk needs to be repaired. Click Repair Disk.

Puis-je simplement modifier le fichier sparsebundle pour définir les bonnes autorisations?

J'ai un article sur la façon d'essayer de réparer les erreurs sparsebundle basées sur NAS sur mon blog . En résumé:

1. hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your disk}/{name of}.sparsebundle

   Vous verrez alors quelque chose comme

   /dev/diskx Apple_partition_scheme
   /dev/diskxs1 Apple_partition_map
   /dev/diskxs2 Apple_HFSX
   

   Où x est l'ID de disque pour le disque externe. x peut être 2, 3, 4 ou supérieur. Vous êtes intéressé par celui intitulé Apple_HFSX ou Apple_HFS.

2. fsck_hfs -drfy /dev/diskxs2 en utilisant n'importe quel appareil pertinent situé à l'étape 1.

   J'espère que vous finirez par voir

   Le volume a été réparé avec succès

3. hdiutil detach /dev/diskxs2

Cependant, depuis OS X 10.6.3, Time Machine refusera d'écrire sur un volume de destination qui échoue à sa vérification. Même si le processus ci-dessus réussit à récupérer la sauvegarde, vous devrez peut-être supprimer les marques noires que Time Machine a écrites en cas d'échec de la vérification.

4. Déverrouillez le sparsebundle

   chflags -R nouchg /Volumes/{name of your disk}/{name of}.sparsebundle
   

5. Remettez-le à son emplacement d'origine

   mv /Volumes/{name of your disk}/{name of}_YYYY-MM-DD.sparsebundle /Volumes/{name of your disk}/{name of}.sparsebundle
   

6. Dans le répertoire de niveau supérieur du sparsebundle, modifiez le fichier com.apple.TimeMachine.MachineID.plist.

   • Retirer

     <key>RecoveryBackupDeclinedDate</key>
     <date>{whatever-the-date}</date>
     

   • Changement

     <key>VerificationState</key>
     <integer>2</integer>
     

     à

     <key>VerificationState</key>
     <integer>0</integer>
     

Les attributs étendus sur le sparsebundle peuvent empêcher les écritures sur le fichier:

Courir

chflags -R nouchg flattop.sparsebundle

Mais faites attention, le faisceau clairsemé peut avoir été protégé car il est vraiment cassé.

Ce n'est pas aussi simple que chmod. Premièrement, il apparaît que 10.5 / 10.6 / 10.7 présentent tous des différences mineures dans la façon dont un paquet clairsemé est géré. Deuxièmement, les drapeaux et le statut sale / mauvais d'un paquet clairsemé sont stockés ailleurs. Troisièmement, vous devrez peut-être attaquer le bundle clairsemé lui-même - pas le système de fichiers qui y est contenu.

Votre meilleur pari est de laisser l'Utilitaire de disque s'occuper de réparer l'image avant de regarder le système de fichiers intégré. Il fonctionne à la fois sur le bundle et les systèmes de fichiers - et sait comment Apple a stocké les choses.

Les détails de l'ensemble sont exclusifs ou difficiles à discerner à partir des documents des développeurs - et ce n'est certainement pas quelque chose que d'autres utilitaires tiers souhaitent corriger à ce stade. Tant que vous utilisez une version égale ou plus récente de l'Utilitaire de disque que le mac qui a effectué les sauvegardes, tout devrait bien se passer. Une fois que vous avez abandonné l'Utilitaire de disque - vous pourriez essayer quelque chose comme Drive Genius ou Disk Warrior - mais je m'en tiendrai à l'outil d'Apple si vous espérez réutiliser ce bundle.

La nature des bundles clairsemés - en particulier les liens durs ainsi que le concept selon lequel ils ne sont pas compactés lorsque les fichiers sont supprimés, il y a beaucoup de travail à faire . J'ai eu DiskUtility exécuté pendant deux semaines et je n'ai toujours pas effectué de réparation sur une archive de 800 Mo.

Dans la pratique, il serait préférable de simplement revenir à une version antérieure de votre NAS s'il possède des instantanés ou s'il est lui-même sauvegardé. En fin de compte - s'il y a des erreurs que fsck / Disk Utility ne peut pas corriger, votre paquet fragmenté sera marqué comme mauvais et il sera verrouillé. Vous pouvez alors lire des choses, mais ne plus jamais y écrire. Voyez si vous pouvez connecter une machine au stockage et réparer les choses (les connexions DAS ou haute vitesse sont meilleures - tout comme une machine qui peut avoir le temps de réparer les choses et de ne pas redémarrer est idéale)

Bonne chance - cela peut ne pas être récupérable à partir des détails que vous avez fournis.

@ La réponse de Garth n'a pas fonctionné pour moi. J'ai dû ajouter l' -readwriteoption pour hdiutilque cela fonctionne pour mon image cryptée. Sans cette option, hdiutilne demande pas le mot de passe.

À l'étape fsck, j'ai rencontré un Disk full error. Pour résoudre ce problème, j'ai utilisé l' resizeoption pour agrandir la taille de l'image avant d'exécuter fsck.

Voici les commandes que j'ai utilisées pour le réparer:

# chflags -R nouchg MyImage.sparsebundle

# hdiutil attach -nomount -noverify -readwrite -noautofsck MyImage.sparsebundle
Enter the password to access „MyImage.sparsebundle“: 
/dev/disk2              GUID_partition_scheme           
/dev/disk2s1            EFI                             
/dev/disk2s2            Apple_HFS                       

# hdiutil resize -size 1.5t MyImage.sparsebundle
Enter the password to access „MyImage.sparsebundle“: 

# fsck_hfs -drf /dev/disk2s2
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine-Backups
** Checking extents overflow file.
** Checking catalog file.
** Rebuilding catalog B-tree.
…

# hdiutil detach /dev/disk2s2

Comme expliqué dans les autres réponses, le chemin du périphérique peut varier, donc au lieu de disk2s2vous devez utiliser le disque qui est imprimé par la hdiutil attachcommande. De plus, vous n'avez besoin de cette resizeétape que si vous l'avez Disk full errorobtenue lors de l'exécution de la fsck_hfscommande. De plus, au lieu de mon, 1.5tvous devez entrer une nouvelle taille raisonnable qui est juste légèrement plus grande que la taille actuelle de votre image (vérifiez avec du -hs MyImage.sparsebundle).

J'ai un NAS Syology et recevais l'erreur NO-WRITE lorsque j'essayais d'exécuter le correctif, mais je suis tombé sur cette version modifiée qui a sauvé mon bacon.

http://tonylawrence.com/blog/2012/08/11/fixing-corrupted-time-machine-backups/

Si vous sauvegardez une image disque de bundle clairsemée sur une machine et essayez de l'ouvrir sur une autre, vous pouvez obtenir le message d'erreur «aucun système de fichiers montable», surtout si les noms d'utilisateur des propriétaires diffèrent entre les deux machines.

Ma solution copiait le bundle sur mon disque local et fonctionnait

sudo chown -R MyUserName nonmounting.sparsebundle

dessus.

Après cela, tout s'est bien ouvert et tout allait bien avec le monde.

J'ai fait toutes les étapes ci-dessus mais après un certain temps, l'image n'a pas pu être réparée à l'aide de fsck_hfs ou hdutil, beaucoup d'erreurs liées aux threads ou aux nœuds corrompus.

Ce qui a fonctionné pour moi, c'est:

1. (Facultatif) Connectez un lecteur externe USB 1 To formaté HFS Jornaled.

2. (Facultatif) Dans Airport Utility, accédez à Time Capsule Disks -> Archive Disk dans le lecteur connecté à Time Capsule par USB. Cela m'a pris 12 heures pour 600 Go.

3. hdiutil attach -nomount -noverify -noautofsck /Volumes/DISK/MyFile.sparsebundle

4. Ensuite, le disque était visible à l'aide de DiskWarrior . Dans l'onglet Répertoire, cliquez sur Reconstruire . Cela a pris environ 1 heure.

Une fois corrigé, je pouvais enfin monter et sauvegarder mes fichiers.

Cela a fonctionné pour moi:

• Faites un clic droit sur l'image du disque, changez "Tout le monde" pour lire et écrire.
• Terminal ouvert
• chmod -R 777 {disk image path}

C'était apparemment un problème d'autorisations.

REMARQUE: CELA RENDRA VOTRE SAUVEGARDE ACCESSIBLE À TOUTE PERSONNE QUI Y A UN ACCÈS PHYSIQUE

J'espère que cela peut aider quelqu'un.

J'ai été verrouillé de mon compte de coffre-fort hérité après une mise à jour de sécurité d'El Capitan avec une erreur «pas de système de fichiers montable».

Ce qui a fonctionné dans mon cas a été d'ouvrir le fichier sparsebundle en utilisant `` afficher le contenu du package '' dans le menu déroulant et de changer manuellement l'accès pour `` tout le monde '' de `` pas d'accès '' à `` lire et écrire '' pour chacun des éléments inclus. Pour le répertoire «bandes», j'ai utilisé la commande «appliquer aux éléments inclus» dans le menu déroulant.

J'ai eu un problème similaire avec un sparsebundle hébergé sur une machine Windows. J'ai tout essayé dans ce sujet et dans d'autres threads, résultant toujours sur un système de fichiers non montable erreur de (affichant également une erreur 112).

Le problème était Windows Defender, qui a détecté l'un des fichiers du sparsebundle en tant que cheval de Troie (Trojan: Script / Foretype.A! Ml). D'autres personnes ont signalé des faux positifs similaires, comme le cache Spotify ou les fichiers compilés par Rust .

Pour résoudre le problème, il suffit d'exclure le fichier de la quarantaine Windows Defender et de remonter le sparsebundle. Cela a pris trop de temps, vous pouvez donc obtenir une sortie à l'aide de cette commande:

hdiutil attach -verbose -debug -mountpoint /mount/path /path/to.sparsebundle

J'ai juste eu le même problème

** /dev/rdisk2s2 (NO WRITE)

lorsque vous essayez de réparer un TM-sparsebundle en cours sur un QNAP 419II.

J'ai "éjecté" la monture TM à l'aide du Finder et j'ai exécuté

hdiutil attach -nomount -noverify -noautofsck ...

commande (trouvée ici Fix Time Machine Sparsebundle NAS Based Backup Errors ), qui (contrairement à la première exécution avec laquelle elle a imprimé "/ dev / disk2s2 Apple_HFSX") cette fois, elle a donné

/dev/disk1s2            Apple_HFSX  

Vérification du journal système avec

tail -f /var/log/fsck_hfs.log

Non montré

/dev/rdisk1s2: fsck_hfs run at Sun Feb 17 17:53:20 2013
/dev/rdisk1s2: ** /dev/rdisk1s2
/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-540.1~34).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
... LOTS-OF-OUTPUT ...
QUICKCHECK ONLY; FILESYSTEM CLEAN

Néanmoins, la réactivation de la MT a toujours entraîné un message de sauvegarde currepté :(

Bonne chance!