Jump to content
theboyk

(Retrospect 9) How to limit proactive backups to ethernet connections only?

Recommended Posts

I've been trying to use proactive backups for the various mobile devices on our network and because a number of these devices are dealing with large video files, I have the minimum activity threshold set to 500 MB/m so as to not grind Retrospect backups to a halt. While we're typically working over gigabit ethernet (and backups don't even come close to the minimum activity threshold set to 500 MB/m), the problem I'm having is, when an employee first appears on the network, it's usually via WiFi because they're first arriving in the studio in the morning, or when returning from a meeting, and their machines are on and auto-connect to one of our wireless APs. Shortly after that, they connect via Ethernet, but by then it's too late—Retrospect has already pinged them and tries to back them up, but the backup fails because they hit that minimum activity threshold. Proactive backups only take place every 12 hours, so once that backup has failed, it's another 12 hours before it attempts again (which is usually sometime after-hours, which means it's possible the machine won't even be on the network as they've taken it home, etc.).

 

So, how am I supposed to get Retrospect to back these devices up properly?

 

All of these devices have a dedicated, static IP for their wireless card and another static IP for their ethernet card—and I was hoping that by adding the client via the ethernet-based IP address (vs hostname), that this wouldn't be an issue, but unfortunately, this isn't the case. Once the client is registered by Retrospect Server, it seems like it completely ignores the source IP address and just sees the client as an available client.

 

Does anyone know how I can get this to work?*

 

Thanks,

Kristin.

 

*without being extorted into upgrading to Retrospect 10.

Share this post


Link to post
Share on other sites

All of these devices have a dedicated, static IP for their wireless card and another static IP for their ethernet card

 

Thinking lateraly, would it be possible to setup a firewall rule at the OS level to block Retrospect connections to and from the static IP range for the wireless cards so as far as Retrospect is concerned they do not exist untill they are connected by ethernet?

 

In theory this is possible on Windows 7 and 8 but I don't know about OS X so this may be a non starter.

Share this post


Link to post
Share on other sites

Possible, but none of the machines are running OS X-level firewalls, and I'd rather not do that (it'll open a can of worms). I had assumed (foolishly) that this sort of thing would have been thought of years ago since it's been a pretty common "feature" of Retrospect for years...

Share this post


Link to post
Share on other sites

I don't think Retrospect 10 changes this operation -- regardless of how you add the client (I add mine by hostname), if it sees the client on the network anywhere -- it will try to back it up.

 

I have this issue with clients who go travelling and then connect to the campus network over VPN -- they start getting backed up no matter how slow the connection is.

Share this post


Link to post
Share on other sites

So, there's no Retrospect-based solution to this issue? Brutal? How do people properly managed mobile-device backups then (with Retrospect)?

Share this post


Link to post
Share on other sites

I haven't read this thread closely, so if I miss the point...please forgive me. Retrospect does support multiple network interfaces.

 

If you configure multiple interfaces, you can login a client using the ethernet interface and that client will only communicate over that interface.

 

 

 

If you want a client to always use a specific IP or interface at startup, you can play around with these notes from our engineering team:

 

 

There are two ways of doing this. The first is to cd into "/Library/PreferencePanes/Retrospect Client.prefPane/Contents/MacOS/"

directory then run the following command:

 

sudo ./retroclient -ip x.x.x.x

 

This will stop the currently running retroclient and start a new one mapped to the targeted ip address.

 

***

 

A second way would be to alter the "com.retrospect.retroclient.plist"

launchd script file in /Library/LaunchDaemons/. They would have to add two string fields to the ProgramArguments key.

 

<key>ProgramArguments</key>

<array>

<string>/Library/PreferencePanes/Retrospect

Client.prefPane/Contents/MacOS/retroclient</string>

<string>-ip</string>

<string>x.x.x.x</string>

</array>

 

 

After altering the launchd script they would have to stop/start the client from the preference pane. This way the targeted ip address would remain beyond reboots.

Share this post


Link to post
Share on other sites

Mayoff,

 

All of the above solutions seem to relate to Restrospect Server's IP address (either setting various interfaces on the Retrospect box itself for load balancing, or setting the IP address of that the client connects to Retrospect Server on on the client end). Neither of these solve my issue. What I'm trying to do is have Retrospect Server only back a client up if that client is using specific IP address. For example, our mobile devices all have two IP address assigned to them—one IP for when they're on ethernet, and another IP address when they're on WiFi. I want Retrospect Server to ONLY backup mobile devices, via a Proactive Backup, when they're on ethernet (as trying to back them up results in a backup failure because the connection is too slow).

 

How do I do this? This seems like a fundamental issue surrounding Proactive Backups and mobile devices, so I can only hope that there's a solution for this issue that we're all overlooking?

Share this post


Link to post
Share on other sites

If you add a client to Retrospect using the direct IP method at IP XYZ then Retrospect will only look for that client at IP XYZ. If nothing is found on the network with that IP an error will be reported. This is a global login and how we talk to a client will not change from one script type to another script type.

Share this post


Link to post
Share on other sites

Really? All of my mobile devices were added via their ethernet IP address, yet Retrospect attempts to back them up no matter what IP address they connect with? This was the first thing I attempted (as normally, I use hostnames when adding devices so I can utilize DHCP).

Share this post


Link to post
Share on other sites

Tech support just got back to me and it turns out there's a bug in the software affecting Proactive Backups and the use of Activity Performance Threshold settings. Great. Anyone want to take bets as to whether or not this bug is going to get fixed for v9 users? I can't believe I'm stuck with this crap...

Share this post


Link to post
Share on other sites

...and I just heard back. The bug will be addressed in a future update...to Retrospect 10. The bug existed in v9, they were obviously aware of it, and it continues to be a bug in v10. What a joke.

Share this post


Link to post
Share on other sites

Really? All of my mobile devices were added via their ethernet IP address, yet Retrospect attempts to back them up no matter what IP address they connect with? This was the first thing I attempted (as normally, I use hostnames when adding devices so I can utilize DHCP).

 

Note: The following is using Retrospect 8 Professional for Windows so the menus, tabs and buttons may not be the same for Retrospect 10.

 

I think what Mayoff is trying to point you towards is changing the Clients to only be accessed via a specific IP instead of the default 'Multicast - Piton Name Service' which will find the client at any IP address.

 

Go to Configure > Clients, select a client and click Properties. Goto the Access tab and click Change. Click on Advanced and some more options will appear. Under Access Method select Direct and enter the ethernet IP address of the client. Click Test for Retrospect to check that a client is currently connected at that IP address and OK to apply the changes. The client should now only be accessible at that one IP address.

 

I have used this in the past to restrict Rerospect to backup VMware VMs via a host only virtual network instead of the physical network where the clients have access to both networks.

 

 

John

Share this post


Link to post
Share on other sites

If you want a client to always use a specific IP or interface at startup, you can play around with these notes from our engineering team:

 

 

There are two ways of doing this. The first is to cd into "/Library/PreferencePanes/Retrospect Client.prefPane/Contents/MacOS/"

directory then run the following command:

 

sudo ./retroclient -ip x.x.x.x

 

This will stop the currently running retroclient and start a new one mapped to the targeted ip address.

 

***

 

A second way would be to alter the "com.retrospect.retroclient.plist"

launchd script file in /Library/LaunchDaemons/. They would have to add two string fields to the ProgramArguments key.

 

<key>ProgramArguments</key>

<array>

<string>/Library/PreferencePanes/Retrospect

Client.prefPane/Contents/MacOS/retroclient</string>

<string>-ip</string>

<string>x.x.x.x</string>

</array>

 

 

After altering the launchd script they would have to stop/start the client from the preference pane. This way the targeted ip address would remain beyond reboots.

 

Neither of these options made any difference. Looks like I'm stuck with a non-functioning backup system with user's required to manually update their machines. What a piece of junk...

Share this post


Link to post
Share on other sites

I'm puzzled by your experience that if you add a source directly by IP address, Retrospect will seek and find the client at another IP address. That hasn't been our experience. If we add a client by direct IP for whom we inadvertently haven't set up an IP address reservation, the backup inevitably fails (for a regular script) or does not execute (for a proactive script) if the client has been assigned a new IP address by DHCP. Only if we have added the client by hostname will Retrospect use whatever the first-connected IP address happens to be.

 

(I can't see why it should make a difference, but we only use Tags, not client names or favorite folders, as sources in our scripts.)

Share this post


Link to post
Share on other sites

Mine is the exact same setup—added directly through IP address, and scripts are based on tags. I watched as one employee (my "test" device) walked into the studio this morning. They were added to Retrospect using their static IP address for (used for their ethernet connection), yet 30 seconds after they entered the studio, popped their laptop on the table, opened it and walked away to get a coffee, Retrospect started backing them up. I can see their machine as I type this, still with their ethernet cable unplugged.

 

I've even modified the launch daemon file, as per "technical support" suggestions, without any success.

 

Of course, none of this would be an issue if the threshold bug in Proactive Scripts was fixed, but since that's not going to happen, I'm currently stuck with having to manually monitor devices on a daily basis, manually backing them up each day.

Share this post


Link to post
Share on other sites

I have seen this as well (though having just updated to Retrospect 10, I have not tested to see if they've fixed this yet).

 

But -- with 9 -- I have added all my computers via hostname. If the computer has to go to the shop, I have *cloned* the computer to other hardware temporarily. The other hardware is pulling a different DHCP address at that point -- but the computer continues to back up (proactive backups).

 

It may be that *proactive* backups are actually doing wider LAN searches than scheduled backups are for some reason. Maybe it's Tag-related, but I'd find that hard to believe, too...

 

And, it may be some cruft left over from the fact I'm using a really old "config80.dat" file that's been around for a while -- or that all the clients have just been continual client *upgrades* (rather than removing the client and adding the updated client clean.)

 

But I've *always* only ever added my clients by hostname (Add Source Directly...) And I see this daily. The clients are *not* limited to backup by having added them with a specific hostname.

Share this post


Link to post
Share on other sites

I see mention of the activity threshold, but not mention of the speed threshold. Is there a reason that could not be used? WiFi is quite a bit slower than GigE. As long as the speed of GigE is better (I presume it is, otherwise, why insist on using it?) you should be able to pick a speed threshold that allows backup over GigE, but not WiFi.

 

Am I missing something?

Share this post


Link to post
Share on other sites

Yea, based on the v8 manual, this was my initial approach, but it never worked successfully either, so I moved to attempting to use Activity Threshold (which seems to work at first, but after a week, I realized it wasn't stable either).

 

Anyway, it's not an issue—I've already moved all mobile devices to CrashPlan Pro (with the rest of our devices to follow as part of our eventual migration to a new backup solution).

 

Thanks,

Kristin.

Share this post


Link to post
Share on other sites

Here's a bit of description and example to support folks who are wondering about the differences between "Speed threshold" and "Activity performance threshold."

 

Speed threshold: Checks the initial connection speed between a Retrospect server and client. Use this setting to test the speed of a connection to a Retrospect client before starting the backup.

 

Activity performance threshold: Monitors the performance of a backup (local or client) for its duration and stops the activity if the performance drops below a certain level. [Note: This feature was added many years ago to prevent backups from getting stuck on a volume where the backup performance slowed to a crawl but where the backup wouldn't actually time out. This condition rarely occurs, and when it does, it's indicative of some other issue. It's a good idea to seek the advice of technical support before using this feature. Don't use this feature to test for backups over a slow connection, as Retrospect will waste a bunch of time determining what to back up before timing out. 99% of the time, Speed threshold is the one to use.]

 

Here's an example of Proactive Backup skipping a client that doesn't meet the Speed threshold (attempts are made after the "Retry failure after n minutes" time has passed, 30 minutes in this case):

+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 12:23:02 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 6440 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 1:32:32 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 3261 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 2:02:43 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 3012 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 2:32:56 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 4414 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 3:03:12 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 5224 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 3:33:27 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 2301 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 7:31:13 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 2409 KB/sec, threshold 10000 KB/sec)
+ Normal backup using Laptops at 11/28/12 (Activity Thread 1)
To Backup Set TreehouseVaultA...
- 11/28/12 8:17:00 PM: Copying Macintosh HD on cMBP-Treehouse
!Backup client cMBP-Treehouse is too slow (measured 4571 KB/sec, threshold 10000 KB/sec)

Share this post


Link to post
Share on other sites

So, FWIW -- I just saw this today with the Retrospect *10* engine (but a client still on Retrospect 9).

 

Client was in another subnet on campus (which I could see via ARD), but the client started backing up (proactive script) while I had been watching the console for another, unrelated reason.

 

 

So, I don't (yet) know if the problem will go away if the client is updated to Retrospect 10 or not. But I can guarantee the client was added via hostname...

Share this post


Link to post
Share on other sites

Well, your issue may be resolved by moving away from Retrospect, but it's not resolved for the rest of us that occasionally see this problem...

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

×