Couple Questions About VPN and Remote Backup

[jethro]

Hi. We've been using Retrospect for many, many years. We currently have v15.6 running on a Mac Mini server, and have 3-4 client machines (running Mac Mojave or Big Sur) we backup in addition to the server itself. Two of the clients are laptops that are on a ProactiveAI scripts, the rest are traditional. The office has a WatchGuard firewall/security appliance operating as the router and firewall.

So we, like many, have been working remotely more lately. I just have a couple questions regarding continuing backup when client machines aren't in office on the local network.

1) Is backing up when client machines are connected via VPN 'possible'? 
I know there's probably a LOT more details needed to fully get into this, but I just want to know if it 'should' be possible before delving into the specifics about 'how'.

2) Is backing up over a VPN connection different than what Retrospect describes as 'Remote Backup' (as seen here)?

2b) If Remote Backup is different than VPN-connected backup, and potentially 'easier' & more reliable, do these instructions apply to v.15.6 as well? I have the v15 manual, and it states Remote Backup as a new feature, but then doesn't describe how to set it up like that article does. Just want to know if the process is basically the same.

3) We do have a license for Retrospect v17 that we could upgrade the server to if there are significant improvements to the ability to backup clients when not on local network. We haven't installed it since v15.6 has been decently stable otherwise, and the upgrade process can sometimes come with risks or downsides. Would upgrading to v17 offer a fair amount of benefits to us here?

 

Thanks for any tips or direction here! We just wanted to start with the basics before spending a lot of time getting into specifics about what needs to be done.

[DavidHertzberg]

(Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales.  I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here.)

jethro,

My Retrospect installation uses a LAN between rooms in my apartment, so I don't have a VPN. 

1) However my understanding of VPNs, which is basically contained in the lead of this Wikipedia article, is that no special special procedures are required if the client machines' addresses can be uniquely defined  via subnets per pages 24 and 74 of the Retrospect Mac 17 User's Guide and ports 497 and 22024 can be opened throughout the VPN for both TCP and UDP per page 227.  But consider Nigel Smith's item 1. in the post directly below.

2a) The last paragraph before the P.S. in the post linked-to in my next paragraph mentions a separate VPN Backup feature.  However that paragraph talked about a preceding sub-Appendix that was later removed from the published Mac 17 UG.  Besides, the feature was AFAICT merely a different Tag for Remote Backup—so maybe it was removed because of Nigel Smith's item 1. in his post immediately below.

2b) Remote Backup is required for VPN backup when  1)'s "if" can't be satisfied; i.e., the "backup server" doesn't have a unique address for a "client".  This is typically the case for Work From Home, but AFAICT Remote Backup was designed in 2018 for another atypical case described in the fifth paragraph of this post in another thread.  The rest of that post describes the consequences of the 2018 kludge in the design of Remote Backup.  I've submitted a feature request  Support Case—per my suggestion to Alanna in that post, requesting that the kludge be remedied 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. 

IMHO the Retrospect "Inc." engineers would respond that the multi-threading capabilities of a Storage Group—about which I updated the post when I became aware of them—would eliminate the kludge without implementing my request.  However the preceding post in that same thread hints at the GUI deficiencies of Storage Groups in Retrospect Mac (per this post in a later thread)—deficiencies that don't exist in Retrospect Windows.  I have repeatedly recommended that Retrospect Mac users stay away from Storage Groups until the GUI deficiencies are fixed, which apparently won't happen soon—because my information is that Retrospect "Inc."'s recently-hired GUI expert has been diverted to developing Mac and Windows Consoles that can communicate with the forthcoming "backup server" implementation on Drobo and other Linux-based NASes.

3) Definitely upgrade to Retrospect Mac 17 if you're going to use the Remote Backup and/or Storage Group features; the cumulative Release Notes show there have been a lot of bug fixes.  Three Retrospect Windows enhancements to 17.0.1—not yet for Mac—are (I've shifted Scheduled to the front):

Quote

New Remote Backup: Support for Scheduled Backups in addition to ProactiveAI Backups

New Remote Backup: Support for Administrator-Initiated Restore

Improved Remote Backup: Support for Duplicate/Copy scripts

 However those haven't yet been documented, because the Rothschild family would surely use a space-based laser to ignite 🤣 (that's a Marjorie Taylor Greene joke) the Walnut Creek CA headquarters of Retrospect "Inc." if they published an updated version of the Retrospect Windows 17 UG or KB article.

Edited June 1, 2021 by DavidHertzberg
In 3) paragraph, add two additional Retrospect Windows 17.0.1 enhancements that aren't in the Mac cumulative Release Notes. In 1) paragraph, consider Nigel Smith's item 1. in the post directly below.

[Nigel Smith]

Everything David says. And I'd add that:

1. Most VPN servers don't allow "network discovery", either Bonjour (like you'd use to list available printers etc) or Retrospect's version, between subnets.
2. Remote Backup is a lot more flexible in that the client wouldn't need to be on the VPN to be backed up. That also reduces the load on your VPN server, helping the people that need to use it.
3. If the use of VPN is a requirement, eg compliance issues, you can actually use Remote Backup through, and only through, your VPN. Otherwise you'll have to open the appropriate ports on the server to the Internet (probably including port-forwarding on the WatchGuard).
4. Most home connections are slow. Get initial backups done while the machines are directly connected to the "work" network, then use incrementals when the machine is out of the office. In your situation you could try a transfer from your current backups to a new, Storage Groups based, set (I've not tried this myself, so don't know if you can). RS will do this switch to incrementals seamlessly, just as it would usually.
5. There's no deduplication across different volumes in Storage Groups, so you may have to allow for more space on your target media.
6. Deffo upgrade to v17!

[jethro]

Hi, thanks for the quick & thorough responses here. Much appreciated!

It looks like the bosses laptops, which are on the ProactiveAI script, are backed up locally when they're at home using Time Machine and/or Carbon Copy Cloner. So it's probably not critical to get them working through the VPN tunnel when remote, especially with the extra complexity and strain it might put on the network (our new office has cable internet, so slow upload speeds).

For my computer, which is NOT on a ProactiveAI script, I may see if I can get a manually initiated Remote Backup going late at night every now & then. Our network admin added the port forwards to our firewall, so it 'might' be ready to go. And it would only be incremental backups, and not on the entire computer – just certain directories.

I think the only issue may be that I uninstalled my client software, and reinstalled it, so I could get it setup with public/private key security (it had been password). I now would have to get Retrospect server to recognize & update the connection to the client, correct?

I may look into upgrading to v17 when back in the office.

Thanks again!

[DavidHertzberg]

(Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales.  I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here.)

jethro,

Your post immediately above says

Quote

For my computer, which is NOT on a ProactiveAI script, I may see if I can get a manually initiated [my emphasis] Remote Backup going late at night every now & then.

I don't think you realized the implication of what I was saying about the Retrospect Windows Scheduled Backups enhancement in section 3) of my last up-thread post.  That enhancement isn't in Retrospect Mac 17, which means the only way you can currently do Remote Backups using a Mac "backup server" is with Proactive scripts.  To understand why, you also need to consider portions of the first 3 paragraphs in this post in another thread;  they reveal that for Remote Backup the Retrospect engineers needed the capability of having a "backup server" script stand ready to act whenever a "client" machine "reaches out"  to it.  That capability has been in Proactive scripts for many years, so to get Remote Backup all the engineers needed to do was add a specialized extension of Retrospect's public-key cryptography facility  to Proactive script processing.  The "Remote Backup: Support for Scheduled Backups in addition to ProactiveAI Backups" Release Note for Retrospect Windows 17.0.1 implies they eventually figured out how to add the same crypto extension to Scheduled script processing, but not yet for Mac "backup servers".

That means the only way you can currently get Remote Backup of your computer late at night is to run a Proactive script with the exact Tag "Remote Backup Clients" in its Sources.  You could schedule that Proactive script to run during a late-at-night period on certain days , but only "manually initiate" the booting of your computer during the time that script runs if you want it to be backed up.  But then you'd run into the "kludge" problem if you later decided to back up your bosses' laptops at home using a Remote Backup Proactive script instead of TM/CCC.  You'd have to schedule the Remote Backup Proactive script during one time-of-day period to give their computers backup priority, but make sure you didn't boot your computer during that same time-of-day period to avoid its grabbing Remote Backup priority.

Of course the Remote Backup priority-grabbing problem would disappear if your Proactive script had a Storage Group destination, which would enable up to 16 simultaneous backups—with simultaneity working fine on a fast "backup server" Mac because of slow "client"-to-"backup server" data transmission speeds.  But then you'd run into the incomplete-GUI problem for Storage Groups on Retrospect Mac.  And I don't expect that to be fixed in Retrospect Mac 18.0—according to past practices due to be released in early March 2021, because AFAICT StorCentric management has demanded the Retrospect "Inc." GUI engineers give priority to supporting the Windows/Mac Console needs of a "backup server" release running on a Drobo/Linux NAS.

[Nigel Smith]

5 hours ago, DavidHertzberg said:

That enhancement isn't in Retrospect Mac 17, which means the only way you can currently do Remote Backups using a Mac "backup server" is with Proactive scripts

Totally untested, but you might be able to spoof what jethro describes by having a 24hr/day Proactive script with a large "days between backups" setting -- RS wouldn't back up the client whenever that client contacted it, only when the user used "Backup Now". That setting would, of course, apply to all clients in that script, which would be all those tagged for Remote Backup.

I'd question why you'd want to do that though! Far simpler to just set things up as normal for Remote Backups, and if you only wanted those to happen at certain user-decided times (perhaps they always want to wait until they've finished both their work and their evening's Netflix viewing before clogging their network connection with RS traffic) allow them to turn their client on and off as it suits them.

[DavidHertzberg]

11 hours ago, Nigel Smith said:

Totally untested, but you might be able to spoof what jethro describes by having a 24hr/day Proactive script with a large "days between backups" setting -- RS wouldn't back up the client whenever that client contacted it, only when the user used "Backup Now". That setting would, of course, apply to all clients in that script, which would be all those tagged for Remote Backup. 

Does the Back Up Now choice on the Retrospect Mac Client menu-bar icon actually work for Remote Backup "clients?  I have no way of testing that, so maybe you could.  Page 74 of the Retrospect Mac 16 User's Guide says

Quote

The Back Up Now and Restore Files menu items are inactive until the client computer has been logged into a Retrospect server where these options are activated.

My understanding is that Remote Backup "clients" are not logged into the "backup server" unless and until they "reach out" to that server, which would happen when the "client" machine boots with its Client running or turns on its Client.  By thus "reaching out", a Remote Backup "client" has automatically put itself into the volumes queue of any Proactive script specifying Remote Backup sources that is currently  "proactive" per page 107—so clicking the Back Up Now choice wouldn't AFAICT accomplish anything additional.

Besides, page 74 goes on to say

Quote

Mac: By default, backed up files and folders are stored in a Media Set chosen by the system administrator in the Retrospect Client preferences. The Media Set is selected using the Back up on demand to popup list.

That paragraph is speaking of a popup list  on the Clients panel of the "backup server"'s Retrospect->Preferences, and it would therefore have to specify a Storage Group to allow for simultaneity.  Because of the current limitations of a Storage Group, the administrator would IMHO periodically have to Copy Backups from that designated Storage Group to another Media Set.

[jethro]

Thanks for the additional replies here. I haven't had a chance to try testing this yet, and may not for a couple days. But I'll check in if I have success (or not).

I think I was just going on the statement made on the 'How to Set Up Remote Backup' page regarding the 2 different scenarios that allowed Remote Backup, one being ProactiveAI scripts and the other being 'On-demand Backup and Restore', as noted:

Quote

On-Demand Backup/Restore

On-Demand backups and restores for a remote client work exactly the same way as they do for local clients. The administrator can enable the option in Volumes on Windows and Sources on Mac.

Again, the Retrospect engine must be set up with a public/private keypair, and the administrator must deploy the client with the public key.

So that led me to believe that my client wouldn't have to be included in any kind of ProactiveAI script if I wanted to just do a manual 'on-demand' backup. But maybe I'm not understanding that correctly (and maybe it wouldn't work on v.15.6 anyway)...

[DavidHertzberg]

jethro,

On -Demand Backup/Restore was a capability added to Retrospect Mac 9, per pages 4–5 of the Retrospect Mac 9 User's Guide Addendum.  So I guess the same "standing-by" for a "reaching-out" Remote "client" must have been added to that capability—as it was for Proactive scripts—to the "backup server" in Retrospect Mac 15.6.  I can't find a post on the Forums from anyone who has used it, so I guess we'll have to see if Nigel Smith can run a test.

P.S.: Assuming On-Demand Backup does work for a Remote "client", then the Client for that Remote "client" would have to be non-operational for that "client"—either because the machine wasn't booted or because the Client had been turned off—whenever a Proactive script specifying the tag "Remote Backup Clients" as a Source was running.  Otherwise the "client" would be backed up by that Proactive script.

Edited February 10, 2021 by DavidHertzberg
P.S.: Assuming On-Demand Backup does work for a Remote "client", then the Client for that Remote "client" would have to be non-operational for that "client" whenever a Proactive script specifying the tag "Remote Backup Clients" as a Source was running.

[DavidHertzberg]

On 2/9/2021 at 4:12 AM, Nigel Smith said:

I'd question why you'd want to do that though! Far simpler to just set things up as normal for Remote Backups, and if you only wanted those to happen at certain user-decided times (perhaps they always want to wait until they've finished both their work and their evening's Netflix viewing before clogging their network connection with RS traffic) allow them to turn their client on and off as it suits them.

Nigel Smith,

I'm surprised at you! 🙄  Don't you realize that the whole idea of modern  (since low-cost large-capacity HDDs were introduced in the 2000s; previously it was that tape drives were expensive) client-server backup is based on the principle of not trusting ordinary users to be responsible for backing up their own machines?  That's why  Retrospect Mac 9 introduced "Locking client features and preferences"—page 8 of the Retrospect Mac 9 User's Guide Addendum, with the first preference listed being "Turn off the Retrospect Client software".

A long-time close acquaintance (we've never been in each other's apartments) is quite knowledgeable in her specialized field—which isn't related to computers or engineering, and is a part-time teacher of university courses that require her to grade student exams and papers etc..  I happened to ask her in January 2018 how she was backing up her Mac, and she said she had bought some kind of wireless external HDD to use with Time Machine.  I no longer recall the details, but the HDD was USB-powered and had a battery that was good for 10 hours.  It turned out she wasn't routinely plugging in the USB cable to her Mac—her only USB electrical power source, apparently because she was afraid of tripping over a USB cable in her small apartment.  So Time Machine was not in fact backing up her Mac; thank goodness she hadn't had a disk crash.  How do you know some of jethro's bosses aren't as lazy (she never checked if TM had been successfully backing up) as she was?  Wouldn't jethro have to be monitoring his bosses under your proposal?

Prepare to be picked up by the fearsome Retrospect Support Police and be taken to a backup administrator re-education camp.🤣

[Nigel Smith]

On 2/10/2021 at 8:50 PM, DavidHertzberg said:

I'm surprised at you! 🙄  Don't you realize that the whole idea of modern  (since low-cost large-capacity HDDs were introduced in the 2000s; previously it was that tape drives were expensive) client-server backup is based on the principle of not trusting ordinary users to be responsible for backing up their own machines? 

<snip>

 

Prepare to be picked up by the fearsome Retrospect Support Police and be taken to a backup administrator re-education camp.🤣

In my defence, your honour...

My personal preference is to lock things down because I don't trust ordinary users. But there are some who cause so much aggravation that, for the sake of my own sanity, they get the "This is why you shouldn't do that..." speech during which it is made clear that if they do do that then it is completely on their own head when they do it wrong. And I've got the email trail to prove it...

Plus, in this case it's jethro who wants to choose his backup times -- and I'm sure he can be trusted to do it right! And if he doesn't and it all goes pants, I've got the forum screenshots to prove that it wasn't my fault, your worship 😉