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.03.2018 18:16 CET]
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>
   - 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''))
-  - I recommend to disable your backups 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 connectec via your network one way or the other)
+  - 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)
   - 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}}

/usr/local.org

User Tools

Site Tools

Differences

Page Tools