Differences

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

--- docs:tips_n_tricks:max_os_x:fix_time_machine_sparsebundle_errors [17.04.2020 17:44 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>
-:!: 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:
+<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.\\
+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>
-:!: Just realized that the source recommends to use raw disk devices, which means to use ''/dev/rdisk''... instead of ''/dev/disk''... :!:
+<note important>Just realized that the source recommends to use raw disk devices, which means to use ''/dev/rdisk''... instead of ''/dev/disk''...</note>
@@ Line 18: / Line 18: @@
   - Start a shell (Terminal Window) with root permissions and recursively clear the //user immutable flag//:<code>
 ~ # chflags -v -R nouchg /Volumes/Backup_Volume/MyHostname_YYYY-MM-DD-HHMMSS.sparsebundle</code>
-  - attach the sparsebundle as volume without mounting<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
@@ Line 60: / Line 60: @@
 ** 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.\\ :!: Therefore I recommend cabled network during the recovery process.
+</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.
-  - If this does not finish successfully or did a "QUICKCHECK ONLY", run disk repair again:<code>
+<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
@@ Line 98: / Line 99: @@
 </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}}