How many VM’s in your Veeam backup Job?

[TimeKnight]

*Short Question*
I am curious how many VM’s people put in a single Veeam Backup & Replication Job?
I have 1 job backing up my entire production cluster containing 228 VM’s.

*Extra Info*
As I said I have 1 job backing up my entire cluster and I seems to be having a problem over the weekend with the “Transform previous full backup chains into rollbacks” I am backing up my VM’s Monday through Friday and I Friday I create a synthetic full. My full (.vbk file) is about 1.7TB. Each incremental is between 50GB and 160GB and I keep 15 restore points.

My problem is that process to transform my backups into rollbacks is taking 35+ hours on the weekend and last weekend the process failed saying I had insufficient resources. My Veeam server is a Dell R510 with a Single CPU Xeon X5650 (6 cores + HT) 2.67GHz and has 12.0 GB of RAM. For storage we have 12 2.0TB SATA HDD in a RAID 6 configuration giving us about 18TB of space.

I contacted Veeam support (and opened ticket 5182631) and the suggestion I was given was to create smaller backup jobs instead of 1 large job. I asked for recommendation and while I could not get one, I was told that most customers do not have more than 10 VM’s in a Veeam job Really so I need 23 veeam jobs? Guess I will lose out on a lot of de-duplication if I have to split up my job.

I am hoping to get some feedback from users to find out how you have designed your Veeam backup jobs.

[Vitaliy S.]

Hi Brian,

If I were you I would probably split this job into 5-6 separate jobs and used containers such as VM folders, host or datastores to backup all your VMs. In this case you would not lose much in deduplication, but will win in synthetic full creation time.

On top of that, I've just found an existing topic that might have an answer to your question : Are you a large customer backing 300+ VMs?

Hope this helps!

[averylarry]

I would suggest that data size might mean more than # of VMs. For instance, when you said 228 VMs, I thought that was a lot compared to my 5. However, my 5 VMs also use about 1.7 TB.

Personally, I would suggest switching to reverse incremental. Then your transformation is effectively spread out over the entire week. Each night's backup will take longer (obviously), but you won't have the extra long transformation on the weekend. (And in my experience the reverse incremental doesn't take as long as a transformation.)

If you're worried about the extra time running on snapshots, then you could have the job run a tranformation more than once per week.

Oh -- and it might be obvious but a common technique is to split jobs based on OS. Clear advantage for deduplication.

[TimeKnight]

All my VM's are Windows (Server 2008 R2 & Server 2003 R2)

my problem with the reverse incremental is tape. We run a backup to tape of our Veeam backup folder. A full backup on the weekends and then a incremental tape job every night, if i run the reverse incremental veeam job i will be pushing much more data to tape every night.

[dellock6]

Hi Brian,
we have much more than your VMs, and they are splitted by resource pools, since we extract them from vCloud Director. I also did some quite large Veeam design, and I never personally created job with more than 40-50 VMs. Having a single huge job is best for deduplication, but creates other problems. First of all, the full backup VBK file is quite large anyway, so dealing with it start to be difficult (moving it, importing it again from tape, mapping...).
Second, as Vitalyi said, synthetic creation will be really hard to complete, and if something times out or crashed, you had an inconsistent state for ALL your VMs, and not only a subset of them.

Having that number of VMs, if your deduplication ratio is your main concern, I will personally go for a dedup appliance and let it do all the hard work.