Exchange backup speed

[emachabert]

I all,

I just read through the post about Exchange replication speed but it is not speaking much about backup speed so I create a new one, if it is not a good idea please delete that post.

The setup:
I'm running Veeam 5.01 on virtual machine (Win 2K8R2, 4Gb, 4 Vcpu @ 3ghz). The whole setup is made up of an HP P2000 SAN (8gb/s FC, 6gb SAS 15k drives, 2Gb cache) and two ESX server (4.0U2).
VMs (22 VMs) are stored on two LUNs (on a RAID5 array made up of 8 disks 450GB 15K), Veeam VM has a backup disk (RDM) stored on a LUN made up of two 2TB SATA disks (RAID1).

All VMs'backup are fast (between 255MB/s and 980 MB/s, reverse incremental job, applicaction level processing) except the Exchange 2K7 VM (Win 2K8R2, 190GB, 180 mailboxes) which can't go more than 60MB/s.

Is the Exchange backup speed reason the same as the one explained in the post about Exchange/SQL server replication speed ?
I also noticed that incremental files are pretty bigs.

How are your Exchange's backup speed ? The numbers showed in Veeam's commercial PDF about exchange speed are pretty higher than 60MB/s !!!

Thank you.

[Gostev]

Hi - yes, the reason is exactly the same as stated in the replication topic. Exchange/SQL workload generate many more changed data blocks that must be processed during the incremental run, which directly affects VM processing time and so the performance rate. Obviously, VMs which have just a few changed blocks since last run will be processed many times faster.

So this is normal, but if you are concerned by incremental backup speed you are getting and would like to make it faster, remember that switching from reversed incremental backup mode to regular incremental backup mode will reduce incremental backup speed in about 3 times.

Please let me know what PDF are you talking about.

Thanks!

[emachabert]

Hi,

Many thanks for the quick answer, that's why I like Veeam !

I was talking about this PDF (for 4.0) http://www.veeam.com/insane-backup-spee ... 4.0_ss.pdf (page 1).
I'm not really concerned at this time, the whole backup takes 1h58 (from 3am to 5am), I 'm just wondering if my setup is good and if the speed is "normal". This job has been configured two days ago and I hope it wont increase each night at a point the job runs for 4 or 5 hours...
Will the next release handle worloads like SQL or Exchange by using smaller blocks and achieving better speeds ?

I am using reverse incremental because I am backuping to disk and Veeam says it is the "recommended mode" and because I think it is a good thing that the latest file is the full one.
Do you think I should reconsider my choice ?

Each night the job runs and during the morning the full backup file is written to tape through a dedicated backup network so I always have latest full backup on tape without any trouble on production network.

[Gostev]

Hi Eric,

Well, that PDF is not really our marketing, but rather a collection of user quotes picked up on this forum. But, there is nothing wrong with that number from the document - I would guess the backup job there was running more often than once per day. For example, if you configure the job to run 4 times per day every 6 hours, each job pass will complete 4 times faster than daily job pass (because of 4 times less disk changes to process).

Yes, your speed is "normal" and inline with what other customers are reporting for Exchange and SQL servers.

It is way too early to talk about the next release yet. I prefer not to make any promises until our QC validates any new technology, because otherwise I may potentially set false expectations to our customers and partners. Risk that something will not go as planned is always high here at Veeam, because we do not copy existing technologies, but instead innovate and invent absolutely new ways of doing things. So, when there is a roadblock encountered, we do not have a luxury of reversing someone else's code like our competition does and instead have to research, or sometimes even scrap whatever we have and go back to the drawing board for complete re-design. By the way, if you ever wondered why Veeam never publishes its roadmap - this is one of the biggest reasons...

Can you please clarify where did you find the information that reversed incremental is the "recommendation mode"? This is recommendation is definitely wrong, as each backup mode has its own advantages and disadvantages (see table in FAQ). Every customer has to select backup mode that suits specific environment and requirements best based on this information. For example, from what you explained above, it sounds like this may indeed be most suitable backup mode for you.

Thanks!

[emachabert]

Hi,

In fact, when you create a new job you have the choice between different modes. At this point, when you click on "reverse incremental" you can read "Recommanded for backup to general purpose disk" in the description text .
By the way, I clearly understand all that you said and I support the effort you put in making innovative and reliable products.

I have one last question
What would happen if veeam server crashes (for any reason, eg. hardware crash, process killed by someone stupid) during the backup job in reverse incrmental mode? Would all the backups be destroyed since it was writing the full backup file ?

Thanks.

[Gostev]

Oh, this recommendation only says that reversed incremental should be used with raw disks targets (because it is I/O intensive)... meaning, no good for backing up directly to deduplicating storage. Also, not ideal for copying produced backups to tape, removable storage, remote site - as huge file will need to be copied over daily (can be a problem when backup file is a few TB in size, but of course not a big deal with smaller backups).

Server crash in the middle of backup will not cause any issues. The backup set will not be destroyed because our backup storage is transactional. Data cannot be lost no matter what - just like you cannot loose a file on NTFS volume, or a database record by crashing the server while those are being updated. Of course, you will not be able to restore from the latest restore point (because it is incomplete), but you will be able to restore from any previous restore point with VBK being inconsistent.

Now, you may ask what happens next? When the backup job starts, first thing it always checks to see if VBK file is in consistent state. If VBK is inconsistent, the job first rolls VBK back to the last known good state (by undoing any modifications from previous run). Once that is completed, regular incremental replication pass is performed.

Thanks!