Backing up large file shares

Availability for the Always-On Enterprise

Re: Backing up large file shares

Veeam Logoby tsightler » Thu Jan 05, 2017 12:31 am

If you are reading lots of data, but transferring very little, this usually indicates one of two things, something wrong with CBT, or something in-guest is touching lots of blocks, making VMware believe the blocks have been changed but, for whatever reason, there's no actual changed data. I'd suggest starting with a CBT reset, verify that CBT is actually working (i.e. no surprise HWv4 VMs), and work from there.
Veeam Software
Posts: 4768
Liked: 1737 times
Joined: Fri Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: Backing up large file shares

Veeam Logoby ddrrdd » Mon Jan 09, 2017 10:43 am

10 To on only one disk can be huge for you (depend of the performance of your hardware / storage bay)

If all your data of that server is only on one drive, I kindly recommend you to split that drive in multiple smaller disk/vmdk an aggregate them in one drive/mount point using the OS disk manager / lvm.

I administer many DB and you should expect better performance with multiple stream to read/write your data than only one for your 10 To.

You should expect better virtualisation performance in many points: you can use multiple LUN / datastore in your storage, multiple virtual HBA in vmware, your backup can read multiple disk in parallel (restore will also be faster), your snapshot commit will be more efficient…

In linux lvm usage is very common, no so with Windows but there is also a performant disk manager. Pay attention to disk resizing if you plan to grow your volume and use the stripping aggregation (test the resizing need with small virtual disks before your 10 To)

Best Regard,
Posts: 6
Liked: never
Joined: Thu Oct 13, 2016 4:01 pm

Re: Backing up large file shares

Veeam Logoby Seve CH » Mon Jan 09, 2017 4:04 pm


I am against too many disks. In my experience, the more disks the VM has, the longer the stunt time is while taking or removing snapshots. That could lead to time-outs (and cluster failovers), sockets closing and so on.

For instance, we gave up with frequent incrementals or replications in our file servers (7-8 vDisk, 7-8TB) because the stunt time was 6 to 8 seconds and every snapshot operation (especially taking snapshot) generated 2000-4000 handles closed by clients and Citrix problems with profiles being inaccessible. Now we make only daily backups at night of these servers (way far from the RPO of 15 minutes for all application Veeam announces though).

We have an image archive (PACS) with the same problem wich must be backuped frequently and what we have done is to consolidate data in less disks via extend disk, add mirroring of the old partition and then remove the old disk mirror. With that we removed 10 vDisks and the stunt time of that server (8TB) went down to approx. 2 seconds and the application doesn't crash anymore (8-10 seconds stunt was too much). We didn't consolidate more because vmware doesn't allow to do hot-extend over 2TB.

In all cases the problem was not the size of the VM, but the number of disks and marginally the load on the VM and host. Tested on ESX 5.1, 5.5, 6.0. I have no idea if the stunt times are better in 6.5. It is not a Veeam problem, but a vmware "feature" (reproductible while taking manual snapshots from vSphere client of test VMs).

Best regards.
Seve CH
Posts: 10
Liked: 6 times
Joined: Mon May 09, 2016 2:34 pm
Location: Switzerland
Full Name: JM Severino

Re: Backing up large file shares

Veeam Logoby mkreitzer » Tue Jan 10, 2017 11:16 pm

Just don't expect to be backing them up to tape. Even though 9.5 finally made it possible to avoid having tape copy jobs terminate when the primary backup job starts, I don't think Veeam is capable of parallel tape drive usage when copying a single VM even in 9.5. We backup multiple 10TB+ VM's daily, but a single LTO6 drive takes days to copy a full backup of just one of them.

It's extraordinarily aggravating.

Also, Seve CH, you're adorable. :) It's "stun time", btw. It's a shame that with the huge head start VMware had that they could not implement a ReFS 3.0/NetApp/Everybody but VMware style snapshot system before Microsoft. We still have to consider snapshot deletes a potentially disruptive event.
Posts: 8
Liked: never
Joined: Thu Dec 17, 2015 3:54 pm
Full Name: Michael Kreitzer

Re: Backing up large file shares

Veeam Logoby Delo123 » Wed Jan 11, 2017 8:06 am

A SAN with Veeam Snapshot integration would be nice for these cases, but i stopped trying figuring out how Veeam decided who to integrate. Hp/EMC and then of all possible brands Veeam choose Nimble? Anyway, a lot of Vendors tell me Veeam has no resources and they are all ready blabla, time will tell i guess :(
Posts: 348
Liked: 94 times
Joined: Fri Dec 28, 2012 5:20 pm
Full Name: Guido Meijers


Return to Veeam Backup & Replication

Who is online

Users browsing this forum: Google [Bot] and 36 guests