Jump to content

Recommended Posts

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.

 

Edited by DavidHertzberg
Add last sentence to first paragraph, saying Automatically Add Clients doesn't create a "client record" that Nigel likes, and clause to third paragraph per Nigel's test

Share this post


Link to post
Share on other sites
13 minutes ago, DavidHertzberg said:

That's because there's no "client record" on the "backup server" for an AlwaysRemote "client" machine.  None, nada, zilch.

You might want to edit your post following the results of my last test in the post before, where an "AlwaysRemote" client was indeed added without user intervention to the server and can therefore be seen in the server's Sources list -- what I'm calling a "client record" because that's where you set things like client options and tags.

Share this post


Link to post
Share on other sites
10 hours ago, DavidHertzberg said:

As for where you said I was wrong, you quoted a sloppily-written section of a KB article.

It would appear that "sloppily written" really means "Goes against my belief that..."

On 8/1/2020 at 11:06 PM, DavidHertzberg said:

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".

...so the official documentation stating that you can switch seamlessly between local and remote backups -- including an example using the industry standard method of onboarding work computers that are to be used remotely -- and the way Retrospect has been shown to work in practice are, quite simply, wrong. They must be wrong, because you say they are. So there really is no point continuing...

Share this post


Link to post
Share on other sites

(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:

Quote

“Automatically add clients”. This is recommended. The Retrospect server will then periodically check the network for new clients with the matching public key [my emphases] and automatically add them to Retrospect’s Sources list. Clients so added will be tagged with the “Automatically Added Clients” tag, providing both a place to look in Retrospect for automatically added clients and also a way to create a script that will use the tag to automatically back up such clients.

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:

Quote

When a remote client contacts the Retrospect engine for a backup, the running ProactiveAI script will accept the connection and begin a backup, assuming the destination is available....Finally, the Retrospect engine must be set up with a public/private keypair, and the administrator must deploy the client with the public key. When the Retrospect engine launches and detects the keypair, it begins listening for remote connections and automatically creates the "Remote Backup Clients" tag [my emphases].

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.😎

Edited by DavidHertzberg
Rewrite to clarify what I think is going on, counter Nigel Smith's trust in "official" documentation, and not accuse Heithcock of malicious desire

Share this post


Link to post
Share on other sites

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.

 

Edited by DavidHertzberg
Corrected first sentence in "Everybody" paragraph; I had written an e-mail to the head of North America _Sales_, not Tech Support

Share this post


Link to post
Share on other sites

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:

Quote

I didn't notice this last night, but it appears that the client was added with the interface "Default/Direct IP", in contrast to the clients automatically added from the server's network which were "Default/Subnet". I don't know what this means if my home router's IP changes or I take the laptop to a different location (will the server consider it to now be on the "wrong" IP and refuse to back it up?) or if I know take it into work and plug in to the network (will the server not subnet-scan for the client, since it is "DirectIP"?).

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:

Quote

NEW "Ignore client discovery" checkbox for preserving Client's address in certain firewall and NAT environments

That sounded applicable to your "third 'if'" paragraph, so I searched the Forums and found this 2018 threadlstone19, 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. 😃

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×