scheduling an unattended backup on MacOSX server
 

I am looking for a backup solution for MacOSX server. We want to schedule backups on the server with SuperDuper!. Unfortunately the manually tells this is only possible when the user is logged in. We don't want to leave any user logged in to execute a backup. Is there any option to circumvent this limition? Apart from this it SuperDuper! suits our needs.

You have two choices. You can have an unprivileged user logged in with the screen locked (using a password protected screen saver), or you can install and schedule as root.

The first one is not an option. I don't want to login each time the server reboots to have backups.

Will the second option still work if the server reboots and nobody logs in as root user ?

Thanks.

Yes: at least in Panther and Tiger, root's crontab runs when no one is logged in, and root has access to the screen, so SD! will run.

Schedule SD! as root?
 

Are we talking about:
1. Logging in as the root user and creating a schedule in the SD! UI
2. Creating a launchd script to run as root or something else...?

I'm running Mac OS X Server 10.4.8

Logging in as the root user and creating a schedule.

It worked
 

No users were logged in and the log shows it ran as scheduled. Thanks.

Glad I could help, caleban, and that the solution worked. :)

Do OS X client backups still require a user logged in with the screen locked?

It's as it has "always" been.

This response is a bit too cryptic for me, unfortunately, and I really need to know the answer; I need an fully unattended backup solution.

• Can I schedule an unattended SD! backup on MacOSX 10.4.10 by scheduling it as "root"?
• For security reasons I really would prefer not to login as root; I don't currently have it enabled for interactive login sessions. Since it sounds like it's an issue with the cron job privileges, would either of the following work?
  • setup the backup schedule through the GUI client using my normal login; move the crontab entries to the root crontab manually; or
  • run the SD! gui client as root using sudo (not sure whether the difference between effective and actual uid would matter)

thanks,
Pete

You'll need to log in as root and schedule that way. You can then disable root login again.

After I scheduled a backup with SD! launched as root, I noticed that I could not unmount the destination FireWire drive. Even after I deleted its schedule. Even after I removed its cron task for the root account manually (why did the latter hang around after deleting the schedule?) with CronniX 3.0.2 <http://h775982.serverkompetenz.net:9080/abstracture_public/projects-en/cronnix/>.

Why won't something "let go" of my FireWire HD, what is that something, and how do I unmount it, so I can swap-out drives for my rotating backups?

Thanks!

I don't know: if you look at open file references with lsof, do you see what process has the drive active?

Thanks for the prompt reply!

That's a good idea to correlate a process with a volume, which ought drastically to narrow-down the possibilities for the culprit process.

I haven't yet gotten back over to the server site to try it yet, but when I ran lsof here, I was overwhelmed by its complexity: There's a "DEVICE" column, which seems the only candidate for which hard drive volume, but it has an unintelligible name, e.g., "14,2" instead of the actual name. Is there another Unix command that will cross-reference that obscure device number with the actual name of the hard drive partition?

I looked around the more user-friendly Activity Monitor, but couldn't find a way to show a drive volume column.

Are there any other GUI utilities that will do what I need to track down what's not letting me unmount a hard drive that's ever been scheduled with SD! ?

This occurred the very first time I installed SD! and set up a schedule. Am I the only person this has ever happened to?

Thanks!

And why does the cron task for the root account not get removed when the SD! schedule is deleted?

Yes, this is something we've not heard of. Scheduling doesn't really do anything that might lock a volume.

Try running something like:

I believe it does when you quit SD.

75-94-82-80:~ george$ sudo lsof | grep "The-Volume-Name"

WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
75-94-82-80:~ george$


So nothing came up. I'm still not out at my server site, but rather did this on my laptop, but I would think that it would have listed processes associated with my bootup drive, no? ("Macintosh HD")

Any other ideas, or syntax, or a GUI utility?

--
<SeinfeldParaphrase>
These (Unix) pretzels are making me thirsty!
</SeinfeldParaphrase>

>> And why does the cron task for the root account not get removed when the SD! schedule is deleted?

> I believe it does when you quit SD.

I'll repeat the exercise when I go back out to the sever site, then report back here, but I vividly recall quitting, SD!, restarting, and having to download CronniX to inspect root's crontab, and having to delete the task.

Do you mean that you used the name of your boot volume in the place of "The-Volume-Name" on the command line? If so, that likely will not display anything because the name of the boot volume does not show up the POSIX paths that lsof displays (the boot volume is just "/").

My preferred lsof invocation is sudo lsof /path/to/volume/root. For the boot volume this would be sudo lsof / (which will probably print out something from every process on the system!). For most other non-boot volumes it looks like sudo lsof /Volumes/mountedVolumeName. If the volume name has spaces or special characters in it, it will need to be quoted (try putting single quotes around it, which will work as long as the volume name does not have any single quotes in it; or just use the shell's filename completion by typing enough characters to disambiguate the name and then hit TAB, it will automatically escape any special characters for you).

You can test it out by creating a little sparse image (or using any disk image you might have laying around). Mount the image and open a Finder window to the volume itself or some folder in it. Then run the lsof command. You should see an entry for Finder displayed.

Good advice from Chris... although the problem here wasn't that the boot volume couldn't be ejected (that's pretty obvious).

Rather, you need to actually substitute your volume name for "The-Volume-Name".

Ahh, yes. I missed that interpretation. I thought maybe gmachen was testing out the lsof | grep … command using the boot volume name on the laptop as a "trial run" before getting back to the server. But the copy-and-paste of the Terminal output could have been verbatim (not a "sanitized" version) meaning the grep was searching for a made-up volume name.

Just to be completely clear, are you saying that scheduling SD! launched as root via sudo from a regular admin account (with the root account login access remaining disabled) would not work, but rather one actually has to login as root?

If so, I'd be academically curious as to what's the difference. Thanks!

I'm pretty sure that running with "sudo"ed root permissions but from a login session as another user won't set your Home and other items to that user's account for graphical apps.

Please forgive me if I'm beating a dead horse (I think some of us - myself included - are just trying to take the easier way out if it'll only work):
- Not sure what is meant by "won't set your Home and other items to that user's account for graphical apps." You mean setting permissions correctly?
- But in any event, it may be moot: Remember, we're not talking about actually running a backup from a sudo-launched SD!; we're only so launching SD! to set-up the *schedule*, then quitting, and overnight letting the schedule run the backup as root while the login window is up with no accounts open. Will solely setting the schedule under SD! launched via sudo work?
Thanks! (When we get all this ironed-out, maybe it could go in the official FAQ for server administrators.)

No, I don't think it will, as I said.

Dave Nanian obviously is preoccupied with this week's stellar release of SD! 2.5, yet to his credit still finds time to work the forums as best he can, bless his heart! Although he understandably doesn't have time for extended technical tomes on the complexities of Unix.

So I'm wondering whether there are any other Unix experts out there who can explain the - what to me - are very surprising putative differences between doing things in sudo as opposed to formally being logged-in as root, which arise from the security needs by network administrators to clone Mac OS X Server drives while logged-out.

I'm academically curious as to why:

- If the SD! scheduling (only!) is done under sudo while logged-in to an admin account, instead of while logged-in to the root account, it "won't set your Home and other items to that user's account for graphical apps." Does this mean it won't set permissions correctly? I really don't understand: What difference does it make what account the clone is done from if SD! is making, well, a clone, after all? I would think that all account assignment settings already had been made when things originally were installed. What am I missing?

I'm really surprised by this! When I launch other apps under sudo, they seem to think & act like they're in the root account:
- Such apps' plist preferences go into the root account's Library/Preferences folder.
- With Finder launched as root, moving something to the Trash goes to the root account's Trash folder.
- Etc., etc. I trust you get the idea.

I just need to understand the rationale behind some of this Unix stuff, even if I haven't been through the some seven years experience I'm told it takes to really get a handle on Unix. I'd like to think that our utilities' GUI shells on top of Unix put the power of Unix also in the hands of the slightly less technically sophisticated.

Thanks!

If that's the case, then it might work (as I said, which is why I don't "think" it'll work). It's worth a try: it's just not something I've tested, since this general configuration, which it might work (run as root), isn't something we encourage...