SUPPORTDatabase Backup with LiveVault
Database backup using LiveVault
We are often asked whether LiveVault online backup can backup some particular database or database application. Whilst we cannot test every application, we can tell you how to answer such questions because LiveVault uses a generic approach to database backup. However, the techniques used on Windows are different than on Linux or Solaris.
On Windows, the first question is whether the database uses the Microsoft file system or uses raw disk space. A few databases can be configured to do their own I/O directly to a disk partition, bypassing the file system. LiveVault cannot back up raw partitions (nor will other online backup products be able to do so).
The next question is whether the database behaves well after a power outage. Imagine that you pull the plug on the database server, restart Windows and restart the database. Will you be "OK", i.e. will the database recovery nicely from the system crash? Modern databases use transaction logs and other techniques so that they can re-establish database integrity after crashes by unwinding incomplete transactions.
Whatever the recovery experience is with a power outage is exactly what the recovery experience will be after restoring the database from a LiveVault backup. LiveVault begins each backup by taking a snapshot that captures the on-disk state of all the files at an instant in time. If a backup is later restored, the state of the restored files is exactly the state that would have existed had there been a power outage at the instant the snapshot was originally taken.
The LiveVault agent has been designed to be extremely light weight. By taking this generic approach to database backup that relies on snapshots, and with the aid of the LiveVault filter driver to track all the changes to the database, LiveVault is routinely used to backup even the most active databases on a 15min. backup schedule. This provides great advantages:
- After a disaster there can be a recovery point within 15 to 30 min. of the failure.
- After a human error or corruption there can be recovery points every 15 minutes going back 24 hours to allow recovery to a point in time prior to the problem
Users and administrators don't notice a performance hit when the database is running. In essence, LiveVault defers the problem of database transactional consistency from backup time to restore time because the number of times the database will be backed up is much, much greater than the number of times it will be restored.
SharePoint is a database that we are often asked about. This is an example of a modern database application. Therefore, there are no known concerns with LiveVault backing up a SharePoint environment contained on one server. You want to be sure that the database, the documents and document directory(ies) are all included in the backup policy, of course.
There is reason for concern if the SharePoint environment that spans several servers - say the documents are on one server and the database on another. In this case, there is no way for LiveVault to take a consistent snapshot that spans both servers. Therefore there is the risk of some inconsistency if either or both servers are later recovered. The inconsistency might take the form of the database having a pointer to a document that isn't there, or there being a document that is not pointed to from the database.
On Linux and Solaris, LiveVault provides the ability to specify a program or script to run before each backup, and a program or script to run after each backup completes. (Snapshots are not used on Linux or Solaris.) The purpose of the pre- and post- processing scripts is to allow the administrator to ensure that the database is in a state where it can be backed up. For example, some databases have an "online backup mode".
