Shirt Pocket Discussions

Shirt Pocket Discussions (
-   General (
-   -   Scheduled backup to firewire drive on networked computer (

jimco 09-23-2007 08:07 PM

Scheduled backup to firewire drive on networked computer
I'm scheduling a backup to a volume on a firewire drive on another computer on a wireless network. The user's guide makes it sound like a snap but there were all kinds of issues to overcome. I pieced together hints from this forum and information from lots of other websites. In hopes that it will save someone else with the same need about 10 hours of work, I'm posting it here.

If anyone knows of easier or better ways of doing this than I've found, I would certainly appreciate detailed pointers.

Remote Computer (with attached backup drive)

This computer needs to wake up and mount the backup volume on the external disk before the source computer tries to mount it. I couldn't get it to mount remotely (from the source computer) any other way. Unexpectedly, I found that this cron event woke the computer up, so it was not necessary to set up a separate wake event. If it doesn't wake the computer for you, see the wake stuff for the source computer below.

Edit the crontab file ( /etc/crontab ) by adding this line. This would call for the mounting on Monday, Thursday and Saturday (1,4,6) at 1:00 am (0 1). Complete the disk* identifier with the identifier that Disk Utility gives it when it is mounted (get info).


0        1        *        *        1,4,6        /usr/sbin/diskutil mount /dev/disk*
If you know how to use pico (sudo pico /etc/crontab ) this is the easiest way to edit. You can also use TextEdit, but you have to first use Finder's Go>Folder menu command to navigate to /etc, then control-click to open with TextEdit, then save it on the Desktop (you don't have permission to overwrite the file), then replace it in the Finder using your administrator password, THEN reset the owner to root.

By the way, you will probably have to use the crontab command to read the edited file into the cron program. In theory it is supposed to update automatically but I guess I don't know how to make that happen. So just typing "crontab crontab" if you are in /etc works, or "crontab /etc/crontab" if you're not.

Source computer

On this computer, a cron event to mount the remote drive did not reliably wake up the computer, so the first step is to get it to wake up. You can do this with the Energy Saver prefs pane Schedule function. If you need a more flexible schedule (like Monday, Thursday and Saturday at 1 am, you can set it using pmset (power manager settings, which modifies the same settings file that the Energy Saver scheduler does) in Terminal with a command like this:


pmset repeat wake MRS 01:00:00
The next challenge is to mount the target volume connected to the remote computer. SuperDuper's manual says this will happen automatically after you first do it manually, but this did not happen for me - I got "can't mount" errors. I've tested two ways to do this and both seem to work:

EITHER: An undocumented (as far as I know) feature of SuperDuper is a place to add Applescripts that will fire before or after a copy job. Go to ~/Library/Application Support/SuperDuper!/Scheduled Copies ("~" refers to your home user folder). Here you will find your copy schedule file (assuming you already created it). Control-click on it and choose Show Package Contents. Then you will see a file called "Copy job.applescript". Open this in Script Editor, and you will see the comments clearly indicating where the pre- and post-backup scripts go.

One possibility is putting this script in the pre-backup slot:


  mount volume "afp://jimmy.local./Stuff" as user name "user" with password "password"
end try

For user and password, enter the info for a registered user of the remote computer. In this case, the computer's name is jimmy, and the volume on the attached firewire drive is Stuff.

OR: You can also mount the remote volumet with a cron job. Open crontab (see instructions for editing under Remote Computer above) and add these lines:


1        1        *        *        1,4,6        mkdir /Volumes/Stuff
2        1        *        *        1,4,6        /sbin/mount_afp afp://user:password@jimmy.local./Stuff /Volumes/Stuff

Modify for your names, etc. as indicated for the pre-backup applescript above. These two steps will happen at 1:01 and 1:02 am on the three days. Incidentally, there seems to be no way to do this successfully if there is no/blank password on the remote computer.

If you want to unmount/eject the volume when you're done, you can put the following applescript in "Copy job.applescript" (the post-backup slot) as shown above:


tell application "Finder"
  eject "Stuff"
end tell
delay 10

The backup job itself is scheduled in SuperDuper and should be a minute or so after mounting the remote volume.

Quite an ugly hack job, huh?

If you test this, expect SuperDuper to take about 5-10 minutes or so to mount the disk image on the remote volume. I don't know why that takes so long.


dnanian 09-23-2007 08:13 PM

A few things:

- First, this is not generally necessary. I back up to a network volume daily, as do many other users, without any of this complexity...

- Second, the mount is being done by the system. Since 10.4.10 (as I recall), they're scanning the entire volume before it mounts to ensure it's not an invalid volume and thus a security risk. Not much we can do...

jimco 09-24-2007 08:52 AM

Thanks for the reply. Regarding mounting by the system, I don't understand the implication, how that relates. Are you talking about mounting the disk image, and giving an explanation for why it takes so long?

As far as the unnecessary complexity, I would need more detail to learn where I'm going wrong. Here are some of the needs I was trying to meet.

1. Isn't it necessary to make sure the remote computer is awake before beginning the process? We don't want the computer to run awake all the time.

2. Doesn't the firewire drive, specifically the volume containing the image, have to mounted on the remote computer before you can mount it on your source computer? That computer user doesn't want the drive permanently mounted. It has a standby mode so it goes to sleep itself unless it is mounted.

3. I know from the User's Guide that the source computer has to be woken up before SuperDuper can do its thing. I mentioned Energy Saver and pmset, a more complex but flexible alternative.

4. Mounting the target volume on the source computer - this I gather from the Guide should be done by SuperDuper. It wasn't happening in my case. If you can help troubleshoot that I would be grateful. I described two alternatives for getting this done.

5. Unmounting the target volume after the backup - I'm pretty sure SuperDuper doesn't do this, so I mentioned a little insertion for the Copy job.applescript to do it.

So for the 5 things I addressed, as far as I know SuperDuper only is supposed to do one of them. Of course you could avoid all this by leaving the the volume mounted on both computers all the time, and leaving the computers running.

dnanian 09-24-2007 09:17 AM

I don't mean to suggest you're "going wrong", Jim. In fact, I don't think you've gone wrong in your case, nor did I say your complexity was unnecessary. What I said is that this is not generally necessary...

Most users don't need to take these steps (there's a broad mix of users in this forum).

(Yes, I was describing mounting the image and why it takes so long: it's being scanned for validity.)

As far as the destination not mounting: did you receive any errors? The remote volume is mounted by resolving an alias to the mount previously established: this should cause the system to mount the network volume (using authentication from the keychain).

jimco 09-24-2007 09:10 PM


Originally Posted by dnanian (Post 14271)
As far as the destination not mounting: did you receive any errors? The remote volume is mounted by resolving an alias to the mount previously established: this should cause the system to mount the network volume (using authentication from the keychain).

Dave, I retested the scheduled update, following a manual update, all without the mounting scripts, to see if I could coax SD to remember how to find the sparseimage on the volume on the drive attached to the networked computer. No dice. So I sent you the log with the error (from the button inside the log window. I'm stuck

Tnx, Jim

syndicatedragon 10-01-2007 09:52 PM

Actually, the manual mounting might be helpful in my case as well. I have a network volume (SMB) that requires a username and password. I need to schedule as root so the backup always runs (daemon support would be spectacular!). However, I can't seem to add the username and password to the root keychain. Instead of the normal "login" keychain, it prompts me for the password to something called "X509 Anchors" keychain, and the root password doesn't work! In fact I have been unable to ever figure out what this password is! Anyway, long story short, I'm going to try this manual mounting and see if that fixes my problem.

It would also be great if we could have access to the shortcuts that SuperDuper! uses to mount network shares! I then could add the username and password directly to the shortcut. Could that be a potential future addition as well?


dnanian 10-01-2007 10:36 PM

We don't use shortcuts, as such -- we use an Alias, and you can't store a password there.

syndicatedragon 10-03-2007 01:00 PM

Ah. Well, then, I guess the next best thing would be daemon support. Although, I guess I might have the same problem, since the daemon would likely run as root?

Does anyone know how I can store a username/password for a SMB share running as root? Or some alternative so I can run the backup when no one is logged in? The machine in question is a multi-user system and usually there is no one logged in when the backups should occur.

dnanian 10-03-2007 01:22 PM

A daemon isn't going to change this kind of thing, no... but you can pre-mount a volume yourself using cron...

All times are GMT -4. The time now is 10:54 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2022, vBulletin Solutions, Inc.