Veeam Storage Best Practices

Note that right now these are mainly based upon my experience with the ExaGrid backup storage appliance. However, as I get the chance to test other appliances I will update this post and add to the list.

Disk to Disk backups are becoming more and more common, with that comes a new set of challenges. If you are stuck in the old way of thinking then there are many new things that you will need to learn, capacity is probably one of the things that surprise people the most. The idea behind disk to disk backups is to keep many restore points on disk media instead of tape, this allows for quicker restores and no cataloging tapes when a user needs just one file. The downside is that we need HUGE amounts of storage to keep all of the restore points on disk ready to use. Let’s assume that you want to keep one full backup from the beginning of each month (for the last 3 months), you also want to keep a full backup from the last four weeks (from Friday night), and a restore point from each of the last 30 days. Well obviously we can dedupe and compress data with Veeam, but let’s assume that a full backup of everything takes up 500GB of disk space. So for each month we need 500GB, and we need 500GB for each of the last four weeks, and finally, we need to store change delta’s for each night for the last 30 days. (I will assume our nightly change is 10% of a full… so 50GB/night. Therefore total storage requirements for backup data is: 4800GB (so almost 5TB of space).

With an Exagrid or HP StoreOnce appliance, we would only need about 2TB of space, because our full backups should almost completely dedupe when compared against each other, saving us about 3TB of space. The advantage of the deduplicated disk to disk backup storage is very clear, however with it also comes to some challenges and this post is about how to tweak some Veeam settings to minimize these downfalls depending on your situation. These best practices are based on what I have found to work best depending on the situation I was in. They are not the only way you could do things, and may not even be correct in the eyes of your storage vendor, but I will explain the settings I use and why I use them when I did.

Which is better Incremental, or Reverse Incremental?

This can be a complex decision depending on the environment, but in general, if you are using a deduplication appliance (like an Exagrid or HP StoreOnce) or if you are offloading your backups to tape… then you will want to use the Incremental style.

However, if you are using normal disk storage, like a SMSproSafe, then you are better off using the new Reverse Incremental method. This goes back to restoration, 99% of the time when you need to restore a file it will be from the previous nights backup. So if your using Incremental backups and need to restore a file that was not in last nights incremental backup, then Veeam has to sort through other files until it gets all the bits that make up your file. Therefore since Reverse Incremental build a synthetic full backup every night… you can restore the entire VM, or individual files very quickly.

However because disk IO is much heavier when doing a reverse incremental, it would not be a good idea to use this method on a deduplication appliance because it would need to un-deduplicate on the fly in order to get all the data to the Veeam server so it can built the next nights synthetic full backup. (It would do this because Veeam has to read older backup files to get all the data to create a synthetic full backup, and with a true “Full backup” it reads all the data it needs from the VMware datastore)

Should I do Synthetic Full backups or “Real” Full backups weekly?

Again this goes back to whether or not you are using a deduplication appliance for storage. If you are using an Exagrid or an HP StoreOnce or another deduplication device to store your backup files you are better off to disable synthetic full backups and instead do a true full backup each week. This is because of the data re-hydration that must take place while Veeam reads the old files and builds its new synthetic full.

There is a catch to this recommendation, however. If you are using an ExaGrid and it has been sized large enough to hold 8 days of backup data for all jobs in the landing pad (meaning last weeks full backups plus 6 days of incremental plus this week’s full backups) then you could try synthetic fulls. As a rule of thumb, I would try synthetic fulls first, and monitor the amount of time it takes to build the weekly synthetic fulls. If it takes more then 1.5-2x longer then your first full backup did… I would switch to “real” full backups instead of synthetic. Also, you could offset the days that synthetic fulls happen. So for one job do Sunday, and another job to Wednesday then you may be able to get away with a smaller landing pad. You will know quickly though if your unit isn’t big enough for this because it will take MUCH longer to do a synthetic full.

Should I leave compression on or turn it off?

After reading the manuals for both the ExaGrid appliances and the HP StoreOnce appliance, both seem to recommend turning off compression. While I have not tested leaving compression on I do plan to do that in some future testing. Check back for an updated article.

 

If I run across anything else I will update this post. As always if you have any questions please leave a comment or shoot me an email and I will find the answer.

Share This Post

6 Responses to "Veeam Storage Best Practices"

  1. I tried similair things with a Quantum DXi 4520 just see if the dedupe appliance would add any benefit to Veeams own dedupe. It did not. This was using Quantums firmware which used a landing pad rather than the newer release which does inline dedupe I believe.

    Nice article!

  2. Can you please explain “data re-hydration”. I have a DataDomain box and am not familiar with that term. DataDomain does inline de-dup. Does that have anything to do with it?

  3. Data re-hydration is the process of making data whole again. So no matter if your datadomain does in-line dedupe or post dedupe like the exagrid, data re-hydration will happen on both.

    Basically when you request a file from the storage device that file may not be in a usable format (because the box found duplicate data and just has a pointer to the real data) So when it starts sending that file out to whatever requested it …. it has to put the file back together as if it were never deduplicated.

  4. Sorry for the late reply – I recommend against reverse incremental as a general rule as if you are to move the Veeam backups (replicate, rsync, ExaGrid, etc.) -> the big file changes each time the backup is run (VBK).

Leave a Reply