File server backup methodology

[topry]

We are still planning our Veeam implementation as we migrate from ESX 3.5 to VSphere 4.1 and I am interested in any advice/tips on the following configuration.

Initially, we will have a single ESXi 4.1 server connected to a Dell MD3200i SAN. The SAN configuration is planned to have 2 Disk groups with RAID 5 and a hot spare. We are using two groups so we can have two totally separate set of spindles if/when the need arises.

Within each disk group, we will create multiple virtual disks 2TB (minus 512b) or smaller and format as VMFS3 datastores.
The majority of our VMs are small (50GB <) and will take up less than 1TB of total storage as fat disks (less when we migrate and convert). However our primary file server running 2008R2 (dedicated solely to file services) and supporting DFS will have three disks, one for the OS, and the other two to host the file shares - one which will host files that change rarely (long term storage) and will have a backup/replication schedule of once per week. The other is near term storage and have a backup schedule of once per hour, replicating each evening across the WAN to an ESX 4.1 host.

Due to the planned growth of the data, each of the two disks will be configured as thin and 1TB in size. Neither disk will experience a high volume of file I/O during normal usage. The biggest disk i/o will occur when the files are indexed each evening after hours, otherwise I/O during business hours will be modest.

Our primary concern is the backup/replication targets. As the total size of all data exceeds the 2TB limit, I'm assuming that Veeam has the ability to target multiple volumes (mapped drives to the Veeam host) (again we have yet to install/deploy - we have purchased v5 but plan to install on a dedicated Win7x64 VM). Backup will be to a LUN within the same SAN, different disk group (different physical disks) than the VM datatore, using the synthetic backup methodology, then replicating offsite.

Questions:
1) Am I correct that I can select a different backup schedule for each virtual disk for this file server?
2) Are there any challenges/considerations when your total backup set exceeds 2TB?
Unfortunately, we do not have an NFS datastore, so that is not currently an option. From reading the documentation, the backup target must be a mapped drive to the VM running the Veeam software, so I'm assuming we would target multiple mapped drives to host the backup?

I would appreciate any opinions/experience/insight/suggestions anyone has with large backup sets.

[Gostev]

1) Am I correct that I can select a different backup schedule for each virtual disk for this file server?

No, you cannot set backup schedule per disk, backup schedule can be set on per VM basis only.

2) Are there any challenges/considerations when your total backup set exceeds 2TB?

No special considerations that I am aware of.

From reading the documentation, the backup target must be a mapped drive to the VM running the Veeam software, so I'm assuming we would target multiple mapped drives to host the backup?

No, you cannot do that - there is a single backup target per job, and it should be large enough to accomodate the backup file. But I am not getting why you cannot have a single backup target? Max size of NTFS volume is 16TB...

[AlexL]

ESX performance with LUN's >1TB get worse as size increases, also consider scsi reservations, simply put, use max datastores of 800GB .. 1TB

We found that direct san access (EMC FC SAN) is WAY faster than using Virtual Appliance mode.

Doing a backup "per disk" should be possible by doing a backup of the entire VM and set exclusions for the disk(s) you don't want

If possible, for convenience, use multiple jobs to keep backup target files smaller. Easier to work (eg copy) 5x 200GB instead of 1x 1TB

[Gostev]

If possible, for convenience, use multiple jobs to keep backup target files smaller. Easier to work (eg copy) 5x 200GB instead of 1x 1TB

This way you will loose in deduplication ratio a lot though. So when backing up multiple similar VMs, fair comparison would be more like 5 x 200GB versus 1 x 300GB - most would prefer the latter. Backing up a single large VM is different of course, and dedupe will not be as efficient within a single file server.

[virtualwatts]

Hi Tim -

We are Dell bare metal with ESXi 4.1 and MD3220i - our Veeam server is a VM in the cluster. We use virtual appliance mode for our backups and the target is a set of datastores attached to the Veeam vm (residing on a separate MD3000i). Very quick and effective. I run parallel jobs keeping just under the port saturation limit.

Some of us were tesing over at DellTechCenter and didn't find any performance difference if you create one LUN or multiple. In our case we have LUNs at about 800GB as well . However, I found that datastores greater than 300GB were tough to move around on iSCSI so we've been using junctions in the Windows to segregate out a guest disk drive. Also consider that Veeam is writing to a single target and that target fills up quickly. One of our fileshare backups filled up this week and that was a mess. You cannot distribute your backup output in a single job across multiple targets. However, you can backup specific SCSI devices (e.g. 1:1 - 1:4) per job. That means if you use junctions you have access to multiple SCSI devices per Win disk drive, can back them up separately and can target the backups to separate devices.

For Veeam to move quickly through the LUNs you'll need to utilize all of the ports on your controller. Here's a link for some iSCSI configuration considerations on the MD3200i. It turns out Veeam is quite capable of crushing a PowerVault without some iSCSI device driver tweaking. I'm still working with Dell but think we've uncovered a glitch in the firmware for that MD32xxi controller. http://delltechcenter.com/thread/430566 ... t+LUN+path There is a work-around in the link thread by changing the MPIO pathing policy.

Good Luck - love our MD32xxi
Rick

[samuk]

[moved to the existing discussion]

We are about to virtualise our file server.

The VM will have 4 RDM's from the SAN.

3 volumes are of 2TB, and one is 1TB.

What will i need to take into account when backing up this large server of 7TB to a staging area?


Thanks in advance

[Gostev]

Samuk, you will need to configure your VM to use RDM disks in virtual compatibility mode (image-level VMware backup tools cannot backup RDM disks in physical compatibility mode, as these cannot be snapshot). You can refer to VMware documentation for more info if you are not sure how to configure RDM in different modes.

This is the only gotcha I can see. Thanks!

[topry]

Thank you for all of the great information -

One follow-up on the limiting datastore size to 1TB. Since a VMFS datastore is limited to 2TB(minus 512b) and Dell suggests limiting the number of virtual disks on the device for performance reasons - If I create a single 10TB Virtual Disk in each disk group, does ESXi 4.1 allow you to create multiple datastores of varying sizes within that single Virtual Disk? If not, and we must create 18+ virtual disks within the 3200i, according to the Dell documentation, performance would take a serious HIT on most of those LUNs. The Dell docs on the 3200i are good and configuration is straight forward, but I could not find info on that topic. If we could get into our office I could test this, unfortunately the snow/ice here in Atlanta is putting a damper on access.

[topry]

No, you cannot do that - there is a single backup target per job, and it should be large enough to accomodate the backup file. But I am not getting why you cannot have a single backup target? Max size of NTFS volume is 16TB...

If the Veeam host is running on a VM and the backup target must be a mapped drive of that host, to get more than 2TB (datastore limit), should we use a LUN on the SAN accessible to the Windows host via its own iSCSI initiator? Obviously, this is all new to me, so my apologies in advance for what may be blindingly obvious.

[Gostev]

should we use a LUN on the SAN accessible to the Windows host via its own iSCSI initiator?

Correct, this is the recommended approach. Whereas storing backups inside VMFS is not recommended, as this complicates recovery in case of large scale disaster. Besides, you have to deal with 2TB limitation...