DavidHertzberg

fredturner, If your answer to either of the two questions I posed in my immediately-preceding post is "no", you might instead want to consider a couple of suggestions for improving "my usual M.O." described in the first paragraph of your OP. The first suggestion is precisely what I have done for at least the past 5 years (probably 6 years) for my own little home installation. That is to rotate portable HDD destination drives once a week, and to take the previous week's portable HDD to my safe deposit box in my bank branch 2 short blocks away. The bank charges US$95/year for a small safe deposit box. The bank branch is not open 24/7/365, so I have three portable G-DRIVE HDD destination drives instead of two (they're named "G-DRIVE Red", "G-DRIVE White", and "G-DRIVE Blue"; the color part of the names are the ritually-named colors of the American flag I learned as a little kid); the drive I bring home from the bank branch sits just inside my apartment door for a week before being used as a destination again. If you live in Great Britain (which I suspect you do because of the time-of-day you post—but maybe you're a U.S. night-owl), your bank branch may have safe deposit boxes that are accessible 24/7/365 using 2FA. I long-ago decided that having the latest off-site backup of my data lag my on-site daily backup by up to a week is acceptable for my little business, but your customers may feel that's too-lengthy a lag. In any case, the drive swapping that I do at the bank branch could be done by any responsible employee of your customers' businesses—and those businesses probably have an employee go to a bank branch at least once a week for other purposes. The second suggestion is that you monitor your customers' destination drive rotation using the Retrospect Management Console, which is a free feature of every Edition of Retrospect starting with version 18.0. I don't need to do this, because I'm the only employee of my little business and I still remember "three cheers for the Red, White, and Blue". However I should caution you to carefully guard the password (meaning don't store it online) for your Management Console; as Malcolm McLeary pointed out over a year ago in this post in another thread, the Management Console's use of Heroku and its lack of 2FA pose a threat of data theft from your customers.

fredturner, First, can your "beefy internet connection" handle several customers simultaneously copying backups—that were made via Retrospect on your customer's "backup servers"—to your offsite destination? Copying backups would likely be simultaneous because you'd want to schedule the copying when it didn't coincide with the backups being run on those "backup servers"? Unless you can keep both those "backup servers" and your offsite destination available 24/7, that copying period would probably be in the early morning or late afternoon—and I'll assume your customers are in the same time zone as you. Second, are you willing to adapt your OP's "adjusting my usual M.O." to avoid subjecting your customers' backed-up data to ransomware or data theft? Fortunately on 18 August mbennett started a Forums thread about his "way to harden a S******y [my elision—parenthetically explained below—of the well-known brand name] NAS so it can be used with Retrospect to make it ransomware-proof." (Unfortunately that thread's later posts were marred by an argument, begun by me with a gentle expression of concern that higher-ups at StorCentric—which has owned Retrospect "Inc." since 25 June 2019—might delete the thread because S******y NASes are the leading competitor to the Drobo NASes manufactured by another subsidiary of StorCentric.) You should read at least the "Introduction - Why?" section and the first two paragraphs of the "Overall Scheme" section of the .PDF he attached to his OP. If you followed that .PDF, you'd buy a S******y NAS for a few hundred $US and insert at least some members of your "disk shelf array" into it. You'd then follow mbennett's numbered instructions after the second paragraph in "Overall Scheme" to setup that NAS "with one administrative way in, protected by a strong password and two-factor authentication. The NAS will provide a single service, that of an S3 cloud, and will provide no other file storage services." You'd also ensure that each customer's Retrospect "backup server" application be "be password protected with a complex password ...." The .PDF continues "... and locked after 15 minutes of inactivity. You should use File | Lock application if you walk away and leave Retrospect running", but that's a Windows facility—used in the .PDF because mbennett wrote it for Retrospect Windows—that AFAIK has no equivalent on macOS. If your answer to both of those questions is "yes", then IMHO you should "make this less error-prone and more robust" using Copy Backup scripts. Designate the same Activity Thread for each customer's Copy Backup Script that is designated for his Backup script, because (despite my Feature Request in in the April 2017 Support Case #54601) Retrospect doesn't yet have a Copy Lock feature that would pause a Copy Backup run that is overlapped with a Backup run—pausing needed because only the files that are already entered in the Catalog File are copied.

iodigitale, If this setup—which wasn't clear to me from your preceding posts—worked with your previous version of Retrospect, then there's a bug in Retrospect Mac 18. What I don't understand is why other installations haven't reported the same problem. Maybe you're among the first to upgrade to Retrospect Mac 18.1.1? Did any of your backup executions work using 18.1.1? P.S.: Further questions about your customers' setups that need to be answered regardless of whether or not you submit a Support Case for a bug: So you're saying each customer has a "backup server" at his/her location? Do you check at the customer sites whether the scripts have run? Do you personally make all hardware and software changes to these "backup servers" and to the "client" machines they back up? Have the OSes running on the "client" and/or "backup server" machines been upgraded? Have network switches at the customer locations been upgraded? What OSes do these machines run?

iodigitale, Before following the suggestion in my immediately-preceding post, you should consider another possibility I thought of yesterday. It is possible that there isn't any Retrospect Mac 18 bug, but instead that—in upgrading your installation in which "we have a large amount of clients and a lot of them set in dhcp"—your provisions for Subnet Broadcast access per page 82 of the Retrospect Mac 18 User's Guide were messed up. The reason I think you use that access method is, because "we have a multitenant service with about 10 servers and 200 clients", you have no way of ensuring that names of "client" machines are unique except within a particular "tenant". Therefore you must be distinguishing between "tenants" by putting them in separate subnets based on designated ranges of IP addresses. Subnets are designated in Retrospect Mac by defining them per "Configuring Network Interfaces and Subnets" on page 83 of the User's Guide. You give each subnet an Interface Name, and then define its range via the Subnet Address and Subnet Mask. I don't have any subnets defined on my small home network, but I gather that—per "Adding Retrospect Clients to Sources" on page 69 in the User's Guide—you specify the "client"'s subnet in theleft-hand Sources from Interface pop-up menu and specify Use subnet broadcast in the right-hand pop-up menu (not mentioned in the UG—another example of deficient Retrospect documentation). The way to test whether this is the problem is For each of the "client" machines that gets a -519 error, if you select it in the Sources panel of the Retrospect Console and click the Refresh button at the top of the panel, does the dialog show that machine? If not, then your subnet designations must have gotten messed up. Talk to your IT people and fix them, instead of submitting a Support Case. If the dialog does show that machine, OTOH, there's another possibility that doesn't involve a Retrospect Mac 18 bug. That's if you have more than one Retrospect "backup server" running scripts. Your Console may now be be running scripts on a "backup server" for which some sources in the script are not defined.

iodigitale, I intended to add one more suggestion (before the disclaimer) to my preceding post in this thread, but my Web cache for these Forums became corrupted and—by the time I cleared it (following the direction of a Filipino 😲 Retrospect Support person) —I needed to get to the bank and then to the post office before they closed. The suggestion is that you create a Support Case for a bug; here's how to do that (since I wrote that linked-to post, Retrospect 18 was released with mandatory ASM, so you've paid for personal assistance). Here are some facts: Retrospect 18 was released on 25 May, 2.5 months behind the customary first-week-in-March schedule. Another thread of mine—which was locked by the head of R.T.S. because of my "insulting members of the staff with these kinds of comments"—described 18.0-related errors on the Retrospect website that were not fixed until 14 July (nearly 3 weeks after 18.0 was released) following my Support Case #79825. Fully-updated versions of the version 18 User's Guides were also not put on the Retrospect website until 14 July. Here's a post by another administrator reporting a bug in a previously-working feature when he upgraded Retrospect Mac 17.5 to 18.0. Here's a post by you reporting a bug in Retrospect Mac 18.1.1.120, which is a bug-fix release to the 18.1.0.113 bug-fix release a week earlier. My inescapable conclusion from these facts is that there has been a distinct lack of coordination and thorough alpha-testing in Release 18.x so far. I think your "We have different customers in different offices" and "we have a large amount of clients and a lot of them set in dhcp" means many of your "client" machines are in fact defined with the the Subnet Broadcast access method (per page 82 of the Retrospect Mac 18 User's Guide), and that release 18.1.1.120 has messed that up. Here's are questions you need to explicitly answer in your Support Case—and to any R.T.S. person you phone: What major version of Retrospect Mac was your installation using before you upgraded to Retrospect Mac 18? Are the -519 errors exclusively for "client" machines defined with Subnet Broadcast access? If so, can you redefine one of these "client" machines with Add Source Directly and see if you still get a -519 error backing up that "client"? For one of the "client" machines that gets a -519 error, if you select it in the Sources panel of the Retrospect Console and click the Refresh button at the top of the panel, does the dialog show that machine? Are any of your scripts using features that are new or improved in Retrospect 18.0 through 18.1.1 (blue or green tabs in the cumulative Release Notes for those releases)? If not, would you be willing to demand a downgrade to your preceding release—with a consequent refund (the prospect of having to give a refund tends to concentrate a salesperson's mind wonderfully—encouraging rapid action on the part of R.T.S.)? And please post your answers to those same questions in this thread.

iodigitale, First I must ask, in the immortal words of Nigel Smith, "what else changed?" when you upgraded your installation to Retrospect Mac 18. Did you also upgrade to any "improved" networking hardware—because a forced upgrade in early 2017 to an "improved" Ethernet switch gave me -530 errors for a "client" ? I must also ask if your "clients in different locations" are defined with the Subnet Broadcast access method (per page 82 of the Retrospect Mac 18 User's Guide)—because the permanent fix for my -530 errors was re-defining my "clients" with Add Source Directly (also per page 82)—which unfortunately might be a pain in the a*s for your "multitenant service"? Second, I suggest that you consider downgrading your "backup servers" to 18.1.0.113, based on my guess that the hurried (1 week after) release of 18.1.1.120 might not have been thoroughly tested for network communications other than for the one ProactiveAI bug it fixed. If that doesn't solve your problem, consider downgrading your "backup servers" to 17.5.2.103—for which you'll have to get a license from Retrospect Sales. (Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here. Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.)

Would the Retrospect Product Manager be J.G.Heithcock or Brian Dunagan? Or somebody higher up in StorCentric? Whoever he/she is, I'm glad this thread is still un-deleted and un-locked. Sorry if my pessimism about that disturbed mbennett. On 8/20/2021 at 1:00 AM, mbennett said: I just went through my Contents since 1/1/2021, and here's a tally of my "non-responsive" responses—one category for each thread in which I posted: Procedural suggestions derived from Retrospect documentation: 7 Spammer confrontations (I also reported the spam posts—which were deleted by R.T.S.): 2 Retrospect documentation citations that didn't require procedural suggestions: 7 Retrospect version upgrade suggestions: 6 Retrospect feature request suggestions: 2 Hardware suitability guesses: 1 Procedural suggestions going beyond Retrospect documentation: 8 Retrospect bug identifications with suggestions to file a Support Case : 7 macOS bug identifications (in old version, for administrator information): 1 To answer mbennett's question I quoted, I'm here because—for at least the last 4 years—nobody from Retrospect Tech Support has been routinely posting such responses to Forums threads (presumably because of R. T. S. being short of staff). For most of the threads, the responses I've posted have been sufficient. For the remainder—ones where my OS knowledge or Retrospect experience weren't sufficient—my responses have been supplemented primarily by responses from two British administrators and a Swedish administrator. But—unlike me—those people aren't retired, so their time is limited and they're happy to let me handle the easier responses. mbennett used to do some Forums responding, but—excepting this thread—he has to handle Retrospect-related problems when he can charge his customers for assistance time (from 1964–69 I used to do that for defense and NASA contractors running project scheduling and costing apps at the "IBM mainframe" computer service bureaus where I worked). 😎

xavierbt, Sorry, but if I'm correct this may cost you some money. The cumulative Retrospect Mac Release Notes show, for both 😮 17.5.2 and 18.0, "Console: Fixed issue where Full Disk Access alert was incorrectly displayed when certain custom options were set (#9169)". I'd check with Retrospect (European?) Tech Support before upgrading to version 18, because from the cumulative Release Notes that still seems IMHO to be "a work in progress". The "when certain custom options are set" part of the release note raises questions because, as you say in the OP, "All clients have basically the same software because are cloned and don't have significant differences between them." So that's a puzzler.

But I do have a fair amount of knowledge on what in reality is now going to be allowed for posts on these Forums—based on what's actually been done since June 2019 to the Knowledge Base and Tutorials on the official Retrospect website. That's why I'm concerned that you may find this thread locked by the head of Retrospect Tech Support because its topic seems exclusively about what you've been able to do with a NAS brand that competes with Drobo. Having that happen is not going to help the adoption of the protection against ransomware you're worthily advocating. All I'm suggesting is that you put a different spin on the topic. Make it sound like "this is what I've been able to do with Retrospect and a popular brand of NAS to make it ransomware-proof; what are your notes and critiques relating to how what I've done can be perfected and extended to Drobo?" You're ignoring the fact that the Retrospect Inc. no longer exists; it's become Retrospect "Inc."—a wholly-owned subsidiary of StorCentric. As a result, the employees of Retrospect "Inc." have made "improvements" to the website that seem designed to curry favor with their ultimate bosses—even though the "improvements" are IMHO unhelpful to the product their subsidiary sells. Although he'd no doubt personally regret doing so, it's possible the head of Retrospect Tech Support might decide that allowing this thread to keep going—no matter how beneficial to Retrospect as a product—might endanger his 27-year-old job. Employees fearing the effects of a corporate merger often maneuver to protect their own jobs; I'll tell you in a PM about a personally-experienced case of such a maneuver that predictably hurt the merged company. But first, a little full disclosure; both yours and mine. Per your profile URL, you're what Retrospect Inc. has long called a Partner; you sell Retrospect, along with a wide range of other software, to businesses in Southwest Missouri.. I, OTOH, am a retired applications programmer; I used Retrospect Mac from 1995—including backing up a work-provided Windows 95 home desktop— until 2010 when my "backup server" machine died of old age, and again from 2015—when I inherited another "backup server" machine—through today. Now let's proceed to my "personal grudge" about unnecessary -530 errors not having been fixed. I'm not the only administrator who's had a problem with such errors; there have been a total of 42 Forums threads (reverse-date-sorted) about them. Of the 3 threads in which I was the OP, only this most-recent one deals with the still-un-fixed bug I discovered on 30 January 2017 (the 2 preceding ones turned out to have been caused by a problem that Retrospect Inc. couldn't possibly have fixed). The 4 threads more-recent than that thread have many replies; the most-recent one (like 2 of the others it's about Retrospect Windows)—started on 5 October 2019—has 82 replies, only 28 of which are mine. One of my replies in that thread began: But if the engineers can't fix the unnecessary -530 errors, why haven't they enhanced this existing Knowledge Base article to describe the circumstances in which the administrator can eliminate—or at least workaround—the -530 error and the circumstances in which he/she can't? Even better, why haven't they spelled out in the User's Guides the circumstances in which the Multicast access method won't work for a "client" connection? Are they afraid to say when a glorious Retrospect feature doesn't work any more?

mbennett, Your OP asked for notes and critiques. You're not going to get them as easily if the head of Retrospect Tech Support, acting on what he perceives to be Retrospect "Inc." policy, takes this thread down. The following is an explanation of why I think that's a possibility, unless you turn your OP into a Support Case as I suggested above: First, let's apply some "kremlinology" techniques to the evidence for "Retrospect specifically documents support for competing NAS products in the knowledgebase, including Synology and QNAP". The applicable Knowledge Base articles are all under "Cloud Backup", which is of course the crystal-clear place any administrator would know to look 🤣. They are "Cloud Backup - How to Set Up Synology for Cloud Backup" and "Cloud Backup - How to Set Up QNAP for Cloud Backup" A sidelight is that the second article says "Retrospect needs three pieces of information to access Synology:"—even though the article is supposed to be about QNAP, revealing an oversight by the engineer who adapted the first article to create the second article 🤣 . For good measure there are also the KB articles "Cloud Backup - How to Set Up Minio for Cloud Backup" and "Cloud Backup - How to Set Up Zenko for Cloud Backup". All four of these articles are substantially copies of one another; all four refer in their leads to Retrospect 15.1 and were last updated in May 2018, 13 months before Retrospect Inc. was merged into StorCentric. Second, let's extend the "kremlinology" techniques past the June 2019 merger to the KB article "How to Set Up Drobo for Retrospect Backup", which is listed under "Top Articles" and was last updated in May 2020. Its section "Retrospect Setup: Add Drobo as a Destination" links to the YouTube videos "Retrospect for Windows: Setting up a NAS as a Backup Destination" and "Retrospect for Mac: Setting up a NAS as a Backup Destination". Its section "Retrospect Setup: Add Drobo as a Source" links to the YouTube videos "Retrospect for Windows: Setting up a NAS as a Backup Source" and "Retrospect for Mac: Setting up a NAS as a Backup Source". Those same four videos are listed under "Legacy Win—Getting Started" and "Legacy Mac Tutorials—Getting Started". If you watch them, they are obviously pre-merger videos into which the narrator—the head of Retrospect Tech Support—has post-dubbed the phrase "such as a Drobo" into his first sentence. Think about the StorCentric pressure that must have led to the post-dubbing of those videos and their classification as "legacy"; then think how it might apply to this thread.

mbennett, Magnificent job, which I'm not worthy to judge. 😁 (I back up my little home installation to 1 of 3 alternative portable USB3 HDDs, transporting the latest-week's HDD to my bank safe deposit box once a week. I don't have a NAS. My 2020 Mac "backup server" is never booted except when It's in use for backup, and it can only be accessed via my LAN, so I don't worry much about ransomware.) Your ransomware-proofing solution is IMHO much better than the new feature on pages 5–7 of the Retrospect Windows 18 User's Guide, because it isn't tied to the speed of communication to and from a cloud provider. Moreover it IMHO goes a long way towards solving the data-theft problem described by Malcolm McLeary starting with this post in his July 2020 thread. However its discussion in this thread seems IMHO to raise a Forums problem, because Retrospect "Inc." is now a subsidiary of StorCentric—whose Drobo and Nexsan and Vexata NASes are competitors of Synology. My personal experience is that the head of Retrospect Tech Support looks very unfavorably—to the extent of deleting posts—upon any Forums discussion that casts "aspersions" on either Retrospect "Inc."'s employees or the competitiveness of its products. That's why I never fully name any competitor's backup software unless it has also been named in a "Competitive Analysis" article in the "White Papers" section of the Retrospect Knowledge Base. Will he now look unfavorably on any thread that discusses a NAS product that is a competitor of StorCentric products? 😕 My suggestion is that you therefore convert your OP in this thread into a feature request Support Case. Here's how to do that. For the "description of your issue" you could copy the first full sentence of your OP, followed by the full URL link to your .PDF and the 2nd through 4th paragraphs of the "Introduction - Why?" section in it, and end with a request that the equivalent capability be added to StorCentric's LAN software. You can then add another post in this Forums thread giving your assigned Support Case number, even though we other non-Retrospect-"Inc." peasants will not be able to view it. That way we can artfully frame any further posts in this thread as if they are intended to apply to the StorCentric feature request, even though they may regrettably 🤣 also apply to the Synology version of your project. And the StorCentric feature request wouldn't IMHO be asking for the Moon. StorCentric's Data Mobility Suite, announced in October 2020, supports MinIO—which the 5th paragraph of the "Introduction - Why?" section in your .PDF says is what you chose to use to create an internal cloud device.

Nigel Smith, I should have written "I don't believe a .rdb file qualifies as a database requiring a database engine". My guide is the lead section of this Wikipedia article, whose first two paragraphs distinguish between a "database" and a "database management system (DBMS)". I totally agree with rhwalker—quoted here up-thread—that "All of the backup data (files, metadata, etc.) is in the .rdb files which, taken together, comprise Retrospect's database." I'd merely add the .session files, which AFAIK add information on which .rdb file(s) contain a backup of a particular Source file/folder. All I'm saying is that the "backup server"contains no code for doing an Update or Delete of an .rdb or .session file, so it doesn't need to use a packaged DBMS (see the first paragraph in this section of the same WP article)—which you call a "database engine" and which might differ in the Mac vs. Windows variants. Here's an illustrative example. Back in the mid-1960s the standard test of whether someone had graduated from Programmer Trainee to full-fledged Programmer was whether he/she could write pseudo-code for a "three-tape update". The three "tapes" are sequential files, each one of which contains records sorted by "account number". The first "tape" is an "old master file" with one record for each "account". The second "tape" is a "transaction file" containing one or more transactions—including Creates and Updates and Deletes (pseudo-code for Reads was usually considered too application-specific to be included in the test) for some—but not all—of the "accounts". The third "tape" is a "new master file" incorporating the applied transactions. (in the late 1970s, when I worked for the company that later expanded into Verizon, there were three telephone-engineers-retrained-as-"programmers" in my Disbursements Accounting development "district" who couldn't pass the test when faced with a real-world assignment. IIRC I had to give them some helpful hints.) The point of this example is that the "three-tape update" test requires creating your own application-specific—i.e. non-packaged—DBMS. And, by Gadfrey, an .rdb file is actually a portion of a sequential "new master file" whose "account numbers" consist of Source file/folder names concatenated with their dates-times and the backup date-time. According to this 2016 post by madison347 followed by a reply by the head of Retrospect Tech Support, .session files were added to Members in Retrospect Mac 13 (and Retrospect Windows 11) to allow faster Catalog File rebuilds; however .session files are AFAICT really segments of a disk-saved index to the .rdb files in a Member. My overall conclusion is that, since the strictly-sequential creation of .rdb and .session files within a Member is merely a fancy fleshing-out into application-specificity of the Create logic in a classic "three-tape update", it probably doesn't require a DBMS written by an outside software provider—which you call a "database engine" and which might differ between Retrospect Mac and Retrospect Windows. And the same would probably be true for the reading of .rdb files; even if speeded by the use of .session files, it would just be a fancy fleshing-out into application-specificity of the Read logic usually omitted from the "three tape update" test—so it also probably doesn't require a DBMS written by an outside software provider.

twickland, Neither in your OP nor in your later post did you say what error message you were getting for "when I attempted to rebuild the catalog, I was unable to do so because Retrospect failed to accept the media set's password". iodigitale has since reported in the OP of another thread that "when I try to rebuild a catalog and it asks for the password, I receive the following error 'RefBackupsetContainer...TCipher is Invalid'". Is that the error message you were getting? iodigitale didn't say whether he was doing a Rebuild of a Storage Group or a stand-alone Media Set, but—judging from the number of Media Sets in his screenshot—I'd guess it was a stand-alone Media Set. He said he's using "the latest Retrospect 18.1.1 (120) on the Mac".

(Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here. Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.) iodigitale, First, this sub-Forum hasn't been regularly read by anybody from Retrospect Technical Support for the past 2 years or so. The post by the head of RTS here in another thread is a rare exception (I think he scans posts that use his name). So you'll have to submit a Support Case; here's how to do that. Second, I'm wondering whether the error message you received is the same as the one twickland reported receiving in the next-to-last paragraph of this OP in another thread. He didn't say what that error message was, and in this later post in the same thread said and thus never filed a Support Case for the problem. Maybe there's a bug in Retrospect Mac 18 for password Rebuild even of stand-alone Media Sets.

(Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales. I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here. Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.) iodigitale, First, this sub-Forum hasn't been regularly read by anybody from Retrospect Technical Support for the past 2 years or so. The post by the head of RTS directly above yours is a rare exception (I think he scans posts that use his name), and it looks to me as if the engineers' bug fix in Retrospect Mac 18.1.0.113 he referred to didn't actually fix fredturner's problem. So you'll have to submit a Support Case; here's how to do that. Are you, like fredturner, using a Storage Group? If so, be sure to say that in the Problem Statement of your Support Case. A major advantage of a Storage Group is that it can be backed up to from a maximum of 14 Sources simultaneously—each Source backed up in its own Activity Thread to a separate component Media Set. Maybe the engineers put in code that resets Preferences -> General -> Allow ___ Activity Threads to 16, ignoring the possibility that an administrator is running Retrospect on a "backup server" that doesn't have enough RAM or enough processor speed for 14 generated component Activity Thread sub-Scripts—plus one for a possible parent Proactive Script and one for the overall "backup server". If you are instead using only stand-alone Media Sets, my guess is that you've run into the aggressive re-introduction of "value pricing" for lower-priced Editions in Version 18. As described in both tables (Windows and Mac) in this official Retrospect document—linked to from this Knowledge Base article, the Solo and Desktop Editions are now limited to 2 and 4 concurrent Script executions—meaning Activity Threads for Retrospect Mac—respectively. (Those Editions used to be limited to only one Script execution at a time, but that limitation was removed—I'm told by a single engineer acting alone—a couple of years ago.) My guess is that the re-introduced limitation on concurrent Script executions was made dependent solely on the Edition license, ignoring what the user may have put into Preferences -> General -> Allow ___ Activity Threads in a preceding execution of the Console. (Here in the Retrospect Mac cumulative Release Notes for 18.1.0.113 is an example of a fix for a mess-up in 18.0, where AFAICT Preferences -> General -> Allow ___ Activity Threads was being reset purely based on Edition. ☹️ )