Jump to content

DavidHertzberg

Members
  • Content count

    1,260
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by DavidHertzberg

  1. DavidHertzberg

    Only Have RDB Files

    wanderlust, The head of North America Sales says someone was trying to do what you want to do, but was stymied because the Media Set was encrypted and the password wasn't available. If that was you and you are a legitimate relative, I'm sorry. If OTOH that was you and you are a hacker, you've provided a security lesson to us all. Now I'll reveal what I should have written in the second paragraph of this up-thread post: You should first find out the name of the Media Set—I'll call it "Whatever" for this example— that was backed up onto your relative's hard drive, by looking at the name of the folder inside the "Retrospect" folder on it. You should then start Retrospect and—clicking Media Sets in the sidebar—Add (not Rebuild) a Media Set with that same name "Whatever". Add's default places the new Catalog File inside Library->Application Support->Retrospect->Catalogs on your own Mac. When Retrospect asks to Add a New Member for "Whatever", you should select the Retrospect->"Whatever"->"1-Whatever" folder on your relative's hard drive. Don't Add any more Members. I've done this in the past (how navigate to Member?), but I haven't newly Removed and then re-Added an existing Media Set on my own "backup server".
  2. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, I'm sorry my last up-thread post consists of four lengthy paragraphs. I felt I had to present my alternative proposals side-by-side in the same post, in order to avoid having the reader bounce back-and-forth between different posts. First, with regard to all my paragraphs except the third, let's go back to what "came out of the horse's mouth" on 5 September. MrPete said: The proposal in my fourth paragraph is to first automate what MrPete said—after the quoted word "than"—would be less easy to do manually. The user (or a script) wouldn't have to do those things if the user's Client had stored within itself—by the "backup server" at Add time—a pre-formatted "ipsave address" for the "backup server". As I said in that fourth paragraph, if the Client found that automation didn't work then it would know (based on the "hide-and-seek principle") it has to restart itself—because otherwise the "backup server" at that "ipsave address" won't be able to contact the Client at the address the Client is bound to. This proposal would also get around the messy fact that an administrator who won't allow the user to stop and start his/her Client probably doesn't want that same user to be mucking about with a manual ipsave. The proposal in my third paragraph emerged from my memory after I drafted all my other paragraphs. Despite what you said in the last paragraph I've quoted at the top of this post, the fact is that a Retrospect Mac Locate command did work when I was having trouble with "clients" Added via Use Multicast—precisely in the case that the "confused client's" Client was bound to an address that the server couldn't reach. Since what's activated by a Retrospect Mac Locate command must be in the Engine's code—which is common to both Retrospect Mac and Retrospect Windows, there undoubtedly is a way of activating a Locate-equivalent that will work for Windows and Mac variants. Figuring out what—if any (because the Retrospect Windows GUI has been intentionally "frozen in stone" since version 7.7)—command in Retrospect Window's GUI is equivalent to a Retrospect Mac Locate is "above my pay grade", but the engineers should be able to activate underlying common Engine code per the proposal in my third paragraph. P.S.: I have now, crediting you, added your post directly below as an Additional Note to Support Case #75559.
  3. DavidHertzberg

    simple question on uninstaller for Mac Retrospect

    d37fc1fe-a25d-4df0-9b52-cb21971f1fde, So are you now running Retrospect Mac 17.0.2.101 Single Server Edition on a separate dedicated Mac? Release 17.0.1.141 especially had a lot of bug fixes, as the cumulative Mac Release Notes show. Most of the bug fixes are for new Retrospect features, which you're probably not using. Unless you're using the new features, I suspect your "troubleshooting and bugs" are mostly because of recent versions of macOS. For about a week I was running Retrospect Mac 16.6 Engine and Console just fine on my principal-machine MacBook Pro, because the 2010 "cheesegrater" Mac Pro I use as a Desktop Edition "backup server" wouldn't boot (which I eventually fixed with a replacement of its PRAM battery). However my MBP is booting macOS 10.13 High Sierra, and my Mac Pro is booting macOS 10.12 Sierra; neither version is recent. I suggest you phone Tech Support—which no longer reads the Forums—at (888) 376-1078‬ ext. 3; if you upgraded to Retrospect 17 in the last 30 days, you're entitled to free personalized support. If you don't have a dedicated Mac to use as a "backup server", you can buy an old one for a few hundred US$—although I inherited my 2010 Mac Pro. OTOH if you can wait until the end of the year, I've read StorCentric management predictions backed up by titbits from Sales that Retrospect "Inc." is developing a variant of the Engine that will run on at least a beefed Drobo—which may turn out to be more expensive than an old Mac but can also be used as a NAS. You might be able to use the NAS capabilities to replace macOS Server, saving several hundred US$ on your next release of Retrospect by allowing you to downgrade to Desktop Edition. When you talk to Tech Support, you can ask them how to uninstall the Retrospect Mac Engine—since its location is apparently intentionally not in the Applications folder. In the mean time, you can just turn off the Engine in System Preferences->Retrospect. I just Quit the Console each time I boot my MBP, but I could uninstall that with https://freemacsoft.net/appcleaner/ . If OTOH you've actually decided to scrap Retrospect, send me a Private Message and I'll reply with the name of a "push" backup application that—up to its latest version with problems akin to Retrospect Mac 8—is well thought of. Naming competitor apps in Forums posts annoys the head of R. T. S..
  4. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, This KB article says "The Retrospect Client uses the ip and ipsave commands to allow users to direct Retrospect backup traffic through a specific IP address if it is available to the machine the client is installed on." IMHO that means the only way manual ipsave might be made to work is if [1] the "client"'s user knows the the IP address of the "backup server", and [2] the "client" machine—which has "wandered" by either being physically moved to another subnet or by having its IP adapter switched from from a cabled to to a WiFi connection (or vice versa)—can still connect to that "backup server" IP address. However IMHO that would only work if the "client" is set up as a Remote Client and is backed up with a Proactive script, in which case the Client takes the initiative in contacting the "backup server". The -530 problem MrPete and x509 are dealing with is that—as diagnosed by MrPete in this up-thread post—the Retrospect Client for a particular "client" is getting confused, either by getting assigned a virtual interface by Windows APIPA or VMWare, or by a security system, or by a router. That means the "backup server" can't contact the Client for a non-Remote backup. MrPete's solution is to "unconfuse" a "client"'s Client by restarting the Client. As for APIPA, this article says "The APIPA service also checks regularly for the presence of a DHCP server (every five minutes, according to Microsoft). If it detects a DHCP server on the network, APIPA stops, and the DHCP server replaces the APIPA networking addresses with dynamically assigned addresses." So making the "backup server" wait 5 minutes before trying to back up a "wandering" client" might do the trick. However I just remembered this trick for "unconfusing" a "client"'s Client, which worked for my MacBook Pro "client" when I was still Adding it to my Retrospect Mac "backup server" with Use Multicast instead of Add Source Directly (using a fixed IP address)—which MrPete has said doesn't solve his -530 problem. This suggests having the Retrospect Windows "backup server" automatically do the equivalent of Retrospect Mac's Locate (page 51 of the Retrospect Mac 17 User's Guide) 15 minutes before it starts to back up each particular Backup script "client". If the "client"'s Client has been assigned a virtual interface by Windows APIPA, the Locate-equivalent alone should "unconfuse" it. If OTOH the "client"'s Client has been assigned a virtual interface by VMWare, or has gotten confused by a security system or a router, then the Locate-equivalent will fail—in which case the "backup server" should send an e-mail to the Retrospect administrator. I suggest doing the Locate-equivalent 15 minutes in advance because the Retrospect administrator, upon receiving the e-mail, may have time to fix the "client"'s problem before the script begins to back it up. Looking at a post in another thread later, I was reminded that the "backup server" already does "reaching out" to Proactive script "clients" per steps 3 and 4 of this KB article —so extending that "reaching out" as a Locate-equivalent for Backup scripts wouldn't be as "effortful" as the first sentence of the next paragraph says. But that at first seemed effortful, so here's another way or "unconfusing" a "client"—an extension to the suggestion I made in the second paragraph of this up-thread post: Have the "backup server" store its own IP address, which I'll call the "ipsave address", in the Client of each "client" machine added to its Sources. Then, when a "client"'s Client starts up, let it try to contact the "backup server" at the "ipsave address". If it can't, then the "client"'s Client should restart itself—because it must have been "confused" by being re-assigned an address by APIPA or by VMWare or by a security system or by a router. (This is based on the "if I can't see you, then you probably can't see me" principle we all learned as children playing hide-and-seek.) A "client"'s Client successfully contacting the "backup server" for address verification would only be a slight variation of what is already done by a Remote Backup "client". Possibly there should be a script run option to wait 5 minutes before backing up a "client" whose Client has not contacted the "backup server". P.S.: I have now created Support Case #75559, from this post preceded by links to appropriate preceding posts in the thread.
  5. MrPete, Being a Mac user, I have no experience with VSS—but will this help?
  6. 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:
  7. 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.
  8. 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! 😀
  9. 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.
  10. 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."
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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. 😃
  17. 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 🤣 ).
  18. 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.
  19. 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.
  20. 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. 😒
  21. (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.😎
  22. 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.
  23. 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.
  24. 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.
  25. 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? 😕
×