VBK size with Forever Fowards.

[vmtech123]

I was trying out forever forwards and noticed the performance increase right away. I'm still doing some heavy testing and found that switching to a test repo set for PER-VM backups seemed to give me another large boost into the 1.2 -1.5 GB/s range which was fantastic.

I forgot to enable a few things and noticed the backup file grow as I didn't have any maintenance, active or synthetic fulls on which got me thinking.

Will the size be the same under all the following conditions?
Active full enabled
synthetic full enabled
Defrag and compact full backup file

Another thing I noticed was these 10TB plus VM's can get a bit slow with any of those processes. For those who have very large VM's what is the recommended best practice and job recomendation?
I have split many 10TB plus VM's into separate jobs to prevent ending up with a HUGE VBK file as they are already quite large. Just for the ability to work with them or preform a restore I figured that would make sense. Also the ability to just move to a few tapes per vm rather than need a set of tapes each time.

Also, with FF incrementals OR reverse incrementals if I enable the defrag and compact, is that going to save me just as much space as a syn full or act full? what about if I delete a few VM's from job. Will the defrag/compact remove that data?

Thanks

[foggy]

What kind of target storage are you using? Any chance it is a dedupe appliance? Due to the "append" nature of the forever forward incremental method merge operation on these systems the full backup may grow in size if neither GFS (for a backup copy job) nor compact operation is enabled.

Splitting large VMs between the jobs is not the best idea as it could cause issues during FLR.

Will the size be the same under all the following conditions?
Active full enabled
synthetic full enabled
Defrag and compact full backup file

Yes. Please see this user guide section for the answer to the last question.

[vmtech123]

Hey Foggy, I have 2 V7000's. both have a fair amount of disk, not flash. No dedupe. Backup to the first one, GFS copy to second. From there to tape.

The one that I am running GFS copy jobs to seems great. It's the primary one I noticed the jobs growing and just ran some active fulls.

I was just trying to decide if an Active full vs Defrag/compact are going to have the same end result stopping the VM from growing. I am sort of stuck with FF incremental or reverse incremental on this SAN as I don't have a ton of free space and some of the VM's are 20TB. Having them do active fulls would fill it too fast. Spacing them out would also work.

For File Servers I split the jobs up by VM
by "splitting" the jobs I mean I back up one VM (all disks) at a time. I didn't want to back up nine 10TB VM's into a 90TB job. I keep it as 9 separate jobs as an example. I loose some dedupe from veeam, but the restore time and processing time seems to work better for me. I am considering switching to Per-VM backups, but still undecided if that is the right choice.. The performance increase was noticeable, but I am cautious about the space as well.

Forother servers I group the vm's per job to try and benefit from the inline compression /dedupe which is why i am on the fence.

[foggy]

Got it. Per-VM backups will result in the same space requirements as your current 'job per VM' approach and will provide similar parallelability.

[vmtech123]

True for the large servers, I will lose on the app servers where i have 20+ in a job, unless I go 2 Repos, but these are all pretty major changes and I don't have a Spare SAN kicking around along with free weeks of time to test the performance / size differences per job I guess at the end of the day if the MAJORITY of my overall storage is used by the file servers, the bit of dedupe I am getting is pretty minor.

Is it recommended by Veeam to separate 10TB VM's or keep them in the same job?
And will the backup / defrag job function shrink the VM down to actual size the same as an active full?

[foggy]

Is it recommended by Veeam to separate 10TB VM's or keep them in the same job?

Do you mean doing as you do, backing up large VMs in separate individual jobs? There's no such a recommendation, it is mostly defined by your storage and performance capabilities and your overall experience, I would say. You can back up large VMs together unless it affects your backup/restore processes seriously (like, as you mention, with tapes, for example).

And will the backup / defrag job function shrink the VM down to actual size the same as an active full?

Yes, it will rewrite the full backup copying only the required blocks from the previous one.

[vmtech123]

Thanks again, I knew I was on the right track, but sometimes it's nice to have confirmation before wasting many hours and getting unexpected results.