We have Veeam installed throughout our facilities and, for the most part, it functions very well
At present we are attempting to use B&R 184.108.40.2067 Enterprise Plus to get an off-site backup copy of our HQ data (approx 3TB) to a remote facility approx. 30 miles distant using the Backup Copy function in conjunction with the WAN Accelerator. Intersite connectivity for the job is via VPN tunnel. The local site has 50 Mbps synchronous Internet connectivity and the target 60/4 Mbps asynchronous.
We seeded the target repository (via USB3 disk) exactly per http://www.veeam.com/kb1856 and set the backup copy interval to a couple of weeks to ensure it did not expire during the inital sync.
When we initially mapped the job to the seed backup file on the target repository and enabled, it processed for a few minutes and then reported:-
- -All tasks have been processed
-Waiting for new copy interval
- -Waiting for new restore points
So, we ran a single incremental backup to the local repository and then disabled the original backup job. The backup copy job finally started processing. As you might expect, the initial sync would take quite a while due to WAN accelerator fingerprint creation and larger-than-usual incremental vib. One of the VM's within the job has a 2TB volume that takes longer than 24 hours to process during the backup copy initial sync. However, despite setting a 14 day copy interval, the backup copy initial run still cancels 24 hours after the "start at" time with a "copy interval expired" error. Also, if this problem occurs during a VM volume's initial fingerprint creation/transfer period it would appear to cause the backup copy job to ignore the seed data for the VM volume that was being processed during the next (or subsequent) retries of the initial sync.
We don't understand why this occurs - especially when we've purposely defined a long copy interval for the initial run. It almost appears to be a bug in the software. Has anyone else experienced this? If we can't workaround this issue, it would seem we have little hope of getting the large VM copied over to our DR site.