Jump to content

DavidHertzberg

Members
  • Content count

    1,281
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by DavidHertzberg

  1. MrPete, Being a Mac user, I have no experience with VSS—but will this help?
  2. DavidHertzberg

    Only Have RDB Files

    wanderlust, I did use the word "may"—which I have now italicized—in the second and third sentences of the second paragraph of my latest up-thread post. So IMHO you shouldn't find the accusation in the third sentence so offensive. As to it's being ridiculous, another Forums thread deals with a security threat that is extremely similar to the one I posited in that third sentence, described starting with this post in that other thread. In fact the help you ask for in your OP in this thread is exactly the question a hacker who had generated an unencrypted Cloud backup of someone else's data per Malcolm McLeary's post would ask, namely the method by which he/she "simply Recreates the Catalogue for this exfiltrated Storage Set [an ancient Retrospect term for what is now termed Media/Backup Set] , on another machine running Retrospect and restores whatever they want." We can Google "Malcolm McLeary" and "Australia", so we pretty much know what he is. You, OTOH, have provided zero information about yourself in your three posts in this thread, so a little belated suspicion on my part seems perfectly justified. I realize that many posters on these Forums don't use any variant of their real names as "handles" and conceal their occupation, mostly IMHO because they're consultants or employees who are expected to conceal for whom they're working or to already "know it all". I fall into neither category, so my "handle" since registering in 2004 has been my real name and my Location is where I live. You've "never used retrospect before", so why not tell us a bit about yourself to avoid suspicion from people like me? If you need further help from me, please post again in this thread after you've talked with the head of Retrospect North America Sales. I made a typo in my second up-thread post, which I've since corrected; I meant "Retrospect application registration". BTW when I wrote up-thread "If the RDB data on your backup HDD is encrypted, you won't be eventually be able to do a Restore", I assumed the password for any Media/Backup Set encryption had followed your alleged relatives and their machines to their graves. We should all take to heart item 5 on page 11 of the Retrospect Mac 17 User's Guide:
  3. DavidHertzberg

    Only Have RDB Files

    wanderlust, I'm sorry that I gave you the wrong Retrospect operation in my up-thread post. However, when I started thinking about your latest post this afternoon, my suspicions were belatedly aroused. You may in fact be what you said you are in the OP: the descendant of a Retrospect-using family. OTOH you may have illegitimately acquired someone's backup drive, and be trying to restore it for illegal purposes. Please phone the head of Retrospect North America Sales at (925) 231-1313, so he can have the head of Tech Support cross-check your 24 August Forums registration with a prior Retrospect application registration. If the RDB data on your backup HDD is encrypted, you won't be eventually be able to do a Restore. My backup HDDs aren't encrypted, because they're either in my apartment—behind a door with 2 locks—or in my bank safe deposit box. Maybe I should think about encryption.
  4. DavidHertzberg

    Only Have RDB Files

    wanderlust, I'll assume that your family's computer—as opposed to their HDD—is lost or inoperable. You haven't said whether your family used a Macintosh or a Windows computer,, nor have you estimated how old it was, nor have you said whether you accessed the HDD containing the RDB files on a Macintosh or a Windows computer. But—since you've posted in the Forum for Retrospect Macintosh versions since 2011—I'll further assume the answers to the questions in my preceding sentence are Macintosh, no more than 9 years old, and Macintosh. But the answers to the first and last questions could just as well be Windows and Windows. Based on that, what you need to do is install the Retrospect "backup server" application on your own computer, Rebuild a Catalog File on it from the RDB files, and use the Catalog File to Restore the files onto another drive—possibly a USB thumb drive if the total size of the restored files is small enough. I suggest you phone Retrospect Sales at (888) 376-1078 option 2, and ask about whether you can do this with the Retrospect Solo Edition—which I've never used (I have the Desktop Edition because I backup "client" computers as well). If the Sales person says yes, ask if Solo Edition comes with 30 days of free Technical Support for the US$39. If he says no, cagily ask about more expensive Editions—which come with a 45-day free trial that may be all you need. You may not need the Tech Support, because there are video tutorials here for Retrospect Mac, and here for Retrospect Windows. The tutorial for Restore using Retrospect Mac is under the "Legacy" heading, and the tutorial for Rebuild is under "Tools", because nobody in Product Management got the over-worked head of Retrospect Tech Support—who makes the best videos at Retrospect "Inc."—to make more recent ones. No matter; the GUI for Retrospect Mac basic operations hasn't changed since Retrospect Mac 9. You probably want to just Restore the files and folders for Users, or the Windows equivalent, because the applications on your family's computer may not still run on your computer. However you should be able to find applications that will open the restored files on your computer, given that the "lots of memories" are probably in formats that newer applications can still read. Good luck! 😀
  5. DavidHertzberg

    Yet another -530 client not found error

    Oh it's a long long way, from October [2019] to May [2020]. Nigel Smith, You said directly above: My impression—subject to correction—is that MrPete is saying ipsave doesn't work in his circumstances, which include a "client"'s network connection changing. However Retrospect Mac has for years had an option preventing a "client"'s user starting or stopping the Client (pp. 85-86 in the Retrospect Mac 17 User's Guide), and Retrospect Windows has the same option (pp. 236-237 in the Retrospect Windows 17 UG). AFAIK Product Management had the engineers add this option, years ago, because some ordinary users were suppressing Retrospect backups to avoid slowing down their "client" machines. My suggested automation would simply enable the Client to do its own stop/start, without allowing or requiring the machine's user to do it. I recommend that you avoid holding your breath waiting for either Retrospect "Inc." or Microsoft to come up with a permanent fix to the underlying problem. Retrospect engineers seem too busy implementing StorCentric's priorities (2nd long prgf.) to do a deep analysis required for a permanent fix. Microsoft may consider the problem too unimportant for most Windows users to have its own engineers do the analysis and fix. That's why I suggest the stop/start automation, which may be simple enough for a Retrospect engineer to do while waiting for Drobo hardware to become available again. P.S.: What I wrote in the preceding paragraph may have been too pessimistic. 😁 I just talked to someone in Retrospect Sales about another matter, and a fix for bug #8512 is supposed to be in a Retrospect 17.X release scheduled for September–October 2020. So you can start holding your breath.
  6. pjreagan, How about the comparative number of files backed up, vs. the total bytes? Lots of smaller files means a slower backup and compare than fewer larger files. If there's a significant difference in the processor speeds between "AG-04" and "DD-13", that will also affect the Retrospect "client" backup speeds. This post in a 2017 thread, especially the first two paragraphs (the P.S. mostly rules out speed of the "backup server" for "client" files), covers the first part of experiments I ended up doing that have a bearing on this. This post in that same thread, and the one following, covers the rest. This post near the end of the same thread discusses my hypothesis on slowness of "client" backups. P.S.: This ArsTechnica Mac forum post says "My 2012 Era iMac with 1Tb Fusion Drive is starting to really slow down. It seems like when the drive is nearly full, the physical drive doesn't like to spin up anymore. ugh."
  7. DavidHertzberg

    Yet another -530 client not found error

    MrPete and Nigel Smith, I see MrPete diagnosed the Windows Client problem—under "Here are anomalies ..."—in an up-thread post last October. It's that Windows is assigning an APIPA address, possibly because DHCP services are not available in the "wandered-to" subnet. This krypted article gives a brief explanation, and also outlines (one can Google "APIPA Windows" for detailed—and possibly obsolete—instructions) a way of disabling APIPA for the laptop. Of course one should also investigate why DHCP services aren't available in the "wandered-to" subnet; maybe there's a problem with that subnet's router. Now let's consider how the Retrospect engineers might fix the APIPA problem entirely in the Windows Client, without allowing and requiring the laptop user to manually stop and restart the Client (see pg. 237 of the Retrospect Windows 17 User's Guide). This would be an automated version of running a stop/start script to do it. The Client would have to detect that it had been assigned an APIPA address, and then to stop and restart itself. Based on my obsolete and cursory Computer Science knowledge, that would require the Client to be multi-threaded—with the stopping and restarting of the main thread embodied in an auxiliary thread. Based on my observation of the history of Retrospect, combined with my complete lack of knowledge of the Client source code, I doubt that the Windows Client is now multi-threaded. So IMHO fixing bug #8512 would demand a significant engineering effort. I had a phone conversation with someone in Sales this afternoon, and there's a 17.1 release planned for September that may include a fix for bug #8512. An alternative "motivating" approach would be to send an e-mail to the new StorCentric boss of the head of Retrospect Tech Support, who may have influence with Retrospect engineers. He's David Bartizal, and his e-mail address is dbartizal@storcentric.com. That address was supplied by the VP Service & Support himself, in the e-mail conveying his request to fill out a SurveyMonkey survey on handling of an unrelated Support Case. P.S.: The automated-stop-restart solution I suggested in the second paragraph would be inappropriate for an installation set up per Nigel Smith's last paragraph directly above, and for one that isn't supposed to have a router—because the krypted article says "APIPA is a dhpc mechanism that provides dhcp clients with self-assigned IP addresses when DHCP servers are not available." How would you disable the automated-stop-restart solution in such cases? Possibly the Retrospect "backup server" could be enhanced to automatically create and test a 192.168 ... Subnet if there are no Subnets defined, and set a flag in every Client installed using that "backup server" if the 192.168 Subnet fails the test. Would disabling per that flag do the trick?
  8. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, and MrPete, Getting back to what Gilbert and Sullivan might have termed the "poor wandering laptop", I have two suggestions for that -530 problem. My first suggestion is based on henry-in-florida's suggestion, which I tried in late 2018 and which worked. That is to define the laptop as a Source using Subnet Broadcast, and to define all possible Subnets on which the laptop might appear (see pages 228–9 of the Retrospect Windows 17 User's Guide). If you do so, the "backup server" uses Piton Name Service in turn on each defined Subnet to find the "client" by its Computer Name (or the Windows equivalent). This, of course, assumes that the "client"'s Computer Name is not used for different machines in different Subnets; if e.g. Martha in Meteorology takes her laptop from the Science Building when she goes over to the Engineering Building to work with Martha in Materials Engineering on designing a sturdy mast for measuring wind speeds inside tornadoes, and each woman has a different machine named "Martha's Machine", the "backup server" will get confused. Subnet Broadcast actually solved my -530 problem for a month starting in 2018 even though IIRC I had no defined Subnets, but I then switched over to using Direct Access with fixed DHCP IPs defined in my router. The second suggestion is based on an approach I came up with in early 2017, when I started getting -530 errors after upgrading an Ethernet switch. That is to add a preliminary "sacrificial" Backup script backing up each "wandering laptop", as described most clearly in the second paragraph of this June 2019 post. You don't care whether or not the "sacrificial" script gets -530 errors, because using the No Files Rule (No Files Selector for Retrospect Windows) means it's not going to back up any files regardless. The cost is 4 minutes or so of run time. The voodoo idea behind both of these suggestions is that a "client" needs time to "straighten up and fly right", rather than being backed up immediately by a "backup server" Engine that is in the process of initializing itself.
  9. DavidHertzberg

    Yet another -530 client not found error

    rfajman, Thank you for, 3 months later, confirming my point in the post you quote in the post directly above this one. As I'd guessed, the WHATSIS is hardware. My "backup server" doesn't have more than one NIC, so I never knew Interfaces—described on page 297 of the Retrospect Windows 16 User's Guide—are a Retrospect feature (which is why I'm now initial-upper-casing "Interface"). But I don't know how you'd run within Retrospect "a command file that runs in the background", much less one that "periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary." It sounds as if you actually run a Windows command file that checks and reestablishes a proper Windows configuration of hardware and/or software—one that is reflected within a Retrospect Interface. Since you mention "pretty high speed wireless Internet access provided by the place where we live", it also sounds as if your Gigabit Ethernet switch is used only for Retrospect backups. That would imply you are having a periodic hardware or Windows problem with your switch, which your Retrospect Interface "sniffs out". I suggest you temporarily modify your command file to not reestablish the proper configuration, but instead to send you an e-mail or other message. When you get that message, you should then test communication over the switch using programs other than Retrospect. As x509 wrote in response to your 1 June post, "Can you post this [command file] script. Thanks." Please post the un-modified reestablishing version.
  10. DavidHertzberg

    Yet another -530 client not found error

    MrPete,—and maybe x509, With my simple-minded experience, I'm having trouble understanding why for you "an endpoint changes its IP address". I remembered something about a problem Nigel Smith had in the past, but couldn't find the thread for most of an evening. Here it is, starting—for your purposes—with this post describing a procedure that worked for him. The remainder of that thread explains his situation, ending with a post that explains why his procedure is the only one that solved his problem—which may or may not be similar to yours. (My simple-minded experience consists of an home installation with a "client" in the study and a "backup server" in the bedroom. In 1998 I replaced my previous PhoneNet network with a re-purposed piece of in-the-wall coaxial cable running between the two rooms, now attached at each end to a MoCA adapter in turn cabled to an Ethernet switch. I did a test two years ago, and discovered that 802.11g WiFi between the two rooms only ran at 20% of the cable speed—because of multiple Sheetrock walls and a refrigerator in the signal path. Thus WiFi on all my computers is turned off, so I never have any endpoint address change—unless I alter my "client"'s static DHCP IP in my router that's specified in its Sources definition's Direct Access address.) You might consider his 10-step procedure, because it handles a 2-subnet-with-Fortigate-switching problem that's IMHO at least as generalized as yours.
  11. DavidHertzberg

    Yet another -530 client not found error

    MrPete and x509, It sounds as if both of you could use the "ipsave" command described in this Knowledge Base article. This 2019 post in another thread and its follow-ons describes the command's successful use on Windows "client" machines. Other posts you can find by doing a Forums search for "ipsave" describe its successful use on Mac "client" machines, but as a Mac user I didn't want to scare you. The facility was added in Retrospect Windows 10.0, but—starting with that release in 2015—Retrospect Inc. adapted a policy of having the "What's New" chapter in the User's Guides be written by marketing-oriented Product Management people—and having the information in that chapter overwritten in the next UG release. In this case, the astonishingly-specific 🤣 information was: x509, Here's an Ars Technica post by a Drobo user (I'm not one), written in response to my announcing that Retrospect Inc. had been acquired by StorCentric—which also owns Drobo. I saw somewhere in the last year or so that disks used in a Drobo NAS, which can be of different sizes—a formerly-touted feature, can only be read by another Drobo NAS because of proprietary formatting. IME the head of R. T. S. will hit the roof if we say anything too critical.
  12. Nigel Smith, I wrote in this up-thread post "I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it." But IMHO your subsequent posts have not so far really "beaten me to it". That "next issue"—really three "ifs" in one long sentence, covered in your more-upthread post, was: My opinion on the first two "ifs" is based on what I wrote in the last two sentences of the first paragraph and entire second paragraph of this even-more-upthread post. It is that Remote Backup, designed for machines that don't have predictable Internet addresses, will backup any machine having the exact "backup server" Tag "Remote Backup Clients" that "reaches out" to the "backup server" with a public key that is in the "backup server"'s Remote Clients table. So long as such a "client" machine remains truly Remote, a Proactive AI script specifying "Remote Backup Clients" will back up any machine having that Tag—even if your home router's IP changes or you take the laptop to a different location. My opinion on the third "if" is based on my personal experience that Retrospect Mac 16.6's Piton Name Service will override Add Source Directly, so long as the Computer Name matches what is defined for that Source on the "backup server". So if you now (the word I'm sure you meant) take the laptop in to work and plug in to the non-subnetted portion of your LAN, Retrospect will back it up—assuming its Computer Name is unique in the non-subnetted portion of your LAN and has not changed from when a Proactive script added it to Sources. If you've done further testing on these "ifs", please post your results. P.S.: Two days after writing the "third 'if'" paragraph, while disabling access by my Retrospect Management Console to my "backup server" for security reasons (see P. S. and P.P.S. of this post in another thread), I looked at the definition of my MacBook Pro in Sources. I noticed there an interesting Ignore Client Discovery option. The cumulative Retrospect Mac 17 Release Notes have, under "Network" for Retrospect Mac 12.0: That sounded applicable to your "third 'if'" paragraph, so I searched the Forums and found this 2018 thread. lstone19, in his OP there, seems to confirm my own experience of what happens if that option is not checked. Which means if you now take the laptop in to work and plug in to the non-subnetted portion of your LAN, Retrospect will back it up—assuming its Computer Name is unique in the non-subnetted portion of your LAN and has not changed from when a Proactive script added it to Sources. The reason I say "non-subnetted portion of your LAN" is because I assume that— when it can't access the Sources-specified IP address for that Computer Name—Retrospect Mac 12+ interprets the access method Direct IP as if it were Multicast, but if you have subnets defined it might interpret the interface as Subnet Broadcast. Try it and let us know. 😃
  13. svennd, You don't say which variant of Retrospect you are using, but since you use the term "snapshot"—which has been banned for the Retrospect Mac GUI since version 8 (Engine messages still use the term, since the Engine is common code underneath the variant GUIs)—I'll assume it's Retrospect Windows. Pages 8–9 of the Retrospect Windows 17 User's Guide are a minimal description of how to generate the new Restore Preflight report for a snapshot. What it generates is a CSV, which presumably you have to import into a spreadsheet program (whatever that is; I assume one candidate is Microsoft Excel) in order to read. The front screenshot on page 8 of the Retrospect Mac 17 UG shows how to tell that variant of Retrospect 17 where to save the CSV using a macOS GUI dialog. I assume the corresponding Windows GUI dialog would be similar, but whoever in Retrospect Product Management wrote the "What's New" chapter of the Retrospect Windows 17 UG seems to have felt it was more important to show a screenshot of how to generate the CSV—owing to the crufty old GUI of Retrospect Windows (guess which variant I use 🤣 ).
  14. DavidHertzberg

    Retrospect Management Console

    Nigel Smith and anybody else, Here's a March 2020 article titled "How to Set up an iPhone VPN"; if you don't want to use a VPN app, look at the section "Manually Configure a VPN on iOS". I don't have any kind of "smart phone"—much less an iPhone—so I haven't tested out the procedure. Malcolm McLeary and anybody else, I had written an e-mail to the head of North America Sales, asking whether my temporary solution to the security hole in the Retrospect Management Console—that you had identified—would work. When I didn't get a reply I followed up with a phone call voice mail, to which he replied late Friday afternoon. He said he'd just come out of a meeting, and mentioned that there's now a supply chain problem for Drobo devices (I think we can guess where those are manufactured 🙂). I don't know how that'll affect the StorCentric-dictated priorities mentioned in the last sentence of this post in another thread; i.e. whether it'll permit diverting engineers to fixing the Retrospect Management Console problems discussed in this thread sooner or not. I didn't want to interrogate the head of North America Sales on whether this Retrospect Management Console answer will work; after all, I'd be asking a salesperson whether there's an additional feature available at no charge—without paying for the Management Console Add-on. So after a couple of days I tried it this morning; it seemed to work using a Retrospect Mac 16.6 "backup server"—but see the P.S. on Sales "helpfully" giving me the Add-On license. On my MacBook Pro "client" I executed the "Account Creation" procedure in this document, using my regular e-mail password and the Forums password it defaulted to. When I got the confirmation e-mail I clicked the Confirm Account link and assigned an organization name. I copied the UUID from the dialog onto a piece of paper, walked 45 feet to my Mac Pro "backup server", booted it and immediately paused all Retrospect activities, and followed the "System Setup" procedure's "Retrospect Backup" sub-section in the document—copying the UUID from the piece of paper. I then un-paused all activities, went to my MBP's Firefox browser, and opened a tab with the URL https://console.retrospect.com/dashboard?—which inserted the machine= and organization= fields at the end of the URL. I then clicked the name of my "backup server" in the left-hand column, and got a Dashboard delayed behind the actual "backup server" by 2 to 4 minutes. I guess that's the Heroku updating lag—RMC 's price you pay for not having to VPN into each site separately. I can log out the Management Console from my MBP, close the tab, and re-open it again with the the same URL—which on my MBP fills in the remaining fields. When I then click the Log In button on the top right of the Web page, entering the e-mail address I used for Account Creation and putting in the password—with no 2FA—gets me to a Dashboard panel. Above the Dashboard are additional buttons for Past Activities, Sources, Sets, and Scripts; clicking one switches to an appropriate panel. However this enables the security flaw Malcolm McLeary has identified—see the P.S. for why. Clicking the Scripts button gives me a panel with a New Script button on the top right; clicking that appears to enable me to create a new Proactive Script 🙄. Therefore I intend to disable Management Console on my Mac Pro's Retrospect Preferences, since I have no need for it so long as I can walk 45 feet. P.S.: A possible reason the security flaw is still present is explained in an e-mail I got yesterday afternoon from another Retrospect Inc. salesperson just as I was leaving for an appointment. It said he had given me a Retrospect Management Console Add-On license for free, apparently because my posting activity on these Forums—for which I'm not paid—is considered helpful for Sales. The e-mail apologized because the Add-On license might not have worked; when I returned home I hurriedly phoned back and asked the salesperson to remove the Add-On license, which I had intentionally never asked for. But I later created a new RMC with a different log-in, and it too has a working New Script button; see the P.P.S. P.P.S.: That Sales e-mail requested I re-sign-up for a Management Console, which I did this afternoon using a different e-mail address. That Management Console had—as I hoped—only a functioning Dashboard the first time I logged-in, but later logins give it access to Scripts and the ability to create a new flawed script. (Possibly the "gift" Management Console Add-On license applies to my "backup server", not the RMC itself; I'll check by phone later today.) AFAICT I don’t have Remote Granular Management or Shared Scripts; sounds as if my "backup server" doesn't have the Add-On. P.P.P.S: This morning's No Media Action backup of my MacBook Pro—while running and afterward—displayed Past Activities, Sources, Sets, and Scripts on RMC using my newer e-mail address—so the "backup server" security flaw still exists for the RMC . That means my temporary solution doesn't work, so Malcolm McLeary should pursue a permanent solution—2FA or "Backup Sets Must Be Encrypted" preference. BTW naming of backed-up drives in segments on RMC Backup Report and Backups bar chart panes is erroneous, as it is on my Retrospect Mac 16.6 Dashboard panel—with different errors. P.P.P.P.S.: Early on 16 August I submitted a Support Case (note to self: #75170) covering the problem, my test, my suggested enhancements—both "Cloud Backup Sets Must Be Encrypted With AES-256" preference and disabling RMC New Script without the Add-On, and your suggested enhancement. Early on 17 August I submitted a Support Case (note to self: #75180) covering erroneous naming of backed-up drives in segments on RMC Backup Report and Backups bar chart panes.
  15. Nigel Smith, Notice that I rewrote my two preceding posts in this thread, here and here, to explain what I think is going on with Remote Backup in light of your tests. Everybody, I had written an e-mail to the head of North America Sales, asking whether my temporary solution to the security hole in the Retrospect Management Console that Malcolm McLeary had identified would work. When I didn't get a reply I followed up with a phone call voice mail, to which he replied late Friday afternoon. He said he had just come out of a meeting, and mentioned that there is now a supply chain problem for Drobo devices (I think we can guess where those are manufactured). I don't know how that will affect the StorCentric-dictated priorities mentioned in the last sentence of my immediately-above post; i.e. whether it will allow the engineers to divert to fixing the Retrospect Mac problems discussed in this thread sooner or not.
  16. DavidHertzberg

    Tag selection whack-a-mole

    eeolson, I'm not one of your followers; I merely looked at your past posts in your Forums profile by clicking on your name. The underlying code for the "backup server" Engines of Retrospect Windows and Retrospect Mac has been the same since late 2009. The "stagnation" between Retrospect Windows 7.7 and 17 was only in the UI, which has been kept the same partly because of the bad reputation for reliability and temporary hardware compatibility restrictions of Retrospect Mac 8 (which was developed in a hurry after EMC reversed an end-of-lifing of the product)—but mostly because of a Windows limitation described in the second paragraph of the Wikipedia article section here. Retrospect Mac 9 fixed the problems in Retrospect Mac 8; this immediately-preceding WP article section describes its enhancements. Starting with the next WP article section is a version-by-version listing of the enhancements in the "backup server" between Retrospect Mac 10 and Retrospect Mac 14, which correspond to those of Retrospect Windows 8 through Retrospect Windows 12. Retrospect 15 (whose Windows version number was bumped from 13, in order to restore version number parity with Retrospect Mac 15) enhancements included e-mail protection, what is now called ProactiveAI, Remote Backup, data hooks, and the beta of the Management Console. Retrospect 16 enhancements included Storage Groups, deployment tools, and the features of the Management Console Add-On. Retrospect 17 enhancements include Automated Onboarding for the Management Console, speeded-up ProactiveAI, and Restore Preflight. In short, versions of Retrospect Mac beyond 8 exceed (green flags) just "patches that are packaged and sold as expensive upgrades". After using Retrospect Mac from 1995 to 2010—ending with Retrospect Mac 6, I started again using Retrospect Mac 12 in 2015—following a five-year hiatus caused by the death from old age of my ancient "backup server" machine (whose PowerPC hardware was incompatible with Retrospect Mac 8). As I said in the second paragraph of my post directly below your OP, I'm still using Retrospect Mac 16.6—because I don't need the new features or bug fixes so far introduced with Retrospect Mac 17. Nobody else on these Forums has reported a bug with the stickyness of Tag checkmarks. Some administrators—including me starting with Retrospect Mac 14—have had problems with -530 errors on client access, but I discovered a couple of years ago that I could eliminate those errors by using the “Add Source Directly” button at the bottom of the Sources->Add dialog (item 6 on page 74 of the Retrospect Mac 17 User's Guide). In response to my Support Case, Retrospect Tech Support has agreed that my submitted logs show a problem—caused IMHO by macOS/hardware changes that affect the Piton Name Service's use of Multicast—which the engineers haven't yet been able to isolate. What you describe for for your Proactive scripts sounds like a problem that was supposed to be fixed by the "ProactiveAI" enhancement in Retrospect 15. Precisely what version of Retrospect Mac are you using—not just for the Clients but for the "backup server"? Maybe your "backup server" is still running Retrospect Mac 12 (click "About Retrospect" in the "Retrospect" menu), because you're convinced you don't need to spend money upgrading. 😒
  17. (The disclaimer at the top of this post in another thread applies here.) Nigel Smith (the Forums ate my previous version of this post early this morning), When I said "sloppily written section of a KB article", it was with full awareness that from 2015–2020 the "official" documentation for Retrospect features was written by engineers as a series of Knowledge Base articles—some of which were in March 2020 copied as Appendixes to the User's Guides, IMHO partly because Retrospect Inc. could no longer afford to hire a tech writer to update the UGs. That full awareness extends to the notorious decades-long inadequacies of the engineers' alpha-testing that extends all the way back to the Dantz days (read the next page of Ars Technica 2016 Retrospect thread posts following this one). So I'm pretty sure that the engineer who wrote the KB article on Remote Backup alpha-tested his own kludgy feature by taking a machine that had already been backed up as one of a "backup server"'s Sources and having it connect remotely to a Proactive script. Sloppy test + doc. The foundation of the kludginess you've now encountered starts with the Automatically Add Clients option. Maybe it used "the industry standard method of onboarding work computers that are to be used remotely" as of 2009, but it's a potential kludge. Quoting from page 72 of the Retrospect Mac 17 UG: But the kludginess comes into full flower with the Remote Backup feature, which IMHO was developed as part of the 2018 "go big or go home" strategy. You've now discovered that it introduced a contradiction. Quoting from the " Server-Side Retrospect Engine Configuration" section of the 2018 KB article: In your testing, the running Proactive script created an ugly Add of a new Source before the running Engine was able to Automatically Add. Lucky you, 🤣 you get to write the Support Case—copying your posts above—because I can't repeat those experiments in my diminutive installation. If I were Emmanuel Macron, I'd award you the Croix de Guerre; if I were J. G. Heithcock, I'd be disturbed you found this contradiction. But the priorities of StorCentric—which wants a Drobo "backup server" (that post's 2nd long paragraph)—now over-rule those of Heithcock; don't expect the contradiction to be fixed this year.😎
  18. I don't think you read my preceding post thoroughly enough, Nigel Smith; perhaps I wrote it without enough concrete examples. Your scheme would work for RecentlyRemote "client" machines, but not for AlwaysRemote "client" machines. That's because there's no "client record" on the "backup server" for an AlwaysRemote "client" machine. It seems the Automatically Add Clients option will cause a Proactive script to create one, but not one that you like. Here's a couple of contrived concrete examples: Let's first say that I am a PhD Student at the academic institution where you are the backup administrator, and I initially do my research using an on-campus machine that was set up for me. You Added my machine to Sources, so it has a "client record" on the "backup server". Then the COVID-19 pandemic arrives, and you tell me to take my machine and go back to my home somewhere off-campus—where it will have an Internet address that's not on the institution's LAN. That makes my machine a RecentlyRemote "client" which you are still going to backup on your "backup server". Now let's instead say that I have been granted some kind of External PhD Student status, which says that I can do all my research remotely without ever having set foot on your campus. (Maybe I was originally admitted as a regular PhD Student, but I now can't be allowed in Great Britain because I come from the pandemic-ridden U. S..) I'm to use my personal machine for research, and you want to back up the research centrally, but you can't Add it to Sources because there's no way to connect it to the LAN. So there's no "client record" for my machine on the "backup server"—unless a Proactive script creates one per Automatically Add Clients; that makes it an AlwaysRemote "client". This is the original use case for Remote Backup, which IMHO was introduced in 2018 to back up the machines of hired-locally sales or support people; those people would receive all their institutional training via books or Internet, and would obtain their own machines in whatever country they were stationed—such as Sally in Shanghai or Albert in Adelaide. Presumably Retrospect Product Management determined that there were enough customers with such AlwaysRemote staff members that it was worth developing the original Remote Backup feature. Therefore I propose a scheme that will keep the AlwaysRemote capability while adding a RecentlyRemote capability, but introducing a "user-defined matching attribute" that will allow a "member of the class" of Remote tags to be used to specify whether a RecentlyRemote or AlwaysRemote machine should be backed up by a particular Proactive script. I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it. As for where you said I was wrong, you quoted a sloppily-written section of a KB article. If you read that section carefully, you'll see that its "for instance" assumes that the "client" was first given "the initial full backup on the local network". That would make it by my definition a RecentlyRemote machine, not an AlwaysRemote machine.
  19. I don't see how your scheme could apply different "Remote Backup Clients"-derived tags to different "client" machines, and later have a Proactive script recognize which tag should be associated with a particular "client" sending a "back me up" message to the "backup server", without initially having had that "client" machine on the same LAN as the "backup server". You'd want this to happen so that a particular Proactive script could say "my sources include some Remote Backup Clients, but not this one, so I won't even scan it". You pointed out up-thread that a Rule won't avoid scan + snapshot time. The reason your scheme would need to initially have each potentially-Remote "client" machine on the "backup server"'s LAN is that Retrospect provides no other way of defining a machine as a source. That Sources->Add would at a minimum have to capture the machine's Computer Name, because the machine's later "back me up" message would have to include the sender's Computer Name to allow a Proactive script to determine whether its list of "Remote Backup Clients"-derived tags applied to the sender. The "client" machine's name would have to be unique on that LAN, although it might only have to be unique to a subnet of the LAN if the machine's Retrospect Client stored—and later transmitted with the Computer Name—the subnet name. It's also not possible to define a Favorite Folder—or an added drive—on a machine that isn't connected to the LAN. (I've checked this out by shutting down the "client" on which I've drafted this post.) However you can add or remove a tag for a defined source. You were able to define Favorite Folders—on their existing drives—for your own laptops because you'd brought them in and connected them to your "backup server"'s LAN. However I'd advise you against having PhDs/PostDocs bring in their machines for temporary LAN attachment, because that's now a good way 🙄 for you—or them—to catch COVID-19. Taking a broader view, there are two different use cases for Remote Backup. As designed by Retrospect Product Management in 2018, the use case was for AlwaysRemote (my term) machines, those that would never be put on the same LAN as the "backup server". Product Management assumed that an installation would only have a few such machines, so they probably didn't worry too much that their phantom-Tag "Remote Backup Clients" would oblige a Proactive script whose sources included that phantom-Tag to back up all machines sending the "back me up" message. However Alanna's OP in another thread was the first on these Forums to discuss the RecentlyRemote (my term) use case, in which she evidently planned to back up—as split up among different Proactive scripts—many machines that had been recently moved for Work From Home in the same time zone. As I've said in the preceding three paragraphs, that won't work with your scheme unless the RecentlyRemote machines are first brought or sent to the "backup server"'s LAN location—and unless Proactive scripts and the Retrospect Client Installer are both enhanced to store Computer Names to be included in the "back me up" messages. I think my suffix scheme would be preferable, because it handles both the AlwaysRemote and RecentlyRemote use cases. It wouldn't allow you to define Favorite Folders for AlwaysRemote machines, but neither would your scheme per two paragraphs up. Most of the code for my proposed suffix-changing utility already exists, because it's included in the version of the Retrospect Client Installer described for Management Console Automatic Onboarding.
  20. Thank you for your YouTube videos, Nigel Smith; they clarify your "production" use. They show that you first cabled the laptops to the same LAN as your "backup server", and basically followed the procedure from the bottom of page 228 to the top of page 230 in the Retrospect Mac 17 User's Guide. However they show you manually created the Tag "Remote Backup Clients" and used it to identify specific Favorite Folders on your laptops, which explains why those Favorite Folder names appear in your (topmost) screenshot of the Proactive Activity list up-thread. That's what had confused me. What you're forgetting is that Tags are only defined on a "backup server"; they don't appear on the "client" machines that they group together. As I've said up-thread, a truly remote "client" sends a message to the "backup server" whose IP address is stored in server.txt—displayed as the Public Address of its Client. Apparently the message currently says "back me up with any Proactive script; legitimized because I have this public key stored in my pubkey.dat." Page 228 of the UG doesn't explain how the "backup server" knows which backup to on-demand restore for a particular remote "client". Maybe it does so by the IP address stored by a Proactive script in Sources for a particular Remote Client backup, which would explain "Remote Backup: Fixed issue where remote backup failed if client added by name (#7705)" in the cumulative Release Notes for Retrospect Mac 15.6.1. But a remote "client"'s current IP address could have changed. In any case what's needed is a "unique identifying attribute"—as you say, but one stored in association with the Remote Client that can be combined with the Tag "Remote Backup Clients" to designate which Proactive script is to backup that particular "client" machine. I propose a suffix to the Tag, stored in association with the machine's Remote Client. There should also be a simple Retrospect utility program, which would be run by the possessor of a Remote "client" machine to either establish the suffix or to change it. If you repeated your test after the Retrospect engineers instituted use of the suffix for Remote Backup, you'd have to run the utility program to establish a suffix on each of your two laptops. If the salesperson Albert were moved from Adelaide to Beijing with his existing laptop, as described in the last paragraph of this up-thread post, he'd be told to run the utility program to change the suffix The utility would also be used if the possessor needed to acquire or replace his/her remote "client" machine without returning to headquarters; replacement examples—ripped from the headlines 🤣—would be the Shanghai PSB arresting Sally for subversion and then releasing her without her laptop, or Albert taking his laptop on a trip from Adelaide to Kangaroo Island and having it destroyed in the 2020 bushfires. Whether the suffix should be a group number or a multi-character alphanumeric string is a GUI question, although I think a multi-character alphanumeric string (may be empty) is the most administrator-friendly approach. A Proactive script would have to store the suffixes for its Remote Backup sources.
  21. Nigel Smith, You've glossed over the fact that your Proactive script "SG_Test" was evidently created before you "turned off all port forwarding on my router for this test". (Evidence is the script name, where SG stands for Storage Groups.) That IMHO is how you managed to designate Favorite Folders on "Admin's MacBook Air" and "admin2's MacBook" as sources for the script. If you can get one of your PhDs/PostDocs to temporarily install a Retrospect Client on his/her from-the-get-go Remote machine per pages 228–230 of the Retrospect Mac 17 User's Guide, and then create a Proactive script using "Remote Backup Clients" as a source, I predict you won't be able to then designate a Favorite Folder on that machine as a source in that script. All you've shown is that a Proactive script does indeed—or did as of 16.6—generate a list of clients it already has defined, and remembers that list—including possibly-obsolete IP addresses—across "backup server" restarts. Per the cumulative Release Notes for Mac 17.0.1 "Remote Backup: Fixed issue with not logging out clients after ProactiveAI backup (#7967)", your 16.6 script may not be modifying the list for Remote "clients" as it should. I can't test this for you, because I don't have any candidate Remote "clients" that I could associate with my diminutive home installation.😞 You've also glossed over the original concept of Tags: they are merely groups of drives or Favorite Folders that can be referred to in the "backup server" GUI by the same Tag name. The "Remote Backup Clients" Tag is a kludgey perversion of this concept, which needs to be enhanced by something that can be contained in a particular Retrospect Client installation—i.e. a suffix name. Just defining a "Remote Backup Clients - Group 1" to the "backup server" isn't enough; how would you define which truly-Remote "clients" that Tag refers to without particular "clients" identifying themselves as members of "Group 1", using some string associated with their installed Retrospect Client? 😕
  22. I believe I'm right, Nigel Smith. The reason is at the bottom right of your second screenshot, of "Admin's MacBook Air", where it says "Tags: Automatically Added Clients". As to what that means, here's a quote from page 72 of the Retrospect Mac 17 User's Guide, under the sub-section "Using Public/Private Key Authentication with Retrospect Clients": That identical paragraph—under the identical sub-section—is on page 63 of the Retrospect Mac 14 User's Guide, which predates the introduction of Remote Backup. So "Admin's MacBook Air"—and no doubt "admin2's MacBook"—is on what your "backup server" considers to be its network, which probably includes VPN-connected Retrospect-defined Subnets. You haven't said whether the "backup server" is at your work or home location. (However I'm sure Malcolm McLeary, our friendly Forums security guru from Australia, would thoroughly approve of your use of public/private key authentication for these "clients". ) But why didn't "Automatically add clients" just work for Remote Backup; why did the engineers need to do additional programming? Yes indeed, the Remote Backup feature introduced in Retrospect 15 is an extension of public/private key authentication. But the difference is that IMHO (I'm not a networking expert) a Retrospect Engine can't "check the network" in the same way for a Remote Client when that "network" is the entire Internet (and I'm sure the Public Security Bureau of the PRC would object to Retrospect's doing that for a "client" machine—such as the one belonging to Sally in Shanghai—that is behind the Great Firewall). That's why Retrospect Inc. added Remote Backup, in which—as it says on page 228 of the Retrospect Mac 17 UG—"When a remote client contacts the Retrospect engine for a backup [my bolding], the running ProactiveAI script [my bolding] will accept the connection and begin a backup, assuming the destination is available." This is reinforced on the same UG page, in the statement "Scheduled scripts and Immediate executions (Windows-only) are not supported because of their serialized scheduling process. ProactiveAI scripts can schedule backups for any client that is available, including remote clients." In fact the cumulative Release Notes for Mac 17.0.1 have "Remote Backup: Fixed issue with not logging out clients after ProactiveAI backup (#7967)". So "Automatically add clients" is Engine-initiated, but Remote Backup is Proactive-script-initiated. The second sentence of your next-to-last paragraph directly above is simply a restatement of my prefix solution with multi-character suffixes, such as "Group 1", allowed (unless you're proposing numeric-only suffixes with " - Group " automatically inserted, which I think would be less administrator-friendly than even single-character suffixes). OTOH the separate class of tags proposed in the last sentence of that paragraph would save administrators the trouble of typing "Remote Backup Clients" as the start of each such tag.
  23. Nigel Smith, It's the same problem; I just phrased it very badly—so badly that I've now replaced my phrasing with yours in my post directly above your post. Thanks. 😀 However I think your second paragraph directly above indicates you need to re-read the last sentence in the first paragraph and the second and third paragraphs in this up-thread post. I'm not sure you've grasped the idea that a script backing up Remote Clients can't have any pre-existing list of those "clients", because it can't know in advance—directly or by inference from unique "client" names—what their Internet addresses are going to be. Whenever it comes online, each such "client" must send a message to the "backup server" saying "back up my current IP address with any Remote Backup script you've got running that specifies the tag 'Remote Backup Clients', because I know your public key for doing that". My multiple, user-definable, Remote Backup tags solution just expands the message to say "back up my current IP address with any Remote Backup script you've got running that specifies a tag prefixed with 'Remote Backup Clients' and suffixed with a character string I'm now sending you , because I know your public key for doing that". The suffix string would be stored on the "client" in the same public_key folder containing the pubkey.dat file by the Retrospect Client installer, per pages 228–230 in the Retrospect Mac 17 User's Guide. An illustrative but tricky part of my solution would be changing the suffix string stored on a "client", as shown in the following example (which assumes single-character suffix strings): Your London-based company suddenly discovers the unexpected possibility of getting a big product order from a government agency in Beijing, and decides to rush the salesperson Albert in Adelaide there—along with his existing laptop. (For plausibility, let's further assume Albert is a Chinese-Australian with Mandarin-speaking parents, who sent him to "Sunday school" to learn to read and write Standard Chinese.) You must arrange for Albert to change the Remote Backup suffix on his laptop from 'A' (for Australia) to 'C' (for China), so that it will be backed up by the Proactive script intended to back up any of your company's Remote Backup "clients" located in China. There would have to be a Client-installer-supplementing Retrospect utility program for making that change, unless you trust Albert to find the proper file and use a text editor to change 'A' to 'C'.
  24. Excellent investigation, Nigel Smith. However, IMHO as a retired applications programmer, there's about zero chance of the engineers making any substantial change to the way Rules/Selectors are implemented—either moving them forward into the scanning phase or adding AND logic. In regard to the scanning phase, this post ending another thread (read its preceding posts if you enjoy inter-administrator arguments 🤣 ) shows the engineers sped up the scanning phase by nearly 40% in Retrospect Mac 16.0—which enabled them to abandon any attempt to make Instant Scan work with APFS-formatted volumes. (We peasants now know, which we didn't in 2018–Spring 2019, that they had to exert substantial effort in any case because Apple was about to eliminate 32-bit APIs in macOS.) IMHO the engineers are unlikely to slow down the scanning phase for all backups in order to fix an edge case for "no data" backups. I never pay attention to the Dashboard, which has had substantial bugs ever since I first encountered it in Retrospect Mac 12; that's because I know which of the 7 drives has been backed up in my diminutive home installation. In regard to adding AND logic to Rules/Selectors, the engineers haven't yet implemented the GUI enhancement to Retrospect Mac that would eliminate the problem fredturner complained about in the OP of this thread. After Mihir Shah of StorCentric finally lets them do that, IMHO they'll solve the [your re-phrase] "all Remote Backup clients are included in all Proactive/Remote scripts" problem by treating a manually-defined Tag that has the prefix "Remote Backup Clients" as indicating it is eligible for Remote Backup with a script that specifies a Tag with that prefix—as I proposed in the sixth paragraph of this post in another thread. That solution will be a lot less work for administrators to use, and it'll be a lot less programming than what you've proposed.
  25. DavidHertzberg

    Retrospect Management Console

    Malcolm McLeary, I may have found a Retrospect Management Console answer that would satisfy both your desire for monitoring backups and your desire for security with the current version of RMC. It is based on my reading of this "Feature Tiers" section of the Retrospect Management Console documentation. Per the "Features included with Management Console Add-on" sub-section of that section, script creation on an "backup server" Engine seems to require that that Engine not be an "Unmanaged Engine". AFAICT that seems to mean that if a "backup server" doesn't have a license for the Management Console Add-On , then you can't create a script to be run on it using the RMC. That would close the security hole you noticed. Of course that means that your monitoring of an "Unmanaged Engine" would be limited to the Dashboard shown at the top of this "Overview" section of the documentation. But, given that you've updated the Preferences in each "backup server" Engine with the UUID for your Management Console per the "System Setup" sub-section of the documentation, that Dashboard might be sufficient for your monitoring needs. Check with Retrospect Tech Support. P.S.: I wrote an e-mail Sunday night to the head of North America Sales, asking him to find out if my second and third paragraphs are correct.
×