How do I recreate OS9's perfect backup system with the new OSX clients?

[FortuneCreative]

Well, I'm currently backing up 36 clients and have been using the same, practically flawless backup system for 7 years, with Retrospect fullfilling the key component. Autoshutdown is the key capability on the client end. I'm dealing with artists, here, and "Shut Down your computer and walk away" was absolutely perfect. As it is now with your OS X client, you can't even put the computer to sleep or the backup will fail. I just don't understand how I'm supposed to alter my backup system to accomodate the OSX client's inadequacies in this regard.

 

My current system:

artists keep their completed work in one folder, work in progress in another, shut down their machine before leaving each night, leave the macintosh on the "waiting for backup" screen saver

each computer is hit three times per night: once for completed work into a file backup set, once for completed work to DAT tape, once for work in progress to DAT tape

after the third and final backup of the night, the client machine shuts down (especially nice for Fri. night)

monday or tuesday I'll extract the "completed work" from the file backup sets, and burn two CD's of everything, one copy kept offsite. (now mind you, we are talking about 10 to 15 gigs a week)

 

This system works flawlessly, is almost completely automated, and as long as the artists keep their files in one of the two folders, I can recover from any accidental deletions, ommission, or file corruptions.

 

Without the autoshutdown you're boxing me into an unpleasant corner. I either:

 

A. change the average on-time of each machine from 5 days, 10 hours a day to 24/7 (a tremendous waste of power)

 

B. change the time of day the backups occur, which may be when the artist is working (not good, currently open files will get backup errors, crashing of the client machine could occur unexpectedly while the artist is working causing loss of who knows how much productivity, or artist may think the unresponsiveness of client machine during backup is an impending crash and force-restart the machine in the middle of the backup process, massive network activity would disrupt overall company productivity right in the middle of the work day {it currently happens off-hours}, current "end of day backup of everything done that day" would change to "backed up sometime during the day, may or may not be able to recover the file for you depending upon when that day or previous you were working on the file", etc)

 

C. manually initiate every backup after verifying that it won't interfer with the artist (108 manual backups, daily, ouch)

 

D. start having the artists save all of their work to a central server, in which case, what the hell would I need Retrospect for?

 

 

Please, show me the error of my ways, or at least suggest a system that would work with the OS X client. I just don't get it.

[CallMeDave]

Quote:

---

I'm dealing with artists, here, and "Shut Down your computer and walk away" was absolutely perfect. As it is now with your OS X client, you can't even put the computer to sleep or the backup will fail. I just don't understand how I'm supposed to alter my backup system to accommodate the OSX client's inadequacies in this regard.

 

---

 

Certainly OS X is a very different beast then Classic Mac OS is (was). There are no Extensions, and perhaps it is not a trivial matter to run code that will interrupt the OS shutdown routine (I'm not a programmer, I'm just wondering). Apple would have to support something between Log Out and Shutdown. But what if they don't/won't?

 

As for backing up a sleeping Mac, the OS X Client is a unix daemon, and these daemons go to sleep when the Mac does. So the only way to manage that would be to wake up the machine. I did see some program on VersionTracker a while back that was supposed to be able to wake up machines on the LAN if you knew the IP address _and_ the hardware MAC address, but the description said it would only work on NICs with particular firmware. So that would only be a solution for the newest machines (or possibly machines with compatible after-market network cards).

 

That leaves the possibility of simply shutting down a running Mac after a successful backup. But since OS X is a true multi-user environment, what if someone else is logged into the machine (the Sharing preference pane shows lots of ways to log in remotely)? And what about open documents, etc (the unix "shutdown" command will do just that, but it won't care about what applications are doing or what documents are open).

 

If you have a well constructed physical network you could at least try and do backups during the day You don't know if Client slowdown will be an issue, and you _certainly_ should be teaching your users that you don't need (or want) to force restart OS X everytime it seems to slow down (while Darwin does sometimes require a restart it's the applications that are almost always at fault when things go haywire).

 

OS X doesn't currently include a Startup/Shutdown Energy Saver setting the way Classic Mac does, but using cron you could write a shell script that shuts the computer down at a preset time. With AppleScript Studio you could pretty easily write a GUI front end that would count down the time to shutdown. Not nearly as nice as auto-shutdown after backup, but might help save some kilowatt hours if you set it up for Friday nights.

 

Having the OS X Client gracefully shut down an OS X machine after a successful backup would be a Very Good Thing. But the issue seems complicated. Dantz is going to have to come up with some well thought out methods to satisfy everyone.

 

Dave

[FortuneCreative]

Thanks for the suggestions, Dave. I'm gonna try to track down that network/wake from sleep application. I'm only planning on moving people over to X full time if they have a Dual 800 or better, so that may be a viable solution.

 

Anyone else with suggestions, replies are still welcome...

[mcswgn]

In my opinion, with the new energy saver Macs, you don't really want someone to shutdown under MacOS X, just to log out. If it weren't for the fact that the Macs go to sleep so thoroughly that they won't wake up to get backed up, that would be the end of it--no need for autoshutdown. But they do go into comas now, so that's where the "Wake-on-Lan" capability comes in.

 

If you go into the "Energy Saver" system preference pane and click on the Options tab you will know whether a Mac supports "Wake-on-Lan" by whether it has a check box that says something like "Wake for Network Administration". I don't remember exactly, and right now I'm sitting at a b&w G3 that DOESN'T support it :-P This option needs to be checked for it to work.

 

To wake up a remote Mac that supports it you need software that will send the magic packet. There are Mac GUI utilities available to do this (which I know because I was just looking at a couple a few days ago, but can't for the life of me find them again now). However, I have been playing with wakeonlan-0.40, <http://gsd.di.uminho.pt/jpo/software/wakeonlan/> which is a command line tool in perl. It is intended for linux but "make"d fine under OS X (at least with the Developer Tools installed). I like the command line tool because I can put my known hardware ethernet addresses in /etc/ethers and then wrap wakeonlan with a shell script that substitutes the name of a client for its harware address.

 

The real question is how to get Retrospect to work with such a utility and I have been pondering that question for a few days. It seems like Retrospect needs some additional Event types, like a volumeBegin event (it has a volumeEnd event now). If such an event existed you could add to the Retrospect Event Handler (in an "on volumeBegin" section) an instruction to send the magic packet to wake the remote client and then pause (this would seem to be necessary as there appears to be a significant delay between when the magic packet is sent and when the Mac has fully revived, had a cup of coffee, and is ready to talk to the world again).

 

Come to think of it, that wouldn't really work since if the Mac is asleep, the Backup Server will skip it when it does its polling so it would never start the volume. I guess it would need a "clientNotResponding" event included information on the next scheduled backup so you could decide whether to wake it up or pass over it.

 

I can think of a few work arounds, none of which are good. The easiest would be to run a cron job that would issue "wake up calls" to clients on the network at specific times during the night. E.g., client A at 6pm, client B at 6:30pm, etc. and hope that each client finishes before the next client goes to sleep again. You could do the same thing within retrospect if you associated a client or small group of clients with separate scripts. If the scripts were arranged to run so they didn't overlap, then the instruction to wake up the client (or the group) could be put in the "on scriptBegin" (or is it scriptStart?) handler. A third aproach would be to put the instruction to wake up the NEXT client in the "on volumeEnd" handler of the PREVIOUS client, but that would depend upon being able to dictate ahead of time the order in which the Backup Server went around to the clients. Like I said, not a good solution in the bunch...

[FortuneCreative]

Don't know if you work for Dantz, Dave, but until or unless I recieve an "official" response, I'll debate the issues with you.

 

 

"Certainly OS X is a very different beast then Classic Mac OS is (was). There are no Extensions, and perhaps it is not a trivial matter to run code that will interrupt the OS shutdown routine (I'm not a programmer, I'm just wondering). Apple would have to support something between Log Out and Shutdown. But what if they don't/won't?"

 

I'm not following you, here. The OS 9 Retrospect client kindof does a fake shutdown anyways. Network volumes are still retained, it seems, until the full shutdown after backup. The OS 9 client just blacks out the screen, and sits there waiting for backup. Why can't Dantz do the same thing in X? You don't need to "interrupt the shutdown routine", just have Retrospect request the shutdown after the backup is complete. Maybe you would launch the Retrospect client and then initiate shutdown there, rather than from the Apple menu. Can't AppleScript perform such an action? If the shutdown fails because opened files couldn't be saved, etc., at least that would occur AFTER backup, and the "user error" would be immediately apparent the next morning. It may happen occasionally, but would not be a "deal killer".

 

"That leaves the possibility of simply shutting down a running Mac after a successful backup. But since OS X is a true multi-user environment, what if someone else is logged into the machine (the Sharing preference pane shows lots of ways to log in remotely)? And what about open documents, etc (the unix "shutdown" command will do just that, but it won't care about what applications are doing or what documents are open)."

 

With the potential procedure I mention above, this would not be an issue. The user would initiate a Retrospect monitored "shutdown", from within the Retrospect client software. I think the vast majority of Macintosh Retrospect clients are individuals with individual workstations, not multiuser environments, simply from the fact that OS 9 was weak in that regard. Retrospect could simply check for running applications, just like installers do, or just warn the user when they choose the Shutdown option from within the Retrospect client.

 

"If you have a well constructed physical network you could at least try and do backups during the day You don't know if Client slowdown will be an issue, and you _certainly_ should be teaching your users that you don't need (or want) to force restart OS X everytime it seems to slow down (while Darwin does sometimes require a restart it's the applications that are almost always at fault when things go haywire)."

 

This just isn't a viable option. People will have files open that they are currently working on. You're taking an automated process and making it totally manual and monitored. Currently, if an artist wasn't in, Retrospect skips right over them when the backup scripts run that evening. With the current OS X client, if the artist wasn't in that day, their computer would have to be manually restarted in order to backup the work they did the day before. Maybe not a big deal for small businesses, but we are in a 450,000 sq. ft. facility. Many of these Macs are a 10 minute round trip walk from my desk. Also, some of the artists work from 6 AM to 3PM, some work 9AM to 6PM. Currently, they know immediately when they walk in whether backups were successful the previous evening. Even if I don't show up to work for another 2 hours after they do. If the Dantz screen saver is on their monitors when they come in, they know backups failed for some reason or another, and to be extra careful that morning about trashing files, Save As's, and whatnot. With this OS X client, they would ALWAYS be uncertain about what was backed up and when. Again, Dantz has taken a perfect backup system and completely thrown it out the window.

 

"OS X doesn't currently include a Startup/Shutdown Energy Saver setting the way Classic Mac does, but using cron you could write a shell script that shuts the computer down at a preset time. With AppleScript Studio you could pretty easily write a GUI front end that would count down the time to shutdown. Not nearly as nice as auto-shutdown after backup, but might help save some kilowatt hours if you set it up for Friday nights."

 

Anyone with over 30 clients using Photoshop heavily knows that some days backups will be quick, sometimes it'll take hours. Specifying a shutdown time is not a good solution. Currently, the OS 9 client patiently waits until all backups that need to occur, have occured, then it shuts down. Each computer according to it's own backup schedule and backup success. Again, a perfect system.

 

"Having the OS X Client gracefully shut down an OS X machine after a successful backup would be a Very Good Thing. But the issue seems complicated. Dantz is going to have to come up with some well thought out methods to satisfy everyone."

 

Amen to that, brother. Have they just not thought this through? Are they leaving the Macintosh users behind? Wouldn't this be doable with a little AppleScript support? I've yet to receive an official response from a Dantz technician regarding what THEY expect their users to do. Other than a reply months ago from a similar inquiry, in which the Dantz technician stated "we are considering implementing".

[AmyJ]

At this time Retrospect can not wake up a sleeping OS X client or wait at shutdown for a backup. Dantz is investigating the best way to add this type of feature in a future release.

 

 

[mcswgn]

I think you're missing the forest for the trees--

 

Could Dantz setup something like they have for system 9? Absolutely--Unix is much easier to configure in that regard. I could do it myself and I'm no wizard. BUT, it wouldn't do you any good because while it was waiting to be backed up it would go to sleep and then that's the end of it. Retrospect can't wake it up to do the backup once it's asleep! That's what AmyC is talking about, and until that's solved everything else is a moot point.

 

 

[FortuneCreative]

Quote:

---

I think you're missing the forest for the trees--

 

Could Dantz setup something like they have for system 9? Absolutely--Unix is much easier to configure in that regard. I could do it myself and I'm no wizard. BUT, it wouldn't do you any good because while it was waiting to be backed up it would go to sleep and then that's the end of it. Retrospect can't wake it up to do the backup once it's asleep! That's what AmyC is talking about, and until that's solved everything else is a moot point.

 

 

 

---

 

Well, actually, I have my Energy Saver control panel set to "Never", and so would most of my workstations. It most certainly would NOT go to sleep waiting for backups, unless the user made the error of designating a sleep time.

 

So, will the Retrospect client backup register as "Activity" on the system, and the system will start it's count of "inactive time frame before initiating sleep mode" from the point of backup completion? I mean, the menu bar clock's constant activity falls "below the radar". Or is it really a question of "interactivity", counting from the last registered mouse movement or keyboard input? I guess that is definitely a question for a Dantz technician to handle. Anyone?

[mcswgn]

Quote:

---

So, will the Retrospect client backup register as "Activity" on the system, and the system will start it's count of "inactive time frame before initiating sleep mode" from the point of backup completion?

 

---

 

I don't know what in general is considered inactive. However, my experience is the following. A client will definitely go to sleep (if set to do so) when doing the usual thing of just waiting to be polled. That is, backup client active but not currently in the process of being backed up. It will not go to sleep when actively being backed up. On the other hand, I have frequently seen what appears to me to be a client *immediately* going to sleep on finishing a restore. (Restore and not backup because I don't sit at a client waiting for a backup to finish unless I'm actually working on it, in which case it won't go to sleep. But I do often roll a troublesome client to my office--where the server is--while I work on it and so am sitting there very impatiently while it restores.) It's almost as if the sleep timer runs and expires even though the system is "active" (from the stand point of proccess activity, but not from keyboard/mouse activity) and as soon as the system activity stops it goes right to sleep.

 

You know, if your machines are set to never sleep, you could rig up shutdown via remote apple events from inside the event handler. I've never tried to send applescript commands to another computer, so although I know it's possible, I don't know what the issues are to get it to work--except I know it has to be enabled on the remote machine in the Sharing preferences pane. I also don't know what the security issues are.

 

Alternatively, you could do it from the unix side by sending a remote shell command from inside the event handler. That I'm more familiar with, so here is a cookbook recipe:

 

I am assuming that each client has only one volume. If not, you would need to figure out how to know when a client's last volume was finished so you didn't shut it down after just the first one. OK, so for this there are basically three broad steps that need to be completed.

1. enable remote commands on the client

2. create a means of mapping volume/client names to IP names

3. modify the Retrospect event handler to send the shutdown after a volume ends

 

1. enable remote commands on the client...

 

On the retrospect server (logged in as the user that runs retrospect) use the console to run ssh-keygen to create a public/private rsa key pair with empty passphrase. For example:

 

[kyodai:~] mcswgn% ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/Users/mcswgn/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /Users/mcswgn/.ssh/id_rsa.

Your public key has been saved in /Users/mcswgn/.ssh/id_rsa.pub.

The key fingerprint is:

59:e9:75:36:09:34:9d:aa:cc:a1:77:02:b0:a3:81:d9 mcswgn@kyodai.csm.uc.edu

 

Rename the file id_rsa.pub to authorized_keys:

 

[kyodai:~] mcswgn% mkdir clientfiles

[kyodai:~] mcswgn% mv .ssh/id_rsa.pub clientfiles/authorized_keys

 

Make a file .shosts having one line of the form: <Retrospect_server_name> <user_running_retrospect>

 

[kyodai:~] mcswgn% echo "kyodai.csm.uc.edu mcswgn" > clientfiles/.shosts

 

Now go to the client and do two things

a. In the Sharing preferences pane, under the Services tab, check the box for "Remote login"

b. Copy the files created earlier to the following locations

/private/var/root/.ssh/authorized_keys

/private/var/root/.shosts

 

These last two steps would be a lot of work for someone with lots of clients. You could possibly ask the users to do (a). That's pretty straight forward. As for copying the files, you could probably use Retrospect to push them to the clients, or at least put them on a server so they are handy if you have to walk around to each.

 

At this point you should be set up to send remote shell commands to the clients as root without the need for a password! Clearly, each person would need to consider the security ramifications of that. At minimum the Retrospect server would need to be in a restricted location, as anyone who sat down at the server while the retrospect user was logged in would be able to act as root on any of your clients. However, if your clients are not set to read only, then that's true anyway! So this hasn't made it any less secure, it's only made it maybe a little more convenient.

 

In any case, see if it works by sending some commands from the server to a client (laurel, in this case):

 

[kyodai:~] mcswgn% ssh -l root laurel touch /tmp/ItWorked

[kyodai:~] mcswgn% ssh -l root laurel ls -l /tmp/ItWorked

-rw-r--r-- 1 root wheel 0 Feb 7 09:46 /tmp/ItWorked

[kyodai:~] mcswgn% ssh -l root laurel rm /tmp/ItWorked

 

2. create a means of mapping volume/client names to IP names or numbers

 

This could be tricky depending on your setup. Clearly Retrospect knows the (current) IP number of the client, but it ain't gonna tell. Inside the volumeEnd handler, however, there is a variable theClient that holds (duh!) the client name. If your client names happen to be the same as their IP names, you are home free. If not, you would need to either change the client names or set up a translation file. In either case, you would need to rely on the clients having either a fixed IP name or fixed IP number. (So if you use DHCP, you would need the DHCP server to pay attention to the ClientID field and to put the clients in the DNS system with the same name every time. If not, I suppose you could work out a much more complicated system based on an on-the-fly discovery of a client's IP number from it's known subnet and hardware ethernet number. Yuck!)

 

I will assume the client names don't match and so translation is necessary. Create a file /etc/RClients with lines of the form: <Retrospect_Client_Name> <IP_name_or_number>. The following command would then do the desired translation:

 

sed -n 's/client_name //p' /etc/RClients

 

3. modify the Retrospect event handler to send the shutdown after a volume ends

 

In the Retrospect Event Handler (assuming the volumeEnd portion is not commented out) insert the following lines just before the line "end volumeEnd":

 

set clientIP to do shell script "sed -n 's/" & theClient & " //p' /etc/RClients"

if theClient is not "" then ¬

do shell script "ssh -l root " & clientIP & " shutdown now" --skip clients not in database

 

Notice this will not be very friendly--shutting the system down even if the user is still logged in. It should really have the shutdown command wrapped with another if statement that checks for some telltail process on the client to see if they are still logged in (what process would that be? I'm not yet that familiar with the MacOS X specific unix parts) and then only do the shutdown if no one is logged in. If someone can suggest an appropriate process I will modify the above to make it more friendly.

 

If there is more than one volume per client you could force the script to do the volumes in a specific order, I guess. You could then use the variable theVolume instead of theClient and make the translation file be from volume name to client IP name, with only the volume that is to be done last for that client put in the database. Hmm, sounds kind of iffy.

 

Whew! That's a lot longer than I thought it would be when I started. Let me just insert the obligatory disclaimer--

 

Since I have no desire to shutdown my own clients, I don't plan on testing this. Therefore, take appropriate precautions! If anyone does try it, though, I would be curious to know how it went.

 

[FortuneCreative]

Quote:

---

 

I don't know what in general is considered inactive.

 

 

---

 

 

You, my friend, are a genius! Unfortunately, I'm not. Another difficulty I have with your suggested scheme is that my server is running OS 9, not X. Good to know regarding the activity/inactivity behavior of the clients, though. That gets me one step closer. It handles one inadequacy of the Dantz client.

 

Also, anyone know the name of that software Dave mentioned? I've scoured VersionTracker, but I'm coming up empty.

 

Thanks

[mcswgn]

Quote:

---

Another difficulty I have with your suggested scheme is that my server is running OS 9, not X.

 

---

 

Well, I know it's possible to send remote apple events and that would work for a MacOS 9 server to MacOS X client. That, however, I have no experience with.

 

Quote:

---

Also, anyone know the name of that software Dave mentioned? I've scoured VersionTracker, but I'm coming up empty.

 

---

 

Unfortunately, the only ones I know (and which include two on version tracker) are MacOS X only:

Wake 550 0.5

WakeUp 1.0

 

I haven't used either of these. I use wakeonlan-0.40, which is perl and you *can* get perl for OS 9, but I have no idea whether the libraries it uses would be there. Also, you need to "make" it as it comes, even though it is really just a very short perl script. There is a good chance that if the MacOS 9 perl supports the network libraries, then the script would run fine if already made on another machine (like one of those MacOS X clients).

[FortuneCreative]

Thanks, everyone, for all your help. The fact that end-users are providing more support in these forums than Dantz technicians really reflects the unbound spirit of the Macintosh community.

 

It's clear to me from the scarcity of "official" responses that Dantz is not interested in providing solutions anymore. I guess they've been corrupted by the easy money of Windows software sales, a world where "barely adequate" is acceptable. Dantz already has my money, right? Why should they care. I was perfectly happy with Retrospect 4, and upgraded to 5 solely to gain OS X client support. In the process I lost $500, all my previous client licensing, Appletalk client support, and gained absolutely nothing!

 

And the answer is.... D! (from my original post) "start having the artists save all of their work to a central server, in which case, what the hell would I need Retrospect for?"

 

Fortunately, with Apple's new Xserver and Xserver RAID providing 2.5 terrabytes, gig ethernet, etc., I can get an almost perfect solution for around 15K. This is a mind-boggling amount of storage for the price, and as RAID5 it has built-in redundancy. I'll probably need to run a tape backup of the XServer's most recent data, but definitely will have options beyond Retrospect for controlling the tape drive. No OS X client necessary. Done and done. Goodbye, Dantz. You've been a trustworthy solutions provider to my Macintosh needs for 13 or 14 years now (anyone remember the Bernoulli drive?). How or where you lost sight of the golden path you were on, we may never know (could've been; management, marketing, development, Q and A). But somebody not only dropped the ball, they punted. Any of you programmers out there with half a brain (hopefully the right half, but some left is always a good thing), this is a brand new, wide open market. Somebody jump into the pool and show these fools how it's done!

[Mayoff]

Quote:

---

Thanks, everyone, for all your help. The fact that end-users are providing more support in these forums than Dantz technicians really reflects the unbound spirit of the Macintosh community.

 

 

 

It's clear to me from the scarcity of "official" responses that Dantz is not interested in providing solutions anymore....

 

---

 

 

 

Actually this is not true. No one posts more messages on the forum server then Dantz Employees. You will see the list of top posters in the Entrance . Dantz Employees have also replied to this thread.

 

 

 

Because the forum gets an average of about 400+ posts in a week, it is impossible for us to address every post from users. This forum offers community-based support for Retrospect and other Dantz products. This is not an official means of contacting Dantz support. If you have an urgent question or would like to discuss your Retrospect problems with a Dantz technical support representative, please go to:

 

 

 

http://www.dantz.com/support/contact.html

[FortuneCreative]

Quote:

---

Actually this is not true. No one posts more messages on the forum server then Dantz Employees. You will see the list of top posters in the "enterance". Dantz Employees have also replied to this thread.

 

Because the forum gets an average of about 400+ posts in a week, it is impossible for us to address every post from users. This forum offers community-based support for Retrospect and other Dantz products. This is not an official means of contacting Dantz support. If you have an urgent question or would like to discuss your Retrospect problems with a Dantz technical support representative, please go to:

 

http://www.dantz.com/support/contact.html

 

 

---

 

Thanks for the link, Mayoff.

 

Of course the employees will have more posts than the users. I was talking about help. "Dantz is considering adding this feature" does not help. It sounded more to me like she was trying to head this discussion off at the pass, because there is no current solution to this issue, and she could see that nothing positive could result (from Dantz's perspective). The other two participants were indeed helpful, and at least did not convey to me that they were Dantz technicians, just concerned citizens (of the highest order!)

 

I posted this in the forum because I thought a reasoned, responsible response from a Dantz technician may clear the air for your entire user base. I think the other posters to this thread have backed up my original issue, which was "what exactly does Dantz expect us to do?" Retrospect had a well established modus operandi when it came to their client/server backup solution. By eliminating auto-shutdown, you've essentially thrown that established (and very well respected) solution right out the window. I specifically outlined my issue in the initial post (over a week ago). It seems to me this is a software design deficiency (of the highest order!), not one for technical support. Apparently I'm right about that, too, considering you are the second technician to toss off a quick response without actually contributing to the discussion.

 

Look at it this way, if Adobe put out an OS X version of Illustrator, charged $500 for the upgrade, and the software had a capability equivalency of Illustrator 88, I think some people would be slightly peeved.

[CallMeDave]

Quote:

---

And the answer is.... "start having the artists save all of their work to a central server, in which case, what the hell would I need Retrospect for?"

 

---

 

All that valuable data in a single location means a single point of failure. Fire in the server room? Mechnical failure of two members of the RAID 5 set? Server administrator error? All those things scream for multiple copies of the data, both on-site and off.

 

If you can find another product that will support the tape drive you use, can schedule the oprations and do incremental backups to those tapes it will surely be worth considering. But to maintain that because the Client software that Dantz released for a brand new operating system doesn't contain the exact same feature set as the client that was (and still is) available for an older operating system then it's a giant step backwards is just plain silly.

 

Dave

[FortuneCreative]

Well I'd be more than happy to stick with OS 9 for the next year or so, until you guys can get your act together. Unfortunately Apple is seriously pushing. The last 12 machines I bought from Apple will boot into OS 9, but they did not provide an OS 9 system installer disk. That means when things get weird all my usual OS 9 troubleshooting steps take 5 times longer than they did. Apple will let you "restore" OS 9, but only onto a disk that has OS X on it. This means the average number of files on the drive go from under 10,000, to over 100,000. Things like running DiskWarrior, Disk First Aid (or the automatic disk check upon restart after a crash), rebuilding the desktop, all take 10 times longer than they did before. And if I need to reinstall OS 9, you have to boot into X, off of the same HD, then run the "restore" CD's, then after rebooting into 9 you have to reconfigure everything because it was a restore, not a reinstall. Not to mention we really need to be running X to take full advantage of these dual processor machines. All of this is screaming "SWITCH TO X!!!" Unfortunately a backup solution just isn't there for X.

 

Believe me, I understand the risks of central servers. However, you still have done nothing to suggest exactly what your software designers envision as the end user's approach to Retrospect backups when using OS X. So you've ridiculed my choice of D. Yet you haven't offered any solutions. Do I go with A (leave all of my workstations on, all the time)? B (backup while the users are working)? A terrible solution. C (manually coordinate every single backup to avoid interfering with local workstation activity)? Yeah, right. You are offering a product, but you are not offering any solutions. To go back to my earlier Illustrator reference, it's like you've offered a postscript drawing application without including a pen tool. And can we really consider OS X "brand new", anymore? Surely you were provided with advanced info, if not copies of the beta, even before the Public Beta which was released almost two years ago. Surely your software designers didn't think forcing people through the series of hoops such as "mcswgn" suggested (which was still inadequate for a variety of reasons, although very creatively thought out) couldn't possibly be considered a backup solution.

[CallMeDave]

Quote:

---

So you've ridiculed my choice of D. Yet you haven't offered any solutions.

 

---

 

I did no such thing. I ridiculed your over-reaction to one missing feature of software written for a new OS. Especially in light your your understanding of how Apple is pushing/positioning this software; they don't want you to turn the machines off. That's why the took the power keys off the keyboard!

 

 

 

>Do I go with A (leave all of my workstations on, all the time)?

 

Up to you.

 

>B (backup while the users are working)? A terrible solution.

 

Possibly. Possibly not. You haven't tried.

 

>C (manually coordinate every single backup to avoid interfering with local workstation activity)? Yeah, right. You are offering a product, but you are not offering any solutions.

 

DANTZ offers a product with abilities and limitations.

 

>To go back to my earlier Illustrator reference, it's like you've offered a postscript

>drawing application without including a pen tool.

 

Is it? Is it really? That's the ridiculous part. A Post Script drawing application without a pen tool would be like a backup application that had no client support at all. Or did not allow backing up to CD or tape.

 

>Surely your software designers didn't think forcing people through the series of hoops

>such as "mcswgn" suggested (which was still inadequate for a variety of reasons, although

>very creatively thought out) couldn't possibly be considered a backup solution.

 

The Dantz Forum guide said that they're looking at adding this feature in a future version.

Kind of how Illustrator88 didn't have layers, or mesh, or warp tool, or symbols, or so many other features that were added to its basic pen tool as the program matured.

 

Dave

[shadowspawn]

Quote:

---

A. change the average on-time of each machine from 5 days, 10 hours a day to 24/7 (a tremendous waste of power)

 

---

 

If you want suggestions for right now, I vote for A, and it is what I am doing with my clients. Since I have mixed Mac/PC clients, and the shutdown-after-backup had never been an option with the PC clients, it wasn't a big deal.

 

Set the Energy Saver so the monitor goes to sleep, the hard disk goes to sleep, but the computer does NOT go to sleep. This hopefully reduce the "tremendous" waste of power to merely irritating. :-)

 

Tell Mac OS 9 clients: shutdown and walk away

Tell Mac OS X clients: logout and walk away. (Some people will need reminding when you notice they are not getting backed up, the shutdown and walk away gets fairly ingrained!)

[belkind]

The current OS X client can't shutdown the system, the Dantz programmers haven't yet figured out how to get around some understandable problems with the new OS.

 

But from the point of view of energy saving it would be enough to *put the computer to sleep*. It would also be not that disrupting if somebody actually using the computer.

 

Putting to sleep must be easy, e.g. following AppleScript (unfortunately Retrospect Client for OS X doesn't support AppleScript) does the thing

------------

tell application "Finder"

sleep

end tell

------------

 

Also, RetroClient could switch off/put to sleep only if nobody is logged into computer. Then the user would log out but not switch off at going home, and find his computer off or sleeping in the morning.

 

I do really hope, Dantz improves this situation in a *free* update.