This question points to one of the big disconnects between best practices and actual real-world implementation. Backup is intended to help you to get back to where you were on a short-term basis. Backup applications are optimized for that role, and they do a great job of it.
If you take a look at the latest backup applications, with all of the wonderful features -- integration with storage systems, integration with server virtualization, excellent categorization and CDP -- it's really all designed to help you get things back up and running quickly, easily and granularly. Now, archiving is basically a completely different thing. Archiving is historic retention, to enable down the road ways to get back to your data.
Now that role can be served by similar hardware and even software. But if you're trying to use an off-the-shelf data protection system as an archive, you're going to run into some problems. The index isn't going to last long enough and it might not be appropriate for legal retention.
For example, if you were trying to hold a bed of email messages for a lawsuit and yet you were using a daily backup to do so, anything that happened during the day was probably missed. It's just a really poor way to protect information for legal holds. You need archiving just to clear stuff out of the email system. Then an archiving application that does that, maybe one that implements stubbing, is going to be a great match for your needs and is not a backup system.
Similarly, if you need litigation hold and e-discovery support, another email discovery system that supports journaling is going to be a great match for your needs and is not a backup system. The important thing to note here is that no matter what you're trying to do with email archiving, a backup system is not going to get you there. You really need a real email archiving system in order to get a good solution.
Check out the entire Email Archiving FAQ.
