Post by Paul C on Jul 22, 2012 10:00:08 GMT 5.5
Exchange Server 2010 : Backup and Disaster Recovery Planning
As the messaging system is fundamental to the success of a business, more and more companies implement and plan their backup and disaster recovery procedures very carefully to prevent the event of message outages.
The reasons to perform a backup include:
•Disaster recovery Allows you to restore configuration and user data as quickly as possible after a server failure.
•Point-in-time database recovery Allows you to recover a previous version of the database if the current database is not working correctly because of a logical or physical corruption, a virus attack, or a malicious administrator that destroyed or modified the data in the databases.
•Recovery of accidentally deleted items For when users delete items that later needed to be recovered.
•Long-term data storage Provides long-term storage of message data for compliance reasons or because it is company policy. Generally this involves archiving the mailboxes or storing a backup of the databases in a locked-down location only accessible to a person you completely trust.
. Developing Service Levels for Backup and Restore
Before you can think of what types of backup you implement for your messaging solution and how restore will take place, you should plan some time to develop service levels for backing up and restoring your messaging environment.
Very common service levels are summarized into three industry-standard acronyms: SLA (Service Level Agreement), RPO (recovery-point objective), and RTO (recovery-time objective) as described below
Common Service-Level Definitions
SERVICE LEVEL --DESCRIPTION
Service Level Agreement (SLA)
Determines how long the mail service can be down before service has to be restored
Recovery-Point Objective (RPO)
Determines how much data can be lost; measured in minutes
Recovery-Time Objective (RTO)
Determines the maximum time allowed for recovering each service; measured in minutes
To develop your own service levels, you should consider the following questions for your own organization:
•What level of service is required after the message service fails?
•How long can it take before service is restored?
•In case of an outage, do users need their mailbox data or just messaging services?
•How rapidly is mailbox data required?
•How many and what users must be supported during an outage?
•What services are essential to restore, and in what order?
•What is the maximum amount of data that can be lost?
•What budget has to be allocated for backup and recovery?
The overall design of your backup, disaster recovery, and high-availability strategy will depend on these SLAs to cover various failure scenarios. This will not only include considering backup, but also other areas such as high-availability and disaster prevention strategies.
--------------------------------------------------------------------------------
Note: Service levels also have an impact on your database design because they dictate the size of the databases so that you're able to recover with the time you have available. For example, if your SLA is 1 hour, you need to consider the time you need to identify the problem and decide for a recovery, and then add the time needed for the recovery of the database itself. You can imagine that with an SLA of 1 hour a database recovery shouldn't take longer than 30 minutes maximum and thus enforces very sophisticated backup technology or small databases.
Disaster Prevention Strategies
As you prepare to implement disaster recovery solutions in Exchange Server 2010, you first must identify the potential risks to the Exchange Server environment, and then identify the options for mitigating those risks, as detailed below
Potential Data-Loss Risks and Mitigation Options for Exchange 2010
POTENTIAL DATA-LOSS RISK -- OPTIONS AVAILABLE
Loss of a single message
Configure Single Item Recovery settings. Recover messages from backup by using the recovery database.
Loss of a single mailbox
Configure mailbox retention settings to ensure that you can recover most deleted mailboxes before they are deleted permanently. Recover mailbox using the recovery database.
Loss of a database or server
Create a database copy on another server.
Back up the Exchange Server data and recover lost mailbox databases from backup.
Install Exchange Server 2010 with the /m:RecoverServer switch.
Loss or logical corruption of a mailbox database
Create a lagged database copy in a DAG environment. Back up the Exchange Server data and recover lost mailbox databases from backup.
Loss of a public folder database
Implement public folder replicas to other Exchange servers.
Single Item Recovery
Exchange 2010 introduces a new concept called Single Item Recovery. Single Item Recovery, or Dumpster 2.0, the successor to Dumpster 1.0 in Exchange 2007 or earlier, provides some significant advantages over Dumpster 1.0:
•It ensures that all deleted or modified items are preserved; the user can no longer hard-delete any item from their mailbox.
•It ensures that deleted or modified items can be recovered easily.
•It stores all deleted or modified items in a hidden recoverable items folder in the mailbox that can be indexed and is searchable using discovery cmdlets.
•Because the recoverable items folder is part of the user's mailbox, all items in that folder are moved when the mailbox is moved to a different database or server.
•By default the recoverable items folder is given a quota to help prevent uncontrolled mailbox growth.
One benefit of Single Item Recovery over regular deleted items (known from Exchange 2007 or earlier) or brick-level backups is that the user can no longer manipulate or delete any items and you do not need extra backup media to store data for the brick-level backup.
As mentioned earlier, the recoverable items folder is located within the non-interpersonal messaging (non-IPM) subtree of the user's mailbox and thus is not accessible to the end user, but it is accessible to administrators assigned to the Discovery Management role. The folder includes three subfolders called Deletions, Versions, and Purges as described below
COVERABLE ITEMS SUB-FOLDER --PURPOSE
Deletions
Similar to the previous Exchange version, this folder includes all the items that have been deleted or removed from the Deleted Items folder but can be recovered in Outlook or OWA using the Recover Deleted Items option.
Versions
The Versions folder includes an item that was changed and then saved back to the mailbox in its original state. It includes all types of items, but does not include flag changes such as a category change and items in the Drafts folder. This folder is only used when Singe Item Recovery or Litigation Hold (or legal hold) is enabled on the mailbox.
Purges
The Purges folder includes all items that have been manually removed from the Deletions folder to preserve them until the deleted item retention period is reached (only if Litigation Hold is not enabled). This folder is only used when Singe Item Recovery or Litigation Hold is enabled on the mailbox.
Bleo image illustrates how the different folders in the Recoverable Items folder interact with each other and when they are used to store items.
Note: In Exchange 2010, mailbox items are no longer deleted by the user, but instead will be removed by Records Management when the deletion timestamp of the item has been exceeded.
Configuring Single Item Recovery
Single Item Recovery is not enabled by default, so you need to manually enable it using Exchange Management Shell (EMS). You configure deleted items recovery on a mailbox level using the following cmdlet: Set-Mailbox <identity> -SingleItemRecoveryEnabled $true. Alternatively you also can enable all mailboxes for Single Item Recovery using the Get-Mailbox | where {$_.SingleItemRecoveryEnabled –eq $false} | Set-Mailbox -SingleItemRecoveryEnabled $true cmdlet.
The default settings for Single Item Recovery are configured on the database level and include 14 days for deleted item retention and 30 GB as quota limit for recoverable items, as shown in Figure 2. However, you can also configure these settings on the mailbox level by overriding them for specific mailboxes.
Recovering Items from Single Item Recovery
To recover items from Single Item Recovery, you need to configure a mailbox search and then use the Discovery Search mailbox to recover the items to the correct mailbox. This action requires the following additional permissions:
•Full Access permissions on the Discovery Search mailbox for opening the mailbox and looking for the search results.
•Full Access permissions on the user mailbox for opening the target mailbox to recover the items.
•Either Mailbox Search permission or member of the Discovery Management role for defining a search in ECP. To assign this permission, you can run the following cmdlet: New-ManagementRoleAssignment –Role "Mailbox Search" –User <account>.
After you've assigned the permission required to the account, you need to define a mailbox search in ECP as shown
below
Note: By default the search only considers e-mail items, not other items such as contacts or appointments. If you want to restore all items, you need to select Search All Message Types Including Ones That May Not Be Listed Below in the Select Message Types dialog box.
--------------------------------------------------------------------------------
When the Mailbox Search finishes collecting the information, you can either use the Export-Mailbox cmdlet, which has a disadvantage in that you need to know exact folder names, or you can use the easier approach of configuring an Outlook profile that includes the Discovery Search Mailbox and target user mailbox so that you can copy the deleted items from the Recoverable Items folder to the original folder, as shown in below image
Planning Single Item Recovery Capacity
After learning about the Single Item Recovery feature, the logical follow-up question is "Do I still need backups for Single Item Recovery?" As always the answer depends on both your current backup requirements and on capacity planning.
Before performing the calculation, you should ask yourself the following questions:
•What's my current deleted item recovery time in days?
•How often do I require recovering items from backup and from what time span?
•What's my current client load pattern ?
Let's consider that a customer currently maintains a deleted item recovery time of 7 days and maintains backups for 60 days where users require Single Item Recovery. Let's assume the following client load pattern:
•Average message size: 50kb
•Messages sent/received per day: 100
•Items edited: 10 percent
Now let's do the math and calculate the space requirement for the recoverable items folder of a mailbox:
•Assumption: 5 working days * 100 mails = 500 mails per week
•Space requirements for Purges folder:
◦8 weeks * 500 mails per week * 50kb per mail = 195 MB
•Space requirements for Versions folder:
◦10 percent of 195 MB = 19.5 MB
This indicates a mailbox size increase of 215 MB per mailbox, and you don't even need a Single Item Recovery tool or backup of your mailbox databases because Single Item Recovery will be performed within Exchange.
--------------------------------------------------------------------------------
Note: After implementing Single Item Recovery you should monitor the size of the Recoverable Items folder of your mailboxes from time to time. This can be achieved using the Get-MailboxStatistics –id <account> | fl *size* cmdlet.
--------------------------------------------------------------------------------
Another consideration if you implement Single Item Recovery together with high availability of databases is that you can also dramatically reduce the backup frequency.
Ultimately, if the storage subsystem is planned and designed appropriately and mailbox resiliency features of Exchange 2010 are used, traditional point-in-time backups are degraded to only a disaster recovery mechanism—if they are even needed at all.
Mailbox Retention
Every Exchange mailbox consists of a user account in Active Directory and the mailbox stored in the Exchange database. If the mailbox is deleted, or a mailbox-enabled user account is deleted, that mailbox is not yet deleted from the database but is marked for deletion. The mailbox will stay as a disconnected mailbox on the database until the deleted mailbox retention setting is reached, by default 30 days. Only then is the mailbox purged from the database and thus physically removed. The main benefit is that mailbox retention allows you to recover deleted mailboxes up to the retention setting without having to restore the entire mailbox database. To reconnect the mailbox you just select the disconnected mailbox and connect it to a user account in EMC, as shown in Figure 5.
Even with good processes, mailboxes can be deleted accidentally or prematurely. In some instances employees are hired back shortly after they leave; in other incidents mailboxes are deleted with information required by other employees or legal departments. The mailbox retention period should take into account these scenarios and can be set differently depending on the type of user or the circumstances around the employee's departure. Defining the retention should be discussed and approved by each department and any legal counsel so as to reduce the amount of mailboxes that need to be recovered from backup
Mailbox retention is configured on the database level. If you want to change the configuration, you can use the Set-MailboxDatabase <database name> -MailboxRetention 30.00:00:00 cmdlet or you can use the EMC to configure the deletion time in database properties
If you want to make sure that deleted mailboxes are not available as disconnected mailboxes, you can use the Remove-Mailbox –Permanent $true cmdlet.
4. Testing Your Disaster Recovery Plan
The best backup and recovery plan is useless if your administrators do not know exactly what to do during a disaster. Therefore, it is a best practice to test a disaster recovery thoroughly at least once a year with the people involved in normal day-to-day operations of your systems. This test ensures not only that your recovery plan is working as expected and that your team is well trained in how to recover from a disaster, but also that any system changes are immediately implemented into the plan.
To test your disaster recovery plan, consider testing the following areas:
•Rebuild the systems from scratch after a total datacenter loss.
•Provide alternative solutions such as dial tone recovery to bring back the service operation as quickly as possible after server failures.
•Make sure the installation sources are available and updated (for example, latest service packs must be available).
•Test recovery in accordance with your company's SLAs to make sure they are met.
As the messaging system is fundamental to the success of a business, more and more companies implement and plan their backup and disaster recovery procedures very carefully to prevent the event of message outages.
The reasons to perform a backup include:
•Disaster recovery Allows you to restore configuration and user data as quickly as possible after a server failure.
•Point-in-time database recovery Allows you to recover a previous version of the database if the current database is not working correctly because of a logical or physical corruption, a virus attack, or a malicious administrator that destroyed or modified the data in the databases.
•Recovery of accidentally deleted items For when users delete items that later needed to be recovered.
•Long-term data storage Provides long-term storage of message data for compliance reasons or because it is company policy. Generally this involves archiving the mailboxes or storing a backup of the databases in a locked-down location only accessible to a person you completely trust.
. Developing Service Levels for Backup and Restore
Before you can think of what types of backup you implement for your messaging solution and how restore will take place, you should plan some time to develop service levels for backing up and restoring your messaging environment.
Very common service levels are summarized into three industry-standard acronyms: SLA (Service Level Agreement), RPO (recovery-point objective), and RTO (recovery-time objective) as described below
Common Service-Level Definitions
SERVICE LEVEL --DESCRIPTION
Service Level Agreement (SLA)
Determines how long the mail service can be down before service has to be restored
Recovery-Point Objective (RPO)
Determines how much data can be lost; measured in minutes
Recovery-Time Objective (RTO)
Determines the maximum time allowed for recovering each service; measured in minutes
To develop your own service levels, you should consider the following questions for your own organization:
•What level of service is required after the message service fails?
•How long can it take before service is restored?
•In case of an outage, do users need their mailbox data or just messaging services?
•How rapidly is mailbox data required?
•How many and what users must be supported during an outage?
•What services are essential to restore, and in what order?
•What is the maximum amount of data that can be lost?
•What budget has to be allocated for backup and recovery?
The overall design of your backup, disaster recovery, and high-availability strategy will depend on these SLAs to cover various failure scenarios. This will not only include considering backup, but also other areas such as high-availability and disaster prevention strategies.
--------------------------------------------------------------------------------
Note: Service levels also have an impact on your database design because they dictate the size of the databases so that you're able to recover with the time you have available. For example, if your SLA is 1 hour, you need to consider the time you need to identify the problem and decide for a recovery, and then add the time needed for the recovery of the database itself. You can imagine that with an SLA of 1 hour a database recovery shouldn't take longer than 30 minutes maximum and thus enforces very sophisticated backup technology or small databases.
Disaster Prevention Strategies
As you prepare to implement disaster recovery solutions in Exchange Server 2010, you first must identify the potential risks to the Exchange Server environment, and then identify the options for mitigating those risks, as detailed below
Potential Data-Loss Risks and Mitigation Options for Exchange 2010
POTENTIAL DATA-LOSS RISK -- OPTIONS AVAILABLE
Loss of a single message
Configure Single Item Recovery settings. Recover messages from backup by using the recovery database.
Loss of a single mailbox
Configure mailbox retention settings to ensure that you can recover most deleted mailboxes before they are deleted permanently. Recover mailbox using the recovery database.
Loss of a database or server
Create a database copy on another server.
Back up the Exchange Server data and recover lost mailbox databases from backup.
Install Exchange Server 2010 with the /m:RecoverServer switch.
Loss or logical corruption of a mailbox database
Create a lagged database copy in a DAG environment. Back up the Exchange Server data and recover lost mailbox databases from backup.
Loss of a public folder database
Implement public folder replicas to other Exchange servers.
Single Item Recovery
Exchange 2010 introduces a new concept called Single Item Recovery. Single Item Recovery, or Dumpster 2.0, the successor to Dumpster 1.0 in Exchange 2007 or earlier, provides some significant advantages over Dumpster 1.0:
•It ensures that all deleted or modified items are preserved; the user can no longer hard-delete any item from their mailbox.
•It ensures that deleted or modified items can be recovered easily.
•It stores all deleted or modified items in a hidden recoverable items folder in the mailbox that can be indexed and is searchable using discovery cmdlets.
•Because the recoverable items folder is part of the user's mailbox, all items in that folder are moved when the mailbox is moved to a different database or server.
•By default the recoverable items folder is given a quota to help prevent uncontrolled mailbox growth.
One benefit of Single Item Recovery over regular deleted items (known from Exchange 2007 or earlier) or brick-level backups is that the user can no longer manipulate or delete any items and you do not need extra backup media to store data for the brick-level backup.
As mentioned earlier, the recoverable items folder is located within the non-interpersonal messaging (non-IPM) subtree of the user's mailbox and thus is not accessible to the end user, but it is accessible to administrators assigned to the Discovery Management role. The folder includes three subfolders called Deletions, Versions, and Purges as described below
COVERABLE ITEMS SUB-FOLDER --PURPOSE
Deletions
Similar to the previous Exchange version, this folder includes all the items that have been deleted or removed from the Deleted Items folder but can be recovered in Outlook or OWA using the Recover Deleted Items option.
Versions
The Versions folder includes an item that was changed and then saved back to the mailbox in its original state. It includes all types of items, but does not include flag changes such as a category change and items in the Drafts folder. This folder is only used when Singe Item Recovery or Litigation Hold (or legal hold) is enabled on the mailbox.
Purges
The Purges folder includes all items that have been manually removed from the Deletions folder to preserve them until the deleted item retention period is reached (only if Litigation Hold is not enabled). This folder is only used when Singe Item Recovery or Litigation Hold is enabled on the mailbox.
Bleo image illustrates how the different folders in the Recoverable Items folder interact with each other and when they are used to store items.
Note: In Exchange 2010, mailbox items are no longer deleted by the user, but instead will be removed by Records Management when the deletion timestamp of the item has been exceeded.
Configuring Single Item Recovery
Single Item Recovery is not enabled by default, so you need to manually enable it using Exchange Management Shell (EMS). You configure deleted items recovery on a mailbox level using the following cmdlet: Set-Mailbox <identity> -SingleItemRecoveryEnabled $true. Alternatively you also can enable all mailboxes for Single Item Recovery using the Get-Mailbox | where {$_.SingleItemRecoveryEnabled –eq $false} | Set-Mailbox -SingleItemRecoveryEnabled $true cmdlet.
The default settings for Single Item Recovery are configured on the database level and include 14 days for deleted item retention and 30 GB as quota limit for recoverable items, as shown in Figure 2. However, you can also configure these settings on the mailbox level by overriding them for specific mailboxes.
Recovering Items from Single Item Recovery
To recover items from Single Item Recovery, you need to configure a mailbox search and then use the Discovery Search mailbox to recover the items to the correct mailbox. This action requires the following additional permissions:
•Full Access permissions on the Discovery Search mailbox for opening the mailbox and looking for the search results.
•Full Access permissions on the user mailbox for opening the target mailbox to recover the items.
•Either Mailbox Search permission or member of the Discovery Management role for defining a search in ECP. To assign this permission, you can run the following cmdlet: New-ManagementRoleAssignment –Role "Mailbox Search" –User <account>.
After you've assigned the permission required to the account, you need to define a mailbox search in ECP as shown
below
Note: By default the search only considers e-mail items, not other items such as contacts or appointments. If you want to restore all items, you need to select Search All Message Types Including Ones That May Not Be Listed Below in the Select Message Types dialog box.
--------------------------------------------------------------------------------
When the Mailbox Search finishes collecting the information, you can either use the Export-Mailbox cmdlet, which has a disadvantage in that you need to know exact folder names, or you can use the easier approach of configuring an Outlook profile that includes the Discovery Search Mailbox and target user mailbox so that you can copy the deleted items from the Recoverable Items folder to the original folder, as shown in below image
Planning Single Item Recovery Capacity
After learning about the Single Item Recovery feature, the logical follow-up question is "Do I still need backups for Single Item Recovery?" As always the answer depends on both your current backup requirements and on capacity planning.
Before performing the calculation, you should ask yourself the following questions:
•What's my current deleted item recovery time in days?
•How often do I require recovering items from backup and from what time span?
•What's my current client load pattern ?
Let's consider that a customer currently maintains a deleted item recovery time of 7 days and maintains backups for 60 days where users require Single Item Recovery. Let's assume the following client load pattern:
•Average message size: 50kb
•Messages sent/received per day: 100
•Items edited: 10 percent
Now let's do the math and calculate the space requirement for the recoverable items folder of a mailbox:
•Assumption: 5 working days * 100 mails = 500 mails per week
•Space requirements for Purges folder:
◦8 weeks * 500 mails per week * 50kb per mail = 195 MB
•Space requirements for Versions folder:
◦10 percent of 195 MB = 19.5 MB
This indicates a mailbox size increase of 215 MB per mailbox, and you don't even need a Single Item Recovery tool or backup of your mailbox databases because Single Item Recovery will be performed within Exchange.
--------------------------------------------------------------------------------
Note: After implementing Single Item Recovery you should monitor the size of the Recoverable Items folder of your mailboxes from time to time. This can be achieved using the Get-MailboxStatistics –id <account> | fl *size* cmdlet.
--------------------------------------------------------------------------------
Another consideration if you implement Single Item Recovery together with high availability of databases is that you can also dramatically reduce the backup frequency.
Ultimately, if the storage subsystem is planned and designed appropriately and mailbox resiliency features of Exchange 2010 are used, traditional point-in-time backups are degraded to only a disaster recovery mechanism—if they are even needed at all.
Mailbox Retention
Every Exchange mailbox consists of a user account in Active Directory and the mailbox stored in the Exchange database. If the mailbox is deleted, or a mailbox-enabled user account is deleted, that mailbox is not yet deleted from the database but is marked for deletion. The mailbox will stay as a disconnected mailbox on the database until the deleted mailbox retention setting is reached, by default 30 days. Only then is the mailbox purged from the database and thus physically removed. The main benefit is that mailbox retention allows you to recover deleted mailboxes up to the retention setting without having to restore the entire mailbox database. To reconnect the mailbox you just select the disconnected mailbox and connect it to a user account in EMC, as shown in Figure 5.
Even with good processes, mailboxes can be deleted accidentally or prematurely. In some instances employees are hired back shortly after they leave; in other incidents mailboxes are deleted with information required by other employees or legal departments. The mailbox retention period should take into account these scenarios and can be set differently depending on the type of user or the circumstances around the employee's departure. Defining the retention should be discussed and approved by each department and any legal counsel so as to reduce the amount of mailboxes that need to be recovered from backup
Mailbox retention is configured on the database level. If you want to change the configuration, you can use the Set-MailboxDatabase <database name> -MailboxRetention 30.00:00:00 cmdlet or you can use the EMC to configure the deletion time in database properties
If you want to make sure that deleted mailboxes are not available as disconnected mailboxes, you can use the Remove-Mailbox –Permanent $true cmdlet.
4. Testing Your Disaster Recovery Plan
The best backup and recovery plan is useless if your administrators do not know exactly what to do during a disaster. Therefore, it is a best practice to test a disaster recovery thoroughly at least once a year with the people involved in normal day-to-day operations of your systems. This test ensures not only that your recovery plan is working as expected and that your team is well trained in how to recover from a disaster, but also that any system changes are immediately implemented into the plan.
To test your disaster recovery plan, consider testing the following areas:
•Rebuild the systems from scratch after a total datacenter loss.
•Provide alternative solutions such as dial tone recovery to bring back the service operation as quickly as possible after server failures.
•Make sure the installation sources are available and updated (for example, latest service packs must be available).
•Test recovery in accordance with your company's SLAs to make sure they are met.