Does anyone know what this means?

[JohnW]

I have not been able to find the words in this message anywhere. I get it when I am trying to save a Member's properties.

[DavidHertzberg]

IMHO JohnW's post could serve as a textbook example of how not to write a request for assistance.  He doesn't tell us what operation he is trying to perform that leads him to be  "trying to save a Member's properties".  The windows in his screenshot are piled on top of one another, so we can't figure it out.  I'm a Mac administrator with no recent Windows experience, but surely it's possible to drag those windows that have blue title bars around by those bars to separate them.  It might even be possible to temporarily collapse some of those windows into the taskbar, and un-collapse them for a second screenshot.  JohnW also doesn't say what  version of Retrospect he is using, or what version of Windows.

IMHO JohnW should totally rewrite his OP per the above paragraph.  I don't know about the rest of you, but I don't participate in the Forums to be a quiz show contestant .

Edited January 20, 2019 by DavidHertzberg
Fixed typo; inserted real "frownie" in place of "don't insert appropriate smiley here"

[DavidHertzberg]

On further reading in this forum, I see that JohnW has actually provided most of the missing information I complained about in my preceding post in this thread, but he has provided it in the OP in another thread.  In the editing bar at the top of a post, directly to the right of the first vertical divider, is an icon that looks like a link in a chain; if you let the mouse pointer hover over it, the word "Link" appears.  JohnW should have used that facility in his OP in this thread; if he had, I wouldn't have had to criticize it so severely.

We see in the third paragraph of that other OP that JohnW is trying to "open the member properties and browse the disk to update the space information".  From the screen shot in the OP in this post, it looks as if he has folders for multiple Backup Sets ("CSI01", "CSI03-BU", etc.) inside the "Retrospect"  folder on the volume "Retrospect_Backup".  If that is correct, then the message is accurate in saying "another set". If there is in fact more space available on the volume, then the fact that the message can't be bypassed to expand the Use At Most space for the Member is a bug.

I'll try to post back later on how to get around this presumed bug, but I suspect it will involve copying one member at a time to another volume, and expanding its size—and then Recataloging the Backup Set to use the copied Members.

P.S.: mbennett has in the meantime replied in the other thread that JohnW should discuss his problems with Retrospect Tech Support.  I had posted instructions in that other thread on how to file a Support Case, but Mayoff has evidently deleted that generally-harmless boilerplate post because he considers it to be spam.  Discussion with T.S. may not be necessary—see the post two posts below this one.

Edited December 14, 2017 by DavidHertzberg
Added P.S., which I later revised; later corrected 2nd & 3rd sentences of 2nd prgf. to reflect the assumption I was working under for "Scenario 2" in the post directly below—an assumption which I had inaccurately stated in this post

[DavidHertzberg]

The key question is : Why is JohnW trying to trying to update the space information for each Member in a Backup Set?   I have thought of two scenarios, both of which assume that he has acquired a Big New Disk.

Scenario 1:  JohnW is simply trying to accommodate his existing Backup Set on the Big New Disk, but is going about it with the wrong approach.   His approach is wrong because he is trying to preserve each existing Member.  He should instead create a new Backup Set on the Big New Disk, add what he considers to be the appropriate number of Members on it (per pages 404-406 of the Retrospect Window 12 User's Guide), and run a Transfer Backup Sets script (pages 214-219 in the UG) to copy all the backups from the existing Backup Set to the new Backup Set.  JohnW would then have to change all his scripts that refer to the old Backup Set to instead refer to the new Backup Set.  If this is too onerous, he could also temporarily obtain what I will refer to as the Borrowed Big New Disk.  He would then create the new Backup Set on the Borrowed Big New Disk instead of the Big New Disk, and—after running the Transfer Backup Sets script—delete the old Backup Set and recreate it with the same name and the newly-appropriate number of Members on the Big New Disk.  He would then run another Transfer Backup Sets script to copy all the backups from the new Backup Set back to the old Backup Set, but any Members of the old Backup Set would now reside on the Big New Disk.  JohnW would then delete the new Backup Set from the Borrowed Big New Disk, and return the Borrowed Big New Disk to its rightful owner.

Scenario 2: JohnW is simply trying to accommodate his existing Backup Set on the Big New Disk, and is going about it with the right approach.   His approach is right because—for some reason involved with locating particular backups within Members (or—I had thought before experiments on 31 December proved it impossible—making each specific Member the only one in a separate Backup Set used for user-initiated backups and restores)—he must preserve each existing Member.  On the Big New Disk, he should first create a separate new Backup Set for each old Member, distinguishing them with names that correspond to the old Member Names.  He should then run a separate Transfer Backup Set script for each new Backup Set, with the old Backup Set as the Source and the particular new Backup Set as the Destination.  (If there were more than one member in each Backup Set, each one of these scripts would have to have its own set of Custom Selectors (pages 460-466 of the UG) that would effectively restrict the files copied to those contained in the desired Member of the old Backup; since there doesn't appear to be any Selector specifying Member name, IMHO JohnW's  best bet would be Selectors specifying some combination of date and client that reflect the contents of the old Member as appropriate.)  Once all these scripts have been run, he would create the desired comprehensive new Backup Set on the Big New Disk, and specify the Members of all the particular new Backup Sets as Members.  As you may imagine, it's much more fun for me to think up this approach than it would be for JohnW to execute it (insert appropriate smiley here)—but see the P.S. below for a way to simplify that.

P.S.: Further thinking about "making each specific Member the only one in a separate Backup Set used for user-initiated backups and restores" has led me to an insight about making my Scenario 2 solution much easier.  It's based on the idea that the same Member can simultaneously belong to more than one Backup Set, an idea that had never occurred to me before—and which I'm not absolutely sure is valid.  It turns out because of experiments made on 31 December that it isn't valid.  Thus JohnW must already have a separate Backup Set for each old Member "owning" only that old Member.  He would then proceed with running the first round of multiple Transfer Backup Set scripts as described in the Scenario 2 paragraph above, but the Source for each script would be the Backup Set "owning" only one old Member and the Destination would be the Backup Set "owning" only the corresponding new Member.   Each of these Transfer Backup Set scripts would not have to have any Selectors, since the role of the Selectors would be accomplished by having the Source be the Backup Set "owning" only the Member to be copied.  JohnW would then proceed to run the second round of multiple Transfer Backup Set scripts as per the Scenario 2 paragraph above.  Could someone else please say whether the same Member can simultaneously belong to two different Backup Sets—even though  a Rebuild of a Catalog File rejects .RDBs whose creation date is before that of the Catalog File  ?

Edited December 31, 2017 by DavidHertzberg
Added Scenario-2-simplifying P.S. inspired by the _only reason_ why JohnW would need Scenario 2, as shown by 31 December experiments

[DavidHertzberg]

My preceding two posts in this thread have been based on the assumption that JohnW actually has Members of multiple Backup Sets stored inside the "Retrospect" folder on his drive.  That is because, on the USB3 portable drives that I attach to my Mac Pro backup server, there is a folder inside the "Retrospect" folder for the single Media Set (Retrospect Mac term for Backup Set) whose Members I store on that drive.  That folder is named e.g. "Media Set White", and inside it is a file named "1-Media Set White" which is a Member.  I assumed that, in the "CS101" dialog window shown in the OP's screenshot that says "select the next disk member to recatalog", the items shown are other folders within the "Retrospect" folder, and that they therefore enclose folders for different Backup Sets.  That's why I couldn't understand JohnW's saying, in the OP for the other thread, "Well it can't be from another set so that messages is just wrong."

Am I just making an unwarranted assumption that Members for Retrospect Windows are stored the same way they are in Retrospect Mac?  Or does JohnW have an extra level of folders on his disk that is confusing Retrospect Windows, making it think that Members for more than one Backup Set are stored on his disk—which would make the message correct from Retrospect Windows' point of view?  If the latter is correct, then JohnW could solve his problem merely by getting rid of the extra level of folders—which would enable Retrospect Windows to change the Use At Most property for an individual Member as he wants to do.

[JohnW]

I believe you missed the entire point of my post. I'm simply asking "What does the message mean?" Not what to do about it or why I got it. It has ambiguous wording. "The disk has data from another set..." Why the word "disk"? Could it be referring to "backup set" vs. the actual disk or is it seeing more than one of my backup sets that are on the same disk? Also, what exactly would it be deleting?

I showed the screen so that it would be easier to see what action was being performed at the time in case that may help shed light.

[DavidHertzberg]

So you're confirming that you've got Members from more than one Backup Set on that same disk, as I said in this post I had been assuming?  So why did you write, in your OP in the other thread, "Well it can't be from another set so that messages is just wrong. But what is actually wrong?"  If you've got Members from more than one Backup Set on that same disk, then the message means precisely what it says—and IMHO is offering to delete the Members belonging to the other Backup Sets on the same disk volume as the one you're trying to "update the space information" on in the Member Properties dialog.

Your OP in the other thread certainly sounds as if you're complaining about not being able to do something you want to do.  Mayoff has certainly chided me on occasion for a post that in his opinion strayed too far from the problem-solving that in his opinion these Forums are for.  And in general I try to stay within those guidelines.

I reiterate what I said in my first post in this thread, which is that you should totally rewrite your OP in this thread.  Describe precisely what's on your disk volume, and say precisely what you're trying to do.  Then we can say what the message means, and say whether or not it is a Retrospect bug.  Otherwise you're just wasting our time.

Edited December 14, 2017 by DavidHertzberg
Clarified that, if JohnW has Members from more than one Backup Set on the volume, Retrospect is offering to delete the Members from those other Backup Sets

[JohnW]

So I have been told by you and another that I should post to TS to resolve my problem. I did that. I just wanted to know exactly what I asked.

[DavidHertzberg]

On 12/14/2017 at 11:27 AM, JohnW said:

So I have been told by you and another that I should post to TS to resolve my problem. I did that. I just wanted to know exactly what I asked.

The answer seems to be that nobody who has ever posted to these Forums knows what the message means, apparently because nobody has ever seen it before.  IMHO that is because nobody has tried to do what you are trying to do, which is to expand the Use At Most space for an existing Member on a volume which also has Members of other Backup Sets.  Nobody has tried to do that because it is just as easy to add a new Member of a Backup Set on the same volume, assuming the space is available.  And the space has usually not been available on the same volume prior to recently, because there had not until recently been a rapid expansion in the size of a disk available at a particular price—what I have referred to in Scenario 1 in the fourth post in this thread as the Big New Disk.

I just a few minutes ago thought of a third possible Scenario 2 explanation of why you are trying to expand the Use At Most space for an existing Member.  It is that you are the Retrospect consultant for an installation which doesn't have an on-site backup administrator capable of adding a new Member to an existing Backup Set, or which doesn't have such an administrator on-site when the installation's backup scripts—each using a different Backup Set—are run.  This would explain why you are so reluctant to explain what you are trying to do and why you are trying to do it. 

My latest suggestion is that you combine my Scenario 2 solution in the fourth post in this thread, as I modified it in the P.S., with the Borrowed Big New Disk I suggested in my Scenario 1 solution.  You would follow a separate set of steps for each Backup Set: [1] Transfer Backup Set from old Backup Set to equivalent new Backup Set on Borrowed Big New Disk, [2] increase space for the only Member of equivalent new Backup Set, [3] delete the only Member of old Backup Set and add a new Member—with the same increased space—for the same old Backup Set on Big New Disk, [4] Transfer Backup Set from equivalent new Backup Set to old Backup Set—whose only Member would be on Big New Disk, [5] delete equivalent new Backup Set's only Member—which would be on Borrowed Big New Disk—and then delete equivalent new Backup Set itself.  With this set of steps there would be only one Backup Set at a time on Borrowed Big New Disk, so you wouldn't get the message when expanding the Member; also Borrowed Big New Disk would only have to be big enough for the largest expanded Member of any equivalent new Backup Set, so it would only have to be Borrowed Not-So-Big New Disk.  Actually you wouldn't even have to do any Member expansions on Borrowed Not-So-Big New Disk; you would just have to create the only Member of the equivalent new Backup Set with the size you had wanted to expand it to.

And now for a moralistic message:  When you are describing a Retrospect problem on these Forums, don't hesitate to explain the real-world problem underlying it.  You can pick a "handle" that doesn't identify yourself if you are a consultant; you can even pick a "handle" that conceals the fact that you are a woman—which I suspect many of the posters on these Forums are.  If you describe your real-world problem sufficiently well, it's likely that someone on these Forums will be able to solve it by thinking of an approach that wouldn't occur to you—possibly based on a better knowledge of certain features of Retrospect.  Here's an example from about 6 months ago.

Edited December 31, 2017 by DavidHertzberg
It's Borrowed Big New Disk, not Borrowed Big New Backup Set; because scenario 2 in fourth post in thread is only possible per P.S., modified third paragraph