Backup copy jobs to immutable SOBR

[IanBolton]

Hi

We have 2 x SOBR, Primary site is Windows with VBR installed. DR Site is Linux with immutability.
Backup jobs wrote to PrimarySOBR
backup copy job is configured to copy PrimarySOBR to SecondarySOBR (ie. entire repo).

It was configured this way for simplicity and safety - we would not need to configure a secondary destination / backup copy job for each new backup job we created.

However

It seems that this doesnt scale too well when there are large numbers of VMs in the repository.

Eg. Backup job 1 contains 160 VMs
BackupJob2 contains 20 VMs.
Both write to PrimarySOBR
and are copied to SecondarySOBR

One issue is that when browsing backups, by going to Backups\Disk(Copy) I see one job and select properties I see 1yr worth of restore points for EVERY VM I've backed up, and it takes a LONG TIME to populate.

If I wanted to change this, and create a separate Backup Copy job to copy each initial backup job, does it start again with a new Full, to start a new 'chain' at the SecondarySOBR?

Hope this makes sense...

[HannesK]

Hello,

It seems that this doesnt scale too well when there are large numbers of VMs in the repository.

depends what "large" is. 160 is fine and if you see issues with that, please log a support case and post the support case number for reference. If you said 1,600 VMs in one job, I would recommend to split, but 160 is no problem from the software side.

One issue is that when browsing backups, by going to Backups\Disk(Copy) I see one job and select properties I see 1yr worth of restore points for EVERY VM I've backed up, and it takes a LONG TIME to populate.

sounds like too little resources on the SQL database (e.g. SQL express running on 1 vCPU instead of 4 cores). that's independent from backup copy jobs or Hardened Repository

New job = new chain.

Best regards,
Hannes

[IanBolton]

sounds like too little resources on the SQL database (e.g. SQL express running on 1 vCPU instead of 4 cores). that's independent from backup copy jobs or Hardened Repository

VBR Runs with SQL Express on a phys server (part of the Primary SOBR) and is dual socket 40core.

New job = new chain.

That's as I suspected, thanks.