Managing Backup Exec Rights and Permissions in an Exchange Environment
It is very important to ensure that the different user accounts that Backup Exec uses to protect Microsoft Exchange are granted the necessary privileges in order for Backup Exec to function properly. This section offers important guidance for each of the key accounts leveraged by Backup Exec to perform Exchange backup and recovery operations.
Agent for Windows
For the protection of physical Exchange servers, Backup Exec requires the Agent for Windows to be installed to the Exchange server.
For Exchange 2010/2013 Database Availability Group (DAG) configurations, the Agent for Windows should be installed on each mailbox server participating in the DAG.
The Agent for Windows should be installed to the Exchange server and must be running under the ‘Local System’ account on both the Exchange server as well as the Backup Exec server. The file versions of the Agent for Windows on the Backup Exec server and on the Exchange server should match.
Backup Exec Logon Account
To enable key features related to the protection and recovery of Exchange servers, such as granular recovery of Exchange objects, Backup Exec must have access to a uniquely named mailbox within the Exchange infrastructure. This mailbox is accessed by the Backup Exec logon account to enable Backup Exec to interact with Exchange and important components within the Exchange Information Store.
It’s important to ensure that the mailbox is uniquely named and activated. To activate the mailbox, create a new profile within Microsoft Outlook for that user and logon to the mailbox using Outlook.
For information on how to confirm that an Exchange mailbox name is unique within the Exchange organization, refer to the following technote: http://www.symantec.com/docs/TECH24691.
Ensure that the logon account meets the following requirements:
- For Exchange 2003, the Backup Exec Logon Account should have Exchange Full Administrator rights.
- For Exchange 2007, the Backup Exec Logon Account should be a member of the ‘Organization Administrator’ group.
- For Exchange 2010 and 2013, the Backup Exec Logon Account needs to have the ‘Organization Administrator’ role and be configured with ‘Exchange Organization Management’ rights.
- The Backup Exec Logon Account must be member of the local computer’s Administration group on the Exchange servers.
Example Backup Exec Configurations for Protecting Exchange
This section contains a few example diagrams of Microsoft Exchange 2010/2013 environments protected by Backup Exec. Important components of both the Exchange infrastructure as well as the Backup Exec data protection solution are depicted.
The first diagram below depicts a distributed Exchange 2010/2013 environment with two mailbox servers configured in a DAG. In this example, all servers are being protected by Backup Exec, and as such the Agent for Windows is present on each server, including the Active Directory Domain Controller.
In this configuration, presuming the Agent for Applications and Databases has been licensed on the Backup Exec server, all levels of recovery would be available for the Exchange servers in this example, including granular recovery of Exchange 2010 mailbox objects.
Note: Granular recovery of Exchange 2013 mailbox objects is not supported in Backup Exec 2012 SP2. Support for granular recovery of Exchange 2013 mailbox objects is planned for a future release of Backup Exec.
Backup Exec Protecting Physical Exchange 2010 DAG Environment
The second diagram below depicts two very basic virtual environments where Exchange is present. In the first example, a single Exchange virtual machine is being hosted on a Hyper-V server, and Backup Exec captures image-level backups of the Exchange virtual machine by interacting with the Hyper-V host through the local Agent for Windows installed to the Hyper-V host. In the second example, a single Exchange virtual machine is being hosted on a VMware server, and Backup Exec captures image-level backups of the Exchange virtual machine by interacting with the VMware host through the vStorage APIs for Data Protection (VDAP).
Since the Agent for Windows has not been installed on the Exchange virtual machine in either diagram, recovery will be limited to full virtual machine recovery and file/folder recovery; Exchange application recovery or granular Exchange mailbox object recovery would not be available.
Exchange Recovery Methods and Technology
Backup Exec remains a pioneer in application recovery technology, and Microsoft Exchange is no exception. From a single-pass backup of an Exchange server, whether that Exchange server is on physical hardware or has been virtualized, Backup Exec offers a wide variety of powerful and flexible recovery options.
Virtualized Exchange Server Recovery Options
Exchange servers that have been virtualized on the VMware vSphere or Microsoft Hyper-V platforms and protected by Backup Exec can be restored using any of the following methods:
- Full virtual machine recovery
- Exchange application recovery, such as recovery of the Exchange Information Store
- Granular Exchange recovery, such as mailboxes, mailbox folders, emails, and attachments
- Redirected recovery of Exchange data
These flexible and powerful recovery options offer partners and customers the tools they need to quickly and easily recover their Exchange environment, whether they need to quickly recover the entire Exchange virtual machine, restore only a single email, or anything in between.
Full Virtual Machine Recovery
When protecting virtualized Exchange servers using Backup Exec and the Agent for VMware and Hyper-V, the entire virtual machine can be recovered to the original virtual host, or to an alternate virtual host. This recovery operation restores the virtual machine in its entirety, and can be immediately powered on after the restore process is complete.
Full Exchange Virtual Machine Recovery
In order to restore an Exchange virtual machine to an alternate virtual host, the alternate virtual host must be licensed for the Agent for VMware and Hyper-V.
Exchange Application Recovery
Full recovery of an Exchange application instance in virtualized environments is also supported by Backup Exec. This includes the recovery of all selected Exchange application components back to the original Exchange virtual machine.
The recovery of an Exchange application instance is performed by creating a restore job in the Backup Exec interface for the selected Exchange server. Backup Exec intelligently identifies Exchange servers and streamlines the recovery experience by showing the administrator those recovery options and data choices that are specific to the server selected for recovery.
It’s important to note that application-level recovery is only supported for Exchange virtual machines when the Agent for Windows has been installed on the Exchange virtual machine. This allows Backup Exec to detect the Exchange application within the virtual machine at the time of backup and collect the necessary metadata in order to support application recovery operations. The Agent for Windows is also required to be installed to the virtual machine in order to restore data directly back to the virtual machine.
Granular Exchange Recovery
Backup Exec remains an industry leader in the granular recovery of Microsoft Exchange. Administrators can easily recover individual mailbox databases, mailbox folders, emails, email attachments, and many other granular Exchange application objects and recover them back to the original Exchange server, or save them as .PST files.
Granular recovery of Exchange application data is supported for both physical Exchange servers as well as virtualized Exchange servers. Granular recovery of Exchange is supported from a single-pass backup of the virtualized Exchange server; additional backups of the Exchange infrastructure are not necessary.
It’s important to note that granular recovery of Exchange objects is only supported for Exchange virtual machines when the Agent for Windows has been installed on the Exchange virtual machine. This allows Backup Exec to detect the Exchange application within the virtual machine at the time of backup and collect the necessary metadata in order to support granular object recovery operations. The Agent for Windows is also required to be installed to the virtual machine in order to restore data directly back to the virtual machine.
Also, the Client Access Server role needs to be installed on the Exchange virtual machine in order for granular object recovery tasks to be successful.
Note: Granular recovery of Exchange 2013 mailbox objects is not supported in Backup Exec 2012 SP2. Support for granular recovery of Exchange 2013 mailbox objects is planned for a future release of Backup Exec.
For more information about the granular Exchange recovery capabilities in Backup Exec, please refer to the Backup Exec Administrator’s Guide.
Exchange Transaction Log Truncation
In part 7 I should have expanded a little … Transaction logs are a key element of any Exchange infrastructure. Exchange transaction logs are used to track database write operations (such as a user creating an email object) both before and after they are committed to the associated Exchange database. The transaction log process within Microsoft Exchange helps maintain the integrity of Exchange databases over time.
To prevent transaction logs from eventually saturating available disk storage resources, periodic truncation of Exchange transaction logs is needed. Truncation of transaction logs refers to the process by which Exchange transaction logs that can be safely removed are identified and deleted. Backup Exec, through the Microsoft VSS service integration, initiates transaction log truncation as a part of backup operations. This is true for backups of physical Exchange servers as well as virtualized Exchange servers on VMware or Hyper-V platforms.
Backup Exec and Exchange High Availability Configurations
Backup Exec fully supports protecting Exchange infrastructures that have been implemented in highly available configurations. Exchange high availability options and technologies have evolved over time, and the high availability options available are dependent upon the version of Microsoft Exchange being used in the environment.
Exchange 2007 High Availability Configurations
Backup Exec supports Exchange 2007 environments that are implemented in high availability configurations. This includes the following:
- Single Copy Cluster (SCC)
- Clustered Continuous Replication (CCR)
- Local Continuous Replication (LCR)
- Standby Continuous Replication (SCR)
The following is a basic diagram of a Standby Continuous Replication (SCR) environment:
Exchange 2010 and 2013 Database Availability Groups
Backup Exec supports Exchange 2010/2013 environments that are implemented in a Database Availability Group (DAG) configuration. To back up the databases within a DAG, you must install the Agent for Windows on all the servers in the DAG.
To use the Granular Recovery Technology (GRT) option to restore individual items, you must install the Agent for Windows on all Client Access Servers in the site. For Exchange 2010, Exchange recovery operations are performed via Exchange Web Services. Recovery operations are directed to a Client Access Server, and users can select the Client Access Server to use in configurations where multiple Client Access Servers are available, such as for load balancing purposes.
Note: Backup Exec 2012 SP2 does not support granular recovery of Exchange 2013 mailbox objects. This functionality is planned for a later release of Backup Exec.
Best Practices for Exchange High Availability Configurations
It is recommended that Backup Exec be used to protect standby or secondary mailbox servers and Information Stores whenever possible in Exchange environments that are configured for high availability. This allows Backup Exec to successfully protect Exchange data without burdening the active or primary Exchange servers with backup processes and associated overhead.
High Availability Server Options
It’s important to plan a Backup Exec implementation that aligns properly with the topological view of the destination Exchange environment. For example, in environments where Exchange has been configured to replicate or failover across WAN connections, ensure that Backup Exec servers are located at the same site as the Exchange servers they are protecting, and use the Preferred Server Configuration features of Backup Exec to ensure the correct Exchange servers are selected for backup operations. This will prevent Backup Exec from pulling large amounts of data over WAN connections that may have limited available bandwidth.
Utilizing disk storage as the initial or primary location for storage of Exchange backups can help increase overall backup performance and reduce backup windows. For environments where placing Exchange backups on tape media is a requirement, adopting a process of storing backups to disk before copying them to tape (D2D2T) is recommended for optimal performance.
Additional Exchange best practices are offered in “Exchange Protection Notes and Best Practices” (p. 32). For information on Preferred Server Configurations, refer to the Backup Exec Administrator’s Guide.
First Exchange Archive Task Performance
The first time an Exchange archive task is run, it will find a large number of mail messages that are valid candidates for archiving. This can result in an Exchange archive task taking a substantial amount of time to finish the first time it is run. Subsequent runs of the Exchange archive task will only pick up messages that became eligible since the last run, and will not take as long.
It is advisable to plan around the first run of Exchange archive tasks by scheduling it to run over the weekend or over a longer block of available time. Another approach would be to add mailboxes to archive tasks in phases rather than all at once.
Archive Task Scheduling Recommendations
Schedule your archive tasks to run after full backups. Because archive tasks source data from backup images, by scheduling archive tasks to run after full backups they run faster since they process the latest full backup rather than a chain of incremental backups going back to the latest full.
Schedule your archive tasks so that they run outside the backup window. Because archive tasks source data from backup images, archive tasks impact the backup server and not production systems. Scheduling archive tasks to run outside the backup window allow them to make full use of backup server processing cycles and prevent scheduling conflicts between backup tasks and archive tasks.
General Best Practices
Emails Must Be Backed Up Before They Can Be Archived
Due to the unique implementation of archiving capabilities within Backup Exec 2012 SP2, only data that is being protected by Backup Exec 2012 SP2 through backup jobs can be archived. If no backup job exists to protect the Exchange server in question, the email data associated with that Exchange server cannot be archived.
In Backup Exec 2012 SP2, archiving tasks are implemented as an additional stage to a backup job. Archiving tasks will only employ archiving rules against source data from the backup job of which they are a part. When adding an archive stage to a backup job, it is advisable to configure the backup job to be the most compatible with archiving, such as storing backups to disk rather than directly to tape.
The Exchange Mailbox Archiving Option does not support archiving data from backup sets stored only to tape.
The Exchange Mailbox Archiving Option does not currently support clustering. It will install to a Backup Exec 2012 SP2 server that is a cluster node, but it will not be allowed to join the Backup Exec 2012 SP2 cluster.
For the Backup Exec 2012 SP2 Exchange Mailbox Archiving Option, the Backup Exec 2012 SP2 server must be in a domain. For configurations involving multiple domains, the domain of the Backup Exec 2012 SP2 services account must be trusted by the Backup Exec 2012 SP2 server domain as well as the domain of the Exchange servers targeted for archiving.
In addition, the BE services account must be granted permissions on each Exchange server targeted for archiving tasks. The Administrator’s Guide lists additional details in regards to the permissions that need to be provided to the Backup Exec 2012 SP2 Service Account on Exchanges mailboxes in order to enable archiving. Please refer to the Administrator’s Guide for additional details.
Email Archiving Rules
When configuring an email archiving task as a part of a backup job, Backup Exec 2012 SP2 administrators can choose from several options to ensure that archiving processes match the needs of their environment. Rules include the following additional options:
- Email age
- Email size
- Whether or not to only archive emails with attachments
- Whether or not to apply archiving rules to unread emails
Exchange Email Archiving Rules
Archive Data Copied from Backup Sets, Not Original Server
When performing archiving tasks that move old or large emails from primary storage to secondary or tertiary storage, Backup Exec 2012 SP2 does not transfer data directly from the production Exchange servers to the archive. Instead, Backup Exec 2012 SP2 scans associated backup sets managed by the Backup Exec 2012 SP2 server for emails to be archived and copies the data from the backup set to the associated mailbox archive. This moves archiving I/O to the Backup Exec 2012 SP2 server, greatly reducing the performance impact of archiving processes on production servers.
It kind of goes without saying that due to this unique archiving implementation, only Exchange servers and associated mailboxes that are backed up by Backup Exec 2012 SP2 can be archived using the Exchange Mailbox Archiving Option. If no backup jobs exist to protect a certain Exchange server, it cannot be a candidate for archiving, but you’d be amazed how many people forget that and treat the archiving bit of Backup Exec as a standalone – it is integrated after all!
Integrated Data Deduplication
Backup Exec 2012 SP2 supports two types of data deduplication. One is block level deduplication and applies to backup data captured and stored to a deduplication disk storage device. The other is Single Instance Storage (SIS) deduplication and applies to the integrated archiving technology available in the Backup Exec 2012 SP2 archiving options.
The archiving technology within Backup Exec 2012 SP2 is based on Enterprise Vault 9.0. One of the benefits of this technology is the form of deduplication known as Single Instance Storage (SIS). By default, SIS deduplication is enabled for the Backup Exec 2012 SP2 Archiving Option.
SIS deduplication technology ensures that only one copy of an email object or attachment is kept within a vault store. If an archive task processes an email or attachment that matches the fingerprint of an object already in the vault store, the archive task does not store that object again.
The SIS deduplication technology within the archiving features of Backup Exec 2012 SP2 applies across all partitions and archives within and across vault stores.
Single Instance Storage Diagram
It’s important to note that SIS deduplication technology applies only to the archiving capabilities of Backup Exec 2012 SP2 and only adds storage optimization to the vault store. Additional storage benefits can be gained by installing the Backup Exec 2012 SP2 Deduplication Option, which adds block-level deduplication (and associated storage optimization) for the deduplication disk storage device to which backup sets are stored.
Very loosely, we were instructed to delete everything pre dot com bubble bursting (2000), keep everything post and now we are fast running out of data centre disk allocation space, err?
In fact it’s wonder we manage to do anything given the amount of information we need to process. As a consequence we are now facing a greater threat – too much information. There are somewhere between 60 to 160 Billion mails sent around the world every single day. These emails include attachments such as reports, presentations, letters and pictures. In spite of the limitations such as privacy and too much unwanted mail, email is the best way to communicate efficiently, quickly and cheaply. The danger with email, as with any other way of sharing information, is that too much information simply clogs the system up and become a bottleneck to productivity.
Here are some useful top tips that may help:
- Understand the new business user – organisations must better understand the challenges employees are facing when navigating the world of information management. Look at when and how employees are accessing their information, make sure that data is indexed and categorised, and that intelligent archiving and search tools are available
- Prepare the infrastructure – with the relentless flow of information only set to continue, IT infrastructure must be able to cost effectively manage the increasing requirements for storage by implementing solutions able to dedupe and archive appropriately, automate processes and monitor and report on system status across all different devices and environments
- Prepare people – create IT policies that educate employees on how to manage their information – from email practices like limiting the ‘CC’ and ‘reply to all culture’, to saving only the latest document version and overcoming the fear of the delete button. Help employees understand the company’s information retention strategy so they know what information is recoverable. This will empower them to take charge of information control and maintain productivity and efficiency
- Keep security front of mind – it seems like an obvious statement, but reinforcing company security policies around mobile devices could protect against significant and damaging data loss. Make sure employees know the company processes and take advantage of technologies that enable the IT department to see where the most important information is, at all times
- Encourage staff to switch off – with the information era in full swing and with more and more opportunity for employees to stay connected at all times, it’s important that organisations support staff welfare and encourage them to switch off every once in a while
Seriously consider optimising your storage to reduce overall front end storage usage. Improving capacity can be done through integrated archiving and deduplication as well as tiering your storage. Archiving moves old data to a separate store so you don’t have to backup the same data day-in, day-out – forever. Deduplication only backs up data (at a block level) once, using a pointer to the unique data. So you can both reduce the amount you backup as well as dramatically reducing your backup window with archiving and data deduplication.
But, I hear you say, if I implement deduplication technology what are the benefits? Well, Backup Exec can help with that too. Read all about the Backup Exec Deduplication Assessment Tool in Part III.
- Unite Virtual and Physical: Powered by Symantec V-Ray technology, Backup Exec 2012 enables visibility across both virtual and physical environments for fast and efficient backup and recovery while eliminating the need for specialised point products.
- Eliminate Backup Complexity with a New Administration Console: A newly redesigned administration console will provide users with fast, concise management and monitoring capabilities.
- Integrated Disaster Recovery: With bare-metal disaster recovery and Backup Exec’s “no hardware DR” built in, organizations will be able to easily recover a failed system to a physical server, or to a Hyper-V or VMware guest.
- Capacity Licensing: New capacity licensing model for Managed Service Providers (MSPs), mid-sized and lower enterprise organizations will provide easier purchasing and maintenance by capacity as an alternative to existing a la carte pricing.
- Small Business Edition: In less than 10 minutes and with just three simple steps, Backup Exec 2012 Small Business Edition will install and configure backups so small businesses with limited IT experience can protect their data with ease. The new Backup Exec Small Business Edition will bundle Symantec’s data and system recovery technology into one affordable solution with a single license that’s designed specifically for a growing business.