Although backup administrators typically focus on current and future backups, they must also consider the impact...
of changing technology with regard to their ability to retrieve data from legacy applications. As applications evolve from one version to the next, it can become surprisingly difficult for backup administrators to retrieve older data that was created with a prior version of an application. As such, it is important to consider how application lifespans will impact your disaster recovery planning and application backup procedures.
Imagine, for example, that an organization has been running Exchange Server 2007 since its initial release many years ago. Because Exchange Server 2007 is outdated, the organization makes the decision to migrate to Exchange Server 2013. Prior to the migration process, the organization makes a full backup of all of the Exchange Server 2007 mailbox servers and then attempts to reduce the volume of data that must be migrated by adjusting mailbox retention policies to expire messages that are more than sixty days old. The organization might also remove some mailboxes that are no longer needed.
Now imagine that several months have passed since the Exchange Server 2013 migration, and all of a sudden there is a critically important need to retrieve some of the mailbox data that was expired just prior to the migration process. As a backup administrator, the first instinct is probably to restore the data from backup. However, doing so is not necessarily a simple matter.
Microsoft made major changes in the Exchange Server database structure in Exchange Server 2010, and then they made some additional changes in Exchange Server 2013. Because of the database-level changes and other architectural changes, Exchange Server 2007 and Exchange Server 2013 cannot exist together in a common Active Directory forest.
Unless your application backup software is specially designed to handle the differences between the database structures, you won't be able to retrieve Exchange Server 2007 messaging data and insert it directly into an Exchange Server 2013 mailbox database. Similarly, you won't be able to bring an Exchange Server 2007 server into your organization as a way of facilitating the recovery process. The migration process updates the Active Directory in a way that makes these processes impossible.
Recovering data from Exchange Server 2007 is still possible, but you will need an isolated environment to do so because Microsoft does not allow coexistence between the two versions of Exchange Server. While it might initially seem simple enough to create an isolated lab environment, there are additional considerations that come into play.
For starters, Exchange Server has a dependency upon the Active Directory. However, you may not be able to create a lab domain controller in an isolated lab environment from your current Active Directory backups because Exchange Server 2013 makes changes to the Active Directory schema.
Even if it were possible to use a current Active Directory backup to build a domain controller in an isolated environment, you would encounter the problem of object mismatch. Exchange Server mailboxes are attributes of Active Directory user objects. That being the case, you won't be able to cleanly restore a mailbox if the corresponding user account has been deleted. Of course, most backup software does offer a provision for retrieving such a mailbox and associating it with a different user account.
As you can see, there can be some major complications associated with retrieving data from a backup of an outdated version of Exchange Server. Although Exchange Server makes a good example, it is far from being an isolated situation. It is very common for application vendors to make changes to data file structures as an application evolves from one version to the next. As a backup administrator, you have to be aware of how version updates will impact your ability to recover legacy data that was created with a prior version of an application. So, be proactive and put plans in place that will make the recovery process a lot easier.
For example, imagine how much easier the recovery of legacy Exchange Server data would be if the backup administrator knew about the version compatibility issues ahead of time and made a domain controller backup at the same time that the final Exchange Server 2007 backup was made. If it ever became necessary to restore data from the Exchange Server 2007 backup, having a domain controller backup that was made at the same time as the Exchange backup would make creating a lab environment and retrieving the data far easier.
When an application is about to be retired, it might not be adequate to simply make a backup of the application server. The only way to guarantee that you will be able to recover data from the application in the future is to include the applications dependencies in the end-of-life backup for the application. In the case of Exchange Server this would mean making an Active Directory backup, but the requirements differ from one application to the next.
For instance, if an organization was about to retire an older version of SharePoint, the dependencies might be Active Directory and SQL Server. Remember, backing up the SQL database alone might not be enough because there is no guarantee that you will be able to restore the database to a modern SQL Server in the future. It is necessary to back up the entire SQL Server so that you have a copy of the operating system, the database application and the database itself.
Planning for a transition to a new version of an application involves much more than just figuring out how to protect the new software. It is critically important to plan for the future by determining what will be required in order to restore data from the retired application in the future should the need ever arise.
About the author:
Brien M. Posey, MCSE, has received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server. Brien has served as CIO for a nationwide chain of hospitals and has been responsible for the department of information management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.