Backup and Restore: Special Considerations
|
|
|
In this article
Related titles
This topic continues the discussion started at [[articles:Backup and Restore: Classification of Scenarios|Classification of Scenarios for Backup and Restore]]. You should understand backup and restore terms and concepts discussed in that topic before proceeding further.
Transactional applications
Most of database engines are transactional applications. To perform a consistent backup and restore of such an application you need to treat all files that form every single database as a whole. Usually that includes database file(s) and transaction log file(s). And it means that:
- for not-inbox applications you need to use application-aware backup;
- for Windows Server Roles and inbox services System State Backup is usually required.
Restoring full volume(s) with those files could also work but this may be an overkill and could cause problems in case you need to restore only one database and there's another databases on the same volume(s).
To ensure you get latest copy of the data you need to request a flush of all transactions before you perform a backup. There are generally two choices to perform a flush.
- Shut down the database application. E.g. stop the service.
- Use [[Volume Shadow Service (VSS)]] infrastructure for backup. That requires that the following three components are VSS-aware:
- Operating System (OS),
- Database application,
- Backup application.
Without doing either (1) or (2) you can end up with internal database structure get incomplete. If you restore such a backup database recovery should be performed after restore. Depending on specific application recovery can be triggered either manually or automatically. During recovery the latest transactions (not committed properly) would be rolled back and you can lose a significant amount of data inside the database.
Note: “flush” and “commit” are somewhat interchangeable (or at least often related) terms that are used through a lot of documentation.
Examples of Transactional applications:
[[SQL Server]],
[[Exchange Server]] with [[Mailbox role (MBX)]] installed,
[[Windows Server]] roles and features that store internal data in [[Jet database]] such as
- [[Active Directory Domain Services (AD DS)]],
- [[Active Directory Lightweight Domain Services (AD LDS)]],
- [[Active Directory Certificate Services (AD CS)]],
- [[DHCP Server]],
- [[DFS Replication (DFS-R)]],
- [[Single Instance Storage (SIS)]].
Note: for Windows Server roles and features System State Backup is application-aware.
Distributed applications
Distributed application consists of different pieces (or Roles) of software that are usually located on separate servers but act together as a whole to provide a single service to its consumers. An example of Distributed application is Web Front End (WFE) that keeps its data in a database (DB). Usually some part of configuration is stored on the WFE itself (usually in Windows Registry and/or configuration files) and another part of configuration is stored in the database as well as application data.
- In case of disaster or recovery from misconfiguration you need to recover all parts of the distributed application in sync.
- In case of data only recovery it may be safe to recover database only. But usually WFE part should be aware that a restore took place.
So it is highly recommended that backup and restore of distributed applications is performed by application-aware backup application. Such backup application may provide additional benefits. E.g. granular item-level restore of objects inside a single database (e.g. mailbox or even individual email) instead of whole database restore only.
Examples of Distributed applications:
- [[SharePoint Server]].
Redundant data
There are some applications build with high availability in mind. Such applications usually have built-in data redundancy feature. They support several separate copies (or instances) of application data and keep these copies in sync with processes such as replication or mirroring.
In case of a disaster there may be just one (or several) instances of data that have fault. And you may have other instances up and running. In such cases there is usually no need to perform a restore from backup and you should chose of the following two options.
It may be quicker and/or easier to create a new instance of application (i.e. reinstall OS and application) and then let the application re-create the redundant copy from existing master sources.
If you still chose to recover a failed instance from a backup and there are more up-to-date instances available on the network then the recovered instance would need to re-sync all the changes it had already synced between when the backup was taken and when the instance failed.
- Failure to trigger that re-sync may break further replication from and to this instance. That would also result in outdated instance that can cause collisions if it tries to provide service to its consumers. Different applications may provide different mechanisms to protect from such inconsistent restore. (See [[USN Rollback]] for the case of [[Active Directory Domain Services (AD DS)]]).
The requirement to trigger re-sync properly means that:
- either your backup and restore application should be application-aware
- or you need to perform some very complex (and probably unsupported) manual operations.
In case of catastrophic failure when you lost all the instances of data you still need to perform disaster recovery for at least one instance. Then you should follow either of the scenarios described above in this section.
The trickiest thing with such applications is item-level recovery. Solutions for these scenarios vary significantly among certain applications. It will nearly definitely require that you restore a full copy of application data (similar to disaster recovery scenario). Then you should:
- either re-create or somewhat transfer necessary object(s) from restored instance into production instances
- or somehow mark restored copy as “Authoritative” one and force other instances to replicate changes from the restored one. Please keep in mind that the other instances still “remember” that the object(s) you're restoring were previously deleted. And these instances are ready to replicate these changes to the restored instance. And that is probably not what you want them do. So you (or your restore mechanism) should prevent replication to the restored instance. And this means that you are going to lose the changes that were made since the backup you restored was taken.
Both these scenarios mean that:
- either your backup and restore application should be application-aware
- For some applications an application-aware backup and restore software may provide additional features of item-level recovery without performing “Authoritative” restore.
- or you need to perform some very complex (and probably unsupported) manual operations.
For specific guidance please refer to official vendor documentation.
Examples of applications that maintain redundant instances of data
[[Windows Server]] roles and features such as
- [[Active Directory Domain Services (AD DS)]],
- [[Active Directory Lightweithg Domain Services (AD LDS)]],
- [[Domain Name Service (DNS)]].
Note: for Windows Server roles and features System State Backup is application-aware.
[[SQL Server]] using [[Database Mirroring]] feature used,
[[Exchange Server]] with [[Mailbox Role (MBX)]] installed and [[Cluster Continuous Replication (CCR)]] or [[Distributed Availability Group (DAG)]] features used.