Réparer les paquets épars de Time Machine qui ne se montent plus

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

Exécuter

chflags -R nouchg flattop.sparsebundle

Mais attention, le sparsebundle peut avoir été protégé parce qu'il est réellement cassé.

J'ai un NAS Synology et j'obtenais l'erreur NO-WRITE lorsque j'essayais d'exécuter le correctif, mais je suis tombé sur ceci version modifiée qui m'a sauvé la mise :

1. Désactivez les sauvegardes Time Machine afin qu'elles n'interfèrent pas avec le processus de réparation : tmutil disable

2. Monter le partage SMB/AFP contenant le sparsebundle : mkdir /Volumes/TimeMachine ; mount_afp afp://ReadyNAS:<pass>@<ip-address>/ReadyNAS /Volumes/TimeMachine (vous pouvez également monter le partage dans le Finder)

3. Réinitialise les drapeaux du sparsebundle définis par Time Machine qui l'empêchent d'être écrit : chflags -R nouchg /Volumes/TimeMachine/<my-backup>.sparsebundle

4. Attachez le sparsebundle en lecture-écriture : hdiutil attach -nomount -readwrite -noverify -noautofsck /Volumes/TimeMachine/<my-backup>.sparsebundle . Vous devriez obtenir un résultat similaire à :

   /dev/disk2 GUID_partition_scheme /dev/disk2s1 EFI /dev/disk2s2 Apple_HFS

5. En utilisant la dernière entrée de la sortie, exécutez fsck : fsck_hfs -dy /dev/rdisk2s2 . Pour accélérer la réparation, vous pouvez indiquer fsck pour utiliser plus de mémoire : -c 8g si vous avez 8G de mémoire libre, etc. Si vous le souhaitez, vous pouvez exécuter fsck_hfs -dy -Race /dv/rdisk2s2 pour reconstruire le catalogue après vous exécutez la réparation initiale (dans mon cas, l'exécution de la reconstruction avant la réparation initiale a corrompu le système de fichiers de manière irrémédiable).

6. Ensuite, nous devons indiquer à Time Machine que le sparsebundle peut être utilisé. Show contents de l'ensemble épars, puis ouvrez l'onglet com.apple.TimeMachine.MachineID.plist :

• Enlever ceci :

  <key>RecoveryBackupDeclinedDate</key> <date>some-data</date>

• Changez cela :

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

• à cela :

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

7. Ejecter le faisceau d'informations éparses : hdiutil detach /dev/disk2 et éjecter le partage réseau : umount /Volumes/TimeMachine
8. Réactiver la sauvegarde Time Machine : tmutil enable

Remarque : la plupart des commandes doivent être exécutées avec les privilèges de root. Ajouter sudo à la commande si elle échoue.

Télécharger le shell script. ici . Voir également l'annexe ci-dessous. Doit être exécuté en tant que root ( sudo ).

if [[ $(whoami) != 'root' ]]; then
    exit 1
fi

read -p 'Enter Time Machine Hostname: ' HOSTNAME
read -p 'Enter Share: ' SHARE
read -p 'Enter Username: ' USERNAME
read -s -p 'Enter Password: ' PASSWORD

TM_NAME=$(hostname -s | sed -e 's/-/ /g')
MOUNT=/Volumes/TimeMachine
SPARSEBUNDLE=$MOUNT/$TM_NAME.sparsebundle
PLIST=$SPARSEBUNDLE/com.apple.TimeMachine.MachineID.plist

echo "Disabling Time Machine"
tmutil disable

echo "Mounting volume"
mkdir $MOUNT
mount_afp afp://$USERNAME:$PASSWORD@$HOSTNAME/$SHARE $MOUNT

echo "Changing file and folder flags"
chflags -R nouchg "$SPARSEBUNDLE"

echo "Attaching sparse bundle"
DISK=`hdiutil attach -nomount -readwrite -noverify -noautofsck "$SPARSEBUNDLE" | grep Apple_HFS | cut -f 1`

echo "Repairing volume"
#diskutil repairVolume $DISK
/sbin/fsck_hfs -fry $DISK

echo "Fixing Properties"
cp "$PLIST" "$PLIST.backup"
sed -e '/RecoveryBackupDeclinedDate/{N;d;}'   \
    -e '/VerificationState/{n;s/2/0/;}'       \
    "$PLIST.backup" \
    > "$PLIST"

echo "Unmounting volumes"
hdiutil detach /dev/$DISK
umount $MOUNT

echo "Enabling Time Machine"
tmutil enable

echo "Starting backup"
tmutil startbackup

exit 0

Ce n'est pas aussi simple que chmod. Tout d'abord, il apparaît que 10.5 / 10.6 / 10.7 ont tous des différences mineures dans la façon de traiter un faisceau clairsemé. Deuxièmement, les drapeaux et l'état dirty/bad d'un sparse bundle sont stockés ailleurs. Troisièmement, il se peut que vous deviez attaquer le sparse bundle lui-même - et non le système de fichiers qu'il contient.

Le mieux est de laisser l'Utilitaire de disque réparer l'image avant d'examiner le système de fichiers qu'elle contient. Il fonctionne à la fois sur la liasse et sur les systèmes de fichiers - et sait comment Apple a stocké les choses.

Les détails du bundle sont soit propriétaires, soit difficiles à discerner dans la documentation du développeur - et ce n'est certainement pas quelque chose que d'autres utilitaires tiers sont désireux de corriger à ce stade. Tant que vous utilisez une version de Disk Utility identique ou plus récente que celle du Mac qui a effectué les sauvegardes, tout devrait bien se passer. Une fois que vous aurez abandonné Disk Utility, vous pourrez essayer quelque chose comme Drive Genius ou Disk Warrior, mais je m'en tiendrais à l'outil d'Apple si vous espérez réutiliser ce bundle.

La nature des paquets épars - en particulier les liens durs ainsi que le concept selon lequel les fichiers ne sont pas compactés lorsqu'ils sont supprimés, il y a un risque d'erreur. beaucoup de travail à faire . J'ai fait tourner DiskUtility pendant deux semaines et je n'ai toujours pas réussi à effectuer une réparation sur une archive de 800 Mo.

En pratique, il est préférable de revenir à une version antérieure de votre NAS s'il dispose d'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 sparse bundle sera marqué comme mauvais et il sera verrouillé. Vous pourrez alors y lire des choses, mais 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 - de même qu'une machine qui peut avoir le temps de réparer les choses et de ne pas être redémarrée est idéale).

Bonne chance - il se peut que les détails que vous avez fournis ne permettent pas de récupérer l'information.

La réponse de @Garth n'a pas fonctionné pour moi. J'ai dû ajouter l'élément -readwrite à l'option hdiutil afin qu'il fonctionne pour mon image cryptée. Sans cette option, hdiutil ne demande pas le mot de passe.

Lors de l'étape fsck, j'ai rencontré une erreur de type Disk full error . Pour y remédier, j'ai utilisé la fonction resize pour agrandir la taille de l'image avant d'exécuter fsck.

Voici les commandes que j'ai utilisées pour résoudre le problème :

# 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 dispositif peut varier, donc au lieu de disk2s2 vous devez utiliser la disquette imprimée par l'application hdiutil attach commande. De plus, vous n'avez besoin que de la commande resize si vous avez obtenu le Disk full error lors de l'exécution du fsck_hfs commande. De plus, au lieu de mon 1.5t vous devez saisir une nouvelle taille raisonnable, légèrement supérieure à la taille actuelle de votre image (vérifiez auprès de du -hs MyImage.sparsebundle ).