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 and kiss you on both cheeks; 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"now over-rule those of Heithcock; don't expect the contradiction to be fixed this year.😎

Edited by DavidHertzberg
Rewrite to increase clarity and reduce inflamatoriness

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

×