Backups Over Wifi

[09efc6d3-45f8-4c3c-83b8-bc191463db05]

This is more of a feature request as I couldn't find the ability to do what I want in the current version (9.0.0.319)

 

I want to disable clients from performing backups if they are only connected via Wi-Fi.

 

Our office is a mix of about 60 Macs and MacBooks, some of which are on wired and some users roam around on Wi-Fi. The ones that are on Wi-Fi are trying to do their backups and it is slowing down all of the Wi-Fi in our office. And of course getting each user to cooperate and plug into a wired connection all day is a tough sell.

 

I want to disable Retrospect from doing backups while a client's only connection is Wi-Fi. Only if Retrospect detects that the en0 connection is active should it do the backup.

 

Of course this should be configurable from the server side and not an option that the client can turn on and off.

 

Please consider adding this functionality to a maintenance release update.

 

Thanks...

 

Doug

[Guest ogdens]

This is more of a feature request as I couldn't find the ability to do what I want in the current version (9.0.0.319)

 

I want to disable clients from performing backups if they are only connected via Wi-Fi.

 

Our office is a mix of about 60 Macs and MacBooks, some of which are on wired and some users roam around on Wi-Fi. The ones that are on Wi-Fi are trying to do their backups and it is slowing down all of the Wi-Fi in our office. And of course getting each user to cooperate and plug into a wired connection all day is a tough sell.

 

I want to disable Retrospect from doing backups while a client's only connection is Wi-Fi. Only if Retrospect detects that the en0 connection is active should it do the backup.

 

Of course this should be configurable from the server side and not an option that the client can turn on and off.

 

Please consider adding this functionality to a maintenance release update.

 

Thanks...

 

Doug

 

 

Contact Retrospect http://www.retrospect.com/contact (were just users on here).

[Guest Steve Maser]

What I do is give my clients static DHCP addresses for their Ethernet connections and then add the clients via static IP/hostname

 

This way, Retrospect *only* knows about the client when it's on the Ethernet -- it can't see the client when it's on the wifi.

 

So, this is not what you *want* (disable wifi connections), but it would do what you *need* (have clients only backup on Ethernet).

 

Would that work for you?

[Kcaldera]

What I do is give my clients static DHCP addresses for their Ethernet connections and then add the clients via static IP/hostname

 

This way, Retrospect *only* knows about the client when it's on the Ethernet -- it can't see the client when it's on the wifi.

 

So, this is not what you *want* (disable wifi connections), but it would do what you *need* (have clients only backup on Ethernet).

 

Would that work for you?

 

What do the clients do when they go to another network and plug in there? They won't get a static IP and won't have DHCP either??? Or, do you mean that you are assigning static IP addresses to the machines specific Mac address, and then adding to Retro using the assigned IP. That is how my friend does it, and according to him it works great over Wireless if you have to go that route.

[09efc6d3-45f8-4c3c-83b8-bc191463db05]

What I do is give my clients static DHCP addresses for their Ethernet connections and then add the clients via static IP/hostname

 

This way, Retrospect *only* knows about the client when it's on the Ethernet -- it can't see the client when it's on the wifi.

 

So, this is not what you *want* (disable wifi connections), but it would do what you *need* (have clients only backup on Ethernet).

 

Would that work for you?

 

When I add a source and enter their IP address it resolves back to their hostname anyway. Plus I think the Retrospect client still communicates to the server out of the best available interface regardless of which way you added the source to the server. So I don't see how this would work.

Edited December 20, 2011 by DougMeyer

[Guest Steve Maser]

What do the clients do when they go to another network and plug in there? They won't get a static IP and won't have DHCP either??? Or, do you mean that you are assigning static IP addresses to the machines specific Mac address, and then adding to Retro using the assigned IP. That is how my friend does it, and according to him it works great over Wireless if you have to go that route.

 

 

That does not come up for my as my backup policy for Retrospect is that I only back up client machines when they are visible on my local Ethernet networks -- specifically because I don't want to deal with wifi speed issues and off-site backups. This hasn't been an issue for me in the years I've done it this way.

 

YMMV, of course...

[Guest Steve Maser]

When I add a source and enter their IP address it resolves back to their hostname anyway. Plus I think the Retrospect client still communicates to the server out of the best available interface regardless of which way you added the source to the server. So I don't see how this would work.

 

 

If these are Mac clients, you can specify which network has a priority in the Network System Preference. When I set up my client computers, built-in Ethernet is at the top and *then* wifi. If you have them reversed, then that might be the problem.

 

I don't have the same IP address resolving to their wifi MAC address and their ethernet MAC address (here, wifi users get a DHCP pool address) -- are you doing it different?

[09efc6d3-45f8-4c3c-83b8-bc191463db05]

If these are Mac clients, you can specify which network has a priority in the Network System Preference. When I set up my client computers, built-in Ethernet is at the top and *then* wifi. If you have them reversed, then that might be the problem.

 

I don't have the same IP address resolving to their wifi MAC address and their ethernet MAC address (here, wifi users get a DHCP pool address) -- are you doing it different?

 

The problem is not the preference order of the networks. The problem is that when the client is solely on Wi-fi it is still trying to do a data backup, and with 15-30 wireless devices using the wi-fi network it can really strain the entire office when Retrospect starts a backup job.

 

It also irritates me that Retrospect scans the entire source disk from the server side before starting a backup. Rather than the Client engine doing the scan work. You would think that with the Rule definitions that it would only scan the folder hierarchies specified by the sys admin. This adds a significant chunk of time especially when the client is on Wi-fi and doesn't have an Ethernet cable nearby.

 

And since scripts do not execute multiple sources in a multi-threaded fashion it can sometimes take multiple days to do a backup of our office...

 

Do the Retrospect engineers even read these boards? I wonder if they know about the shortcomings of this software.

Edited December 22, 2011 by DougMeyer

[Guest Steve Maser]

So, your issue is primarily that your wi-fi network is not robust enough to run backups over wifi -- so why do it if you don't have to?

 

As for what the engine scans on client machines, why not use "Favorite Folders" instead of scanning the entire disk?

 

And scripts can work to backup multiple sources concurrently -- you just can't back up *to the same media set* concurrently.

[f30e6e60-a263-4d69-8f60-c92703669308]

Do the Retrospect engineers even read these boards? I wonder if they know about the shortcomings of this software

 

Wow. Three posts in and already you're denigrating engineers about whom you know nothing.

 

I'd guess they probably don't read these boards, as it's more likely they're programming when they're at work and relaxing when they're at home. But others in the company do read posts here, and representatives also monitor tech support tickets and track their resolution.

 

If you read Steve's posts more carefully you'd see that his methodology results in wireless clients being invisible to Retrospect while those connected to en0 are seen and backed up. Macspt got it upthread in post #4; is there some reason your infrastructure prevents you from implementing this solution to your problem?

 

Steve is also right to point out that Favorites can be used to limit the data that gets scanned, but the issue of Rules (and Filters before them) not influencing scan behavior is something I've been suggesting/complaining about for years. It was at the very top of my list when I had the opportunity to submit said list before Retrospect 8 was released; I guess it didn't make the cut.

[09efc6d3-45f8-4c3c-83b8-bc191463db05]

So, your issue is primarily that your wi-fi network is not robust enough to run backups over wifi -- so why do it if you don't have to?

This is not relevant to the robustness of my wi-fi network, rather than the nature of the application that is trying to use it. Wi-fi networks were not designed primarily for huge data transfer. They are designed to supplement the Ethernet connection - light activity such as browsing, email, but not gigabytes of data backups. Also, a data backup over Wi-fi will drain the client's battery faster. I am simply asking the engineers to implement a toggle switch that will disable this behavior or prompt the user to use a hard-wired connection.

 

As for what the engine scans on client machines, why not use "Favorite Folders" instead of scanning the entire disk?

I hadn't thought of that - but I went ahead and added some Favorite folders. But since they are nested within the Sources list I am not sure if it will only scan the Favorite folder or if it is still going to scan the parent disk that is above it. The Favorites feature is not clearly documented, so I don't know how it works.

 

And scripts can work to backup multiple sources concurrently -- you just can't back up *to the same media set* concurrently.

This is true, but there are open source backup systems (eg., Amanda) that more efficiently do multithreaded simultaneous network backups from multiple hosts to a "Dump" partition and then can repackage/transfer those dumps in one fell swoop to another disk. It surprises me that a free open source backup system has this ability but Retrospect cannot. The Amanda backup engine makes ultra-efficient use of server and network resources.

[09efc6d3-45f8-4c3c-83b8-bc191463db05]

Wow. Three posts in and already you're denigrating engineers about whom you know nothing.

It was just a question, I was curious to see if anyone has actually heard feedback from the engineers who produce this software, or if anyone has seen their feature requests implemented. It seems there are many others voicing frustrations and not getting anywhere.

 

On the other hand the company I'm working with was a Retrospect 6 customer and when I came on board I implemented the jump to Retrospect 9. None of the new features are really beneficial, I am just asking for a good reliable backup system that squeezes every percent of power out of the system to efficiently collect and back up the client data.

If you read Steve's posts more carefully you'd see that his methodology results in wireless clients being invisible to Retrospect while those connected to en0 are seen and backed up. Macspt got it upthread in post #4; is there some reason your infrastructure prevents you from implementing this solution to your problem?

This methodology doesn't work in my company's network implementation. If a client is on the network, it's ON the network. If you tell Retrospect a manual IP address when adding a source, it still adds, connects and communicates to the client via its hostname, which can point to either of two IP addresses on the client machine. That's the behavior I am expecting, BUT - I am simply asking for an option under Preferences that will prevent clients from performing a backup over wi-fi. This is MUCH easier than segregating the network into Vlans and different DHCP pools and such, none of that will work with the budget I am allowed.

 

Steve is also right to point out that Favorites can be used to limit the data that gets scanned, but the issue of Rules (and Filters before them) not influencing scan behavior is something I've been suggesting/complaining about for years. It was at the very top of my list when I had the opportunity to submit said list before Retrospect 8 was released; I guess it didn't make the cut.

I will try using the Favorites to see if it reduces the number of files scanned.

 

But this is exactly why I'm asking for Wi-fi Retrospect clients to be skipped. The scans take 5-10x longer to run with the network latency added by wireless. On client machines with up to 1,000,000 files each, it can take up to an hour or more for the scans to complete on Wi-Fi. We have a satellite office with client machines over a T1 line and those scans barely even finish before the data backup gets a chance to start. So far I am very frustrated with Retrospect.

Edited December 27, 2011 by DougMeyer

[Guest Steve Maser]

so, if you have DNS set up so that it round-robin grabs either a Wi-FI IP address *or* an Ethernet IP address if you add the client by *hostname*-- why not then just add the client by Ethernet IP address?

 

What am I missing? Are you assigning the exact same IP address if the connection is either Wi-fi *or* Ethernet? If so, why not assign different addresses for each interface?

[09efc6d3-45f8-4c3c-83b8-bc191463db05]

so, if you have DNS set up so that it round-robin grabs either a Wi-FI IP address *or* an Ethernet IP address if you add the client by *hostname*-- why not then just add the client by Ethernet IP address?

 

What am I missing? Are you assigning the exact same IP address if the connection is either Wi-fi *or* Ethernet? If so, why not assign different addresses for each interface?

You're missing the whole point in that I don't want to have to track IP addresses and fuss around with DNS to trick Retrospect into not backing up a client over WiFi.

 

If I add a host by its IP address, Retrospect lists the source as its hostname and it does not even give you the ability to distinguish which interface that host is being accessed by. Yes you can see its IP address but then you have to find out which interface that IP address is bound to etc etc etc. Let's just stop right there.

 

The whole point of all this is that I should not have to fuss with IP addresses and stuff. IP addresses change. DHCP pools change. If I am constantly chasing around IP addresses and DNS then I don't have time to manage my backup solution.

 

Retrospect Tech Support did reply to my ticket though, and they helped me find the option under the script that sets Speed thresholds. Although this is not the ultimate solution I want, it is a temporary workaround. In essence I just want the Retrospect client to have an feature to detect if AirPort is the only active interface and alert the users that their data will not be backed up if they are on a WiFi connection. That's all.

[f30e6e60-a263-4d69-8f60-c92703669308]

Steve helpfully asked:

What am I missing?

 

To which you replied:

You're missing the whole point...

 

But then did not make an effort to answer his questions.

 

 

If I add a host by its IP address, Retrospect lists the source as its hostname

 

Could you be more clear here?

 

When I Add Source Directly using the client's IP address, that IP address is displayed in the Address field of Sources->Summary->Details

 

If I Add Source Directly using the client's fully qualified domain name (not the Rendezvous name) I still see the IP address of the machine in that field, which is the same address as what's in the zone file on the DNS server for that machine.

 

I don't see the machine's DNS name anywhere in the Sources window. Not in Overview, not in Details, not in any of the available column lists.

 

AFAIK, if you add a Retrospect OS X Client machine by its IP address the program will only look for it on that address; it's only when you take advantage of the program's multicast features will it look for clients at different addresses/interfaces (within configured subnets).

 

You still haven't made clear if your client machines have the same IP address configured for different physical network interfaces. Do you?

 

As to fussing around with DNS, it might be interesting to know more about your server setup and zones, but I'm still not sure why it would matter since you can configure things with numbers and don't even require name resolution.

 

 

Dave

[Guest Steve Maser]

If I add a host by its IP address, Retrospect lists the source as its hostname and it does not even give you the ability to distinguish which interface that host is being accessed by. Yes you can see its IP address but then you have to find out which interface that IP address is bound to etc etc etc. Let's just stop right there.

 

The whole point of all this is that I should not have to fuss with IP addresses and stuff. IP addresses change. DHCP pools change. If I am constantly chasing around IP addresses and DNS then I don't have time to manage my backup solution.

 

Retrospect Tech Support did reply to my ticket though, and they helped me find the option under the script that sets Speed thresholds. Although this is not the ultimate solution I want, it is a temporary workaround. In essence I just want the Retrospect client to have an feature to detect if AirPort is the only active interface and alert the users that their data will not be backed up if they are on a WiFi connection. That's all.

 

 

I'm not saying this to be snarky, but there are a whole lot of other advantages to using static DHCP if you are administering clients on a network (beyond Retrospect)-- you should look into it. It's not a whole lot of work, and there are a lot of advantages to setting things up that way. If you don't have somebody else managing a DHCP server for you, it's (relatively) trivial (for example) to pay the extra $50 to get a copy of Lion Server and set up static DHCP for your Ethernet clients. I've managed networks with many many hundreds of clients in dozens of subnets using static DHCP setups. Once you have the initial setup done (admittedly an initial time sink if you don't have *anything* doing DHCP -- but it sounds like you do), it shouldn't be a constant struggle to manage static DHCP -- unless your client computers are *constantly* getting new logic boards/Ethernet cards.

 

As for your feature request -- that's about all it can be at this point -- a request for possible future features. There's nothing in the current design of the client that would alert the users that they are on a wi-fi network and aren't going to get backed up (or that a speed threshold isn't being met and the backup is being cancelled.) And there's nothing in the *server* configuration that can identify if a client is broadcasting over a wi-fi network vs. an Ethernet network (especially if you have wired and wifi on the *same* subnet for some reason) -- the server just sees the client. Period.

Edited December 31, 2011 by Steve Maser