feature request: split vbk

[deepak.irani]

HI All,

We have backup of a single drive which is 8 TB in size. For secondary storage option we are using azure blobs. Limitation with blob is to have 4.6 TB of single file. We can not use per VM vbk as only one server is the object for backup here.

[DGrinev]

Hi DeepakR,

There is no tool to split large VBK in the current version of the product.
However, your post is counted as a feature request, thank you!

[mclemen2]

Another +1.

I have several hosts (some VM some Veeam Agent for Windows hosts) that have up to 25TB disks. I'd like to split them up. Especially since when backing up to SMB repos where Kerberos has a 10hour timeout. If separate files were written out, the ticket would be updated within the window.

[fika]

Any news regarding this feature request ?
Thank you very much Veeam dev team !

[foggy]

Hi, what is your use case for splitting VBK file?

[AlexK977]

Another +1 for this.
We're hitting a 4TB max file size problem on our Isilon.

@DGrinev: Is there a list online where we could see, if Feature Requests will be/have been tackled ?
Thx

[DGrinev]

Hey,

There is no way to track FRs online, since they are noted in the internal system which is available only for Veeamers. Thanks!

[Gostev]

Question: does Isilon support S3 interface?

[AlexK977]

@Gostev: I don't think so. There is only a thing called CloudPool, where you could connect the Isilon to S3 storage in the cloud. I think the Dell EMC ECS storage has it's own S3 interface.

[madmadmaddog]

We asked for this feature 6 months ago. Tired of waiting with no idea if it would happen we had to move to a competitor. What ever happened to v10?

-Matt.

[mkaec]

I don't think they ever committed to implementing the feature. Sadly, the common destination for most customer requests (with most software vendors, not just Veeam) is eternal hold.

[Gostev]

That is a fair thing to say. With hundreds of pending feature requests, 95% of them will remain in "eternal hold" - with only the most pressing ones ever getting a chance to be implemented.

[Andreas Neufert]

Maybe already too late. But let me add here that there is dsmISI Load Balancer Software that split our workload in a way that all Isilon nodes work on a single Veeam write/read stream in parallel and as well split the backup file. So performance plus and no file sice limitation anymore.

[lmbutault]

any news of this feature request in update 4 ?

please add me to this feature request please

[veremin]

This feature is not available in Update 4. Thanks!

[cmcgee]

+1 for this - huge files are very difficult to manage, single VMs option hurts the dedupe ratio, and is still not a viable alternative for large file and database servers, etc.

[bhnelson]

Another +1 here.

We're trying to mirror our Veeam backup repo to AWS S3, since Veeam can't do that natively. 5TB per-file limit and we have a couple VMs over that size for a full backup.

This is another 'how does a backup product even exist without this feature' kind of feature. And seeing forum requests for it going back to at least 2014 doesn't bode well for ever seeing it implemented.

[veremin]

It seems you're trying submit a feature request for one feature, while in reality you need a different one - copy backups to object storage as soon as they are created .This feature is already in development. Thanks!

[bhnelson]

It seems you're trying submit a feature request for one feature, while in reality you need a different one - copy backups to object storage as soon as they are created .This feature is already in development. Thanks!

Yes, that would be great. However after all the hype at VMware World last year, we expected that functionality to come in U4... and were disappointed. Now we're expecting it to come in U5, maybe this year, but who knows? Not gonna hold my breath. We're trying to do it now and can't wait around for Veeam's development cycle.

It'd be nice to at least see basic functionality in lieu of advanced... This feature should be SIGNIFICANTLY less work to implement than direct S3 integration. And it's been requested a slew of times over at least the last 5 years. And there are numerous use cases, as others have mentioned. Mine is just one more on the pile. Please don't tell me I'm asking for the wrong feature.

Incidentally, how do you handle S3's 5TB limit for the scale-out repos today? And how will you handle it with the 'copy to S3' option in the future? Seems like you'd need the 'split vbk' feature for those tasks anyways! I'd wager the functionality is already in the code somewhere, just not exposed to the user. Or maybe Veeam just flat out fails in such situations today. I can't say I've tested it.

[jmmarton]

Keep in mind backups sent to object storage are stored as objects, not as files and a single restore point could be made up of multiple objects. This means the splitting up of VBKs shouldn't be necessary when storing in S3. Here's an example from my home lab where I take a daily active full of a VM and then move those backups to Minio, which provides S3-storage. You'll see a bunch of objects from May 1 even though there's just a single RP from that day.



Ultimately within a backup chain there's a bit of source-side dedupe going on as well when sending to object storage which minimizes the data sent and stored in the first place. The large VBK problem is more of an issue with file-based storage.

Joe

[LBegnaud]

+1 for this feature

Azure SMB is a pretty perfect way to create an SoBR for a BR server in azure... except that they have a 1TiB filesize limitation.

[controlfreak]

+1 for this feature request.

This affects our managed agent backups more than our per VM backups, because the agent backups are larger. We are talking about 2TB+ file server backups (this is a single server in this job).

This also affects my VM backup copy jobs, which are 1TB+. Having one master backup copy job is great from a management perspective, but it doesn't work with huge VBK files. I have about 6 backup copy jobs to reduce the VBK size. I would prefer to have a single backup copy job.

To support the 2 TB+ VBKs, I'm having to reformat my 20TB file server data partitions with "Format /L /A:64K" due to file system limitations (https://www.veeam.com/kb2023). I can now take larger backups, until we hit the new NTFS limits. We can't expect our data volumes to support VBKs that perpetually increase in size. These huge files are also bad for data dedup and for multithreading.

Please add a Max VBK size or a VBK split option for VM and Agent based Backups and Backup Copy Jobs.

Thanks!

Control Freak

[jmmarton]

In the meantime, for your situation you may wish to consider ReFS rather than NTFS with deduplication. Windows dedupe typically doesn't work with files > 1 TB, and for large file servers it's quite possible for a single disk to exceed that size so splitting the VBK still wouldn't help. With ReFS at least merge/transform should be much quicker thanks to block cloning, plus ReFS supports larger file sizes than NTFS.

https://docs.microsoft.com/en-us/window ... s-overview

Joe

[controlfreak]

Thanks for the ReFS recommendation Joe. We will look into it as an alternative to NTFS.

-Control

[mkaec]

I'm starting to think there is a serious architectural limitation that is causing the product team to not want to implement this. The reasons given for wanting to be able to split the VBK files are reasonable and logical.

[jrbaumann]

+ for this feature

Anyone know if this is being worked on?

[foggy]

Hi Jeff, so far it didn't get high enough in the priority list.

[jplopper]

+1 For this. NetApp has a single file size of 16TB. When largers CIFS or NFS shares are backed up to a VBK, we're probably going to hit this limit.

[edingc]

+1 for this request.

[PHBG]

+1 for this request
I'm an old Veeam fan and I remember their story. The first versions of Veeam Backup were design to be simple, tiny specialized for virtualization only. Very good products but not covering many of big company needs (for example backup physical server and not only windows but more AIX, Linux). With every new version they become more and more enterprise products. For better or worse some of the limitations they have now, are due to
their legacy in the past design.
I think sooner or later they will implement splitting vbk. The VMs and severs become bigger every year. We have some monster VMs in our company. One of them is 150TB and still not possible to backup with VBR due to such limitation. One 150TB file? What about 1 PB server - 1 PB vbk file?