Skip to main content

Hi Folks,

 

Just wanted to share my opinion on this. I was around when Cloud Connect was introduced and remember the struggle with customers when explaining backup copy job copy intervals. Often I would hear.. “can we not just have our legacy, backup job done then offsite?”. Veeam brought in the immediate copy not to long ago and I have already noticed some issues. When you leveraged periodic BC jobs you could set the copy interval differently for tenants with different quality bandwidth. I could be wrong but with Immediate copy if it gets behind it will copy one day, then right away try the next in order to catch up. If you have many backup copy jobs and only so many concurrent connections available this then becomes an issue. I prefer periodic copy, I can say to the tenant, yes we will get your backup copy jobs over the wire but with your current bandwidth we need 3 days… then it is up to them to increase bandwidth. 

This is a great thing to note for VSPs.  It could end up in a loop and jobs will become unstable.  To me as well this could be part of the Best Practice piece for VCC to take in to account client bandwidth then determine whether you turn on the Immediate Copy or not.  Great info nonetheless @Geoff Burke 


yeah it is funny how over time one’s tastes in wine and backup copy job methods evolve. I at first too thought.. “yuck copy interval” now though :)>


Immediate copy jobs can't have active fulls which is an issue for us for some jobs. And for Veeam One immediate jobs are also not normal copy jobs and missing in some reports.


In my opinion the immediate copies are easier to understand than the periodic ones. The intervals need a bit more planing and also depend on your backup window and runtime.


I agree with Geoff regarding Veeam Cloud Connect. By default I still use periodic copy jobs for our tenants. Also especially because immediate copy jobs has to be linked to an existing backup job. For Veeam Cloud Connect most of the times those VMs taken to the service provider are only the most critical VMs. Normally those are fixed. Mostly a tenant pays to a service provider for used storage and number of VMs taking to VCC. You always have to think twice if you want to copy this VM also to the VCC, that’s the logic we are using.

 

Bu as Regnor says, the immediate copies are a lot easier to explain to customers and even colleague-engineers. A lot of them are not fully aware of how periodic copy jobs are working...


Nice, I like immediate to get everything copied over high bandwidth, but if your jobs are running over 24 hours this is a good work around.

 

Another option is to schedule things in a more parallel format, or recommend higher bandwidth.


The biggest challenge with immediate copy jobs is tenant bandwidth. Hence, if their bandwidth is limited to the point the copy job won’t complete before the next backup job runs, its probably not the best method to choose.

That said, its nice for those occasions that a customer runs into an issue with internet interruption or something else stopping their copy jobs from running.  When the connectivity is re-established, the jobs will run continuously until caught up. Provided, again, the tenant bandwidth out paces their backup jobs.


Comment