Problems scheduling multiple backups
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.
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. |
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... |
Deleted all of the schedules; no change. However, here's what I'm seeing in the log for the failed backups:
Code:
| 04:00:36 AM | Info | PHASE: 1. Prepare to Copy Files Code:
jochs@mini ~ $ ls -al /Volumes/Delorean/Personal/ |
We're simply trying to set the permissions for the file properly with
Code:
sudo -P -u your-uid chmod 0775 path-to-image |
Quote:
I just verified this by running a SD backup - no problems. Then unmounted Delorean, started a Time Machine backup, and tried SD. Bam - failed. |
That's... weird. I don't know why they would change your own image at all.
|
1 Attachment(s)
Quote:
So:
http://www.shirtpocket.com/forums/at...8&d=1254863439 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:
|
How about partitioning the Time Capsule (or attaching an external USB drive) to host the images on different volumes?
|
Quote:
|
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 |
Quote:
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. :) |
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.
|
All times are GMT -4. The time now is 06:38 PM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.