2 backup jobs of same servers to Repo and Cloud

Hi Peter, 

the questions is very “tricky”, and it depends…

since V12 you can send backups directly to cloud🙃, so an independent job for each locations works.

The thing I don’t really like at all, it that both tasks running at the same time.

if the bandwidth is good, I would say independent job, directly to cloud, after Local one.

if the bandwidth isn’t that good, what about a backup copy job?

also not to impact the production with snapshots and full/ active/ whatever backups and so on.

https://helpcenter.veeam.com/docs/backup/cloud/cc_backup_copy.html

im assuming the environment is holding virtual machines.

is that cloud repo immutable?

I would also love to read what the guys may say, 

this is just my little personal opinion here.

cheers.

If you are using v12 then I would set up the backup job to local repo and then backup copy job pointed to the main job.  This way the main job finishes then the backup copy runs to the cloud repo.  No conflicts. 😎

Hi HunterLAFR,

Yes - the cloud Repo has immutability turned on and the servers are on VMware( 15 servers).

Well my concern is more on the fact that both jobs take incremental backups with CBT - which would result in that the backups of the servers would not be the same ??

As all files which has been modified during the first snapshot and backup - would be different from the second snapshot and backup to the Cloud Repo (VCC) !!!! - and as old backup administrator that would just not in my optic be the best solution 😲😲😦. 

I would prefer top have 1 daily backup job to local storage and then either do a backup copy job to the Cloud (object lock or other immutability activated) or setup a SOBR to handle the offsite backups.

I can’t say that the solution is incorrect until we have completed our restore scenario test - but I am quite convinced that the 2 backup jobs would be inconsistent with eachother - due to the fact that modified files would only be present in the later backup job…..

Just for less administrative overhead, I’d go with the single job, with a SOBR, backing up locally (Performance Tier), then copying to offiste. You still have to monitor the 2 destinations where files are stored, but at least you’d only have 1 job to manage.

With Veeam the answer it always “it depends” based on your requirements.

Personally, I like less overhead.

I’d do one of 2 options.

1. Create a primary job to local storage and run a copy job to the cloud
2. Create a SOBR with the cloud being the lower tier.

Are you looking to store long term GFS data in the cloud and have it immutable?

The first one is how I’m doing it between 2 SANs right now and it works great. less stress on the production system ruining the copy job from primary backup storage than 2 jobs as well. 

Some of this will depend on your connection speed. I have 10Gb network so the copy jobs really push that bandwidth. 

While you CAN back up a multiple times with multiple jobs, unless you have a reason too it’s not as common.

I will sometimes create a job and reuse a VM for testing things, or if I wanted to create a copy job of a specific VM, but it was already in a job that had way to many VM’s. I could just create a second job for that VM to a new location etc.

Mostly though, 2 jobs for every VM is not best practice. That is why copy jobs exist. 

Either a SOBR or a copy job would work for going to the second target.  SOBR is quick and easy if you are planning on having the same retention on both using the copy type, copy and move if you want to change retentions but that can be a little bit tricky maybe.  I setup a server yesterday with a backup job and then backup copy job to the cloud repo since we can now go direct to object with v12.  Either works.  I posted a question about this the other day and 3/3 responses said copy job vs SOBR which might be easier to do.  I’m starting to believe SOBR is going to be better if I want to have more than one performance extent, or if for some reason I needed an archive tier.

Hello All,
Thanks for all of your feedback and suggestions - I now have enough ideas to go into a deeper dialog with the consultants and start building a more straight forward and compliant backup solution.

Tak care out there - it can be a harsh world….

Br

Peter