Growing usage of email for business communication, increasingly stricter regulatory norms, and laws mandate the long-term retention of email data. An inadequate data protection strategy and infrastructure can lead to data loss, severely impacting business continuity. IT Teams are often called upon to recover specific email data to cater to a data loss request or a business request for accessing past communication or legal or compliance queries.
Scenario A: You’re just back from vacation, full of energy and ready to get to work…but a few hours later, an unfortunate incident leads to a small office fire…luckily the office sprinklers put it out. However, in the process, your laptop is now wet, and the data on it (including all downloaded mail) is inaccessible…lost.
Scenario B: A deadly virus or ransomware infects your computer network and servers. This corrupts the email backup, throwing everyone out of gear and disrupting the workflow.
Scenario C: One of your users accidentally deletes mail and wants those back.
As part of information security, compliance, and IT requirements, businesses need to ensure that ALL the emails transacted by users are kept safe in a secondary or alternate store to facilitate:
Before you read on, it may be helpful to note that backup and archival are different.
Endpoints are client devices and software users’ access to work with their emails. Many organizations deploy tools to take backups of the email data on the client devices of their users, typically PST or EML files. In some organizations, it’s up to the end users to ensure that their data is safe. The backed-up data will contain a snapshot of the user’s mailbox on the endpoint (such as a desktop or mobile) at the time of the backup. Typically these backups are a collection of client data files (PST/EML or any other format) and are not conducive for searching or selectively downloading email without much effort. Furthermore, this method is too technical for any end user to access the backup themselves to search through and restore mail.
Use this method:
In case of loss, failure, or corruption of a user’s endpoint device/software, the administrator can restore the last good backup to get your users up and running quickly.
Some challenges with periodic backup from the endpoints are:
It’s pretty easy on most mail systems to configure a journaling rule to send a copy of every mail transacted by selected or all users to an email ID (typically called a journal email ID). Generally, this journal email id is just another mailbox in the same mail system. The administrator configures a desktop email client, like MS Outlook or Thunderbird, to POP mail from this journal email ID into a local PC to create PST files/EML files. These PST and EML files are backed up in secondary storage. The journaling mailbox and the PST/EML files are regularly cleaned and rotated to prevent endpoint storage bloat.
The use of the Single box Journaling method:
This method of email backup, collects all mail for all users in one account and further splits this into multiple PST/EML files. This fragmentation makes it challenging to do any kind of processing on the data or even restore any specific email for any user. This is a feel-good or notional backup, which suffers several of the same limitations as the first strategy.
Some challenges with the Single box Journaling method are:
This is typically done by all mail administrators, wherein they periodically back up the entire mail storage from the backend to a secondary store (relevant only for on-premises setups) The mailbox storage is captured via a snapshot tool, a tool like rsync to copy all the files, or a database backup tool depending on the mail solution deployed. Since many users pop and automatically delete mail from the mail store on the server, this backup method will likely capture even less data than the first strategy of backing up the endpoints.
Use of this method:
This method is a must for backend server maintenance and management procedures, which are used to restore the mail server or storage in case of an irrecoverable crash during a disaster. This method supports the disaster recovery requirement and should not be confused with an email backup, which can be used for selective restoration or search.
Some challenges with this method are:
This method is not helpful while attempting to restore an individual email or a full mailbox of a user since this is a raw backup of the mailbox storage in its most native format and is only meant to be used during a server restore procedure.
It’s pretty easy on most email systems to configure a journaling rule to send a copy of every mail transacted by selected or all users to a separate on-premise archival platform, which ingests the email and retains the email in a search-ready form. The main reason to keep this data on-premise could be an infosec requirement. However, enterprises and government organizations have significantly accepted moving their data storage and management workloads to the public cloud. You may want to evaluate whether your on-premises archival platform allows you to keep all data online and search ready, whether you can quickly find and restore any information quickly, and if your users can access their archived email safely, securely, and not be able to tamper with it, etc. Related: Components and costs of maintaining an on-premise setup While this method doesn’t replace strategy 3 (a server or mail store backup), it certainly can help you retire strategies 1 and 2 and improve the productivity of the users and IT team.
In this method, you would configure your primary mail platform to push/journal a copy of every mail transacted to a separate operational infrastructure on the cloud. Related: 4 Reasons Why Email Journaling is Necessary for Your Enterprise Having the data at a separate location in the cloud improves the data’s redundancy, reliability, and safety. Related: How to Protect Your Cloud Data from Hackers: 6 Ways to Keep Your Data Safe And evaluate whether the cloud email archiving platform supports the following critical capability:
If you are using an on-premise mail server platform, then strategy 3, which is to maintain Server/backend storage backups, is a must from a service operational and DR strategy perspective. Strategy 1 and 2, which are methods to backup email data, may not be required anymore if you opt for strategy 4/5, which is email archiving, since a copy of every mail is captured and stored in the archive store by design. Many archiving platforms may give you tools to search for email, restore mail selectively, and even allow your users to access their archives (self-help), besides a host of other features. Here is a table covering all the above strategies and mapping them against the required features to manage email data effectively.
| Strategy | 100% mail archived. | Compliance needing Fast Search across mailboxes | Organisation-wide Knowledge discovery | End-user self-service for discovery and recovery | Data safe in an independent infrastructure | All Data online and Search ready |
| Periodic BACKUP from the endpoints | No | Not possible | Not possible | Not available | No. Most backups are stored at the same site | Not possible |
| Many to one journaling | Yes | Not possible easily | Not possible easily | Not available | No. Most backups are stored at the same site | Not possible |
| Mail store BACKUPS | Not possible | Not possible | Not possible | Not possible | No. Most backups are stored at the same site | Not possible |
| Mail ARCHIVING in-premise | Yes | Yes. But not scalable | Yes. But not scalable | Sometimes available | No. Typically at the same site | Maybe. Some have secondary volumes |
| Mail ARCHIVING on cloud | Yes | Yes and elastic | Yes & elastic | Yes | Yes | Yes |
