Storage Groups vs. standard script?

[fredturner]

Hey Everybody—

I've been very pleased w/ how much faster backups are now w/ Retrospect 16, since InstantScan is working again. And the ability to back up multiple clients at once via Storage Groups is a very welcome new feature. One problem is that there doesn't seem to be much documentation about pros/cons and caveats...just one brief KB article. Two things I've encountered are:

1. No way to limit the number of execution units a group can use (at least, not that I can tell). It appears that a Storage Group will simply use however many threads you've specified for the whole Engine in Preferences. If that's the case, I'd suggest v16.1 adds a field to the Media Set options that allows limiting based on preference and/or practical disk speed limitations (while not limiting the overall # of threads/units).

2. More importantly, I seem to have trouble w/ a standard, nightly script that I want to back up to the same Storage Group that my client stations back up to. Obviously, Storage Groups are targeted at Proactive executions, but the KB article also says, "Scheduled scripts support Storage Groups as destinations, but the backups run on a single execution and not in parallel." I keep having trouble getting these scripts to finish executing. Just now, I had one disk in the script back up 8GB, then during scanning of the next disk, the whole thing just stopped and is showing that it needs media. The media has plenty of space, and the hang appears to have occurred before the scanning even finished. Has anybody else seen this or know why it is balking after a partial backup?

There may be more going on than I'm realizing, but again, I just don't see much in the way of specific documentation! Thanks for any suggestions or thoughts.

Fred

[DavidHertzberg]

fredturner,

I'm not running Retrospect Mac 16 yet. However the second and—especially—third paragraph in this post in another thread is my educated guess as to what this Knowledge Base article really means.  I wrote in the post's third paragraph (where "doohickey" is an old American term for a mechanism of unknown identity—which in this case could consist of a list of source-volume names processed by coding in the Retrospect Engine):

Quote

A Storage Group folder has a doohickey within it that keeps track of the names of each Backup/Media Set whose Catalog File is contained within it.  The names of the Catalog Files are apparently suffixed (I can't tell, because the names of the individual Catalog Files have been obliterated in the Retrospect Windows screenshots in the KB article) with the name of the individual source machine and drive name.  If the administrator runs a Proactive script that backs up a machine and/or drive previously unknown to its Storage Group destination, the doohickey is used to automatically create a new Backup/Media Set Catalog File within the Storage Group folder.  If OTOH a Proactive script backs up a machine and drive previously known to its Storage Group destination, the doohickey simply redirects the destination of the backup to the appropriate existing Backup/Media Set Catalog File .

Considering your Problem 2. based on what is shown for Retrospect Windows in the KB article, if you look at your applicable Storage Group folder—which is likely by default inside Library -> Application Support -> Retrospect -> Catalogs on your "backup server"—you'll find a Media Set Catalog File created by the doohickey for each source-volume combination.  My wild-a**ed guess is that you might be able to use the Console GUI to navigate to one of those Catalog Files and open it as if it's an ordinary Media Set.  If you can do that, you can likely open the Members tab for that Media Set and click its Edit Pencil at the bottom of the dialog box; this will allow you to mess with the space allocation.  What you might want to do is to try reducing the space allocation in "Use at most" for the single Member of the first Media Set within the Storage Group, or at least notice that it's allocated for all the available space.  What seems preferable to me is that you click the '+' button to add a second Member—preferably on a second disk, and adjust its space allocation when you do that.  Either way Your Mileage May Vary, and I'll be praying for you.

However the more I think about your Problem 2., the more I think the correct thing to do is to phone or e-mail Retrospect Tech Support.  If you do that right away, you'll still be within your 30 days free personalized support period.  This sounds to me as if the engineers didn't actually test "Scheduled scripts support Storage Groups as destinations", especially to the same Storage Group as used for a Proactive script, so you may have uncovered a bug.  Here's why and how to file a Support Case for a bug.

As for your Problem 1, here's why and how to file a Support Case for an enhancement.

[DavidHertzberg]

fredturner and anybody else,

I just noticed that there's a new bug-fix version of the Retrospect application as of 28 March, which I think may be later than what fredturner reported using in his OP.  Here are the cumulative Release Notes for Retrospect Mac 16.0.1.105; observe that for the Mac (and also for the Windows) variant most of the new fixes are for Storage Groups.

P.S.: Now there's a a further new bug-fix release for both the Windows and Mac version of the Retrospect application as of 11 April.  The cumulative Release Notes for Retrospect Windows 16.0.2.101 has the following entry:

Quote

Storage Groups: Fixed issue where media request would show up incorrectly due to "Use At Most" logic error (#8012)

That certainly sounds like a fix for fredturner's Problem 2, but I don't know whether the fix is also applicable to Retrospect Mac—and the engineers simply forgot to document it.

Edited April 19, 2019 by DavidHertzberg
P.S. linking to cumulative Release Notes for Retrospect Windows 16.0.2.101, which contains a fix that _may_ be applicable to fredturner's Problem 2 withRetrospect Mac