Multiple NICs, VLANs and subnets and forcing client to use specific subnet with Retrospect server

[Indi-Tech]

Hello,

We have Retrospect running on a MacOS 10.11 server (3,1 MacPro) with one NIC (primary) assigned to an "office" VLAN/subnet and the other NIC (secondary) assigned to a "service" VLAN/subnet. We have another server that is configured in like fashion. One server is for office operations and the other for our IT services. Retrospect server is configured with both subnets; however, even if the client on the "service" server is added manually with the "service" subnet IP, Retrospect server ends up communicating over the "office" subnet IP.

We are trying to keep Retrospect communication on the "service" VLAN/subnet and dedicated NIC but it keeps defaulting to the "office" VLAN/subnet and dedicated NIC which is assigned as the primary NIC in MacOS. Multicast works on the "office" VLAN and is not allowed to transverse VLANs, intentionally.

Browsing to add clients works fine over both subnets, are we missing something?

[DavidHertzberg]

Indi-Tech,

You don't say which version of Retrospect Mac you are using, so I'll refer you to the Retrospect Mac 15 User's Guide.  "Network Interfaces" on page 60 sounds applicable to your problem. 

For further information, see "Advanced Networking" on pages 74-77.  I suggest that —at a minimum—you add your "client" machines with Subnet Broadcast on your "service subnet".  If you feel more energetic, you can Add Source Directly—for which you will have to assign each "client" machine a fixed address on your router using its MAC address.  That's what I do on my home LAN (with "backup server" and "client" now running Retrospect Mac 16), for which Multicast stopped working a couple of years ago for mysterious hardware-related reasons.  But I have only one subnet, so Add Source Directly may not solve your problem —whereas Subnet Broadcast probably will.

[Indi-Tech]

On 5/2/2019 at 5:36 PM, DavidHertzberg said:

Indi-Tech,

You don't say which version of Retrospect Mac you are using, so I'll refer you to the Retrospect Mac 15 User's Guide.  "Network Interfaces" on page 60 sounds applicable to your problem. 

v16

Quote

For further information, see "Advanced Networking" on pages 74-77.  I suggest that —at a minimum—you add your "client" machines with Subnet Broadcast on your "service subnet".  If you feel more energetic, you can Add Source Directly—for which you will have to assign each "client" machine a fixed address on your router using its MAC address.  That's what I do on my home LAN (with "backup server" and "client" now running Retrospect Mac 16), for which Multicast stopped working a couple of years ago for mysterious hardware-related reasons.  But I have only one subnet, so Add Source Directly may not solve your problem —whereas Subnet Broadcast probably will.

All addresses mentioned are static server addresses.

I added the client to the server, manually, twice and each time it showed as connected to the VLAN the primary NIC is assigned instead of the IP I manually connected to. For example, 192.168.10.5, instead of 192.168.30.5. I waited until today and removed and re-added the client from the server end, manually. This time the server end showed the client added with the service VLAN. On the client end it still reports as being connected via the office VLAN, even while being backed up. Misleading, hard to confirm the actual IP/subnets used between client and server. So on the client end it would show 192.168.10.5 and on the server end it shows 192.168.30.5.

I also noted that backup speeds were triple that of speeds when backing up over the primary VLAN, that which multicast is present. All factors other than Retrospect ruled out. Both NICs on both servers transfer 120-150MB/s between each other over 1Gbps cat 5e so the difference between NIC/VLAN combos seems to be with Retrospect. The office VLAN, with multicast, gets about 16MB/s throughput, the service VLAN gets about 70MB/s. The RAID units on either server perform at 500MB/s, each.

 

[Indi-Tech]

10 minutes ago, Indi-Tech said:

Scratch that, Retrospect server just reset the IP from the 172.31.30.1 I added the client with and even had a backup with, to 172.31.10.1. What gives?

Speeds are still better, but they should have been either way.

 

[DavidHertzberg]

Indi-Tech,

Since you're using Retrospect Mac version 16, look in that User's Guide at page 64 for "Network Interfaces" and pages 78-81 for "Advanced Networking".

I have no knowledge of VLANs; I just now took a look at the appropriate Wikipedia article.  However you might find an answer in this relatively-recent Forums post and its successors by an administrator who is much more knowledgeable than I am about such matters.

I have also noticed that the version 16 Mac Client's Advanced tab has a new Public Backup Server entry capability.  As is unfortunately par for the course in recent versions of Retrospect, the "What's New" chapter of the UG is pure marketing drivel, and doesn't discuss that capability.  However you might try clicking the lock icon and entering your "Client"'s password to make changes, then clicking the Edit button and entering the address of the "backup server".  I must caution you that Your Mileage May Vary, and see the P.P.S. below.

Finally, how did you generate the screenshot in your most-recent preceding post—the one you posted as if it were a copy of another post?  Was it with the Retrospect "backup server", or with another application?

P.S.: I suggest you phone Retrospect Technical Support at (888) 376-1078 or (925) 476-1030‬; they're on extension  3.  If you bought Retrospect Mac 16 within the past 30 days, I believe they'll give you personalized help for free.

P.P.S.:  The new Public Backup Server entry capability is described in this section of a Knowledge Base article, and is intended for use in Remote Backup (introduced in version 15, so nothing remains in the UG).  But IMHO that doesn't mean you couldn't pervert it to do what you want.  You could speed the perversion by simply installing a server.txt file on each "client" machine, as described in "Installation Process" in the KB article.  However using this capability would for now require converting your scripts to Proactive, so you'd do better to phone RTS instead.

[Indi-Tech]

6 hours ago, DavidHertzberg said:

Finally, how did you generate the screenshot in your most-recent preceding post—the one you posted as if it were a copy of another post?  Was it with the Retrospect "backup server", or with another application?

P.S.: I suggest you phone Retrospect Technical Support at (888) 376-1078 or (925) 476-1030‬; they're on extension  3.  If you bought Retrospect Mac 16 within the past 30 days, I believe they'll give you personalized help for free.

Thanks.

Screenshots are generated with MacOS and of the desktop. I may call support, seems like a bug that the correct IP is not displayed. Retrospect server is configured with both NICs, everything is set per the manual's instruction.

[DavidHertzberg]

Indi-Tech,

Apologies for not realizing until now what your problem probably is. 

First, for background, you should watch this Retrospect Mac Tutorial video again—even if you have watched it already.  Note that, at minute 1:47, the last thing the head of RTS does is add "client" computers—and he does it by first specifying the pre-defined name for the NIC and then specifying the method of scanning for "client" computers.  I strongly urge you to specify Use Subnet Broadcast, and I hope that "is added manually with the 'service' subnet" means that's what you did.

But the key requirement IME is that the Client on each "client" not yet have a "backup server" address stored in a "secret field" within it at that point—which is the situation assumed in the Tutorial, meaning it hasn't yet been imprinted with the address of the "backup server" with which it is supposed to communicate.  That imprinting is done by the "backup server" when you first Add a "client"; therefore (as told to me 4 years ago by Andy —now departed from RTS) you must Uninstall and then Install the Retrospect Client on each "client" computer.  I have done this in the past by downloading the latest Retrospect Client .zip from the website, rather than messing with trying to accomplish this from the Console.  But before running the Retrospect Client Installer.pkg for the "client" you must have first Removed that "client" computer from Sources via the Console.  Only after running the Retrospect Client Installer.pkg on the "client" computer can you then re-Add the "client" into Sources from the Console—via Use Subnet Broadcast—and thus imprint the "secret field".  Up through Retrospect Mac 15, the "secret field" where the Client stores forever (I'm not sure whether Refresh can change it) the identity of its imprinted "backup server" used to be displayed—uneditable—in the Advanced tab of the Client; version 16.0.2.101 displays 0.0.0.0 instead for what is now called the Private Backup Server field—which may merely be a byproduct of Engineering hijacking the associated dialog control for use in editing the newly-added Public Backup Server field when needed for Remote Backup.  The unchangeable-after-imprinting function of the "secret field" is informed speculation, BTW, since I don't have access to the Retrospect source code.

After you've done this for each "client" computer (the sequence I recommend is:  [1] do all "client" Removes from the Console, [2] do the Client Uninstall and Install on each "client" computer, and [3] do all "client" Adds from the Console), you'll have to re-add the "clients" to each Backup/Archive/Proactive script that uses them.  After doing all "client" adds for a script by selecting the script in Scripts and then check-marking the boxes for all desired "clients"' in the panel shown by clicking the script's Sources tab, you should Save the script and then click its Summary tab.  If the "clients" don't appear in the backing-up sequence you want, you can—with some GUI kludginess—drag their names in the Summary list pane into the desired sequence (thanks derek500 ); if you've dragged, do another Save of the script.

If you don't believe me, read this final post in the Forums thread I linked to up-thread.  Nigel Smith says what I suggested didn't quite work for the problem he was having, but that it was because his problem was dealing with a Fortigate setup—with "client" computers connecting at random to only one NIC at a time—rather than the multiple NICs you evidently have on your version of the Mac Pro (3,1).

P.S.: Changed 2nd substantive paragraph to get rid of male-chauvinist-like language, and clarify that paragraph—I hope.

 

[Indi-Tech]

Thanks DavidHertzberg, we followed all of the steps you mentioned, initially. And have now repeated them.

Here's the test setup we are working on that's giving us issues.

I think the issue may be that the client (primary server) has (2) NICs, each one on a different VLAN. The client and server always grab the NIC that is assigned as the primary by the OS, but we need it to use the secondary.

Client configured, no backup as of yet. Grabs the primary NIC, no option in the client to specify NICs, that we can find.

The server has both NICs and subnets configured. The intent is to have the two servers perform backup activities on the 172.31.30.0/24 subnet and dedicated NICs.

When adding the client via subnet, the console only sees the client IP of the primary NIC. Even though we're scanning on the secondary NIC and subnet, the console still reports the client's primary NIC IP/subnet. In the picture below, the IP should be reading 172.31.30.1.

So we add the client manually.

The client is added and shows the proper IP. Shown, before the first backup.

Then once a backup happens, the client IP reverts to the primary NIC of the client.

The client shows the private server address on the service VLAN as it should be...

...but the client is communicating on the office VLAN.

Net Monitor showing activity on client NICs during backup, confirming backup is occurring on service VLAN. (Gigabit ethernet over Meraki switch, both servers are fast, each with a RAID5 system pushing 500 megabytes per second. Backup speed seems slow, Chronosync pushes 115-125MB/s with the same setup)

Office VLAN.

The client "Tim" also hosts a share that is used by backup server because the backup server also hosts a share that requires backup. So "Tim" provides the share that is used for that backup. You can see in the image below that "Tim" is configured as a source (172.31.30.1). We have no problem with this configuration, and confirmed data transfer is happening on the service VLAN, as it is configured to do.

Any thoughts on all of this?

 

 

[DavidHertzberg]

Indi-Tech,

My little brain is thoroughly confused by "the client (primary server)" in the third paragraph of your immediately-preceding post, and by "hosts a share that is used by backup server because the backup server also hosts a share that requires backup" in the final paragraph.  Please rewrite that post using the terms "LAN data server" and "Retrospect backup server" to distinguish the separate functions of these machines/drives on your LAN.  You'll need that rewrite, if for no purpose other than to communicate clearly with Retrospect Technical Support, which I suggest you do—ASAP to get your free personalized T.S. if possible.

 

[Indi-Tech]

8 minutes ago, DavidHertzberg said:

Indi-Tech,

My little brain is thoroughly confused by "the client (primary server)" in the third paragraph of your immediately-preceding post, and by "hosts a share that is used by backup server because the backup server also hosts a share that requires backup" in the final paragraph.  Please rewrite that post using the terms "LAN data server" and "Retrospect backup server" to distinguish the separate functions of these machines/drives on your LAN.  You'll need that rewrite, if for no purpose other than to communicate clearly with Retrospect Technical Support, which I suggest you do—ASAP to get your free personalized T.S. if possible.

 

How about starting with the client having (2) NICs and tell us how to get the Retrospect server to connect to a specific client NIC.

[DavidHertzberg]

1 hour ago, Indi-Tech said:

How about starting with the client having (2) NICs and tell us how to get the Retrospect server to connect to a specific client NIC.

Indi-Tech,

I have no idea, except that it sounds as if the "client having (2) NICs" is actually a LAN data server, which implies that it is shared on the LAN by the "Retrospect backup server" machine as well as other machines.  If so, is there any reason that you can't back up the "client having (2) NICs" as if at least its "server_RAID" drive is a network share to the "Retrospect backup server" machine rather than as a "client"?  See pages 71-72 of the Retrospect Mac 16 User's Guide.

Please be aware that I'm a home user with a simple LAN, composed of "client" machines and a single "backup server" machine, all of which have only one NIC apiece, and I don't have a LAN data server.  You'd have to set up an afp: or smb: address that would somehow specify using the "LAN data server"'s secondary IP; this makes it seem as if you can do it with AFP.

P.S.: Changed first paragraph to suggest that "server_RAID" be treated by the "Retrospect backup server" as a network share, and split off second paragraph with caution on how to do it.

Edited May 13, 2019 by DavidHertzberg
Changed first and second paragraphs to suggest that "server_RAID" be treated by the "Retrospect backup server" as a network share.

[Lennart_T]

2 hours ago, Indi-Tech said:

How about starting with the client having (2) NICs and tell us how to get the Retrospect server to connect to a specific client NIC.

In case you didn't know: This is (mainly) a user-to-user forum, not Retrospect Support.

To get (official) support, please start here: https://www.retrospect.com/en/support/edition

[Nigel Smith]

13 hours ago, Indi-Tech said:

How about starting with the client having (2) NICs and tell us how to get the Retrospect server to connect to a specific client NIC.

By default, Retrospect Client will bind to the first available active IP address. In a dual-NIC setup (e.g. network card and wireless in a laptop) that "first available" can vary.

So you'll need to tell the client which IP to bind to -- see this page for details.

Obviously, only works for static IPs. Luckily it sounds like that's what you are using.

That might be enough to get you going. Otherwise, could you re-post the problem but refer to machines as "clients" for the ones you want to back up and "server" for the one doing the RS backup? Like David, I'm getting a bit confused as to what's what!

[DavidHertzberg]

Thank you, Nigel Smith, for that suggestion.   I'd forgotten about this prior thread of Nigel's, to which I made a few ignorant contributions.  However it looks as if this post in an earlier thread is closer to solving Indi-Tech's problem.

Nigel's problem dealt with "clients" that can be on either of two different subnets when they connect to his LAN, with his "backup server" machine only sitting on one of the two subnets.  lwhitten's problem, in the earlier thread, was that—for speed in backup—he/she wanted his "client"'s Client to access his "backup server" over a dedicated cat6 cable port rather than via a router with dynamic DHCP IP addresses.  Using ipsave—described in the "Binding Retrospect Client to a specific IP address" Knowledge Base article Nigel linked to above, lwhitten found it worked OK for scheduled backups and "kind of OK" for Proactive backups.   Indi-Tech's "LAN data server" that is also a Retrospect "client" is, I confidently assume, not being backed up with a Proactive script—since it is undoubtedly always connected to the LAN.

In case it's not obvious why I'm making this post, it's so other administrators will in the future be able to find a solution for similar problems by doing a Forums search.  An enabling Client "ipsave switch" was fixed in Retrospect Mac 11.5 and in Retrospect Widows 10.0, but Retrospect Inc. never described its function in either variant of the User's Guide—only in the KB article.

[Indi-Tech]

On 5/13/2019 at 12:00 PM, Nigel Smith said:

By default, Retrospect Client will bind to the first available active IP address. In a dual-NIC setup (e.g. network card and wireless in a laptop) that "first available" can vary.

So you'll need to tell the client which IP to bind to -- see this page for details.

Obviously, only works for static IPs. Luckily it sounds like that's what you are using.

That might be enough to get you going. Otherwise, could you re-post the problem but refer to machines as "clients" for the ones you want to back up and "server" for the one doing the RS backup? Like David, I'm getting a bit confused as to what's what!

Thanks Nigel, that did the trick! Is this in the manual, I don't see it?

What to watch for when applying this method:

1. You'll need to remove and re-add the client.

2. The client will show that it is not connected to the network, when it actually is.

We have confirmed that the proper NIC is now being used. Short test so speeds are low, or is it encryption, we're using the most basic version? (We rarely get more than 40MB/s with Retrospect when the same setup gets 115MB/s with Chronosync).

Now there's all this great troubleshooting info for this topic in the forum where it is searchable! Indi-Tech appreciates the suggestions to "call tech support" and "read the manual", those are great tips for folks who know very little about technology in general.

[Nigel Smith]

27 minutes ago, Indi-Tech said:

Thanks Nigel, that did the trick! Is this in the manual, I don't see it?

What to watch for when applying this method:

1. You'll need to remove and re-add the client.

2. The client will show that it is not connected to the network, when it actually is.

I've not seen it in the manual but, to be fair, dual active NICs on a client isn't common and they can't document *everything*. Searching the KB for "bind" gets me that linked page as second hit -- although you have to be techie enough to know the term "bind" in relation to NICs and IPs...

You don't always have to remove and re-add the client -- depends on how it was added in the first place. But it won't hurt to do so unless you are trying to preserve an easily-followed backup history (and, usually, you do this kind of shenanigans because you can't get any backup to begin a history with!). 

Connection not showing might be a client-version thing -- certainly works for me in e.g. 15.6.0

As to speed -- unencrypted will be faster than encrypted, fewer large files will be faster than a lot of smaller ones,  and so on. Try your own tests and see where the bottleneck is, watch the network usage, CPU %s, and disk I/O rates at both ends, etc. And when you say encryption are you talking encrypted communications, encrypted backup set, or both? (IIRC, Chronosync offers encrypted comms but not the backup itself, instead recommending you use an encrypted disk if you want that sort of thing. But it's been a while...)

[DavidHertzberg]

On 5/21/2019 at 12:54 PM, Nigel Smith said:

I've not seen it in the manual but, to be fair, dual active NICs on a client isn't common and they can't document *everything*. Searching the KB for "bind" gets me that linked page as second hit -- although you have to be techie enough to know the term "bind" in relation to NICs and IPs...

You don't always have to remove and re-add the client -- depends on how it was added in the first place. But it won't hurt to do so unless you are trying to preserve an easily-followed backup history (and, usually, you do this kind of shenanigans because you can't get any backup to begin a history with!). 

Connection not showing might be a client-version thing -- certainly works for me in e.g. 15.6.0

As to speed -- unencrypted will be faster than encrypted, fewer large files will be faster than a lot of smaller ones,  and so on. Try your own tests and see where the bottleneck is, watch the network usage, CPU %s, and disk I/O rates at both ends, etc. And when you say encryption are you talking encrypted communications, encrypted backup set, or both? (IIRC, Chronosync offers encrypted comms but not the backup itself, instead recommending you use an encrypted disk if you want that sort of thing. But it's been a while...)

Indi-Tech,

Retrospect Inc. could have, in fact, put a sentence or two about "ipsave" in the User's Guide.  However a search of the cumulative Release Notes shows this feature was added in September 2014 to Retrospect Mac, and in March 2015 to Retrospect Windows.  It therefore ran afoul of the User's Guide policy described in this post in another thread (which is not the only place I have complained about it).  But Google shows you're a consultant (or someone has stolen your "handle" and logo), so you'll have to develop an encyclopedic mastery of the Knowledge Base articles to justify your charging the big bucks—which is why I think Retrospect Product Management intentionally adopted this "disappearing documentation" policy as part of its "go big or go home" strategy.

lwhitten complained about the connection not showing in this post I linked to above.  He/she was using "a trial of [Mac] v14", and you're using Mac version 16, so Nigel Smith must be somehow hitting the sweet spot in Retrospect versions—or there's another explanation.

As for the speed of backup over a LAN, dittberner@dbr3.de complained about that for nearly 2 years before switching to another client-server backup application.  I came up with a hypothesis here, but my hope—expressed a couple of posts down in that thread—that things would improve with version 16 has not been realized.   My average speed in Recycle backups over my home LAN is around 600MB/min; my hypothesis might explain why ChronoSync—which you're probably using in Synchronize mode—is faster.

 

[Indi-Tech]

8 hours ago, DavidHertzberg said:

But Google shows you're a consultant (or someone has stolen your "handle" and logo), so you'll have to develop an encyclopedic mastery of the Knowledge Base articles to justify your charging the big bucks

We are an independent technology consulting and support company.

Counter to your statement, we are using Retrospect at the low end of the scale. Our own knowledge base of Retrospect support tickets goes back to 1999, 2 years older than the Apple ID of the company founder was established. 😎 The big boss does recollect something about this issue in the deep past and having to, "bind",  the IP in a sort of way. Not because of multiple NICs but because of scanning subnets and having issues, or something like that.

Our content creation clients with 100TB plus RAID units from Facilis and 45 Drives could never use something like Retrospect and have files backed up in time. At least, not based off our tests. We use Retrospect for office operations and for home professionals, small businesses with smaller files. You know, like it's the 1990s again. 😎

We recently had a working Retrospect backup setup mysteriously forget the favorites that were set, preventing the backup from working until the favorites were re-established. No change to the setup was made before the malfunction occurred. Not the kind of reliability we can use with our bread-and-butter cliental. And exactly the kind of behavior Retrospect has always exhibited. It's a good product but seems to have been stuck in time in some aspects.

[DavidHertzberg]

1 hour ago, Indi-Tech said:

We are an independent technology consulting and support company.

Counter to your statement, we are using Retrospect at the low end of the scale. Our own knowledge base of Retrospect support tickets goes back to 1999, 2 years older than the Apple ID of the company founder was established. 😎 The big boss does recollect something about this issue in the deep past and having to, "bind",  the IP in a sort of way. Not because of multiple NICs but because of scanning subnets and having issues, or something like that.

Our content creation clients with 100TB plus RAID units from Facilis and 45 Drives could never use something like Retrospect and have files backed up in time. At least, not based off our tests. We use Retrospect for office operations and for home professionals, small businesses with smaller files. You know, like it's the 1990s again. 😎

We recently had a working Retrospect backup setup mysteriously forget the favorites that were set, preventing the backup from working until the favorites were re-established. No change to the setup was made before the malfunction occurred. Not the kind of reliability we can use with our bread-and-butter cliental. And exactly the kind of behavior Retrospect has always exhibited. It's a good product but seems to have been stuck in time in some aspects.

Gee, Indi-Tech, and yet you only joined these Forums on 2 May 2019.    Maybe your big boss belonged under a different Forums "handle"?  Anyway, good of you to condescend to ask for help from us home professionals.

I'll deal with your Favorite Folder problem later, to the extent I can, after I've had dinner and watched a movie.

[Indi-Tech]

3 hours ago, DavidHertzberg said:

Gee, Indi-Tech, and yet you only joined these Forums on 2 May 2019.    Maybe your big boss belonged under a different Forums "handle"?  Anyway, good of you to condescend to ask for help from us home professionals.

I'll deal with your Favorite Folder problem later, to the extent I can, after I've had dinner and watched a movie.

No worries.

It is odd, we ask for help here on the forums and are told to go ask Retrospect tech support. We mention we are using the software for basic needs and get accused of being condescending and have our legitimacy questioned. Only one person that's responded provided on-topic and useful information that was concise and to the point, without attacking the poster.

Curious to hear your thoughts on why a favorite stops being recognized as a favorite when nothing has changed on the client or server. We have a different thread for that on these forums, we won't be continuing that topic here. 

 

[Lennart_T]

2 hours ago, Indi-Tech said:

It is odd, we ask for help here on the forums and are told to go ask Retrospect tech support.

I do want to reply to that statement. You wrote to David in what I think is a demanding tone "How about starting with the client having (2) NICs and tell us how to get the Retrospect server to connect to a specific client NIC." English is not my native language, so I may have misunderstood.

It is a common mistake in these forums to believe they ARE the official support, so I provided you with the fact they are not. And then I wrote that IF you want proper support, this isn't the right place. I wrote that with a good intension.