SuperDuper! Service
12 07, 14 Filed in: Macintosh Software
This is how customer support should be everywhere - by David R Beebe
Long before there was Time Machine there was SuperDuper!. It's an application that performs on-demand and scheduled bootable backups of a single drive. I've always used it to make a copy of Macintosh HD on a weekly schedule and I've continued to do so as a supplement to Time Machine. I am still running on OS X 10.6.8.
Recently, I've outgrown my 4TB drive for Time Machine. To make room, I moved my 1.5TB of Aperture libraries to a pair of 3TB WD MyBook for Mac drives. The libraries are mostly static so a nightly backup is adequate. I set the initial backup parameters and ran it manually in Super Duper. Following that, I used the application to schedule the nightly execution.
As you would expect from someone with multiple backup options, I periodically check the logs and the backup copy for accuracy. What I found was perplexing. Despite the job being told to copy drive A (disk7s2) to drive B (disk8s2), the log showed it was trying to copy drive B to drive B. I utilized the send log to Shirt Pocket with a brief description of the problem.
A quick response from Dave Nanian at Shirt Pocket appeared in my inbox. He asked if the drives had been reformatted before being used. I had thought they had been as most drives I buy come formatted as NTFS. Apparently I skipped this step as these came formatted as Mac OS Extended (Journaled). Spoiler alert: Per the Info panel of Disk Utility, the physical volumes had unique names I had assigned and unique disk numbers. However, the physical drives had the same USB Serial Number and IODeviceTree assignment. The logical volumes had the same Universal Unique Identifier and IODeviceTree assignment.
Dave suggested reformatting drive B which I did but Disk Utility did not show the data had changed. I even restarted Disk Utility but I did not reboot the OS. In a series of email exchanges, Dave suggested using Terminal to update disk8s2 as follows:
• sudo /System/Library/Filesystems/hfs.fs/hfs.util -s disk8s2
The command completes quickly but there is no status from it and there isn't a verbose option. I checked with Disk Utility again and there was still no change in what was being shown for drive B. Dave suggested deleting the previous scheduled job and creating a new one to run soon. He was confident that the above action worked. I am happy to say that it did but puzzled that the info in Disk Utility did not update until the drive was written to. Perhaps it was correct with the initial erase in Disk Utility.
Regardless, my thanks to Dave and Shirt Pocket for guiding me through this problem. Dave saw the issue to the end even though it wasn't a problem with their SuperDuper! application. This is how customer support should be everywhere.
Recently, I've outgrown my 4TB drive for Time Machine. To make room, I moved my 1.5TB of Aperture libraries to a pair of 3TB WD MyBook for Mac drives. The libraries are mostly static so a nightly backup is adequate. I set the initial backup parameters and ran it manually in Super Duper. Following that, I used the application to schedule the nightly execution.
As you would expect from someone with multiple backup options, I periodically check the logs and the backup copy for accuracy. What I found was perplexing. Despite the job being told to copy drive A (disk7s2) to drive B (disk8s2), the log showed it was trying to copy drive B to drive B. I utilized the send log to Shirt Pocket with a brief description of the problem.
A quick response from Dave Nanian at Shirt Pocket appeared in my inbox. He asked if the drives had been reformatted before being used. I had thought they had been as most drives I buy come formatted as NTFS. Apparently I skipped this step as these came formatted as Mac OS Extended (Journaled). Spoiler alert: Per the Info panel of Disk Utility, the physical volumes had unique names I had assigned and unique disk numbers. However, the physical drives had the same USB Serial Number and IODeviceTree assignment. The logical volumes had the same Universal Unique Identifier and IODeviceTree assignment.
Dave suggested reformatting drive B which I did but Disk Utility did not show the data had changed. I even restarted Disk Utility but I did not reboot the OS. In a series of email exchanges, Dave suggested using Terminal to update disk8s2 as follows:
• sudo /System/Library/Filesystems/hfs.fs/hfs.util -s disk8s2
The command completes quickly but there is no status from it and there isn't a verbose option. I checked with Disk Utility again and there was still no change in what was being shown for drive B. Dave suggested deleting the previous scheduled job and creating a new one to run soon. He was confident that the above action worked. I am happy to say that it did but puzzled that the info in Disk Utility did not update until the drive was written to. Perhaps it was correct with the initial erase in Disk Utility.
Regardless, my thanks to Dave and Shirt Pocket for guiding me through this problem. Dave saw the issue to the end even though it wasn't a problem with their SuperDuper! application. This is how customer support should be everywhere.