All Activity

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.

Since the head of Retrospect Tech Support evidently deleted the post I made in this thread on why and how to submit a Support Case for a bug, JohnW should look at this post in a prior thread for the same information. The worthy protector of the Forums has called that post "spam", but IMHO he really objects to the very relevant fifth paragraph for a reason you can all undoubtedly figure out for yourselves.
I agree with Lennart_T that JohnW should open a Support Case, but IMHO it should be two Support Cases for the two separate bugs. I have not posted about opening a Support Case in the other thread he opened, but have instead devoted that thread to proposing a couple of workarounds for the second bug. IMHO the second bug is a manifestation of JohnW's trying to do something no Retrospect administrator has done before, because only the recent advent of Big New Disks has made it possible for administrators to copy old Members and try to expand their size. Therefore he needs a workaround for the second bug, because he shouldn't expect a quick fix.
As far as the crashing encountered in the first bug is concerned, it is worth considering Retrospect bug #6535—which the Release Notes say was fixed for Retrospect Windows 12.0.

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 either locating particular backups within Members or 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. 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. If it is valid, then JohnW can simply set up—if he hasn't done so already—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?

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.

Second the motion. Starting another thread on the same issue didn't get you any meaningful results either. I've never seen this error and your situation is too complex for people on the forum to debug. Get on the horn with support. Good luck.

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 (don't insert appropriate smiley here).

On 9 December I ran an unplanned test that verified my hypothesis in this post in the thread.
On the night of 5 December my main computer, an Early 2011 15-inch MacBook Pro, wouldn't boot. I brought it in the next day to Mike's Tech Shop; they said the logic board was dead, and that they couldn't replace it because that model was declared "obsolete" by Apple on 1 January. I decided to buy a 2016 15-inch MacBook Pro as an "open box" special, doing so because I could take immediate delivery and because it came with macOS 10.12.6 installed (my rule is never to install an Apple OS whose last digit is not .3 or greater, and macOS 10.13.2 has just been released). The 4-core processors in the new machine are 2.7GHz vs. 2.0 in the old machine, and RAM on the new machine is 16GB vs. 8GB in the old machine. Both the new and old machines have 500GB SSDs; the SSD in the old machine was installed in early May, so—within the limitations of the old machine's drive interface—its drive speed ought to be about the same.
Before bringing the old machine in to Mike's I had run a Restore of the old machine's 5 December Retrospect incremental backup onto a spare portable HDD. Overnight starting 6 December I used Migration Assistant to copy the files from that HDD onto the new machine. Despite a couple of missteps and an adapter problem (the Apple Thunderbolt-3-to-Thunderbolt-2 adapter Mike's sold me turns out not to work with DisplayPort monitors, meaning I can't connect the new machine to my 27-inch Apple LED Cinema Display until I receive a StarTech adapter that will work from NewEgg), I had the new machine more or less operational with its built-in 15-inch monitor on 7 December.
Every Saturday I run Recycle backups of all my 6 drives onto a portable 500GB USB HDD. The run on 9 December did a LAN backup of my new MacBook Pro in 2.5 hours, vs. the 3.5 hours the backup of essentially the same files from my old MacBook Pro had taken on 2 December. The MD5 validation of the backup of the new machine was also correspondingly shorter than that of the old machine. IMHO that proves "the main factor limiting speed of [backups over] networks is the traversal of multiple files in the file system by the client computer."

(Running Win 10 64 bit) I have several backup scripts. Each time I try to recreate any catalog file from disk backups, Retrospect 12.6.1 crashes without an error... just gone -- blink! A text appears stating, "Preparing to execute" and a few seconds later comes the crash. So after trying anything I could find here and via Google and, of course, reboots, I decided to simply wipe Retrospect and start over. I did that. Now I have a new problem: Each time I try to recatalog any backup and just after I press the "Save" button to save the new catalog file, The "Preparing to execute" displays and then I get a browse prompting me to "Select the next disk member to recatalog." Well there is no next disk member and I selected "No" to the question "Are there any more disks in this Backup Set?"
So what's going on here? I've never seen this behavior before and I have been using Retrospect since version 4. There is no way to continue on and let the system recatalog. This behavior started right after the reinstall.
Problem two is the reason I want to rebuild the catalogs in the first place. Also a first for me: When I open the member properties and browse the disk to update the space information, I cannot then save the Member Properties. I get an erro as in the image below, "The disk has data from another set..." Well it can't be from another set so that messages is just wrong. But what is actually wrong?

I think mdgarnett should do a Copy Media Set, with the destination Media Set a new one whose first Member is on the larger drive. Instructions for doing this are on pages 137-139 of the Retrospect Mac 14 User's Guide. Instructions for creating a new Media Set are on pages 87-90. Obviously mdgarnett will have to change the Destination Media Set in scripts that reference the one on the smaller drive.

Mac Retrospect v14.6.1
I'd like to do a simple move of a media set to a larger drive but I can't find any instructions on how to do this. Is it possible or do I just have to start all over with a new media set on the larger hard drive?
thanks.

If redleader is getting -530 and -519 errors only on laptops logging on to the WiFi, but not on computers permanently cabled to the LAN, I suggest reading this post.
All of my client computers are connected to the LAN by Ethernet cable. However 3 years ago, when I started using Retrospect again, I was getting errors—and I now believe they were -530 errors—until Alan of Retrospect Tech Support told me to give the clients static IP addresses. The post linked to in the preceding paragraph tells how to do it for my particular router. Since it is done by associating a particular LAN address with the computer's MAC address (which as you can read here has nothing to do with whether the computer is an Apple Macintosh as some people think) that should work for all redleader's computers—including those connected over WiFi because that connection must also be through the router. He/she should talk to his ISP or router provider.

Oh well, #sigh
I have a few Macs.
All on WIFi
All on DHCP
They have to be this way, because they roam from office-to-office, client-to-client, home-to-work-to-home ... like laptops do.
The error -530 and associated -519 has be around in almost every version of retrospect I have used for the past 20 years.
I can never find the solution, apart from a full client reinstall, and I can not be doing that every week TBH!
Is there ever going to be a stable answer?
Each Mac, Client and Server has no firewall or anti-virus FYI.
The fixed desktop Laptops that do not leave the office have no issues.
The laptops returning to the office login automatically to the WIFI and have no network issues for everyday work; email, www, ftp, server shares, printing ... what so ever.
Server: Mac OSX 10.11.6
Client: OSX 10.12.6
Retrospect 13.5
Please don't say 'upgrade to the latest version of Retrospect or I may have to slap you :-)
That has never been an answer to this issue.

Thanks Twickland and thank you David! All working now. I went to...
Restore
Search For Files And Folders
More
Open
and then added each tape from the Backups Folder - each tape still contained all the info of what was on it
Fantastic! Thanks again for all your help guys

Well, I did get a response, and after ~5 follow-ups and replies, I was told that the problem is a known issue with email servers that don't use SSL for authentication, and that it will be fixed in the March release.

I have several scripts set up for doing "Transfer Backup Set". In every case, automatic grooming always fails with "error -2249 (could not find session). Rebuilding the catalog file does not fix the problem. The next auto-groom fails with the same error. I can, however, do a manual groom on those backup sets from the backup set dialog. Any ideas on what the problem is?

You may be confusing a backup set with the tape members of that backup set, as none of the screenshots above show any actual tape members.
Your third screenshot above shows that Retrospect is aware of six backup sets. You can highlight any or all of them to search for your files of interest. You can also open more catalog files and search them as well.
I can't say what limitations, if any, that Retrospect 5.1 may have regarding how many backup set catalogs that it can be aware of and search through in one go. That may depend on how many tape members are in each backup set, as well as the total count of files in the backups. As David notes above, having a backup set's catalog is not useful if you don't actually have the tape members of that backup set.
In your next post, please give us an idea of how many tape members there are in a typical backup set of yours. You can find this by going to Configure>Backup Sets>Configure [specific backup set]>Members.

Perhaps I should have more correctly stated that Instant Scan only works on Windows Hosts with NTFS volumes (and NTFS Journals), and the Retrospect client installed directly on the host.
NAS boxes share files use the open source SAMBA suite to present files using the SMB / CIFS protocol independently of the underlying file system. Most NAS Units run a variant of Linux and use EXT, ZFS, or BTRFS file systems under the hood, all of which are journaling file systems, but not NTFS, and hence would not work with Instant Scan.
Even Windows NAS Servers ( Windows Storage Server) present their NTFS files as SMB/CIFS shares. (But of course, being Windows, you could install the Retrospect client on them and take advantage of Instant Scan because they DO use the NTFS file system under the hood)
I do also admit that my approach would not reduce Volume Scan times, whereas Lennart's approach would.

> I intend to post it in every new thread that appears in this forum
David, if you decide to keep posting the above document to every thread, it is going to be deleted. It isn't appropriate to spam the forum with repeated content.

Ah I seeeeeee. Yes the drive I have doesn't work on anything more up to date than a G4. I'll read through the link you very kindly supplied above and see if I can get that to work. Thanks again for your help David.
Stu

Sorry, Stu, I meant "come clean" in the sense of fully describing what your (as it turns out) own situation is, not to imply any cloak and dagger. I assume you are still using the G3 because of some combination of "they don't make graphics programs like that anymore" and "I can't find/afford/attach a tape drive that can read those old Retrospect backup tapes on my modern system". Otherwise I would suggest buying a copy of Retrospect Mac 14 Desktop Edition for your modern system, and building/Rebuilding a Media Set containing the old tapes you actually have for it.
David H.