Should I upgrade from version 6?

[ecolebilingue]

What I'm doing these days is backing up Mac user home folders to a file based backup. I have a Drobo diskpack for storage.

 

I am constantly frustrated by Retrospect v6. It constantly gets stuck on a loss of the network connection with the client. It can't detect this and just move on. Many clients show in the log as "not visible on network" yet when I browse the network in Retrospect, I see them. I constantly get corrupted catalog files. Rebuilding sometimes helps.

 

My questions is whether I should upgrade or not. From reading this forum, it doesn't sound like all is perfect in Retrospect land. 10 days to get a response to a support ticket is not acceptable.

 

I'm trying to avoid going to rsync scripts but that sounds more reliable at this point.

 

Crashplan looks ok but it's easily four times the price of Retrospect. I'm not sure what other products to investigate.

 

What other products should I look at?

 

[Maser]

Why not try Retrospect 8? You get 30 days with a "trial" license, IIRC...

 

If you don't like it, evaluate something else?

 

(However, if you are having some kind of network problems, Retro 8 may not work any better than Retro 6 does...)

 

 

[Daniels]

Have you made sure your clients do not go to sleep since I have found this to cause a loss of communication between Retrospect and the client?

I have made sure to set all my clients to never sleep or ever put the hard drives to sleep and I very rarely experience a loss in communication.

[twickland]

It constantly gets stuck on a loss of the network connection with the client. It can't detect this and just move on.

Retro 6.1 isn't supposed to get stuck and if it's behaving correctly, it should log a 519 network communication failed error and move on after 5 minutes or so. It may be that the Retro.Config file has been corrupted, or it may be an issue with the client app.

 

If you'd like more advice on this angle, post your question in the "Desktop, Workgroup and Server for Mac OS X " forum.

[ecolebilingue]

Thanks for the comments. We have no network issues. And machines are not going to sleep.

 

Usually this issue happens with laptop users. I think it typically happens when a user leaves the office or closes the lid of their laptop during the backup. Retrospect just sits there trying to "retry" and never gives up.

 

Is their a way to check the timeout setting in the config file? Is it just a text file?

 

 

[rhwalker]

Is their a way to check the timeout setting in the config file? Is it just a text file?

No. No.

 

If you'd like more advice on this angle, post your question in the "Desktop, Workgroup and Server for Mac OS X" forum.

Here is the link for the Retrospect 6.x forum:

Desktop, Workgroup and Server for Mac OS X (Pre-8.0 versions)

 

And, when you repost, it would be very helpful to provide some specifics:

 

(1) exact version of Retrospect 6 (6.x.x)

(2) exact version of Retrospect client (x.x.x) that sees the problem

(3) hardware and Mac OS X versions for affected computers and Retrospect server

(4) whether this is seen on all clients or just some, and the differences for those clients.

(5) some information about your network infrastructure

 

Russ

[dcomiskey]

If v6 is running fine for you, there really is no reason to switch. And given that some of us are STILL having major issues with v8.x 5 months after release and despite several "updates," I'd encourage everyone to stay away from this nightmare. It remains THE buggiest piece of software I've used in 15 years.

[ecolebilingue]

Thanks. That is the kind of feedback I'm looking for. I noticed that nobody said "go for it!".

 

Version 6 is working but I have to babysit it too much for my tastes.

 

I will demo version 8 since it's a free download. I also want to demo Crashplan Pro. Though it's 3X more expensive, it sounds like it's much more compatible with a mobile fleet of computers.

 

[Maser]

I have no problems with 8.2. I rely on it fully at this point.

 

But I don't use tape.

 

I don't backup to a NAS or Drobo.

 

And I don't have a server with an Apple RAID card hosting the engine computer.

 

I back up about 60 10.6.4 and Windows 7 clients -- most laptops -- (and 3 10.6.4 server machines) using 8 concurrent proactive scripts to an External firewire RAID drive and I groom a media set weekly (and groom other media sets on a once-every-5-weeks schedule.)

 

I use custom rules and no encryption on my media sets.

 

For me, it's working as I expect it to work (with the exception of some esoteric bugs I've recently discovered/verified). Some things could be faster (and a *lot* should be rewritten -- I'm talking to *you* Roxio about improving the reporting/browsing of what actually gets backed up -- , but I'm satisfied with the product at this point to do what I need it to: back up everything daily and easily restore files when I need to recover them.

 

But, I am not you.

 

I can only say "try the free demo and see if it works for you." It would be remiss of anybody to imply you shouldn't also try other products and buy them if they work better for you. Retrospect 8 is basically a brand new product with an old name. You shouldn't think of it as an "upgrade" to Retrospect 6.

 

I would never revert back to Retrospect 6 at this point. It would be impossible to function without the ability to do concurrent backup/restore -- especially with all the laptops I have in my area. Grooming is just icing on the cake.

 

Those two functions alone -- and they work -- make me overlook some of the (significant) shortcomings.

[amkassir]

Maser, I was encouraged by your post.

I use custom rules

 

One concern I have is the report by Daniels in this thread. It seems to indicate the presence of some serious bugs in the creation of rules. On the other hand, your post seems to indicate that you've had no problems with custom rules.

 

Right now the main reason I haven't tried 8.2 is the report of broken rule-making, and I'd like to hear your experience. I'm still using version 6 under Leopard, and haven't made the leap to Snow Leopard yet for the single reason that version 6 cannot properly restore Snow Leopard system files.

[Maser]

The rules I needed to make -- work. I'm not sure what more I can tell you about them. IMO, starting clean with 8.2 is better than trying to work with something that wasn't working properly in 8.0 or 8.1

 

I do agree there are some oddities with rules (setting some things seem to change unexpectedly, but I'm not sure how much of that is to force you into the logic you need to follow.)

 

If you have a rule question, I can try to answer how I do it (or how I might do it).

[Gorbag]

I'll second Maser's comments. I've had 8.x since 8.0, and had a lot of problems until the 8.2 update. Things seem to be stable now, but part of the key was wiping everything clean (including past backups!) and starting over when 8.2 was released.

 

I do use rules, and I guess the key is to figure out how to do what you need with the rules that don't cause a problem (see the various threads in the bug reports section) and you won't have a problem. Sounds trite, I know, but until they fix the rule engine to support at least what the UI seems to allow you'll have to stick with pretty simple things.

 

Good luck!

[Daniels]

Since I was able to build my rule off of a pre-defined one I was able to work around the rule issue. If you can keep the rules as simple as possible you should not have any problems. Even if you have a complex rule you might want to think about breaking it up into multiple rules as a work-around.

Since I could never get 8.1 to work I basically started clean with 8.2 and other than a few inconveniences which are mostly related to out-dated hardware it has been working successfully for me the last eight months.

Also closing the lid on a laptop is the same as putting the machine to sleep so I not surprised that you get an error in these cases.

[twickland]

...until they fix the rule engine to support at least what the UI seems to allow you'll have to stick with pretty simple things.

Actually, we've managed to create some pretty complex rules. Our normal backup rule, designed to exclude a whole raft of different files, currently has over 50 different conditions and subconditions, including multiple "All" conditions. Getting to this point was neither easy nor straightforward, however.

 

A couple of hints:

• You can't create an All condition at the top level of "Include" or "Exclude" (at least, we've been unable to to so). For an "All" condition, you need to create a new condition under "Any" and then incorporate your subconditions under this new condition.
• When creating a complex set of conditions, Retropect will sometimes change the subconditions under previously-created "All" conditions. These changes range from promoting subconditions to a higher level, to deleting them entirely. The solution is to keep scrolling up and down the rule as you edit, correcting and recorrecting the undesired changes that Retrospect has made. Following this iterative process, we were finally able to achieve the rules we wanted

 

In our experience, a rule, once saved, remains stable; they have only changed unexpectedly for us when we were in the process of actively editing the rule.

 

[rhwalker]

Since I could never get 8.1 to work I basically started clean with 8.2 and other than a few inconveniences which are mostly related to out-dated hardware it has been working successfully for me the last [color:red]eight months[/color].

That's very interesting because Retrospect 8.2 beta 1 was released on June 10, 2010 (4.5 months ago), Retrospect 8.2 beta 2 was released on June 29, 2010 (4 months ago), and Retrospect 8.2.0 (build 399) itself was released July 27, 2010 (three months ago).

 

Russ

[Daniels]

I was given an Alpha build of 8.2 towards the end of February/beginning of March since I could not get 8.1 to stop crashing during a backup.

[rhwalker]

I was given an Alpha build of 8.2 towards the end of February/beginning of March

You are either a brave man to use that in a production environment or your data is not very important.

 

Russ

[Daniels]

Having something is better than having nothing which is what was happening with 8.1

[rhwalker]

Having something is better than having nothing which is what was happening with 8.1

That's not true with backup software. Or perhaps my data is more precious than yours. Because of our backup policy and data retention needs, I can't afford to move to a backup solution until that solution is rock solid.

 

"Something" may be corrupting data on which you depend, and you won't know about the corrupted / missing data until years down the road when you need it.

 

Backup software is in an entirely different class from games and "normal" applications. It's database software, and you can't go back in time to get something that doesn't exist any more because of defects in the software. The bar is very high.

 

No backup is better than unreliable backup. At least with no backup, you know where you stand and adopt other options.

 

Russ

[demani]

Russ: A) how do you know if something is reliable? You check it. It is entirely possible for an Alpha build to be reliable for a specific use, assuming testing is done to verify that.

 

If you are waiting on rock-solid, then you must not be using v8 at all. If you are, well, then see A.

 

 

[rhwalker]

Russ: A) how do you know if something is reliable? You check it. It is entirely possible for an Alpha build to be reliable for a specific use, assuming testing is done to verify that.

Yep. Extensive pre-deployment testing against our requirements.

 

If you are waiting on rock-solid, then you must not be using v8 at all.

Not yet for production use. Yep, you are right. It's never passed our isolated testbed tests. Much time wasted (well, not wasted because our data hasn't been exposed). Thorough testing takes lots of planning and time. Backup on an isolated testbed, restore to isolated systems, etc., test usage. Much disappointment.

 

Note that we only back up to tape. It may or may not work for disk-only or optical media backups - I haven't tested those because they are not part of our backup policy.

 

And, even if (when) Retrospect 8 becomes solid, we can't use it for production until it is scriptable to coordinate with external events (coordinated stop/checkpoint/start of services for backup). Hope springs eternal ...

 

Russ

[Daniels]

I forgot to mention I also use only tapes for backups so I was more interesting in getting the program to work properly than be left with no backup at all. The main reason I was given the Alpha build was to test the PowerPC platform since 8.1 would not even get through a backup before crashing the engine.

[ecolebilingue]

I'm glad I could start such a great discussion. What do people think about upgrading to the Windows version of Retrospect server instead of going to the new Mac version. We are mostly a Mac network but do have windows and unix servers. I don't really care what platform the backup software runs on as long as it's reliable.

 

[Daniels]

I have be running 7.6 Multi-server for Windows since it came out and it works really well. I have found 8.2 to be stable but it sounds like I am one of the few who have actually had success with it. I have not upgraded to 7.7 for Windows since I don't need the added options however I have heard there are a few problems with it but most of these seem to deal with Exchange Servers. If people are worried about stability and/or reliability with 8.2 I would definitely suggest giving 7.7 for Windows a try.

[anothersmurf]

I strongly recommend sticking with 6 if possible. I've found that it runs best on old hardware and old versions of the OS. (I've got a G5 running 10.4 just for Retrospect 6.) It works for modern clients, but unfortunately I don't think you can still buy Retro 6 licenses.

 

The only other Mac server-based backup solution I know of is BRU. Last time I looked at it, I found it unacceptable because it lacked security features, but there's since been at least one major update so perhaps that's been addressed. The more I use Retrospect 8, the more inclined I am to give BRU another chance.