Planning for disaster should mean more answers than there are questions. And is a critical part of determining the type of backup you need.  If your backup application cannot meet these needs, then chances are disaster recovery will be painful if not, impossible.  It is where consistent application backups can be critical to business continuity when disaster strikes.

Application-Consistent Backups

Although not every situation uses consistent application backup as part of a disaster recovery strategy. There are many advantages to using this type of backup, especially for database applications. When a backup started, a complete snapshot was taken before backing up only the blocks of data. Which have changed from the last successful backup.

The full snapshot allows immediate restoration of files and applications. Or the complete system to any server regardless if it is in a physical or virtual environment. Application consistent backup adds an incremental block level backup. While removing the requirement to perform additional full backups following the initial one.

Application-consistent backup is vital to the use of database-backed applications. SQL Server and Microsoft Exchange are relatively dependent upon application-consistent backups. It is because these programs typically rely upon log files as opposed to writing directly to database files.

When the VSS writer is activated, SQL server and Microsoft Exchange delete the pending processes from memory. And transfer the log file contents to the primary database files. This process ensures that a system crash during operations does not compromise the primary database.  Instead, it implicates merely a risk to the active log files.

Crash Consistent Backups

In the case of a crash consistent backup, all the data is backed up. At the same time plus, the backup does not pick up the contents of the memory. Or any other forthcoming I/O (input/output) operations. When crash-consistent backup restores, the data will be in the same position it would have been if it had failed. At the precise moment that the backup occurred.

If a data system restores to a crash consistent state, then it will be a requirement to follow any processes. Which would need to track the system had crashed at that specific point.  Plus, when the system goes down you lose all of your data on the disk. And then you have to wait for the application to verify all of your data.

A crash-consistent backup requires a significant effort when it comes to backup software. It is why the Volume Shadow Copy Service (VSS)  includes in the operating system. The backup software works in conjunction with VSS. When the VSS is activated, the Input/Output pauses to allow a block-level snapshot to be taken. The backup software then accesses the backup from the snapshot when necessary.

Inconsistent Backups

An inconsistent backup is an older type of backup method.  The backup system starts the reserve and the files structure and the backs up the data. Until the end of the structure. In the event, a file modifies after the backup occurred. And before the backup process is complete, the result is an inconsistent backup.

Inconsistent backups can prove to be hazardous for database applications. Because databases comprise many interdependent files.  Additionally, inconsistent backups only take the data that is available on the disk during backup. Which means a pending operation in the memory of a database will lose.

Crash-consistent backup has in common with inconsistent backup is that the memory contents and any pending Input/Output processes not captured. As it would in the event of a system crash at the time the backup occurred.

These are some of the main backup methods that data centers use to prepare for disaster recovery.  Additional methods may apply depending upon specific applications and infrastructure.

ServerPronto offers the best affordable and secure hosting service in all dedicated server packages.

Photo credit Flickr/U.S. Geological Survey