Exchange backup, resource reduction?

[Lars-Owe]

Hi!

Our Exchange servers is the biggest node in our backup system, with about 389TB of data. Every weekend we see a combined ingest of about 25TB from four servers. Would this type of data respond well to deduplication and/or compression? I understand that it's a bit like asking how long is a piece of string, but roughly, what could be a reasonable expectation?

My reasoning goes something like this. We cannot afford 2x400TB of extra disk space to move these backups from tape to disk, but perhaps it would be feasible to buy a smaller amount of disk, if possible, and offset that cost from savings of x TB worth of licenses and say two more tape drives which we would otherwise have to purchase?

 

[moon-buddy]

With an Exchange DB of this size, I would consider another backup option to achieve Operational recovery fast. TSM backups would do nicely for catastrophic recovery - one where you have a longer RTO.

Dedup will work but if I were to to do this, I would use a JBOD at the back end for backups (dedup enabled) with a target of a one to two week data hold for Operational recovery. This is quick and straightforward. Anything longer than this would rely on TSM long term like tape.

Now, this may not be a cheap solution. You should look at the value viewpoint of the data you are trying to protect. Is the e-mail system, and its contents, valuable to the conduct of your business? What is this cost? Would investing in hardware still be much less than a resulting loss or potential loss on the e-mail system?

 

[Lars-Owe]

Good points. I'm much more knowledgeable about our backup system than our e-mail system, but I'll try do describe the situation. We currently have four main Exchange servers, each with 24x3TB worth of storage. I think we could afford to lose two of them and still have a working system. There's a fifth server acting as lagging copy. The backup system is typically used to retrieve old mail (several years ago), no longer present in the Exchange system. This happens a few times a year. It's also a copy of the information as a last resort, that cannot easily be tampered with, should something really bad happen. I.e. RTO demands are relatively lax.

This fall the system will be upgraded to six Exchange 2016 servers, three in each location, where we should be able to lose one site and still have a functional system without manual intervention.

Student e-mails are stored in another system.

If, and this is a big if, the data could be reduced by 50%, the savings from 200TB worth of backup licenses and two tape drives would just barely buy 2x200TB disk space. Anything less than 50% would be a loss compared to the current situation, but more than 50% would be financially favourable and possibly a better technical solution?

 

[moon-buddy]

Deduped backup does not decrease license cost from a TSM perspective. What TSM looks at is the actual size of the backup.

Deduping backup reduces your time-to-backup (node handling dedup) and disk storage requirements. When data is written to tape, data is re- hydrated as you cannot store deduped data on tape.

Have you ever considered using a DAG solution for your Exchange? Some companies use this in lieu of keeping backups and for Operational recovery. The mailbox post are then backed up using other methods like Mimosa or traditional TSM.

 

[Lars-Owe]

Interesting. http://www-03.ibm.com/software/products/sv/spectrum-protect-suite says (abridged):

Choose from flexible licensing options

• Front End – Capacity is licensed the same way users see it, which simplifies show-back and charge-back auditing.
• Back End – Capacity is measured at the backup servers, after efficiency features have been used.

We've always charged our customers based on the amount of data used in the backend. I've been thinking of deduplication as an efficiency feature. This was also an important point of sales argument when we changed from PVU-based licensing to a TB-model a few years ago. I'm aware of dehydration, and we're thinking of keeping disk-based copies only for deduplicate-friendly backups (in recent versions they can even be replicated without dehydration!? although we're still at 7.1.4.109).

We're using a DAG solution, which takes care of recent history in Exchange. When someone wants to retrieve a mail from five years ago, or as a defense of last resort, the backup comes into play.

 

[moon-buddy]

IThis was also an important point of sales argument when we changed from PVU-based licensing to a TB-model a few years ago.

I have been used to PVU for a very long time until we reached a threshold that makes per TiB licensing more cost effective.

Do you run a macro from IBM on a regular basis to see what the amount of backup data you have (required to see if you are still within licensing limits)? If you do, look at what it spits out - the actual total backup as is. Not the deduped data from the back end.

 

[Lars-Owe]

Part of the report looks like this:

*----------------- Deduplication Benefits ----------------*
TSM Data deduplication resulted in
TB being excluded from measurement: 1.27