Lengthy Scan Times

[grs007]

I'm just wondering if anyone else is experiencing 20 minute scan times to backup small portions of the start-up volume. I get almost the same results across the network as well. I support other backup solutions that perform the identical scan in under a minute both locally and across the LAN. Anyone experience any better scan performance ?

 

Server is PowerMac dual Quad Core 3ghz with 6gb RAM, and sata 250gb startup volume is RAID 1 WD's (not dogs) with 146gb in use. Retrospect version is 6.1.230, client is 6.3.027 and I have tested this with the 8.1 trial version of Retrospect with identical results.

 

I would be very interested in hearing from anyone else with feedback on the scan performance (which directly relates to backup performance).

 

As an aside, I've scanned through the 12 pages of 'release notes' for version 8.2 and even though I understand everything I read, I became dizzy. My hats off to the development staff that worked on this release, I hope this isn't just a list of complaints, but a list of bugs that were addressed. Having been SW QA manager for a large corporation I know what it takes to maintain SW, and that's a mouthful of release notes. Looking forward to further enhancements on the leading backup solution.

[rhwalker]

This has been discussed at length in these forums over the years.

 

Because of the design of Retrospect, it does a full recursive tree walk of the filesystem tree, then passes the list of files to the filters ("selectors", now known as "rules" in Retrospect 8) to decide which files will be candidates for backup, and then, after sorting that huge list (one of the reasons that Retrospect needs lots of RAM) so that it can be evaluated against the contents of the backup set (f/k/a/ "storage set" in the early versions of Retrospect, now known as "media set" in Retrospect 8 new-speak), uses the "matching" criteria (whether files changed from versions in the backup set, etc.) to decide whether the files are to be backed up in the current session. All of that takes time - it's CPU intensive, I/O intensive, and RAM intensive.

 

Such a strategy was fine when volumes were small and didn't have gazillions of files.

 

The only way around it with the current design is to segregate your changing files into Retrospect "subvolumes" ("favorites" in Retrospect 8 new-speak) so that only those "subvolumes" get scanned (by the magic of Unix "chroot" - see the man page for details ("man chroot" in Terminal, without the quotes)).

 

And don't expect Retrospect 6.1 to change - it's dead, Jim.

 

Russ

[grs007]

The only way around it with the current design is to segregate your changing files into Retrospect "subvolumes" ("favorites" in Retrospect 8 new-speak) so that only those "subvolumes" get scanned (by the magic of Unix "chroot" - see the man page for details ("man chroot" in Terminal, without the quotes)).

 

And don't expect Retrospect 6.1 to change - it's dead, Jim.

 

Russ

 

Russ,

 

Thanks for the suggestion of subvolumes, that sounds totally workable. I love scanning the 'System folder' when all my client wants to backup is his documents. I look forward to testing 8.2 to see the results.

 

As far as Retrospect 6.x, I kinda figured that out when they came out with version 8.x but thanks for the reminder.

[rhwalker]

I look forward to testing 8.2 to see the results.

The Retrospect 8.2 design is unchanged in this respect. However, the terms did change:

"Selectors" are now "Rules"

"Subvolumes" are now "Favorites".

 

As long as the design remains unchanged, the behavior will not change (except due to bugs).

 

Russ