(what are these boxes?)
This topic continues the discussion started at Classification of Scenarios for Backup and Restore. You should understand backup and restore terms and concepts discussed in that topic before proceeding further.
↑ Back to top
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:
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.
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:
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.
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:
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.
Examples of applications that maintain redundant instances of data