Really, Retrospect 8? You're THAT bad?

[brewster71]

I'm finding Retrosopect 8 a real disappointment. I use it at several clients and the results have been all bad.

 

I'm trying to back up an office of 40 laptop users who are always on the go. They live in 2010 and thus have laptops that sleep a lot and are on and off the network several times a day. I'd expect Retrospect to be able to handle this...but no.

 

I have all the staff in one backup script, but of course all the staff arent always in the office. Is it true that when a rarely-present user is in the office, and I want to back up their computer, that I have to create a whole new backup script? Really, Retrospect? I can't just select them in the current script's Sources and hit "Backup Now" or something similar?

 

Also, it seems at any given time that at least 5 of the users just stop backing up.

 

And occasionally, it will start to back up one user and hang indefinitely. That user will leave the office with their laptop, but Retrospect will just hang for days on that person, with the message "Building Snapshot". I hit "STOP" and it asks me if I really want to stop. I click yes. It doesn't stop. It just stays stalled. It doesnt even move onto other users.

 

And really - I managed five or six clients with high volume (15-40 users). Do you really need to shut me out of managing a backup machine over the network because my laptop's version of the manager app doesn't match the version of the engine of the server? Then make me download two different pieces of software EVERY time? You're really gonna make me go through that once a month? What if I want to update it later? Too bad. I just get shut out.

 

Honestly, this software is so inconsiderate of it's users, I find it appalling.

 

Mac OS: Server 10.5.8 and 10.6.3

Retrospect versions. 8.x

[CallMeDave]

I have all the staff in one backup script...

 

Is it really a Backup script, and not a Proactive Backup script?

 

Do you really need to shut me out of managing a backup machine over the network because my laptop's version of the manager app doesn't match the version of the engine of the server?

 

If it's critical for you to support multiple versions of the Engine there's no reason you can't maintain multiple matching versions of the Console application. At this point, expecting different versions to _always_ communicate (as opposed to sometimes communicating) is unrealistic and frankly unfair. If changes are made to both, why would you expect either to remain backward/forward compatible?

 

Then make me download two different pieces of software EVERY time?

The Sparkle auto-download steps are poorly thought out, and the web link only allows for a complete download. But nothing is _making_ you do anything; you can decline the auto-update and just visit the webpage, if you'd rather. I do hope someone there (um, Eric?) recognizes what an awful user experience the whole update process is and works to fix it. They meant well, I'm sure, but it's a big fail.

 

You're really gonna make me go through that once a month?

Now _that's_ funny! Once a month; LOL!

[brewster71]

At this point, expecting different versions to _always_ communicate (as opposed to sometimes communicating) is unrealistic and frankly unfair

 

I don't expect it to always communicate. I'll settle for 60% of the time. Every other piece of remote management software I have that has (Server admin, Remote Desktop, etc) works perfectly well without having to upgrade both versions every time there's a dot upgrade. Retrospect doesn't, and in not doing so, it comes off as clumsy, antiquated, and unfriendly.

 

you can decline the auto-update and just visit the webpage, if you'd rather

 

Yet, I can't use my software or access any information on it unless I update it. Lame.

 

The Sparkle auto-download steps are poorly thought out

 

They were thought out? :confused2:

 

Any word on how to immediately backup one source or do I need to check if it's a proactive backup or not? Does it matter? I'm upgrading the server that the version of Retrospect is on or I'd tell you. I didn't set this particular script up, so I'm not sure which it is.

 

All I do know is, I couldnt even use Retrospect to back up the server I'm about to upgrade because Retrospect was hung up trying to back up another user's machine who isn't even in the office.

 

But that's probably an unrealistic expectation...

[hkumagai]

After reviewing the posts about Retro 8, it looks like I am not alone cursing it out.

 

My Retro clients' status show up as "Backup Interrupted." It has backed up tiny bits of some clients, and none of others, in the past month. My theory is that backups are proceeding so slowly that it exceeds the time laptops are in the office. They each have their own Proactive job. They are all Mac, running the latest client software.

 

I don't really see any meaningful logging or history either. And if there is, it's not in a visible place.

Edited April 13, 2010 by Guest

[CallMeDave]

I'll settle for 60% of the time

 

I assume then you've already done the math here, noting how many builds of the Retrospect Engine have dropped, how many builds of the Retrospect Console application, and how many have required version-matching?

 

Perhaps once the product has matured further, updates to one component that don't require updates to both may become the norm. But for now, supporting disparate versioned Engines won't be as elegant as if they're all in the same Console window, but it's only a 53 MB package.

 

I can't use my software or access any information on it unless I update it. Lame.

Not sure what "it" is in your context, although the use of "update" suggests that you're talking about needing to bring the version of the Engine up to the level of the Console you're running remotely. This is the administrator-centric view of the world; instead you could (as the administrator) fall back to a version of the Console that matches the existing Engine, providing you with access to your information without impacting the server or its current schedule(s) at all.

 

I need to check if it's a proactive backup or not? Does it matter?

Proactive backups were conceived (back in the 20th Century) for users with 2010 habits. If you don't know if you're taking advantage of this (one of Retrospect's strongest suits) then my attempts at fully answering will be inadequate. Yes, it matters.

[brewster71]

:coolness:

If you don't know if you're taking advantage of this (one of Retrospect's strongest suits) then my attempts at fully answering will be inadequate. Yes, it matters.

 

Yeah, like I said,

 

1) this is one of many clients I have and

2) I didn't set up the script and

3 the server is now in the middle of an upgrade and I can't look at Retrospect.

 

So, if it does indeed matter whether the script is proactive or not, then that infers there is a way to actually do an immediate backup from a source to a media set. How?

[CallMeDave]

if it does indeed matter whether the script is proactive or not, then that infers there is a way to actually do an immediate backup from a source to a media set.

 

I tried to be careful not to make inaccurate statements, as I'm not using Proactive Backup Scripts in Retrospect 8 (and features available in Retrospect Classic are not all present in the new product). So while I may have indeed implied some specific capability, what I was trying to convey is that Proactive Backup Scripts may allow your Backup Plan to proceed satisfactorily without needing to ever manually trigger any specific action.

 

Perhaps Steve will contribute, as he's been using Proactive since the beta. In the meantime I'd suggest reading the newly released User Guide; it has lots of information about how to leverage this capability.

 

 

Dave

[Maser]

Since I was namechecked and having read the thread...

 

1) If you are backing up 40 laptops, you *should* use a Proactive script. I'd probably suggest 2-4 Proactive scripts backing up to separate media sets (if you have enough RAM on the engine machine to run concurrent activities).

 

The multiple-laptop scenario is *exactly* why you use proactive scripts and not "backup" scripts.

 

2) There is a bug in 8.1.626 (you didn't explicitly say you were running this version, but you should be) where the console can sometimes not update itself. It may be that the activity had stopped, but the console didn't say so. Sometimes quitting the console and restarting it can show you the current status.

 

Otherwise, doing a "stop" can take up to 10 minutes to stop if there is some problem with the activity.

 

3) You said at one point they "each have their own Proactive job".

 

If you actually have *40* proactive scripts running -- that will kill the engine and it's not surprising that you aren't getting backups.

 

How much RAM does your server have? I find that with 4G RAM, I can get at most 5 activities running at once.

 

 

4) If you want to do an *immediate* backup of a client -- you use the big "Backup" button and run the Wizard. However, if the media set is in use, you have to stop any other backup going to that media set.

 

But, as in #3 above, if you actually have *40 proactive scripts* running, you won't get that thread to sneak in easily.

 

 

I recommend you stop the engine, restart it and actually take a look at the scripts to see what's going on.

 

 

[CallMeDave]

If you actually have *40* proactive scripts running -- that will kill the engine

 

The Original Post(er):

 

[color:purple]I have all the staff in one backup script

[/color]

The thread was hijacked in Post#137544, a different member reporting without adequate explanations.

 

Brewster Brownville has put in the effort to get answers; I'll focus on those for now.

[Maser]

The thread was hijacked in Post#137544, a different member reporting without adequate explanations.

 

Brewster Brownville has put in the effort to get answers; I'll focus on those for now.

 

 

 

Whoops -- missed that. It was late. I was tired.

 

 

But, yes, having *too many* proactive backup scripts causes problems. There's probably a sweet-spot for how many proactive scripts vs. amount of RAM available vs. what type of CPU you run that could be correlated.

 

All I can confirm is that having 40 proactive scripts on my 4G RAM intel Mac mini -- pretty much killed it when I tried it.

[Maser]

But, that said, with 40 clients in one proactive script, it's not likely you'll necessarily be able to backup one client "immediately" by changing the "schedule" of the client.

 

You might get better luck if you delete the last (working) activity for that client -- that seems to reset the client to "ASAP" (a Retro 6 term) and that will prioritize that client in the proactive script higher.

 

 

But, with 40 clients -- if matching *all* clients is not a requirement -- I'd still recommend breaking the clients into 2-4 different sets backing up to different media sets.

 

But it depends on what you are backing up whether or not "matching" will make a significant difference.

[brewster71]

Thanks for the feedback, guys.

 

To clarify: I am using a single Proactive Backup script, with about 50 *members*. Not 50 scripts. It's a 2008 MacPro, with 4GB RAM. Most of the processor time is spent between iCal Python processes and Retrospect.

 

I also tried a Restore today of a 10MB folder, and it took about 5 mins to scan the Backup Set to present me with my options of "what to restore" and "where to". I clearly selected the folder I wanted restored, clicked the checkbox next to it, then selected the destination (a empty folder I'd created just for the restore). Then the Restore failed (?), with the message:

 

No files need to be restored

4/26/2010 3:18:35 PM: Execution completed successfully

Duration: 00:00:01

 

4) If you want to do an *immediate* backup of a client -- you use the big "Backup" button and run the Wizard.

 

Ok, this is just plain embarrassing. Not sure how I missed that - oh wait, yes I am: I'm a moron.

 

 

 

 

 

Edited April 26, 2010 by Guest

[bioheath]

I have 61 proactive backup scripts set to run every other day and it works pretty well. Every 10 days or so I need to stop and start the engine process in order to keep the console GUI responsive, but the engine itself never hangs.

 

The 61 proactive backup scripts + 9 backup scripts point to 44 media sets. The clients are split about 40% windows, 60% mac with 1 linux client.

 

The server is a dual quad 2.8GHz Mac Pro with 6GB RAM. After running for about 10 days the active memory for the engine process on the server consumes about 1.5GB RAM at idle (real) signaling the need for a restart of the process (and a slew of patches, but I digress).

 

Just FYI. Nothing profound to contribute.

[dcomiskey]

Yes, OP, it is THAT bad. And I'm pretty angry there has not been ONE update for this program in months. I, too, cannot stop a script without having to reboot my server (which, you know, I'd rather not do during the work day!). I have random problems with my tape library (even with bar codes, which barely helped my issues). All we are doing is a daily incremental with a weekly rotation and a monthly full. Pretty damn simple. yet, as of now, I have no backups since last Wednesday now because "all of a sudden" my tape library keeps faulting out while retro is moving tapes (and, btw, is now stuck in "moving" a tape for the 6th time this week and I can't fix it other than a reboot).

 

There are so many complaints on here about Retro 8, but I get the feeling the folks at Dantz couldn't care less at this point about fixing them. This is by far one of the buggiest programs I've ever used. Unfortunately, the enterprise backup options for OS X are so slim that this is almost the only "option" now.

[Mayoff]

We will soon be releasing a public beta with well over 300 bug fixes. This version is being used successfully at several large private beta locations.