The Power of Next-Generation Archiving Continues to Amaze
Even before I began working for an integrated content archiving software provider, I was well aware of the fact that archiving software provides benefits across several spectrums.
There’s saving storage costs by moving information off expensive production storage; there’s eDiscovery savings and risk mitigation by proactively retaining and disposing of information according to policy; and there’s the end-user productivity benefit of allowing workers to save as much information as they need without having to create PSTs or figure other work-arounds to get past quotas. All of these benefits are huge, but there is so much more to the story.
Quick background to set some context here – I come from the world of ECM and records management. I began to study eDiscovery from that perspective, thus I thought of the benefits of proactively managing information from the point of view of a records manager or a General Counsel. And, yes, these folks really care about archiving and the benefits is can provide.
However, these folks are less likely to want to dig under the hood of the archive software and see what truly differentiates one from another. And, I was no different…I was so impressed with all the benefits that archiving could provide, it almost didn’t matter to me that all the differentiation is under the hood.
What’s changed for me since coming to work at Mimosa is that I know talk to way more IT operations and infrastructures pros than I ever did before.
These folks want their records managers and General Counsels to get the legal and risk mitigation of the archive solution. But, these folks also have to deal with many things that records managers and General Counsels never have to think about.
Ask a GC what IOPS is I guarantee you won’t get the right answer. But, input-output per second (IOPS) on an Exchange server is an extremely important metric.
The more IOPS on your server, the harder it is to manage and scale. And, first-gen archiving solutions rely on capture mechanisms like MAPI and Journaling, both of which can increase IOPS up to 50%. Once you take that increase into account, the benefits of archiving start to look less glamorous.
And so, I’m back to the title of this post. Mimosa is the only next-generation archiving solution that capture content with zero production system footprint. No increase to IOPS, no agents on Exchange servers. Mimosa captures a full compliance copy of all Exchange data (including those things journaling can’t get like calendar items, task, item histories, etc.) and then uses “Smart Extract” technology to archive any information that meets an organization’s archiving policy.
Oh, and by the way, because Mimosa uses “continuous application shadowing” (using transaction logs from Exchange to be replayed into a shadow database, from which information is archived), the system also offers completely integrated recover and optional DR. Important?
Go ask any message administrator that has had to remount the last full tape backup, plus any incrementals, in order to recover a mailbox. My money says they will take Mimosa’s point-in-time recovery capabilities that have the mailbox back in a matter of minutes instead of spending a full day trying to restore a mailbox.
It’s part of what I love about the job – getting a new perspective on the benefits of archiving. And, learning the importance of next-generation archiving because of things like integrated recovery. Archiving has always killed multiple birds with one stone…Mimosa just keeps adding more and more birds to the repertoire…and it’s fun to watch.
August 6th, 2008 at 4:03 am
You comment that there is zero impact on the Exchange server. This is false. If you are reading the Transaction log files, then this is putting an IO load on the Transaction Drive subsystem. In fact when Exchange is running it never reads the Transaction drive it only adds data (writes). So if you have to re-read the logs this is a 100% impact which then has to be committed to the network subsystem. What is worse this is occurring during core operational hours rather than being scheduled for off peak times!
August 7th, 2008 at 8:48 am
Heath:
Thanks for your comment. In one sense, you are correct – there is an actual “load” on the production system. However, the load is so negligible as to be zero when compared to MAPI or journaling. Microsoft publishes requirements and makes recommendations for disk I/o requirements for environments using log shipping technologies (see Mailbox Storage design : http://technet.microsoft.com/en-us/library/bb738147(EXCHG.80).aspx). Every time data is read from or written to Exchange, disk I/O is generated. Understanding the sources of Exchange disk I/O helps you plan and configure your disk subsystem in a way that maximizes performance. The I/O pattern is 100% sequential writes during normal operations and 100% sequential reads during recovery operations on the transaction log volumes. The load on Exchange to replicate the closed transaction log files is extremely low. Mimosa has run many tests and I/O stats come back with near negligible impact on the I/O subsystem. Importantly, it wouldn’t impact the live database performance as the transaction log files should be on a separate spindle of drives. Furthermore, this is the same method that Exchange 2007 uses for CCR, LCR, and SCR. Log Shipping has also been used with Microsoft SQL and many other databases for many years with negligible impact. If absolutely necessary, we can schedule Log Shipping to run after hours.