Jump to content
brentsallee

Very Slow Performance under Retro 8

Recommended Posts

Yes, just a rough idea. For many of us running business here, it's of vital importance to know that one needs to find a "workaround" for one week, one month or three months.

 

In any case, a big Thumbs Up, Dear Robin, for your constant patience and time you spend in answering all our questions ....

Share this post


Link to post
Share on other sites
However your argument is slightly flawed in that Retrospect is not a brand new product and therefore using brand new routines that still need optimising, it is version 8.1 and has been using the same cataloging design for over a decade and has been offering poor performance for many, many years.

The product might not be new, but the code base is. Retrospect 6.x and its predecessors were based on a Mac Classic PowerPC code base, ported to the Carbon API, emulated under Rosetta on Intel architecture.. That's why it had to be scrapped to get a native Intel program. Retrospect 8 is a complete rewrite, starting from the Retrospect Windows code base. The GUI interface was scrapped to use the Leopard APIs, and the engine, being so close to the OS syscalls, is almost a complete rewrite from the Windows codebase. That's why the stability is not good, hopefully will improve as the code matures. Even so, when it stabilizes, some serious attention could (and should) be paid to the algorithms used and to whether the program can be factored into parallel execution units for multiple cores. Right now, even though multiple backups can be run concurrently with Retrospect 8, each backup is not split into concurrent execution paths. Hold on to your seats if/when that is done, because that's when the real difficulty comes for reliability if it's not done right by programmers with extensive experience in parallelism. Say what you want, but this is a completely new pile of, ahem, code.

 

Note: I have used Retrospect for over 20 years.

That's an interesting claim considering that Richard Zulch's patent on which the product is based (Zulch, U.S. Patent 5,150,473 (issued Sept. 22, 1992)) was only filed on January 16, 1990. Might seem to present a possible statutory bar on that patent's validity if you have been using the product for over 20 years (depending on how many months "over" 20 years the product was out).

 

You have me beat because I have only been using it since 1992.

 

Russ

Share this post


Link to post
Share on other sites

Retrospect started life as Diskfit, which we were using to back up our huge (40MB) SCSI drives to floppy disks in the mid 80's. If I remember correctly, it was an application written for SuperMac for to back up their hard drives (old age and memory might be a factor in some lack of precision here). It evolved and matured into Retrospect over the years.

 

Share this post


Link to post
Share on other sites

Actually Retrospect and Diskfit never shared any code. Diskfit did come first, but Retrospect came a little after. both existed together for a few years.

Share this post


Link to post
Share on other sites
Actually Retrospect and Diskfit never shared any code

 

From TidBITS # 97, December 1991:

http://www.tidbits.com/tb-issues/TidBITS-097.html#lnk3

 

For those of you who haven't heard the history, Dantz originally developed a backup program, DiskFit, for SuperMac many years ago. It shipped with all Dataframe hard drives from SuperMac, but when SuperMac decided to concentrate on the graphics business, it sold the rights to DiskFit back to Dantz. Dantz cleaned it up a bit, made sure it was System 7-compatible, and recently released it as DiskFit Pro.

 

DiskFit Pro is a perfect example of a focussed program. It defines its purpose clearly and narrowly, and it performs that task admirably. DiskFit Pro tries to be a fast, easy backup program for people who have better things to worry about than backing up. DiskFit Pro isn't in the same class as Dantz's high-end backup and archiving program, Retrospect, but it doesn't try to be. The main things that Dantz added to DiskFit Pro include a DiskFit Pro Reminder Control Panel that can remind you when to back up and some interesting features to that help deal with the proliferation of aliases in System 7.

Share this post


Link to post
Share on other sites
What you are saying is interesting : around 110 MB/m seems to be the max. speed. I wonder where this "limitation" is coming from ? Version 6 under Windows was doing around 500 MB/m ..... both to tape and to disk.

 

 

Seems to be a problem with the clients. As a further test I have just used Carbon Copy Cloner to clone a client to a spare volume on the server. It ran at 1.5GB/min.

 

If freeware can get it right, how difficult can it be? :-)

 

Whilst I appreciate Retrospect don't have to respond to this forum, they must be listening and it would be nice if they did!

Share this post


Link to post
Share on other sites

Hi everyone,

 

Has anyone who previously posted their performance here with a retrospect version <= 8.1.150 Tried with the latest build(8.1.525)? I would be interested to know if there have been any positive or negative changes.

 

-Jeff

 

--Edit: Graham,

 

I personally, have not seen such low performance with my setup. I have however, seen many posts about this subject, and an investigation is in progress.

Edited by Guest

Share this post


Link to post
Share on other sites

I'm getting about the same performance as I was before the most recent update (around 400-500MB/min) using a dual 1.25 G4 to back up to an LTO3 tape library (SCSI PCI-Express card), only counting what the console describes as the copy speed, not counting catalog updates at the end of the entire backup, mostly because I have yet to reach the end of an entire backup, since I'm attempting to back up 2-3TB volumes to tape and the last version didn't seem to be able to copy files past the second tape in a set.

 

I like the sound of concurrent backups all getting a "full-speed" of 120MB/min after catalog updates, but it's definitely frustrating to go from a single-task speed of 800-1000MB/min to the possibility of multiple tasks at one-tenth the same speed. I don't quite have 10 clients to back up concurrently, but if the speed ratios hold, I might end up setting up multiple proactive scripts to multiple different media sets to get the same volumes of data backed up in the same time-frames as before, just by making sure they all happen at the same time.

 

Definitely a possibility I hadn't considered before, but I'll have to make a determination once I get through the full backups.

 

Other stories? Anyone tried more than 2 or 3 concurrent tasks?

Share this post


Link to post
Share on other sites

Please, please, let's get it to be reliable first. It doesn't help if it "crashes fast" or very quickly produces unusable backups that can't be restored.

 

A backup program should "just work". Getting it to work faster should be the second (or fifth) order of business, not the first. Retrospect 8 is not, by any stretch of the imagination, production quality software yet, probably not even beta quality yet (at least by the standards I used to have back in the days when I wrote software).

 

Russ

Share this post


Link to post
Share on other sites
09-08-09 03:35 PM - Post#127765

 

In response to Graham

 

We hope to have an update by some time next week.

Robin Mayoff

Senior Manager, Retrospect Tech Support

Retro-Talk, KB & Forum Admin

 

March 2010 and we are still waiting for Retrospect 8 slow network issues to be fixed. I wonder if EMC will extend my extend my "Annual Support and Maintenance"... I don't feel I've got my moneys worth this year. Retrospect 8 (so far) is a dog.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×