Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by DavidHertzberg

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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, which is a bug-fix release to the 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 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.
  6. 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, based on my guess that the hurried (1 week after) release of 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—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.)
  7. 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). 😎
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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".
  14. (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.
  15. (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 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 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. ☹️ )
  16. (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.) I'm feeling in a slightly combative mood this morning, Nigel Smith; please excuse me. I don't believe a .rdb file qualifies as a database, because there are no "backup server" facilities for doing an Update or Delete of one per CRUD—only a Create or Read. That's because Retrospect 1.0 was released for Mac in 1989 (bottom of the official History article, just above "Patents"). In 1989 large-capacity HDDs were still way too expensive for Mac owners to afford them, so all backup had to be to magnetic tape—a sequential-memory medium. And, by Gadfrey, the first line under "Patents" in that same article is "5150473-Data storage format for addressable or sequential memory media – January 16, 1990, our backup set format". My guess is that the .rdb format had been perfected from Dantz Development's point of view by the time "Retrospect 5 for Windows released. (First Windows release)" in 1999, so they didn't change it then and haven't since. If you want to Delete a .rdb file—even one on HDD or in cloud storage—as opposed to Member removal from a Retrospect Catalog, you must use a "Finder" facility; there's no way you can Update one unless you're a Retrospect "Inc." engineer. The practical consequence of this is that IMHO the source code for doing a .rdb Create or Read must be essentially the same—and be written by Dantz and its successors—for the Retrospect Mac and Windows variants of the "backup server". No doubt there are some variant-dependent fillips required because of differences in the C++ compilers used for the variants, but these would handled by "if #Mac" and "if #Windows" macro expansions in the source code. Because of the application's requirement for reading .rdb files created many years previously, the engineers wouldn't want the format to change. Besides, I'm sure in their minds the .rdb format long ago achieved perfection.
  17. Nigel Smith, Sorry to get you agitated, but I think you're missing the point that—per the quote here up-thread—a Media Set's "data base" is contained in the .rdb ("Retrospect data base", geddit?) files crammed into its Members together with the .session files. The format of these is sufficiently unchanged that, per pages 15–16 of the Retrospect Mac 10 User's Guide, you can generate a Retrospect Mac 10 Media Set Catalog from the Members of a Retrospect Mac 6 Backup Set Catalog. (You recommended this in a post in a 2019 thread.) I've searched the Forums to find an example of someone creating a Retrospect Mac Media Set Catalog from the Members of a Retrospect Windows Backup Set or vice-versa. I can't find one and don't have a Windows machine to test, but I'll bet it can be done—because I'll bet the format of Member files in either variant is the same. Probably twickland should ask Tech Support about it when he files his delayed Support Case. (FWIW, here's a Knowledge Base article that's totally useless.) Let me give you a personal example of the wide meaning of the term "data base", derived from the death of my ex-wife in January 2021. When I finally got access to her non-password-protected iMac several months later, I found a Microsoft Word file she'd created in 2020. The file consisted of 155 comma-separated e-mail addresses, most preceded by a person's name. (If you're curious why I didn't simply use her list from Gmail, I didn't know the password for the Macbook she used for a "don't contact me, I'll contact you" e-mail to 33 people after the effects of lymphoma and its treatment caused her to go into isolation.) I copied each name and its e-mail address into a Contact in a newly-created Group in my Apple Contacts application. That included, for about a dozen e-mail addresses, substituting a '?' for a first name or last name I couldn't guess. I then exported that Group in Virtual Contact File (.vcf) format, and attached the .vcf to an e-mail to my ex-wife's executor—who has used it to generate successive e-mails to those 155 people. The point of this example is that Apple Contacts can qualify as a useful Data Base Management System, but comma-separated lists can't—for the same "data base".
  18. Nigel Smith, DB engines? I'm glad it's a couple of hours since dinner; otherwise I'd get sick laughing.🤣 In this 2010 post by the very-knowledgeable user rhwalker, he said He may still be talking about the Retrospect 6 Catalog File; that format was changed in Retrospect Mac 8, to the extent that Retrospect Mac 6 Catalogs were initially non-convertible. However I'm still running Retrospect Mac 6.1 on an old Mac to back it up; I just looked at one of that Mac's Catalog Files with TextEdit, and it's incomprehensible. twickland, I see you're looking at the Forums again.😄 Can you please post a Support Case now, supplementing my Support Case #80364, to help engineering figure out the -2262 and Rebuild errors in your OP in this thread? If you do that, maybe we can get an 18.x bug-fix release that'll let you use a Storage Group again. Can you please furthermore clarify why you are using Password Only protection for your Media Sets? Despite its inadequate documentation in the User's Guides, I already had figured out what the head of Tech Support said in his e-mail reproduced here up-thread. Let's pretend I moved to the UK and went to work for you in IT. Assuming you had to keep your "backup server" running 24/7, you might simply want to password-protect your Media Sets to prevent me stealthily doing a Restore to my own machine of confidential files you had backed up from management's computers. OTOH, if your installation processes information you want to keep secret from the Chinese, you might want to encrypt your Media Sets in case I were an undercover spy for the Ministry of State Security or the People's Liberation Army. However Retrospect encryption would slow down your backups because it's software-only, so you might be willing to be satisfied with with Password Only because of my (let's further pretend) having been vetted by MI5. Is this analysis correct?
  19. At 9:13 a.m. EST—2 hours before Retrospect "Inc." normal CA opening time on July 26th, I received the following e-mail—which is a copy of an Additional Note in Support Case #80364: At last, after nearly two weeks, some action! I guess Tech Support believes this issue is a bug. 😁 Nigel Smith, I took a look tonight at the contents of StorageGroupTwickland.rbc and "Macintosh HD.rbc" using TextEdit. I can't figure out any of the contents (maybe the engineers are obfuscating it for security), but the contents of the first .rbc file is much less than the contents of the second .rbc file. The log for my daily Backup script run this morning said "Finished scanning backup set data files to Backup Set Media Set White". I think that's adequate evidence for "Same actual code but compiled per platform", with "if macOS then mac_db_code else win_db_code" not being applied to all log messages. As per up-thread, it's obviously applied to the Retrospect Windows "backup-server"-only GUI (ancient, but more modifiable than Retrospect Mac Console).
  20. GTA_doum, First, you don't say what version of Retrospect Windows you are running. Given that this Wikipedia article says Windows Server 2016 has at least two successors, I suspect you aren't running the latest Retrospect Windows release. But that may not matter. Second, you don't say how much bigger your "bigger drive on a replacement computer" is. Does that "replacement computer" have a version of Windows Server already installed? If so, and you want to keep it, you'll want to restore only the non-OS portions of what you have got backed up—and the drive on the replacement computer must be big enough for those plus the OS that's already there. If not, then you'll want to wipe the drive on the replacement computer and— with enough space—follow the applicable "Disaster recovery" procedures on pages 316–328 of the Retrospect Windows 16 User's Guide. Finally, you don't say whether the "bug" that "is still present" gives you the same error message -3045 as in rfajman's OP in this thread. If so, I suggest you read the same 2014 Knowledge Base article I suggested he consult in February 2018. My suggestion evidently solved his problem; he was still posting here in 2020. However, I just noticed that rfajman's OP also reported "I got other errors before this, the most significant being Retrospect telling me that it was going to wipe out information on the other SSD, not the one I told it to restore to". In case you were also getting these, here's MrPete's recently-updated thread "ADMIN GUIDE: Hints for success with Disaster Recovery". See the section "Bare Metal Recovery" in that thread's OP.
  21. twickland and Nigel Smith, Last night I repeated the tests reported in this up-thread post, because I was pretty sure I'd remembered the Options phrase incorrectly. After creating "StorageGroupTwickland" as password-protected, with a Catalog on "Macintosh HD SSD" and a large-enough Member on "Macintosh HD Sierra" (an extra partition on the HDD that I originally inherited with my 2010 Mac Pro), I first ran a No Media Action script to backup "Macintosh HD" and then reran the same Backup script adding "Macintosh HD New". At the end of the second run, the Summary Options for "StorageGroupTwickland" still included "Has password". I then did a Rebuild of "StorageGroupTwickland", and discovered that Rebuild elimination of "Has password" really results from kludgey Storage Group implementation. The Rebuild GUI asked me to Add a Member, and the only appropriate Member is "1-StorageGroupTwickland" in the Retrospect folder and "StorageGroupTwickland" sub-folder on "Macintosh HD Sierra". Note that "1-StorageGroupTwickland" is an empty folder; unlike the "1-Macintosh HD" and "1-Macintosh HD New" sub-sub-sub-folders contained within their respective sub-sub-folders in the "StorageGroupTwickland" sub-folder, it contains no .rdb files. Thus, despite what the head of Retrospect Support says in this up-thread post, the Catalog Rebuild process cannot read "the header of the .rdb file to identify if it is encrypted". Maybe Retrospect 18 attempted to fix this, with results per the OP. Are .rdb headers of password-protected Media Sets also so marked, or are they marked only in the .rbc Catalog? Was Rebuild of a password-protected Storage Group alpha-tested?
  22. You're correct about Restore of a client-volume pairing, Nigel Smith; I didn't look closely at the lower part of the Mac screenshot in this section of the KB document.🙁 But that section doesn't make it clear whether doing a Restore from such a pairing will give you the Restore Assistant options as described on page 106 of the Retrospect Mac 18 User's Guide. However I later tried clicking the Restore button, and it gave the options—though I didn't actually do a Restore. I don't have a Windows machine, but I was fairly sure you can't "easily search for every occurrence of 'Important.docx' across a Storage Group". IMHO you're over-estimating the current capabilities of the "meta catalog" for a Storage Group; I looked at one via TextEdit on my Mac "backup server", and it wasn't comprehensible but was quite small. However I later tried clicking the Restore button and using the option to do a search for filenames containing "Retrospect", and it found files in each of the component Media Sets—though I didn't actually do a Restore. The "backup server" source code was made common across the Windows and Mac variants in 2009. I'm pretty sure the only special Retrospect Windows provisions are its still-built-in GUI and its different terminology—which sometimes sneaks into Retrospect Mac messages as "backup set". I'd love "a preference so we can switch both Mac and Win consoles to our preferred method of display". But IMHO as an outsider that doesn't have any possibility of happening—given evident redirection since June 2019 by StorCentric, except as a feature of the projected new LAN Console connecting a Mac or Windows machine to a Drobo NAS variant of the "backup server" via a Web server. That new LAN Console isn't expected any earlier than Retrospect 19.
  23. I much prefer the Retrospect Windows approach, as shown in the "How to Use Storage Groups" KB article. That article shows that, in Retrospect Windows, you can restrict Restore and Transfer (Retrospect Windows term for non-Finder-level Copy) and Verify to a particular Backup Set (Retrospect Windows term for Media Set) without using a Rule (termed a Selector in Retrospect Windows). If that restriction were also extended to Rebuild—which I suspect would be easy as far as the "backup server" is concerned, the OP's original error messages in both this thread and the"Rebuilding only a portion of Storage Group Set?" thread you cite up-thread would have been easily remedied via Rebuilds of the component Media Sets. My guess—as an outsider—is that the "hide the existence of a Storage Group's component Media Sets" approach of the Retrospect Mac Console has as much to do with the relative lack of engineer competence in Console modifications as it does with a difference in philosophical approach. That's not casting an aspersion on any current engineer, only acknowledging the reported departure of the original Console designer some years ago.
  24. Sorry, Nigel Smith, but a Storage Group has one Catalog for itself plus one Catalog for each component Media Set. On my "backup server", within Macintosh HD SSD->Library->Application Support->Retrospect->Catalogs, there's a "StorageGroupTwickland" folder (my naming imagination is limited on Friday nights) with a StorageGroupTwickland.rbc Catalog File directly following it. Within the "StorageGroupTwickland" folder are Catalog Files "Macintosh HD.rbc" and "Macintosh HD New.rbc", created when I successively ran scripts backing up first one—then both—other local drives to StorageGroupTwickland. As a final proof, last night just for kicks I ran another Rebuild of StorageGroupTwickland; the Console Activities panel showed Rebuild activities simultaneously running (different Activity Threads) for StorageGroupTwickland.rbc and the two component Media Sets. As for "no usable purpose", if twickland had been running Retrospect Windows 18 he might have been able to individually Rebuild his component Backup Sets (Retrospect Windows term for Media Sets)—and thus recover his existing Storage Group backup. Of course he would then have had to individually Transfer Backup Sets (Retrospect Windows term for Copy Media Set) for those component Backup Sets to the corresponding component Backup Sets of a new Storage Group that still had the proper consistent password protection, but the Retrospect Windows UI would have enabled him to do that too. IMHO the inadequate explanation of underlying functionality—which I've had to supplement in this post as well as up-thread— in the "How to Use Storage Groups" Knowledge Base article, which has finally simply been copied into the Retrospect 18 User's Guides, is a sterling example of the erroneous policy—begun IIRC in 2016—of having the engineers explain new features in KB articles because it was too much trouble/expense to revise the User's Guides. I'm not casting aspersions on individual engineers—they're not trained as technical writers—but on Retrospect Inc. management as a whole. I'll see if I can test this over the next few days. As for the "nice work", it was mostly recognizing the unexpected when it appeared under my nose.😎
  • Create New...