Recommended v9 Backup Job Settings for Dell DR4100

[rreed]

Morning everyone, other folks are asking about other dedupe devices so I'll go ahead and make sure we're covered here as well please. Veeam v9, backup jobs straight to Dell DR4100, CIFS share via VM proxies (hot-add). 10Gb infrastructure (SAN, network, DR4100), VMware 6u1b. Weekend full/week day incremental.

Repositories are decompressing before sending, per-VM backup files (nice), no limits on concurrent tasks or data rates, disable vPower NFS, manual selected Gateway server.

We used these job settings through v8 and kept them the same in v9 (fresh build on fresh server, migratory process rather than in-place upgrade): forward incremental w/ full on Saturday (separate schedule for fulls would be nice), no maintenance, enable inline dedupe, exclude swap file, exclude deleted file blocks, no compression, local target 16TB+, no ecryption, enable CBT.

What's the latest best practice w/ v9 writing directly to Dell DR please? Of the balance of speed, space consumption, and recovery time, I would say recovery time is our priority. We've just added 27TB to our existing DR's so it's hard to say how we'll come out wanting to shrink our data footprint in the end. Right now restoring from dedupe is dismal so anything we can do to optimize getting data back out of them is priority at the cost of some performance, space consumption, etc.

[ChuckS42]

I don't believe anything has changed with regards to writing backups to a Dell DRxxxxx device. If there are any changes, they'd come from Dell. (I have had an open case with Dell on Veeam backup performance and stability for almost a year now.) Per-VM backup files should work fine. Always limit concurrent tasks or performance suffers.

[rreed]

We limit our concurrent tasks by way of staggering job schedules here. We have a limited amount of VMware resources to lob proxies at this all day long so we stagger our job schedules to take the burden off proxy CPU slots; currently only around 20-24 per data center, but I'm fixing to add 1-2 more if I can. Typically when jobs are sitting waiting here it's because of waiting on available proxy servers.

[foggy]

Could you please share the reasons for not using automatic resource scheduling in Veeam B&R and manually staggering the job start times instead?

[rreed]

Sure foggy, see my post above please. Aside from being uncomfortable w/ too many Saint Bernards trying to come in through the cat door at the same time, it became too difficult to predict when a given job or especially given VM was going to finish its backup by a certain time when everything just dog piled into a big queue. We have our most important and biggest VM's firing off first, then second tier a half hour to hour later (effectively giving first tier dibs on resources to get started first), then third tier later on in the evening. In total things seemed to help stabilize a bit in an already unstable environment, we could better predict if/when our tier one VM's would get a head start, and felt better about not seeing so many jobs waiting on infrastructure resources (proxies). Again though, I'll be throwing some more proxies at it now that we've just installed another blade server and some more SAN space.

By automatic resource scheduling, do you mean just scheduling all jobs to fire at the same time, or is there a handy check box I missed?

Getting back on topic, how do my settings look please? And many thanks!

[foggy]

Then this probably comes from previous versions, since now priority in assigning resources is given to the tasks of an already started job, not allowing any dogs to pile into a queue. Yes, by automatic resource scheduling I mean scheduling all jobs to fire ~at the same time, starting the most important ones a few minutes earlier than others, but seems you're taking what is best for you of both approaches and are comfortable with that, just wanted to make sure you're not missing anything in how resources are scheduled.

Your settings look good to me.

[rreed]

Excellent, many thanks foggy.

Question while we're at it and since you mention it, so if we scheduled our jobs to start say, five minutes apart from each other (6:00, 6:05, 6:10, etc.) would the later starting jobs get in proper line while waiting for resource, all running in their proper order as resources become available? Or once things start piling up into a queue, jobs/VMs start randomly? If that makes sense. I'd love to be able to effectively say, "Here's the order in which individual VM's/HDD's will get to go, when the one before you is finished."

[foggy]

so if we scheduled our jobs to start say, five minutes apart from each other (6:00, 6:05, 6:10, etc.) would the later starting jobs get in proper line while waiting for resource, all running in their proper order as resources become available?

This. Here's a bit more on that.