Please share your first v4 impressions here :)

[musicman]

Nice! Stupid simple to setup, especially in HotAdd mode on a VM. Getting about 40MB/s on first pass and 200+MB/s or so on the delta passes - mostly with smaller VMs, so throuput is affected by snapshot setup and teardown.

I do have a question about replication - it work great, but it is setting up Thick disks on the replication server, even though the source is Thin disk. Is this normal or controllable?

[Gostev]

Mark, currently it is "normal", we had to drop support for replicating disks as thin as it required significant changes in a few existing components, but we were running out of time. This limitation is actually documented in the Release Notes under Known Issues. Overall, there are no technical difficulties with replicating disks as thin, and we will add this in the future updates.

[Gostev]

Hello,

I've upgraded to v4 recently ..

well I'm not impressed by the speeds I'm getting on replication jobs.
In fact I expected little bit more from new version.

I've heard that there will be no big improvement if I don't use ESX 4 but I count that there will be some (~+30 MB/s) improvement.

In my case there is no speed improvement from version 3.1
On average it's 48 ~ 61 MB/s

I'm using VC4 - ESX 3.5, 2GB FC SAN, EMC Clariion CX300 and CX3-10
Backup Server is Dell PE 6650 with 2 x Xeon 2,5 Ghz 4 GB RAM

What might be the reason for this ?
the SAN speed, backup server performance, Vi3 ?

or it's normal that there is no speed improvement taking into account I'm still using ESX 3.5 ?

Thanks.

Hello, yes this is normal - replication engine for ESX 3.5 did not change in this release.

In case of ESX 3.5 backup, speed improvements mostly come from slightly increased speed of data retrieval from source storage (about 10-20%), and due to the new backup storage format (which can be noticed on VMs with high I/O only, up to 5 times performance increase there).

But, since you are replicating, backup storage does not come into play at all - because we write into "plain" VMDK file on target. While source data retrieval speed gain is pretty minimal overall, and is mostly negated by the fact that you are already at the speed where network connection and VMFS write speed start coming into play.

In order to see significant increase in replication speed, you need to be on ESX4... this would increase your current incremental replication speed around 10 times for most VMs.

[garethhwilson]

we are testing V4 with an aim to moving from vranger and so far i am very impressed

we are using the vstorage api and we are backing up 1.7TB into 525.8 GB with a compression ration of 3x

pity the resore speeds are a lot slower than the backup speeds but you cant have everything

[Gostev]

Luckily in most cases you will want to restore individual files instead of entire VM, and this restore type is where Veeam really shines

[Felix]

I'm happy with the new version after some initial problems I'm seeing substantial speedups in backup times.

Before switching to 4.0 backup time of 1.5TB VMDKs, of which about 1.1TB were backed up using Veeam Backup 3.1 in VCB mode and MS iSCSI path to SAN took around 8.5 hours, on occasion much longer, exceeding the backup window.

Switching to Veeam Backup 4.0 at first most backups were failing, because I used independent disks, which are unsupported and cannot be auto-skipped using vStorage API as opposed to VCB.

Then I decided to switch all those disks to normal mode and include them in backuo, so now I'm backing up 1.5TB in around 2 hours unless InVM database backups have been run, which increase the amount of changed data to be transferred significantly in which case backup time jumps to about 5.5 hours.

I noticed that a busy small bussiness server running AD, File Server and Exchange didn't gain much still taking about one hours to backup (down from 2 h, so not too bad). But backing up SAP servers with huge databases (~70GB) has sped up significantly, with incrementals running at up to 1 GByte/s.

In the future I'll try switching those InVM database backups to a share on the backups server, which would give consistent backups times and avoid backing i/o for that data to occur twice (once to vmdk on sans, then from san to backup host).

In addition Veeam Backup 4.0 puts much less load on the SAN during backup, because it doesn't have to transfer data continously, but only changed data.

I think backup times still could be improved, by running multiple jobs in parallel, because much of the time neither SAN bandwidth, backup RAID, nor CPU time are saturated. I'd love to see backup concurrency support per job as opposed to having to run multiple backup jobs, which has problems because eg. it cannot fully use compression gains trough deduplication.

Before deciding on Veeam Backup this April, I tested vRanger 3 which allowed concurrent VCB jobs and allowed to saturate SAN bandwidth nicely by running 3-4 concurrent backups tasks in one job, but it was inferrior in many aspects compared to Veeam, as was esXpress which had by far the longest backup times.

[JorisK]

- Deinstalled VEEAM 3.1
- Removed all backup data
- Installed VEEAM 4 update 1
- Restarted all the QUEUE's

First Full backup was made using VCB since all settings got inherited, tonight the first incremental starts using the vStorage API. Speeds are okay by now but tonight should make the difference.

I also have to mention: only 6 VM's out of the 120 failed and succeeded after the retry job, no errors.

Currently we backup 5TB data / 120VM's at 4 concurrent backup tasks.

[glemmestad]

Just a quick update that I am now backing up a total of 10.2TB of data, 212 VMs and 11 templates, spread over 32 seperate (concurrent) jobs running accross 3 backup servers.
Man, I just love this WebUI !! I can see all the statistics above from ONE location... imagine compiling all that without WebUI. And the graphical representation of the backup windows and performance/speed/time per server? Awesome!

[Jonathan]

We've been running the new and improved Veeam B&R for about two weeks now and I can honestly say it's been a revelation. It's insanely fast, easy to use, stable and has (almost) all the features we want. The person who thought up the functionality where you can use a replica to restore individual files from a VMDK should get a medal. Maybe it existed in earlier versions too, but it's a real life saver.

Incremental backups are extremely fast on most VM's. An incremental backup of our 500GB+ fileserver (2.6 million files) is done in under 3 minutes. The initial full backup took only 1:19:00. Due to the nature of vRanger's file level restore function, we were still relying on file-by-file backup using Backup Exec, which took us 6 hours every night. That has just been cut down to 3 minutes

Just two minor issues: we're still waiting for thin provisioning support for replicas and backups of a 200GB Exchange server still take roughly 2,5 hours (same as the initial full backup). But looking at the vrb files, that's probably due to the nature of Exchange databases (daily vrb's are usually 40GB for a 180GB vbk).

Coming from vRanger, it makes me bang my head against the wall for ever buying their software
My blood pressure has dropped a few points now

[Gostev]

Jonathan, great feedback, thank you for taking your time to write this. Support for thin disks for replication is scheduled for version 4.5 (Q1 2010). What causes Exchange to be slower to backup and larger rollback files is transaction logs... we will be testing some potential changes to the code and this may partailly resolve both issue (cannot say for sure until we test, so no promises).

Even, no wonder you are enjoying what you actually took part in creating

[JorisK]

- Deinstalled VEEAM 3.1
- Removed all backup data
- Installed VEEAM 4 update 1
- Restarted all the QUEUE's

First Full backup was made using VCB since all settings got inherited, tonight the first incremental starts using the vStorage API. Speeds are okay by now but tonight should make the difference.

I also have to mention: only 6 VM's out of the 120 failed and succeeded after the retry job, no errors.

Currently we backup 5TB data / 120VM's at 4 concurrent backup tasks.

Some results after one week running on version 4:

We run with 4 concurrent backup queue's, backup about 5TB data on 100+ servers in 6 hours, which took previously 12 to 13 hours. In version 3 we usually had about 10 VM's failing to backup, but since the upgrade we have no failing VM's anymore, all of them succeed. Write speed is limited to 200MB/s because our diskcontroller can't write much faster. (100% write cache)

We still run on VCB since vStorage is very slow, still no idea why. @Gostev: could it be vStorage backup is slow because we ran the first backup using VCB? I have fresh and new backup data files but the first time we started our queue's the queue's where still in VCB mode. After the backup succeeded i switched them to vStorage which gave poor results)

The results look good, but i think they can get better when using vStorage.

[Gostev]

For everyone else, reportedly vStorage SAN mode is faster than VCB SAN mode. This needs to be investigated with support.

[gvinpin]

I am impressed with the product itself, v4 is a big step forward.
Not impressed with migration

I had to re-do all my jobs, as they were sitting for days in some (conversion mode) and then failing.
All my jobs are big, we are talking ~50TB of backup jobs.
On the bright side, search function during job set up is a welcome addition, as I group backups on server name basis.

Now backing up 400 servers with only some warnings, no errors for 3 weeks