Problems scheduling multiple backups

[diamondsw]

My SuperDuper backups are on disk images on a network volume (Time Capsule). I schedule three backups for 4AM - my boot drive, one set of files from my data drive, and a second set of files from my data drive. Sadly, the backups almost never all succeed when scheduled - but running any of them manually works like a charm.

1. Oddly, when I select "Options" > "On Successful Completion", "Eject <volname>" is grayed out - this is regardless of scheduling, but odd.
2. For a while, destination volumes would have problems mounting when scheduled. When run manually, it worked fine. Disk Utility showed nothing out of the ordinary on any volumes. After a while this just went away - which always makes me a bit nervous.
3. When the backups complete, the disk images are unmounted but the Time Capsule volume is not. I'm pretty sure previous versions unmounted both.
4. I'm getting frequent problems trying to run multiple scheduled backups - only one tends to run, and the window is stuck on a strange mishmash of the results from the previous backup (green bars, steps completed, OK button) and the settings for the next backup in the popups at the top of the window. Not sure what is happening, but it fails to backup most nights. Yet on some nights, it works. Frustrating.

I'm pretty sure I deleted all of my scheduled backups after 2.6.1, but I'm trying again tonight, and setting all scripts to "Quit SuperDuper" when done - since once all of them complete that's the desired behavior.

[dnanian]

1. This is because image files are always mounted, copied to and then ejected.

2. I don't really know why this would be, but do delete/recreate the schedules.

3. No, the network drive wouldn't have ever been unmounted.

4. Again, let's try deleting and recreating the schedules...

[diamondsw]

Deleted all of the schedules; no change. However, here's what I'm seeing in the log for the failed backups:

| 04:00:36 AM | Info | PHASE: 1. Prepare to Copy Files
| 04:00:36 AM | Info | ...ACTION: Preparing Tera
| 04:00:36 AM | Info | ......COMMAND => Verifying the integrity of volinfo.database
| 04:00:36 AM | Info |       volinfo.database OK
| 04:00:36 AM | Info | ......COMMAND => Enabling permissions on Tera
| 04:00:36 AM | Info |       Refreshing Disk Arbitration ...
| 04:00:48 AM | Info | ......COMMAND => Verifying that permissions are enabled for Tera
| 04:00:48 AM | Info |       Permissions on '/Volumes/Tera' are enabled.
| 04:00:48 AM | Info | ...ACTION: Mounting Video
| 04:00:48 AM | Info | ......COMMAND => Preparing Video
| 04:00:48 AM | Info | ......COMMAND => Setting ownership and access modes for '/Volumes/Delorean/Personal/Video.sparseimage'
| 04:00:48 AM | Error | chmod: /Volumes/Delorean/Personal/Video.sparseimage: Permission denied

What makes no sense is that the permissions are set for everyone to have full access to the image - and it works fine when manually run.

jochs@mini ~ $ ls -al /Volumes/Delorean/Personal/
total 577078476
drwxrwxrwx   5 jochs  jochs           264 Sep 17 01:51 ./
drwx------@ 21 jochs  jochs           670 Sep  3 03:37 ../
-rwxrwxrwx@  1 jochs  jochs          6148 Jan  9  2009 .DS_Store*
-rwxrwxrwx@  1 jochs  jochs  261865046016 Oct  5 04:04 Dante.sparseimage*
-rwxrwxrwx@  1 jochs  jochs  329063297024 Oct  5 04:06 Video.sparseimage*

[dnanian]

We're simply trying to set the permissions for the file properly with

sudo -P -u your-uid chmod 0775 path-to-image

I don't know why it would deny us permission to do so... but that's what the error is saying...

[diamondsw]

Originally Posted by dnanian

We're simply trying to set the permissions for the file properly with

sudo -P -u your-uid chmod 0775 path-to-image

I don't know why it would deny us permission to do so... but that's what the error is saying...

Figured it out - if Time Machine is backing up to the same volume, then it locks down the permissions on the mount point - can't even "ls /Volumes/Delorean" (yes, I named the drive Delorean). This also explains why it would fail sometimes, but not every time. Ever since Snow Leopard, Time Machine has been backing up every hour - and if it happens to be running when SD starts, it clobbers my SuperDuper backups.

I just verified this by running a SD backup - no problems. Then unmounted Delorean, started a Time Machine backup, and tried SD. Bam - failed.

[dnanian]

That's... weird. I don't know why they would change your own image at all.

[diamondsw]

Originally Posted by dnanian

That's... weird. I don't know why they would change your own image at all.

Well, no, Time Machine don't change the image itself, but it mounts the Time Machine disk (where the SD image file is located) in such a way that Mac OS X has exclusive access to it.

So:

• I have a Time Capsule that is the Time Machine target of four Macs in my house. Nothing special there - just default configuration in OS X.
• The Time Capsule shares its disk under the name "Delorean".
• On Delorean, the various Time Machine backups are stored at the root of the disk using the standard naming convention of <Host>_<MAC Address>.sparsebundle.
• On Delorean, I have several sparse images for SuperDuper backups - things like "/Volumes/Delorean/Personal/Video.sparseimage". I also use it for Linux and Windows backups, but that's neither here nor there.

So, what happens is Time Machine mounts Delorean, and then mounts its own sparsebundle (for instance "Mini_0016cba7083c.sparsebundle", which mounts as "Backup of Mini"). I can access "Backup of Mini" all I want, but the Time Capsule mount - "/Volumes/Delorean" - does not show on the desktop, and is inaccessible via the Terminal as described above.

When SuperDuper tries to run after Time Machine has the volume mounted, it can't get to the sparse image it needs, since Time Machine has mounted it in this funky way, and the chmod call fails. I'm assuming any attempt to access the contents of "/Volumes/Delorean" would fail at that point.

I can see a variety of solutions, but I don't know that any are very good:

• Mount the Time Machine volume again on a different mount point. Not sure if this is possible, but network filesystems are designed for multiple access.
• Remount the Time Machine volume with different permissions. Not sure how this would affect the ongoing TM backup.
• Wait until Time Machine is done with the drive, then run the SD backup.

For now, I'm using TimeMachineEditor to keep Time Machine from running when SuperDuper is doing its thing, but it would be super nice if a workaround could be put in place for this admittedly strange circumstance.

[dnanian]

How about partitioning the Time Capsule (or attaching an external USB drive) to host the images on different volumes?

[diamondsw]

Originally Posted by dnanian

How about partitioning the Time Capsule (or attaching an external USB drive) to host the images on different volumes?

Definitely not going to do that over a software glitch - that would require deleting a terabyte of data (which would be *painful* to back up again), losing my Time Machine backup history, and/or purchasing a new disk and wall mounting it. I'll stick with manually running my Time Machine backups until this is fixed.

[Michael@wengam]

I've seen problems like this with my Time Capsule, too, but with scheduled runs of another program (not SD!) that only does folder synchronization. Syncs with that program fail if Time Machine starts accessing the Time Capsule first.

Haven't figured it out, but it seems to be something to do with the fact that if a Time Machine backup is running, a second 'volume' appears in the /Volumes folder with '-1' appended to its name: somehow this gives Time Machine the protection it needs but also lets you access files on the Time Machine in Finder--but spoils access for other programs because the file path names that were set don't work with the '-1' appended name.

In fact it was for this reason that I stopped trying to run SD! backups to disk images on the Time Capsule; I also have a simple NAS which works fine, so I still use that instead if I need to backup to a network disk image.

[edit]
More information about Time Capsule's multiple identities here:
http://discussions.apple.com/thread....977&tstart=176

[diamondsw]

Originally Posted by Michael@wengam

I've seen problems like this with my Time Capsule, too, but with scheduled runs of another program (not SD!) that only does folder synchronization. Syncs with that program fail if Time Machine starts accessing the Time Capsule first.

Haven't figured it out, but it seems to be something to do with the fact that if a Time Machine backup is running, a second 'volume' appears in the /Volumes folder with '-1' appended to its name: somehow this gives Time Machine the protection it needs but also lets you access files on the Time Machine in Finder--but spoils access for other programs because the file path names that were set don't work with the '-1' appended name.

In fact it was for this reason that I stopped trying to run SD! backups to disk images on the Time Capsule; I also have a simple NAS which works fine, so I still use that instead if I need to backup to a network disk image.

[edit]
More information about Time Capsule's multiple identities here:
http://discussions.apple.com/thread....977&tstart=176

Oddly enough, I think this is the way it used to work. The "-1" is used when Mac OS X tries to mount a volume and finds that the volume name is already used by something else. You can do the same thing with fixed disks or a couple disk images.

However, that does point out that SuperDuper certainly could mount the network volume again under a new mount point - one that is usable - and get on with its business. Agreed it's annoying to have to check the mount point to see if it's "special" and then remount, but from all of the blog posts over the years, I gather you're used to dealing with "special" behavior from OS X.

[dnanian]

Actually, OS X adds a digit without the "-" when it finds the mount point in use (and we show that to you in the volume pop-ups, and predict that behavior as well to ensure we're writing to the proper volume, even with a network mount)... however, if the 'host' volume for an image doesn't mount properly, the path to that image changes which can cause (relatively obvious) problems... it's sort of like changing the filename of the image.