• State Suggested Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 854 views
  • Users 0 members are here
Options
Related

Backup VLAN unreachable after linking to hypervisor

jjcowan
6 months ago

Historically we've deployed the agent on all of our VM's and protected them directly from the core (no hypervisor associations/links). Each VM was given a secondary network adapter and assigned a static IP on a "backup" VLAN (i.e. 192.168.3.0/24... normal adapter/traffic is on 192.168.2.0).

Recently, we've linked our VCSA and associated all VM's with it. Everything seemed fine for about a day, backups continued on all VM's, until the RR core server had to be rebooted for something unrelated. After coming back online, all VM's which were added via their "backup" IP are unreachable, but there are some VM's which were added via their DNS name and those are still online?

It seems like a switch/networking issue, but nothing has changed in that area. It just seems too coincidental that these go offline right after associating them with our hypervisor (even though backups continued for a day or so after being linked until it was rebooted).

I've disabled/reenabled the network adapter and some other basic troubleshooting along those lines. And I've also tried disassociating one of the unreachable VM's with its hypervisor, which should theoretically put it back to how it existed prior to being linked to it, but no luck. Anyone ever see any behavior like this?

  • 0 6 months ago

    Linking the VMs to a hypervisor is only from the license perspective it has nothing to do with the protection perspective so the VMs going offline after linking them is just a coincidence. 
    If the VMs are offline from the core perspective please try the following:

    • Make sure the VMs Rapid Recovery agent service is running. (As you linked the VMs I am assuming these VMs are agent-based)
    • If the VMs are using antivirus add the Rapid Recovery exclusions recommended here Best Practices enabling Anti-virus Exclusions (4036144) (quest.com)
    • From the core do a ping to the IP address of the VMs
    • If ping is successful perform a telnet from the core to the VM port 8006 (default protection port)
  • 0 6 months ago

    Off the top of my head the first question I have is you mention agents, VMware (VCSA) and linking. Are you still using agents and linking? Or did you switch to using agent-less backups via VMware? I assume you're still using agents by the description, but I just want to validate. 

    The second, this actually sounds like what happens with licensing when you exceed your licensing or the core can't hit the LP correctly. If you click on one of the Protected Machines that isn't lit green, got to Settings > Licensing under License Details does it say Trial? 

    Personally I'd check the license first to validate it's pulling a license. If you have access to the LP check and make sure you haven't exceeded it (rapidrecovery.licenseportal.com). 

    Again, I'm sorry if that is off base, however as it's worked for as long as it had until you started to 'link' things, it very well might not be a networking issue, but a licensing once since Hypervisor Linking is only there to really serve as a licensing feature. Agent-less backup however, that is another story altogether. Which, as you mention VCSA, I'd highly recommend you doing going forward rather than use all these extra NICs on everything. 

    I look forward to your reply. Cheers. 

  • 0 6 months ago in reply to phuff

    Thanks for the info, that explains why they're orange (at least the working ones). Basically, they're all "Active, Trial started", but the ones added via their DNS name are orange and backups are coming through successfully, the ones added via their backup adapter/address are transparent and offline.

    And yes they're backing up via agent, not agentlessly. When our account manager requested we link them in this way they explained that linking them in this manner would not establish agentless backup, and that it would still back up via the agent (and that's how it was spelled out in the documentation/instructions as well).

  • 0 6 months ago in reply to jjcowan

    Hypervisor linking will not change from agent to agent-less no, that is (currently) impossible. The fact that it says active trial started is another vote to regardless of what else is going on there is a License issue. Regardless I would log into the LP if I were you and see what the LP says is connecting and where you are at with your license (rapidrecovery.licenseportal.com). Now, agents do work for sure, however situations like this yet again to promote the use of agent-less technology if you're open to that idea going forward. 

    Victor has the right idea too, you'll need to have the ability to connect into the core/agent back and forth on port 8006, from whichever IP you're using to connect. Now if you do have multiple NIC, network binding and order/priority can matter too (also if you happen to have more than 1 gateway on a given OS). For the backup network, if that is not on the domain, just use the IP/Subnet and not a gateway. Also as its agent based, you might find that extra layer of networking doesn't really bare much fruit, unless of course the RR Core itself is not on the domain network. More often than not, once we moved to 1Gb networks, especially 10Gb, and our repositories aren't SSD, there really isn't a performance hit. 

    Sorry, not trying to preach, just thinking out loud. It is weird that the DNS ones work and the statics don't, more often than not that is reversed.