Faster/more responsive when recycling

[emulator]

I've posted something similar to this in the past, but I thought that I'd underscore its need again. When recycling a large or very complex backup set, Retrospect can take a LOOOOOOONG time. For example, we have a SQL server backup set that started recycling this morning at 5am. The time is now 7:15am, and the recycle process is still underway.

 

What's worse, when the recycle process is performed, other backups are slowed to a crawl. Backups that normally take 10 minutes to complete are stretched out to over an hour.

 

I'd like to see this corrected.

[Richy_Boy]

I never quite understood why recycling takes a long time - is it not simply wiping the disk and catalog file? (assuming it's a single disk set)

 

I also have huge problems with constantly having to rebuild catalogs and failed / corrupt grooms which makes the whole solution very inefficient when I have a limited backup window.

 

Still, many things have been suggested in the past, yet I've not noticed a SINGLE major change implimented on the back of them.

 

Rich

[Richy_Boy]

Oh, by the way, my reply may have sounded a little fed-up. This is probably due to sitting here trying to remove several snapshots from my backup set ONE BY ONE, each time it's hanging Retrospect for several minutes until done.

 

The fact that the product was designed without the 'thought' of being able to multiply select these things is terrible, yet to have the app hanging when you try and use the weak functionality should have never got past the test phase before release, in my opinion.

 

Rich