Seeking best practice and suggestions

[chris352]

Hello,

First our environment:
3 Dell R510's Dual 5620s, 128GB ram 8 nics.
1 Gbps network
EMC VNX 5300 SAN
Dell R310 Veeam Backup server, X3450 CPU, 24GB ram

We're currently using Veeam to perform hourly snapshots from 9am to 5pm with 10 days of retention on our 40 production VM's with a total backup size of 4TB's.

We're backing up to a QNAP with 4 3TB sata drives in a raid 10 being served up via CIFS.

I have a couple of questions.

1: Transform is sllloooowww we're talking 40+ hours, what can we do to improve this?

2: Is it best practice to create one job with all VM's in it?

3: We're considering using Veeam's instant VM recovery in our DR plan however my thoughts are 40 production VM's running off of a QNAP box is going
to be too slow to operate. My idea is to connect 6Gbps DAS to our Veeam server (Physical btw) to allow for our production machines to all be launched
in the case of a storage disaster.

My thoughts with number 3 are we would likely see the transforms speed up as well considering our Veeam server is beefier than a QNAP and
it could potentially support us running our production machines until we get our storage back online.

I'm considering hanging a Dell MD1200 DAS off our Veeam server with 12 3TB drives in a RAID 10.

Any input is greatly appreciated.

[dellock6]

1. Do not do transforms on a Qnap, these operations are too much IO intensive and a Qnap has not enough cache or CPU power to do that kind of operations. Sad but true.
2. "Its depends". One job gives you the best deduplications since it can compare all your VMs, but in a single job VMs are processed sequentially. If this setup gives you a total backup time that is ok for you, go with it. Otherwise, split it in two or more jobs and configure proxies to do cuncurrent jobs.
3. That kind of storage will be for sure faster than the Qnap. Also, for your DR design, remember that your backup jobs will be locked during the transform, so if you need quick instant recovery you're better switch to other backup configurations that can unlock the backup files more quickly.

Luca.

[Vitaliy S.]

My 2cents - CIFS shares have never been a good target for backup jobs that are configured with transform option enabled. You'd better use Windows/Linux repositories, as these will allow us to run a small runtime on the repository, which in turn should boost the transform performance.

[chris352]

1. Do not do transforms on a Qnap, these operations are too much IO intensive and a Qnap has not enough cache or CPU power to do that kind of operations. Sad but true.
2. "Its depends". One job gives you the best deduplications since it can compare all your VMs, but in a single job VMs are processed sequentially. If this setup gives you a total backup time that is ok for you, go with it. Otherwise, split it in two or more jobs and configure proxies to do cuncurrent jobs.
3. That kind of storage will be for sure faster than the Qnap. Also, for your DR design, remember that your backup jobs will be locked during the transform, so if you need quick instant recovery you're better switch to other backup configurations that can unlock the backup files more quickly.

Luca.

Thanks Luca we'll take that into consideration.

[chris352]

My 2cents - CIFS shares have never been a good target for backup jobs that are configured with transform option enabled. You'd better use Windows/Linux repositories, as these will allow us to run a small runtime on the repository, which in turn should boost the transform performance.

Well news to me

I'm thinking after we move to DAS for our backup storage the issue of speed/transform time should go away.

My main concern now is the DR plan. Is it realistic to be able to run 40+ VM's in instant recovery mode or should I just setup local replication jobs?

[foggy]

Chris, actually, Instant Recovery is not meant to act as a full DR solution, but rather as a "spare tire". Please review this thread for some good considerations about the whole concept and usage of this functionality.

You'd better use replication to a full-blown DR site if you need to failover all of your VMs in case of disaster.

[Vitaliy S.]

I agree with Alexander, running 40+ VMs from a single repository server might be a challenging task. Btw, here is another good reading on expected vPower NFS server performance, please take a look: vPower NFS Performance

[chris352]

Appreciate all of the replies.

We're mainly trying to sort a production storage failure scenario. We do backup offsite but do not have plans to run production offsite more as an insurance policy if our production environment goes up in smoke.

Is it possible to use the replication feature to a local NAS (like the QNAP for instance)?

Basically we'd be using DAS for all of our backups and our QNAP would be recommissioned as a failover datastore for our vSphere environment. I've tested the QNAP quite a bit and it actually handles
iSCSI/NFS pretty well. Not as fast as the EMC box but enough to get us by.

[Vitaliy S.]

Is it possible to use the replication feature to a local NAS (like the QNAP for instance)?

If you can connect this device to the ESX(i) host, then yes. For replication jobs you need to specify target host you're going to transfer VMs to.

[chris352]

Perfect! Thank you!