Segment Veeam files after "X" size

[ericcsinger]

Does Veeam have the ability to segment/split/chunk files after they're larger than "x" size? If not, there really needs to be, because multi-TB files just aren't meant to be copied to tape as a single file. We have a few VM's with single VMDK's that are 4TB in size (used), and it take a really long time to copy the vbk to tape. The copy time isn't as much of an issue, but when we have a hiccup or some other issue during a backup, we need to copy the entire 4TB vbk file again. I'll place part of the blame on our backup software for not properly creating check points, but at the same time, I honestly think you guys should have this as a feature (if you don't already). Ghost has this and its a 10+ year old product. Tape isn't going anywhere any time soon, so even if tape isn't your primary backup solution, the system still needs to be designed in a way that makes it tape friendly.

Further more, if we need to restore from tape, (lets say single file restore) it would be really useful if we only needed chunk 1 / 75 to restore a single file instead of needing all 75 chunks (as an example).

[veremin]

Hi Eric,

No, there is no such an option to split backup files into small chunks. Neither is there an granular file restore from tape mediums. Anyway, we've heard your feedback!

Thanks.

[ericcsinger]

Just curious, is this in a road map at all? I was kind of hoping this might be a version 9 feature.

[Gostev]

Not on a roadmap currently due to a very low demand. However, direct restore from tape is planned. Thanks!

[Dima P.]

Hello Eric,

it take a really long time to copy the vbk to tape.

Wanted to chime in and ask how you are currently backing up your files. I mean it looks like you are using file to tape job to copy the Veeam’s backup files, is that correct? Thanks

[ericcsinger]

Hi Dima,

I'm only interested in discussing about file segmentation in this thread.

[veremin]

Backup file segmentation is not planned for version 9.

Though, in version 9 we're planning to introduce per-VM backup chain functionality, meaning that with this option VMs chosen as backup job source will have own set of backup files (fulls, increments). Not only would that enable multiple write streams within a single job with parallel processing enabled, but also it would make restoration from tapes easier, as you would need to restore a .vbk/vibs of corresponding VM, not a huge .vbk containing all source VMs.

Thanks.

[ericcsinger]

Hi,

While I appreciate the replies, it really seems like this is going no where. I just wanted to check in and see if this was something you were considering. Its a pain point for me, but you guys don't care since its apparently only me and I guess a few other customers (as I'm not the only one who's requested this). Then again, how would I know since you guys don't actually have a formal feature request solution that would have true ranking, or if you do, I've not seen it.

[Gostev]

I just wanted to check in and see if this was something you were considering.

Hi, Eric. As per my previous response - no, we are not considering this particular feature. While direct restore from tape is planned. Thanks!

[ericcsinger]

I saw your post, I wan't stating that I didn't get an answer. What I meant is that you guys lack a true feature request / voting tool, so there's no good way for me or anyone to know that a feature has been requested, and if so, how it ranks. I've worked with some solution providers that had this (LANDesk as an example) and it was awesome. It showed not only feature requests, but also there status, such as "actively being developed" or "under consideration". It was a formal way to gather new requests from everyone and properly rank things. Another good example is VMware's fling request... It needs to be moderated for sure (for example, duplicate requests need to be merged), but its the fair and proper way to handle requests. Perhaps give folks two votes per year or something like that. Maybe even do weighted votes or more votes based on the number of sockets a customer owns.

This would eliminate the need for informal, anecdotal forum posts, and instead when someone has an idea you say "submit a feature request and vote on it".

[tntteam]

Hi there,

I would like to upvote this feature.

Scenario : we are using veeam to backup exchange servers, which each has multiples 300GB vmdk resulting in a backup file size ~3TB for a single VM. We use windows deduplication which is atm single core and not recommended for big files.

Possibility to split the backup file per vmdk or per size limit would be awesome.

Also I think you should REALLY consider this feature request, as IT evolves the size of data in single server goes up, more and more customer will ask you for this.

My 2 cents