Differences

This shows you the differences between two versions of the page.

--- docs:tips_n_tricks:max_os_x:fix_time_machine_sparsebundle_errors [13.06.2012 21:31 CEST] – peter
+++ docs:tips_n_tricks:max_os_x:fix_time_machine_sparsebundle_errors [25.06.2020 01:01 CEST] (current) – peter
@@ Line 3: / Line 3: @@
 [This is an extract from //[[http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-based-backup-errors.html|Fix Time Machine Sparsebundle NAS Based Backup Errors]]// by //Garth Gillespie//]
-:!: This is work in progress! Not all steps are verified yet! :!:
+<note warning>This is work in progress! Not all steps are verified yet!</note>
+<note tip>Maybe one reference in the comments to the article denoted above is worth reading: http://sansumbrella.com/writing/2012/the-reluctant-sysadmin-nas-time-machine/((Basically he suggests to create a sparsebundle on your own first, give it a custom band size:
+  # creates a sparsebundle disk image with a 128MB band size
+  MACHINE_NAME=your-machine-name
+  echo $MACHINE_NAME
+  hdiutil create -size 900g -type SPARSEBUNDLE -nospotlight -volname "Backup of $MACHINE_NAME" -fs "Case-sensitive Journaled HFS+" -imagekey sparse-band-size=262144 -verbose ./$MACHINE_NAME.sparsebundle
+))\\
+Inspired by his basic Idea, that the problem might be related to //ext2/3/4// file systems limitations, I changed to XFS for the underlying file system and got a stable backup.</note>
+<note important>Just realized that the source recommends to use raw disk devices, which means to use ''/dev/rdisk''... instead of ''/dev/disk''...</note>
-  * Connect your Backup Volume
-  * I recommend to disable your backups as it seems to disconnect your Backup volume.
+  - Connect your Backup Volume((Might be done via the Finder or by\\ ''mkdir /Volumes/Backup_Volume''\\ ''mount_afp -i afp:/''''/<user>@<host>/Backup_Volume /Volumes/Backup_Volume''))
-  * Start a shell (Terminal Window) with root permissions and recursively clear the //user immutable flag//:<code>
+  - I recommend to disable your backups((Either in the Time Machine system preferences dialog or by ''tmutil disable'')) as successive tries seem to interfere with the recovery process. Furthermore, it might be a good idea to keep the backup volume open by displaying it in the finder and to make sure that your network connection is stable (provided your backup volume is connected via your network one way or the other)
-~ # chflags -R nouchg /Volumes/Backup_Volume/MyHostname_YYYY-MM-DD-HHMMSS.sparsebundle</code>
+  - Start a shell (Terminal Window) with root permissions and recursively clear the //user immutable flag//:<code>
-  * mount the sparsebundle as filesystem<code>
+~ # chflags -v -R nouchg /Volumes/Backup_Volume/MyHostname_YYYY-MM-DD-HHMMSS.sparsebundle</code>
+  - attach the sparsebundle as volume without mounting((it's been ''Apple_HFS'' instead of ''Apple_HFSX'' in my case))<code>
 ~ # hdiutil attach -nomount /Volumes/Backup_Volume/MyHostname_YYYY-MM-DD-HHMMSS.sparsebundle
 /dev/disk1              Apple_partition_scheme
 /dev/disk1s1            Apple_partition_map
-/dev/disk1s2            Apple_HFSX</code>Use the partiion listed as ''Apple_HFSX'' in the following steps (i.e. replace ''/dev/disk1s2'' the your partition). This will implicitly start a file system check. As checked with ''ps'', the actual command run seems to be\\ ''/System/Library/Filesystems/hfs.fs/Contents/Resources/../../../../../../sbin/fsck_hfs -y /dev/disk1s2''
+/dev/disk1s2            Apple_HFSX
-  * Monitor the progress of the file system check<code>
+~ #</code>Use the partiion listed as ''Apple_HFSX'' in the following steps (i.e. replace ''/dev/disk1s2'' by your partition). This will implicitly start a file system check. As checked with ''ps'', the actual command run seems to be\\ ''/System/Library/Filesystems/hfs.fs/Contents/Resources/../../../../../../sbin/fsck_hfs -y /dev/disk1s2''
+  - Monitor the progress of the file system check<code>
 ~ # tail -f /var/log/fsck_hfs.log
-/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-491.6~3).
-QUICKCHECK ONLY; FILESYSTEM DIRTY
-/dev/rdisk1s2: fsck_hfs run at DDD MMM DD 'HH:MM:SS YYYY
 /dev/rdisk1s2: ** /dev/rdisk1s2
 /dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-491.6~3).
@@ Line 31: / Line 37: @@
 ** Checking multi-linked directories.
 ** Checking volume bitmap.
+   Volume bitmap needs minor repair for orphaned blocks
 ** Checking volume information.
-** The volume Time Machine-Backups appears to be OK.
+   Invalid volume file count
-</code>(If something goes wrong, you have to clear the //user immutable flag// again.)
+   (It should be 3180308 instead of 3355480)
-  * When done (successfully), run disk repair:<code>
+   Invalid volume directory count
-~ # fsck_hfs -drfy /dev/disk1s2
+   (It should be 356386 instead of 356055)
+   Invalid volume free block count
+   (It should be 15844066 instead of 16637291)
+   Volume header needs minor repair
+(2, 0)
+/dev/rdisk1s2: ** Repairing volume.
+** Rechecking volume.
+** Checking Journaled HFS Plus volume.
+** Detected a case-sensitive volume.
+** Checking extents overflow file.
+** Checking catalog file.
+** Checking multi-linked files.
+** Checking catalog hierarchy.
+** Checking extended attributes file.
+** Checking multi-linked directories.
+** Checking volume bitmap.
+** Checking volume information.
+** The volume Time Machine-Backups was repaired successfully.
+</code>(If something goes wrong and you have to start over, you need to clear the //user immutable flag// again.)\\ Most failures at this point were due to accidental unmount of the underlying ''/Volumes/Backup_Volume''. I believe the unmounts were caused by network errors while using WIFI.
+<note important>Therefore I recommend cabled network during the recovery process.</note>
+  - If this does not finish successfully or did a "QUICKCHECK ONLY", run disk repair again((The Disk Utility does not use ''-r'' which means to rebuild the catalog tree. Try again without it if you run into an “Disk Full” error during rebuilding the catalog B-tree)):<code>
+~ # fsck_hfs -drfy /dev/rdisk1s2
 ** /dev/rdisk1s2
         Using cacheBlockSize=32K cacheTotalBlock=8192 cacheSize=262144K.
@@ Line 46: / Line 74: @@
 ** Rebuilding catalog B-tree.
 hfs_UNswap_BTNode: invalid node height (1)
-** The volume Time Machine-Backups could not be repaired.
+** Rechecking volume.
-        volume type is pure HFS+
+** Checking Journaled HFS Plus volume.
-        primary MDB is at block 0 0x00
+** Detected a case-sensitive volume.
-        alternate MDB is at block 0 0x00
+** Checking extents overflow file.
-        primary VHB is at block 2 0x02
+** Checking catalog file.
-        alternate VHB is at block 391877934 0x175b952e
+** Checking multi-linked files.
-        sector size = 512 0x200
+** Checking catalog hierarchy.
-        VolumeObject flags = 0x07
+** Checking extended attributes file.
-        total sectors for volume = 391877936 0x175b9530
+** Checking multi-linked directories.
-        total sectors for embedded volume = 0 0x00
+        privdir_valence=24850, calc_dirlinks=101703, calc_dirinode=24850
-~ # tail -f /var/log/fsck_hfs.log
+** Checking volume bitmap.
-** The volume Time Machine-Backups was found corrupt and needs to be repaired.
+** Checking volume information.
-        volume type is pure HFS+
+** The volume Time Machine-Backups was repaired successfully.
-/dev/rdisk1s2:  primary MDB is at block 0 0x00
+~ # </code>
-/dev/rdisk1s2:  alternate MDB is at block 0 0x00
+  - Finally, detach the file system<code>
-/dev/rdisk1s2:  primary VHB is at block 2 0x02
-/dev/rdisk1s2:  alternate VHB is at block 391877934 0x175b952e
-/dev/rdisk1s2:  sector size = 512 0x200
-/dev/rdisk1s2:  VolumeObject flags = 0x07
-/dev/rdisk1s2:  total sectors for volume = 391877936 0x175b9530
-/dev/rdisk1s2:  total sectors for embedded volume = 0 0x00
-</code>
-  * Finally, detach the file system<code>
 ~ # hdiutil detach /dev/disk1s2</code>
-  * When complete, you need to edit an plist file within the sparsebundle that records the state of the backup. Within the sparsebundle open the file  ''com.apple.TimeMachine.MachineID.plist'' with the Plist Editor. Remove the Entry<WRAP>
+  - When complete, you need to edit an plist file within((use rightclick -> open package contents, not doubleclick)) the sparsebundle that records the state of the backup. Within the sparsebundle open the file  ''com.apple.TimeMachine.MachineID.plist'' with the Plist Editor. Remove the Entry<WRAP>
-|RecoveryBackupDeclinedDate |DD.MM.YYYY HH:MM:SS|
+|RecoveryBackupDeclinedDate |Date |DD.MM.YYYY HH:MM:SS |
 </WRAP>
+  - Finally you want to change<WRAP>
-  * Finally you want to change<WRAP>
+|VerificationState |Number |2 |
-|VerificationState |2 |
 to
-|VerificationState |0 |
+|VerificationState |Number |0 |
 </WRAP>
-Now you can eject the network share and have Time Machine give it another go. After the (long) verification step, backups should proceed once again.
+Now you can eject the network share((Use ''hdiutil eject /Volumes/Backup_Volume'' if you prefer the command line)) and have Time Machine give it another go.
+<note tip>Don't forget to enable backups again ((Might be done via ''tmutil enable'' at the command line)).</note>
+After the (long) verification step, backups should proceed once again.
+{{tag>OSX backup}}
+{{entry>OSX}}
+{{entry>backup}}