Exchange Server 2010 backup and recovery tips and tricks

Transcription

1 Exchange Server backup and recovery tips and tricks

2 Exchange Server backup and recovery Exchange Server A big part of your job as an Exchange Server administrator involves preparing for and recovering from disaster. Luckily Exchange Server has some features that enable seamless backup and recovery. In this expert e- guide from SearchExchange.com, find out about these new features so that you will be prepared in case disaster strikes. And discover important Exchange backup considerations, including DAG size and offsite storage. By: Serdar Yegulalp, Contributor A large part of an Exchange Server administrator's job involves preparing for and recovering from disaster -- setting up a backup strategy or configuring Exchange servers for failover. Microsoft added some seamless new highavailability and site resilience features (backup and disaster recovery) to Exchange Server that do not involve any additional configuration or extraordinary work to establish. High availability (HA) 2007 was a function of continuous cluster replication, which isn't perfect, but still a huge improvement over Windows Server 2003 active/passive failover. In that case, you could leverage Exchange 2007's log shipping and replay functions in conjunction with clustering, but you were still stuck with only one database per storage group. Exchange Server gives you multiple databases through the use of database availability groups, or DAGs, which automatically stay in sync with each other. These groups of up to 16 Exchange mailbox servers automatically replicate Exchange databases and create less of a dependency for a given mailbox to reside on a specific database or server. You can add or remove servers from the DAG at any time with minimal effort. Therefore, DAGs make it possible to combine an HA solution with disaster recovery (DR) because it has elements of both in one package. Page 2 of 8

3 Exchange Server backup and recovery Exchange Server DAGs are also useful because they allow more flexibility in how a particular cluster or server setup can be rolled out. You can start with a single Exchange server on Windows Server 2008 R2 Enterprise Edition, and then add more machines at a later time to increase system uptime and availability or for data protection. Mailbox servers can also act as multiuse machines, allowing them to assume other Exchange roles such as unified messaging. Therefore, you don't need to dedicate them exclusively as a failover for other machines. A DAG can span more than one Active Directory (AD) site. For example, if you have multiple Exchange servers in different data centers, you could include them all in a DAG. Redundancy among the different data centers would add that much more resilience to your setup: If one data center fails, the other continues to run as expected. If you do this, typically you'll need to turn on Datacenter Activation Coordination Mode, which allows a DAG that has been divided across two data centers to survive an outage at one site and still allow both data centers to recover gracefully without each site assuming that it's the only surviving site. Microsoft calls this behavior splitbrain syndrome. Mailbox continuity via dial tone portability Many of the disaster recovery/continuity features of Exchange Server will be familiar to trained Exchange admins, but there are a few end-user continuity features -- like dial tone portability -- that will stand out. Dial tone portability creates a temporary mailbox for a user whose original mailbox lived on a failed database or server. All message traffic is redirected seamlessly to the new mailbox. Users running Microsoft Outlook 2007 or later don't need to reconfigure anything on their end -- they're automatically connected to the new mailbox. A dial tone recovery can be performed on the server where the database failed. This is recommended so that the database doesn't have to be copied to another server, or on another server, which can in turn become the new Page 3 of 8

4 Exchange Server backup and recovery Exchange Server permanent home for that user's mailbox if needed. The new way in which databases are managed make this feature possible. Exchange Server 's database availability groups were also designed so that updates can be applied to machines in the DAG without interrupting services. You still have to apply updates manually on each machine in the DAG in succession, but automatic failover between these machines means you can simply apply the updates, let the DAG handle the failover gracefully each time and continue on without having to take additional steps. Windows Server integration and DAG configuration Exchange Server integrates very well with Windows Server's conventional backup functions. A DAG's failover and continuity functions aren't meant to be substitutes for conventional backup -- just as RAID isn't a substitute for a proper server backup plan. This is why Microsoft created a Windows Server Backup plug-in for Exchange that uses the Volume Shadow Copy Service (VSS). The Windows Server Backup plugin isn't perfect. Its list of limitations includes an incompatibility with Windows Server Backups' command-line interface (which still doesn't work with Exchange ). In addition, backups only work at the volume level (i.e., no backups of only the database or the logs). But despite these limitations, the plug-in is still useful. DAGs can be configured in a few different ways. The easiest way and the one most familiar to Exchange admins, is a simple two-member (two-server) DAG. On the higher end, there is a four member DAG -- two local machines and two other machines placed in a remote data center. The local machines are for availability (if one server goes down, the other keeps chugging); the remote servers are for site resilience (if your onsite data center fails, the other one can pick up where the first left off). All of the work that needs to be done via DAGs can be done from the Exchange Management Console or from a PowerShell prompt -- the former for ease of use, the latter for fine-grained control and scripting. Page 4 of 8

5 Exchange Server backup and recovery Exchange Server Obstacle-free replication These changes mean that many long-time Exchange admins have had to adjust the ways in which they perform certain tasks. The most relevant changes encompass the fact that clustered mailbox servers and storage groups no longer exist. This probably sounds extreme at first, but in practice it means there are fewer obstacles to maintaining replication and consistency. You don't have to manually administer Exchange as a clustered application -- for the most part, that is handled under the hood. Microsoft also made a lot of under-the-hood changes in how replication works. For example, it has streamlined the process of populating passive copies of a database from the database cache. That way, if a failover occurs, the backup database is available more quickly than in the past. Exchange admins who have sweated blood in the past getting backup and disaster recovery features to work ought to be intrigued, to say the least, about what Exchange Server has to offer in this vein. If you're curious about putting it to work in your organization, start by checking out the prerequisites for an Exchange installation and give it a try. Microsoft offers various trial environments, from a 120-day evaluation copy to a preloaded virtual hard disk you can use in your virtual machine of choice. Exchange Server By: Brien M. Posey When Exchange Server RTM hit, some IT pros suggested that database availability groups in Exchange make traditional backups unnecessary. I initially scoffed at the idea. However, Exchange has been available for a while and the idea of a backup-less Exchange server makes sense in some environments. Page 5 of 8

6 Exchange Server backup and recovery Exchange Server The concept behind backup-less Exchange A backup is nothing more than a point-in-time copy of your data. It is this deceptively simple definition that led to the idea of running Exchange without backups. Some say running Exchange without backups is safe because of the way database availability groups (DAGs) work. A single DAG can contain up to 16 mailbox servers and an individual mailbox database can be replicated to any combination of mailbox servers within the DAG. The argument against backing up Exchange boils down to how many copies of data you really need. If you already have 16 replicas of a mailbox database, do you really need a seventeenth copy as backup? Important Exchange backup considerations While the argument against backing up Exchange in environments with DAGs sounds logical, there are a number of important factors to consider before ditching your backup system. DAG size While you can include up to 16 mailbox servers in a DAG, you can also create very small groups. Therefore, you must consider the size of your DAG before abandoning backups. Microsoft recommends that you only consider going without a backup if you have three or more mailbox servers in your DAG. Transaction logs Typically, when you back up an Exchange mailbox server, the contents of transaction logs are committed to the database as part of the backup process. If you never perform a backup, the transaction logs accumulate until the volume runs out of disk space. Because of this, organizations that do not back up Exchange must enable circular logging to prevent log file accumulation. Offsite storage It s easy to think of a backup-less Exchange organization in the same Page 6 of 8

7 Exchange Server backup and recovery way as a disk-based backup solution because database contents are replicated to other servers. Exchange Server However, organizations that depend on disk-based backups usually adopt a disk-to-disk-to-tape solution where the disk-based backups are periodically copied to tape and stored offsite. If the data center burns down, the backups remain safe. If you re considering operating Exchange without backups, it s smart to place a few DAG members in a remote data center. That way, your data remains protected even if something happens to your primary data center. Point-in-time recovery The biggest disadvantage to running Exchange without backups is that you lose the option of accurate point-in-time recoveries. For example, imagine that your entire company became infected with a virus. In this situation, you could restore a backup that was made prior to the infection, rather than trying to remove every infected message from your mailbox database. This is simple with a traditional backup, but isn t practical if you go without. Notice that I didn t say that it s impossible to perform a point-in-time recovery without a backup. Microsoft does let you create lagged database copies that log files are not immediately replayed on. That way, if you need to revert to a particular point in time, you can activate a lagged copy. The problem is that there s a lot of guess work involved in the process. You must know exactly when the problem began in order to get rid of all of the transaction logs that were created after the problem occurred. This is accomplished by replaying the transaction logs that were created prior to the problem. Unfortunately, there isn t an easy way to figure out which transaction logs should be used and which should be deleted. As you can see, it s perfectly feasible to run Exchange without traditional backups in certain situations. That said, I advise backing up Exchange as you always have. If an unforeseen set of circumstances leads to data loss, you won t have to explain to your boss or management that you don t have backups. Page 7 of 8

8 Exchange Server backup and recovery Exchange Server Free resources for technology professionals TechTarget publishes targeted technology media that address your need for information and resources for researching products, developing strategy and making cost-effective purchase decisions. Our network of technology-specific Web sites gives you access to industry experts, independent content and analysis and the Web s largest library of vendor-provided white papers, webcasts, podcasts, videos, virtual trade shows, research reports and more drawing on the rich R&D resources of technology providers to address market trends, challenges and solutions. Our live events and virtual seminars give you access to vendor neutral, expert commentary and advice on the issues and challenges you face daily. Our social community IT Knowledge Exchange allows you to share real world information in real time with peers and experts. What makes TechTarget unique? TechTarget is squarely focused on the enterprise IT space. Our team of editors and network of industry experts provide the richest, most relevant content to IT professionals and management. We leverage the immediacy of the Web, the networking and face-to-face opportunities of events and virtual events, and the ability to interact with peers all to create compelling and actionable information for enterprise IT professionals across all industries and markets. Related TechTarget Websites Page 8 of 8