About copying to Object Storage Repositories

[rleon]

Hi,

I've gone though the documentation and a few threads on this topic.

I just want to verify if I understand this whole thing correctly:

• Object Storage Repos are only supported when used within a SOBR (Aka Capacity Tier).

• The above means you cannot point a Backup-Job, nor a Backup-Copy-Job to an Object Storage Repo. You can only point these jobs to the SOBR that contains said Object Storage Repo.

• Pointing a Backup-Copy-Job directly to a Object Storage Repo will be supported in the future.

• When a Backup-Job points to a SOBR, the SOBR-Offload-Job will move BOTH Full and Incremental backups to the Object Storage Repo.

• But when a Backup-Copy-Job points to a SOBR, the SOBR-Offload-Job will only copy GFS-enabled Full backups to the Object Storage Repo, but not the Incrementals. (If true, this is a major limitation. Any reasons as to why Backup-Jobs don't have this limitation? And will this be fixed soon?)

• With the way the SOBR-Offload-Job works, only Inactive-Backup-Chains will be copied to the Object Storage Repo.

• The above means if you do a traditional WeeklyFull(Sat) + DailyIncremental(Sun-Fri) strategy, the SOBR-Offload-Job will only copy stuff to the Object Storage Repo once a week instead of everyday. (This is a major limitation. Many organizations have a policy that requires the creation of offsite backup copies ASAP, pretty much as soon as the backup files are created everyday.)

• If there is a requirement to make the SOBR-Offload-Job copy stuff everyday, then the workaround is to only do DailyFulls and don't do Incrementals. That way, every backup will be its own Inactive-Backup-Chain, so to speak. But then there is of course a performance trade-off when you give up on Incrementals in your backup strategy.

• If you want to keep the WeeklyFull(Sat) + DailyIncremental(Sun-Fri) strategy, but also want to copy to the Object Storage Repo everyday, then the only workaround is to run a Windows VM as a Veeam Direct-Attach-Disk Repo in your cloud (AWS/Azure), and point Backup-Copy-Jobs at it. In order words, by not using the SOBR Capacity Tier method. The limitation of this method are: Cloud VM disk size limits and increased $$ costs for NOT using Object Storage. And even if the Cloud VM runs as a SOBR Capacity Tier to copy to Object Storage, you still have the limitation (already mentioned previously) where the SOBR-Offload-Job will only copy GFS-enabled Full backups and so no Incrementals. Not to mention the additional traffic charges by your cloud provider.

Thanks for your time!

[Gostev]

1. Correct.
2. Correct.
3. We have not officially announced this capability as coming yet, but it's a possibility.
4. Correct.
5. Correct. Backup jobs do have the same limitation (only "sealed" chains are offloaded), User Guide covers details on this quite well.
6. Correct.
7. Correct. You're confused: offload is NOT offsite backup in the first place, because if moves oldest backups only - while "offsite backup" requires copying latest backup.
8. Incorrect. This workaround will not let you meet your requirement of "copy stuff everyday", because the latest restore point can never be offloaded. So this is not a good solution in any case, unless of course your offsite RPO is over 24 hours. But in any case, with this approach you're trying to leverage offload functionality for the use case it was never designed for, so you may potentially face other unexpected issues too.
9. Correct. This is the only solid solution until v10, where Capacity Tier will support the immediate copy mode.

[rleon]

Thanks for the clarifications.
So, if for some reason a customer doesn't want to use point9's workaround, and just want to stick with the SOBR Capacity Tier method, is there any way at all in v9, to force the SOBR-Offload-Job to copy the latest backups everyday as soon as they are created?

[Gostev]

No.

[rleon]

Understood. Thanks again.