This time I want to pick up an idea which I saw first over on Timo’s blog and add some more details which the customers and of course even me personally really like.
For now I assume the basic understanding of Veeam’s “Backup Copy” feature is clear, if not you may want to check out this post
So what’s the point of this post?
I just supported a customer to set up the following backup infrastructure and I want to share the experiences we made. The customer has two backup servers, one to use as primary server running the main instance of Veeam Backup & Replication v7.0 R2 to protect a vSphere environment and a second one which acts as target for the Veeam Backup Copy. Both servers are installed with Windows Server 2012 to leverage the built in deduplication in addition to Veeam deduplication to achieve a repository wide deduplication. Of course the secondary server is placed in a second in another fire section.
The primary backup server has four repositories in total configured:
Only the two local repositories are being used as target for regular backup jobs and the backup copy job picks up those restore points and “copies” them over to the remote repositories on the second server.
To achieve this I added all repositories as “Windows Server” which will install the Veeam Transport Service on the target system. This was pretty easy to setup and everything worked fine.
By using the direct SAN access via Fibre Channel we could avoid a potential bottleneck. If there is the chance to directly attach your backup server to the SAN I would go for it.
But what if you have to restore a VM or file if your primary backup server is down? Unlikely you think? Just during this setup we had massive issues with faulty hardware on the primary server and had to replace hardware multiple times.
So the plan was (as Timo already described) to install the Veeam Backup & Replication (management) server on the second server as well and to add the “remote” repositories which actually act as target for the backup copy as local repositories.
If you add the repositories the first time you can import the already copied restore points and the server is ready to perform restore operations. But the backup copy is an ongoing process, so to keep the restore points within VBR up to date you will need to use a small PowerShell script. To get a copy of a working script check of Timo’s blog post.
Then I unfortunately run in some problems. As soon as I installed VBR on the second server, the primary server lost its connection to the second server and the backup copy jobs stopped.
The error message from the backup copy job indicated that it could be a firewall related issue
“Error: Client error: Failed to connect to the port [Backup02:2502]
Maximum retry count reached (5 out of 5)
Incremental copy was not processed during the copy interval”
As soon as I disabled the local firewall on the second server the connection came back online.
As you can see the “Veeam Backup Transport Service (In)” rule was missing. But just adding this rule (or a custom rule which allows the ports 2500-3000) didn’t fix it, so I enabled the Windows firewall logging to see what else got blocked:
netsh firewall set logging droppedpackets = enable
You may need to create the log first, which is usually located in: C:\Windows\System32\LogFiles\Firewall\pfirewall.log
The log showed the following entries when I tried to connect to the second server:
2014-01-30 14:03:33 DROP TCP <Source IP Backup01> <Dest. IP Backup02> 49662 6160 52 S 623441555 0 8192 – – – RECEIVE
So I manually added another rule to allow port 6160 and that fixed it! Unfortunately I couldn’t test which default Veeam would enable this communication because the server still suffers massive hardware issues L but now the solution works as expected.
A detailed list of all required ports can be found in KB1518
However let’s do a final step back to the conventional part of this post, because this setup allows a bunch of tweaks to further customize the solution to your needs:
- Different deduplication settings on the local and remote repositories to get fast restores and even more restore points.
- You can combine the Backup Copy with the GFS option to keep full backups based on the GFS principle
- Add a tape library to bring the backups off site.
- Or you may want to back up the VBR configuration of the primary server on the second server and vice versa.
- Also some love to the Hyper-V fans out here, of course this also applies to your preferred platform. You could even speed things up by installing the Transport Service on all Hyper-V nodes.
- Copy your backups to the cloud, accelerated by the Veeam WAN acceleration. And maybe restore them in the Cloud?
Please keep in mind that the second server has only a “passive” connection to the vCenter and doesn’t perform actively backups to not violate any license terms and is only used in case the primary server is not available for restore operations. I hope this helps!