Jump to content

Setting Up Remote Backup

Recommended Posts

What with the coronavirus and all, many in my office are working from home these days. We have been using Retrospect (version 16.5, Mac) for some time now. I set up remote backup according to the directions at https://www.retrospect.com/en/support/kb/how_to_set_up_remote_backup. Rather than uninstalling and reinstalling with the server.txt and pubkey.dat files in the installer, I simply placed those files where they were supposed to go on my laptop, created a Remote Backup Clients tag on the server, and tagged one script (my own) with that tag. The script backed up my laptop remotely with no issues.

Adding others, however, now has me concerned. I planned to send the server.txt and pubkey file (now renamed pubkey1.dat; it seems like they are supposed to be named sequentially, perhaps?) to another user and have him test it, but I added him and a couple of others to the Remote Backup Clients tag on the server prior to him placing the files on his client, to get a head start. One of the scripts I tagged as remote began to run, under my script. I stopped it immediately and removed all the remote backup client tags other than the one.

I went back to the docs, and it doesn't make clear how you are supposed to do set up more than one. The image in the doc shows one script, labeled Remote Computers, with what looks like one source. Are my remote computers supposed to somehow be grouped into one script? That seems odd. Or can I label each individual proactive script as a member of the Remote Backup Clients tag, and if so, what do I need to do to make sure they are differentiated so that my script doesn't pick up someone else's source, as appeared to happen this morning?

Is sequential numbering of the pubkey required? If so, do I need to somehow note which source got what number? Or do I just need to not check the remote backup client tag on the server till everything is in place on the individual client? Do I need to uninstall each client and reinstall with the key and server info inserted into the installer? Or is there something else I need to do?


Share this post

Link to post
Share on other sites


With regard to the use of Tags in Remote Backup, you are first of all the victim of inadequate documentation.  On pages 40-41 of the Retrospect Mac 16 User's Guide, there is an explanation of manually-created Tags.  However at the bottom of the list in the Sources tab for a Script you will find disclosure triangles for Tags and Smart Tags.  Tags disclose a line for each one you have manually defined per pages 40-41, and you click the checkbox on that line to include the volumes or Favorite Folders you have assigned that particular tag.  Smart Tags—which are not defined anywhere in the UG—are automatically populated by the Retrospect "backup engine" (being what I might describe as "smart-as*ed") as you define Sources; in the past they have included All Clients and All Local and All Shares.

Evidently Remote Backup Clients is a Smart Tag added as part of the new Remote Backup feature.  "ProactiveAI Script" in the Knowledge Base article says


To enable remote backup for a ProactiveAI script, select the "Remote Backup Clients" item on Volumes and save on Windows or—on Mac—[my improved punctuation] select the "Remote Backup Clients" tag under Sources and save that selection. 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.

But that paragraph assumes you want to backup all those volumes using a single Proactive script.  (No doubt, when  Product Management added the Remote Backup feature, their vision was that an administrator in London would keep a "backup server" running all the time so that Sally in Shanghai and Alfred in Adelaide would have their machines backed up Proactively whenever those machine connected to the Web.) But, as you say in the OP, that's not what you want to do.  What you need is a way of defining a non-Smart Tag for a particular public-private keypair, so you can use that non-Smart Tag in a Proactive script instead of Remote Backup Clients.  Unfortunately I don't know what that way is.

Therefore what you need to do is to create a Support Case for a feature request.  Here's why and how to do that.


Share this post

Link to post
Share on other sites

Thanks, David, I will do that. The odd thing is, I sent out instructions (with sequentially numbered pubkey.dat files) to four of our developers, just to see. Two of their laptops backed up - once. Two other developer laptops have not been. My laptop started a second backup, but seems to have made very slow progress. (Started yesterday at 6:15 PM, still running, so it says, now on "building the snapshot.") For all five of these scripts, I did not check the "remote backup clients" tag on the Scripts/Sources tab, but I did check the one I created in the Sources/Tags tab. I may wait till Monday to submit the request, as our Proactive scripts are set to run M-F, so perhaps more will "be found" and run after early Monday morning.

Share this post

Link to post
Share on other sites

Alanna and other administrators of installations scared of SARS-CoV-2 (the virus that produces COVID-19 infections),

This first of two posts deals with your OP-expressed desire to have a separate ProactiveAI script for each subset of office-mates working from home.  If you want a separate script for each subset of "client" machines so that the subset can be backed up to a different destination, there is an answer given over the phone to me by the North American head of Retrospect Sales on Thursday—a Storage Group destination.

I upgraded my Retrospect Mac "backup server" from 16.1 to 16.6 Thursday evening and created a Storage Group, whose single member is on the spare space on on the portable HDD I was going to be recycling Saturday morning.  The Storage Group is named "Media Set Groupie" (I was stupid not to have named it "Storage Group Groupie"), which caused a folder with that name to be created on the portable HDD.  Inside that folder is a zero-byte marker file named "storagegroup".  I then ran a Recycle Backup script (I don't do Proactive), whose source was the Macintosh HD on my "client" machine "David's MacBook Pro", and whose destination was that Storage Group.  This created an empty inner folder named "1-Media Set Groupie", and another—when I ran the Backup—non-empty folder named "David's MacBook Pro-Macintosh HD".  Inside the non-empty folder is another folder named "1-David's MacBook Pro-Macintosh HD", which contains the usual .rdb files and .session file.

(The reason for the preceding paragraph is that the Retrospect "engineers" who wrote this Knowledge Base article illustrated it with screenshots of the GUI from their Retrospect Windows alpha-test runs.  Those showed the names of their at-home machines and volumes, which for seeming security reasons they obscured with the digital equivalent of Magic Marker in the screenshots.  So the KB article doesn't visibly make it clear that a Storage Group is merely a container for a Backup Set for each client-volume backed up, and maybe there's a California law against publishing a screenshot of a folder 🤣 showing what's described in my above paragraph—which would be needed to show what the Retrospect Mac "backup server" does because its GUI has less detail than Retrospect Windows' GUI.)

On Friday I ran a Copy Media Set script, copying "Media Set Groupie" (per the KB article, "For transfer in Retrospect for Mac, a Storage Group can be treated like a media set.")—meaning "1-David's MacBook Pro-Macintosh HD"—to a Media Set in spare space on the portable HDD whose last daily backup was Friday morning—which I then put in my bank safe deposit box.  So, using Copy Media Set with a Rule (p.169) that Includes only a particular Source Host, you can get beyond the Storage Group limitation that Member-n-for-every-component-Media-Set (i.e., where n=1, "1-clientname-drivename") must fit (Recycled?) onto the same destination volume.

You should upgrade to Retrospect 16.6, because that point release fixes most of the Storage Group bugs.




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