SOBR - Combining Copy and Move Modes

[jgreenwood]

Hi
Could someone please provide advice on whether the below is achievable or not, and how I might go about it?

Have ESXi VM's and Windows Physical Machines on Prem using the agent

• Short retention of VM's and Physical machines on local disk and a copy of the backups in an Immutable S3 Bucket for Ransomware protection

• Require Weekly, Monthly and Yearly Backups for VM's and Physical Machines for archival purposes offsite in Object Storage (Doesn't need to be immutable)

What's the best way of achieving this? Would it be creating two SOBR's:
SOBR1 - Performance extent would be disk on Veeam Backup server, with capacity tier an S3 Bucket with Object Lock/Immutability - Copy mode enabled on this SOBR
SOBR2 - Performance extent would be disk on Veeam backup server, with capacity tier a standard S3 bucket - Move mode enabled on the SOBR)

The VM's and agents would be configured to backup daily to SOBR1 which would ensure local copy and copy in S3 with immutability
Then a secondary copy job enabled to take GFS backups copies of the agents and VM' backups for Weekly/Monthly/Yearly backups to SOBR2 which would then stage the backups out to the Standard S3 bucket.

Is the above the most efficient way of achieving what i need to?
I know you can combine the modes, but wouldn't want object lock/immutability on my GFS Backups as I believe it costs more.

Can anyone provide advice please?

Thanks

[HannesK]

Hello,
and welcome to the forums. You could do it the way you mention, but it uses more disk space as you have two full backups instead of one (higher costs)

I would go with one SOBR and copy & move mode.
- set "copy backups"
- set immutable for example for 3 days
- set "move older" for example 14 days

Retention is applied according to the retention settings.

Best regards,
Hannes

[jgreenwood]

Hi,
Thanks for the reply.

What would be the difference between the 'copy' and 'move' settings in the above scenario? Because the settings are on the SOBR repository level and not the job level then as soon as backup files land in the SOBR they will be copied automatically to S3. How would the move setting then kick in as the backups are already in S3.

Also because you can only associate a single S3 bucket with a SOBR, that would mean we had to use the same S3 Bucket with Object Lock enabled (which i believe incurs higher cost) would I simply set the retention on the bucket for 3 days, for example.

Thanks

[HannesK]

Hi,

Because the settings are on the SOBR repository level

which ones? retention is defined on job level. So if you have 7 days retention and move after 14 days, then nothing will be moved. only copied.

How would the move setting then kick in as the backups are already in S3.

delete backups from performance tier

would I simply set the retention on the bucket for 3 days, for example.

the immutable setting is usually much lower than the backup job retention setting. of course you run into (cost) issues when you set 90 days immutability and only 14 days backup retention

Your requirement is immutability (no matter what it costs). So adding a second SOBR just adds more costs as you now store the backups twice instead of once

Best regards,
Hannes

[jgreenwood]

Hi Hannes
Thanks for the response.
When i refer to the settings that are set on the repository level, I mean the 'Copy' and 'Move' functionality.

Right ok, so as the backups age out of the operational restore window then they would be removed from the on prem repo and just be stored in S3.
As you can only associate a single S3 Bucket with a SOBR (and this Bucket would need to have Object Lock Enabled) then how would the older 'Move' backups not be affected by the cost of this?

When Veeam Moves the data does it remove the object lock functionality, or do you just set the Object Lock Retention on the bucket to a much smaller figure i.e. 3 or 7 days?

Thanks for your help so far

[HannesK]

then how would the older 'Move' backups not be affected by the cost of this?

I'm not sure that I understand the question. object lock guarantees X days will be available in the cloud. no matter what. It's not relevant whether these backups still exist on-prem or not. It's just about the days configured.

When Veeam Moves the data does it remove the object lock functionality,

no. object lock cannot be removed (it's WORM). if 10 days are configured, then the backups will be available in the cloud at least for 10 days. they could already be deleted on prem if you set a lower backup job retention. But that will give you ugly error messages because we try to delete things that are on WORM storage. That's why I recommend to set the immutable value to a (much) lower value than the backup job retention

3 or 7 days?

these values look good to me