- Service Provider
- Posts: 154
- Liked: 16 times
- Joined: Apr 07, 2015 1:53 pm
- Full Name: James Wilmoth
** All IP addresses are dynamic; no static leases. **
Workstation protection group:
- All assets remain on company LAN (192.168.0.0/24)
- Assets only ever have one IP address
- An asset's IP address has a low probability of change due to lease renewal
Laptop protection group
- All assets float between company LAN (192.168.0.0/24) and other environments, such as end user home, coffee house, client sites, etc.
- Assets will often have two IP addresses: (1) the local LAN address that the variable environment provides and (2) the VPN address when the VPN is connected
- The probability that an asset's company LAN IP is recycled back into the pool is high because of the mobility of the device
- The probability that an asset's VPN address is recycled back into the pool is also high because of the probability the asset will NOT be connected to the VPN at any given time
- The probability that an asset will have the same logical IP address as another asset at a completely separate physical location is high because many consumer routers use the same networks (i.e. 192.168.1.0/24 in this instance)
Protection groups were targeting device hostnames but are now targeting AD group membership; unfortunately both methods exhibit the problem described below.
Because Veeam tracks ALL the IP addresses of an asset in a protection group, there is high probability for Veeam to confuse one asset with another. This has proven to be true on two separate occasions for us. On one occasion, we were attempting to backup providers' laptops; they floated between medical offices on different routable networks and also connected through VPN; this presented a high probability of devices having each other's IP addresses at varying times, and Veeam was unable to track this reliably. We ended up having to abandon ship on using Veeam to backup these endpoints because backup chains were all too often mixed up. The second occasion is the one I'm dealing with at present and to which the aforementioned case numbers pertain. In this case, the problem is more simplistic:
1. One user has a workstation that is permanently offsite; the asset has a local LAN IP address from his consumer router (192.168.1.x) and occasionally has a VPN address
2. However, because the VPN address is recycled into the pool, Veeam gets confused about once a week
3. When the Protection Group runs (about 30 minutes before the job runs), Veeam scans the laptop which is included in the protection group and which previous had VPN address 10.212.134.x; however, how that VPN address belongs to this workstation which is NOT part of any protection group
4. Veeam gets confused and installs the agent on the workstation
5. When the backup job runs, the workstation, which is not part of any protection group, attempts to backup across the VPN tunnel
Veeam protection groups need to have a granular option whereby a specific network can be required for an asset to be considered "online." For example, in the present scenario, I would configure the laptop protection group to only consider an asset online if it has a company LAN IP address. This would result in Veeam never considering it online even if it's reachable with a VPN address. This would result in the asset never backing up across the VPN. And this would solve the problem described above.
Now, this solution would only solve my issues because I don't actually want to backup the laptops across the VPN. I am sure there are Veeam customers that actually DO want to backup laptops across a VPN, in which case, another solution would need to be designed so that Veeam can better track devices that have dynamic IP addresses.
I hope this lengthy post has adequately detailed a realistic world scenario that may or may not be visible to Veeam at the moment. It is certainly something I am running into and would probably run into more often if more of our clients wanted us to backup end user machines which inherently rely on dynamic IP addresses. This entire post is completely irrelevant for server assets because they, in most cases, would always have a static IP address.
Another, potentially better, solution would be for the Veeam protection group scan job to ALWAYS compare the expected NAME with actual NAME. For example, in my scenario, it would see that WORK42 != LAPTOP123 and therefore cannot be the same asset. Therefore, even if the VPN address that LAPTOP123 previous had is now used by WORK42, Veeam would NOT proceed with installing the agent. Rather, it would conclude that LAPTOP123 is offline.
- Product Manager
- Posts: 11623
- Liked: 1008 times
- Joined: Feb 04, 2013 2:07 pm
- Full Name: Dmitry Popov
- Location: Prague
Thank you for your feedback, at the moment I do not have any comments to share. We will discuss your issue with the team and I'll get back to you. Cheers!
Users browsing this forum: No registered users and 1 guest