Object Storage space usage as compared to NFS

[antspants7777]

Hi,
I'm not expecting any definitive answers, as it will depend on the workloads being backed up.

But can anyone give me a ballpark estimates. High /low on the potential space reduction of moving backups stored on local NFS Storage to local S3 Compatible.
I see that in the Veeam calculators for both VBO & VBR the Object storage calculations are often significantly less.
But the VBR calculator only includes calculations for offloads, so may be different to what I am asking

The environment we are looking at initially is for Cloud Connect.
I understand that we cannot migrate these yet. And as as such will be starting new backup copy chains.
We have told the customer that there will be extra data required for this and they want to know how much.

E.g
If a full chain of backups on the NFS backed cloud repositories take 10TB
What would the high/low usage be on an Object backed cloud repository?

In anyone's experience, would enabling Veeam Backup file encryption reduce or negate this completely?

Thanks for your time

[tyler.jurgens]

Encryption will have no effect on space usage.

As for NFS vs Object, it really depends on what you NFS back end is using. I think if its an NFS share with XFS formatted disk, you would gain space savings from the XFS integrations (although I may be wrong here, its always been a bit murky to me if a share from a ReFS/XFS formatted disk gains the same space savings as a direct attached XFS/ReFS disk. I never tested because I don't like using shares as my repositories ). If it is XFS, essentially full backups won't take any more space than an incremental. Object storage works the same way - all backups are essentially incrementals.

In that sense, Object Storage will effectively be just incremental backups all the time. With NFS or other repos, the answer is "it depends". You may see significant savings moving to Object Storage, but you may also see significant savings moving to an XFS repo. The benefit of Object Storage over a traditional RAID running on XFS is the erasure coding configuration you can have with Object Storage, which can better protect your data than any RAID setup.

[Gostev]

You will get space savings from block cloning on an SMB3 share backed by ReFS, but not on an NFS share backed by XFS.

[tyler.jurgens]

Thanks for clarifying that @Gostev!

[antspants7777]

Hi @Gostev,
Thanks for clarifying the above.
We're coming up to speed on the space efficiencies provided by Object Storage for the GFS synthetic process.

Active Fulls used to be a last resort. Due to the space and time required. Most relevant for large backup copies over a slow link.
But now with the new V12 features

1. Direct to Object Storage
2. Synthetic creation of GFS Active Fulls (previously was just synthetic fulls)
3. Active full for a single VM from the job

This is now greatly improved. Such awesome features.

Just to get some confirmation from the comments above.
(BTW, we are not using REFS or XFS in this environment)

1. On our current NFS backups, we used to get a jump in usage for each Monthly GFS backup
This won't be the case for Object as it will use the increments to create the GFS Active Fulls without consuming additional disk space other than the incremental size?

2. This will still be the case for encrypted backups
i.e. The GFS Active Fulls will still be able to create the GFS Active Fulls from encrypted incrementals without consuming additional disk space other than the incremental size?

3. This will still be the case for Cloud Connect customers where the SOBR performance tier is Object storage.
(yes, this is a Service Provider question on the end, so can move this to the other forum, if required)


Thanks for your advice

Cheers

Tony

[Gostev]

Hi, Tony.

1. That is correct. GFS restore points will not consume any physical disk space when created on object storage (and on XFS/ReFS as well). So you can basically have any GFS schedule you like without extra disk space requirements comparing to incremental backup.

2. Not sure what you mean by "Synthetic creation of GFS Active Fulls". Active Full for Direct to Object will NOT reuse blocks, as the whole point for Active Full is to create a new, completely independent copy of all data. If you want blocks reused, don't enable Active Fulls and keep using Synthetic Fulls.

Thanks

[tyler.jurgens]

I would say if you want to use Object Storage for your customers, you will want to read through this thread below:
cloud-connect-backup-f43/cloud-connect- ... 85343.html

It looks like running a dedicated bucket for each customer is likely the way to go for a variety of reasons. This means you wouldn't setup a SOBR for your cloud connect customers to utilize, you would simply create a new bucket and set that up for each customer. Keep in mind, you'd need each customer to be on v12 for this to work.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[antspants7777]

Hi @tjurgens-s2d,
Thanks for your comments.

As per best practice, we would use separate S3 Compatible buckets for each customer.
When we start using Direct to Object, we are just looking for anticipated space usage of Object Storage (with or without encryption) as compared to NFS.

Cheers

Tony