The preferred method for backing up open files in a Windows environment is to use the Volume Shadow Copy Service (VSS) to take a snapshot of the volume that is being backed up, and then base the backup on the VSS snapshot. While this method works relatively well, there are some applications that are not compatible with VSS. Furthermore, Volume Shadow Copy Service isn't an option for backing up open files on servers that are running non-Windows operating systems.
That being the case, I wanted to talk about some other techniques that can be used when backing up open files. But before I get started, I want to point out these techniques are general in nature. Not every backup application supports all of these techniques. However, a good, enterprise-grade data backup product should support most -- if not all -- of these techniques.
Don't skip backing up open files
The default option for dealing with open files in many backup applications is to simply skip the open files. Obviously, the problem with this technique is that you end up with an incomplete backup. Often times, it ends up being the same files that are open night after night, and those files may never end up getting backed up if you just skip the open files. You would only want to do this if your backup software doesn't contain any options for backing up open files, or if you decide that the options that are available have risks that you deem to be unacceptable.
If closed within x seconds
Another technique for backing up open files involves telling your backup application to wait a specific number of seconds (or minutes) for the file to be closed. Otherwise, the open file is skipped. Unfortunately, this technique rarely accomplishes its goal, because the odds of a user closing the file within the specific time period that is allotted by the backup application are pretty slim.
Another problem with this technique is that it can cause your data backup to exceed the backup window. If there happen to be a lot of open files, and the backup application waits for each one of those files to close, then the backup may take a really long time to complete.
Backing up files with a lock
The basic idea behind backing up files with a lock is that just because a file is open, does not mean that it is locked for exclusive use. If an open file is not locked, then a backup application can lock the file, back it up, and then release the lock.
This is one of the better techniques for dealing with open files, but even this technique has a few downsides. First, not every open file is unlocked, so this technique may not allow you to backup all open files.
Another issue with this technique is that because the backup application locks the file, users (or automated applications) will not be able to write to the file until the lock is released. Depending on the nature of the file, this may result in helpdesk calls or application crashes.
Finally, the file could potentially be in an inconsistent state (for example, not fully committing changes to all tables for a database record) at the time that the backup application locks it. This may make the recovery process difficult should the file need to be restored.
Backing up files without a lock
Another viable option is to simply back up open files without trying to lock them first. Sometimes this technique works well, but the problem with it is that you never really know what you have backed up. If a user writes to the file while the file is being backed up, then the backup copy of the file will be corrupt. You may not even know that the backup contains corrupt data until you attempt to perform a restore.
The level of risk involved in using this technique varies depending on the type of file that is being backed up. For example, the odds of someone saving their changes to a word processing document at the exact moment that it is being backed up are pretty slim. On the other hand, if it is a database file that is being backed up, the odds of the file changing during the backup process are fairly high due to the amount of time that it takes to backup a large database, and due to the internal mechanics of database indexing.
Force users to log off
Forcing users to log off revolves around network policies. The basic idea behind this technique is that you can force users to log off the network so that there won't be any open files to deal with.
I used to work for an organization that used this technique. All employees were required to log off when they left for the day, but there was also a mechanism in place that would terminate any remaining connections at 11:00 p.m.
This technique probably helped to some extent. Simply requiring everyone to be logged out before they go home probably meant that there were fewer files open than there otherwise would have been, which ultimately meant that there was probably more data successfully backed up. Having said that though, I would not recommend this particular technique as a part of your backup solution. For one thing, this technique would never work in an organization that operates 24 hours a day.
Requiring users to log off of the network before they go home at night is a good idea for security purposes. However, severing any remaining connections in the middle of the night is a bad idea, even if your company does not operate on a 24-hour basis.
When deciding which of these solutions to use for backing up open files, each option has certain inherent risks, and you must decide whether or not the risks are worth the possibility of backing up data that may otherwise not be backed up. You must also take into account which of these options your backup software supports.
About the author:
Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Performing a bare-metal restore in Windows Vista
Using custom data backup scripts in a modern backup environment
Troubleshooting data backup error log messages
Ten ways storage and backup administrators can save time and money