Server backups

[Graham_C]

I'm using a scheduled backup on an Xserve in a small company. This script needs to run regardless of whether there is any user logged in, and definitely when there is no administrator logged in. As I understand it this is possible by setting up the crontab for user 'system' or 'nobody', but I'm having problems doing this. Super Duper's script appears to hard code a path to the logged-in user's (admin) library. I'm also unclear how to move a script between crontabs for different users - I tried using a GUI utility called Cronnix but it would not let me move a script between users.

My boss is breaking my balls over this especially having coughed up the registration fee, so please help!

[dnanian]

Log in as the "root" user and install/configure SuperDuper! as that. Schedule it as well, and the entry will be placed in the root/system crontab.

[Graham_C]

Originally Posted by dnanian

Log in as the "root" user and install/configure SuperDuper! as that. Schedule it as well, and the entry will be placed in the root/system crontab.

OK, I will try that. Would I then be able to disable the root user again and still have it work?

[dnanian]

Yes, although the root user typically isn't disabled on a server.

[afterhours]

Originally Posted by dnanian

Log in as the "root" user and install/configure SuperDuper! as that. Schedule it as well, and the entry will be placed in the root/system crontab.

I've been trying to isolate a problem with SD backing up an Xserve 10.4.9 OSXS install. SD continues to run with the SDcopy daemon spooling in the /System folder. (at about 133k of 225k files). Have attempted to edit the script (smart backup/bootable -- what SD calls backup - all files) to ignore logs in the /Library/ and /var/etc/ folders.

Any thoughts on additional filters to use?

[dnanian]

I'd use lsof to determine what file is causing trouble (sudo lsof | grep SDCopy)...

[afterhours]

Originally Posted by dnanian

I'd use lsof to determine what file is causing trouble (sudo lsof | grep SDCopy)...

Thanks -- good suggestion.

~ root# sudo lsof | grep SDCopy
SDCopy 1702 root cwd VDIR 14,3 1190 2 /
SDCopy 1702 root txt VREG 14,3 248660 401669 /Applications/SuperDuper!.app/Contents/MacOS/SDCopy
SDCopy 1702 root txt VREG 14,3 81316 1628 /System/Library/CoreServices/CharacterSets/CFUnicodeData-B.mapping
SDCopy 1702 root txt VREG 14,3 352454 1626 /System/Library/CoreServices/CharacterSets/CFCharacterSetBitmaps.bitmap
SDCopy 1702 root txt VREG 14,3 17688 1627 /System/Library/CoreServices/CharacterSets/CFUniCharPropertyDatabase.data
SDCopy 1702 root txt VREG 14,3 528384 401872 /Library/Caches/com.apple.LaunchServices-0140.csstore
SDCopy 1702 root txt VREG 14,3 9839648 235722 /usr/share/icu/icudt32b.dat
SDCopy 1702 root txt VREG 14,3 1797576 242123 /usr/lib/dyld
SDCopy 1702 root txt VREG 14,3 4406292 327788 /usr/lib/libSystem.B.dylib
SDCopy 1702 root txt VREG 14,3 512476 327789 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
SDCopy 1702 root txt VREG 14,3 4607412 327848 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
SDCopy 1702 root txt VREG 14,3 1227624 327790 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
SDCopy 1702 root txt VREG 14,3 1455656 327893 /usr/lib/libicucore.A.dylib
SDCopy 1702 root txt VREG 14,3 801160 327797 /usr/lib/libobjc.A.dylib
SDCopy 1702 root txt VREG 14,3 3436108 327791 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
SDCopy 1702 root txt VREG 14,3 859516 327793 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
SDCopy 1702 root txt VREG 14,3 3137640 327841 /System/Library/Frameworks/Security.framework/Versions/A/Security
SDCopy 1702 root txt VREG 14,3 1012892 327819 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
SDCopy 1702 root txt VREG 14,3 590292 327846 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
SDCopy 1702 root txt VREG 14,3 394264 327842 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
SDCopy 1702 root txt VREG 14,3 1205064 327894 /usr/lib/libcrypto.0.9.7.dylib
SDCopy 1702 root txt VREG 14,3 1145612 327991 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
SDCopy 1702 root txt VREG 14,3 894980 327798 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
SDCopy 1702 root txt VREG 14,3 3755152 327799 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
SDCopy 1702 root txt VREG 14,3 4707056 327845 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
SDCopy 1702 root txt VREG 14,3 10859300 327847 /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
SDCopy 1702 root txt VREG 14,3 769892 327902 /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
SDCopy 1702 root txt VREG 14,3 2226644 328009 /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
SDCopy 1702 root txt VREG 14,3 345360 328195 /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
SDCopy 1702 root 0r 0x02f78e30 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 1w 0x021202e0 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 2w 0x02f78be0 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 3r 0x02f78600 file struct, ty=0x3, op=0x383768
SDCopy 1702 root 4r 0x02f78730 file struct, ty=0x3, op=0x383768
SDCopy 1702 root 5r 0x02f78d90 file struct, ty=0x3, op=0x383768
SDCopy 1702 root 6r VREG 14,3 5425091 235690 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/Extras.rsrc
SDCopy 1702 root 7r VREG 14,3 6657 401823 /Applications/SuperDuper!.app/Contents/Resources/SuperDuper!.rsrc
SDCopy 1702 root 8u unix 0x022af8f0 0t0 ->0x022af7c0
SDCopy 1702 root 9u unix 0x022af7c0 0t0 ->0x022af8f0
SDCopy 1702 root 10r VREG 14,3 137827 3453 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/HIToolbox.rsrc
SDCopy 1702 root 11r VREG 14,3 498430 3371 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc
SDCopy 1702 root 12r VCHR 8,1 0t560 30568836 /dev/urandom
SDCopy 1702 root 13r 0x0240f6f0 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 14r VCHR 8,0 0t16 30568964 /dev/random
SDCopy 1702 root 15w 0x02f782b0 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 16r 0x02f785e0 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 17w 0x02408490 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 18r 0x02f78410 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 19w 0x02389cb0 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 20r 0x02389750 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 21w 0x02120360 file struct, ty=0x6, op=0x3823ec
SDCopy 1702 root 22u VREG stat(/private/tmp/tmp.CQ2fxr): No such file or directory
SDCopy 1702 root 24r VDIR 14,3 102 32664 /System/Library/User Template/English.lproj/Desktop
SDCopy 1702 root 25r 0x02120280 file struct, ty=0x3, op=0x383768
SDCopy 1702 root 26r 0x02f78e80 file struct, ty=0x3, op=0x383768
SDCopy 1702 root 27r VDIR 14,5 102 67177 /Volumes/b/System/Library/User Template/English.lproj/Desktop


Asid from some missing directory issues, I don't see a problem. However, I haven't fully ruled out stupid admin tricks like not starting with a clean destination. let me get a clean drive and see what happens.

[dnanian]

You'll want to see if things are getting stuck there over time, too. Might well be a damaged source or destination...

[afterhours]

OK -- that solved it. The backup drive had been used by other systems and at other times. Using DU to erase the drive was sufficient to permit a full successful backup of the Tiger server.

Thanks for the suggestion to get me thinking again!

BTW, throughput: 8.5 Gb in just under 15 minutes, roughly 2 min/Gb. That's the complete drive cloned, not an incremental, with filters for all logs and cache (and the normal filters in a backup) in play. A second test (running just the normal smart backup without additional filters) evaluated 226k files, moved 380 Mb, took 3 minutes. Both drives are SATA in the Xserve bays, SD running in the Root account.

You've mentioned before that SD can be set to run scheduled, in the root account, and things progress just fine without the server console logged into any one account, right? We'll try it later tonight.

[Graham_C]

Originally Posted by dnanian

Log in as the "root" user and install/configure SuperDuper! as that. Schedule it as well, and the entry will be placed in the root/system crontab.

OK, this is working, but there is a new problem. When the backup completes, it launches the Super Duper application. Since there is no GUI shell actually open at the time, this puts the system into a weird state where Super Duper runs OK within itself, but cannot be Quit. The only way to recover the system is to do a full reboot, meaning I have to do this every morning after the backup has run.

I can't see any setting to stop Super Duper from being launched after the script has run. How can I just let the script run quietly and not launch Super Duper?

[dnanian]

When it completes? It's running while it's copying, Graham...

[Graham_C]

Originally Posted by dnanian

When it completes? It's running while it's copying, Graham...

OK, maybe that's true. I'm not here when it does it, it's the middle of the night. The point is that Super Duper is launched and that screws up the server requiring a reboot to make it (locally) usable. I need the backup to run with no GUI or at least if it has to open a GUI then it needs to close it all down again afterwards. The aim id to get backups runnign with no human intervention required of any kind. At the moment we are a long way from that.

[dnanian]

It should do that, Graham, unless there's an error.

Again, doing this "root" thing is relatively unsupported. As I've likely said in this thread, and certainly in others, you're better off creating a non-admin account -- which you can lock down as much as you'd like -- and leave that logged in. Schedule SD! in that account, unlocked with an admin password...