White Paper:  File Copying is Not Backup

Backup for Workgroups was developed after we ourselves tried a few file copy products and discovered that they really didn't backup any data or perform a disaster recovery for a computer. Thankfully, we were only doing maintenance at the time - had there been a real disaster we would have been in trouble!

Read the story below learn how file copy programs can let you down - let our experience help you decide on a reliable, true backup and disaster recovery solution:  Backup for Workgroups.

1. Relying on People to Perform a File Copy Backup
2. Problems with Using File Copy to Backup Microsoft Exchange Server
3. File Copy Cannot Restore a Computer
4. In Conclusion

1.  Relying on People to Perform a File Copy Backup

When we first started up things here at Lockstep Systems, we setup an e-mail server and a file server. On this file server we installed a large hard drive and created a folder with each persons name, and everyone would just copy files to their folder on the file server. Quickly we ran into problems with this method. First, it was rare if anyone ever remembered to copy any files to the file server. Second, nobody was really sure what files were important so we never knew whether we were copying the right files to the file server. Third, if any files were in use, the file copy within Windows would stop copying the files. We quickly learned that expecting people to copy files produced little to no results.

Another product we created at Lockstep had a rescue kit capability. We extracted this feature from the product and created a utility that would copy our complete computers to our folders on the file server. This solved the problems of not knowing what is important by just copying everything to the server. And we wrote the utility such that if a file was in use, it would be skipped but the rest of the files would be copied. We now felt we had a backup solution for our users. All they needed to do is to run this file copy utility and their entire computer would be replicated to the file server. However, this solution created a horrible problem:  it gave us the false sense of security when in fact, having a file copy only backup solution was woefully flawed.

2.  Problems with Using File Copy to Backup Microsoft Exchange Server

We did not understand how ineffective file copying was until one day we decided to perform some internal maintenance. Before we began the maintenance we decided that we wanted to test the restoration of our Exchange Server to make sure that if we caused a problem we could recover from it. We found a spare, blank hard drive, removed the Exchange Server’s hard drive, and replaced it with the spare and set off to restore the computer from our file copy.

It was a miserable failure. We were persistent and tried various ways to make it work - trying everything we could find in the Microsoft Knowledge Base on backup and Exchange Servers. After wasting one solid week we finally understood exactly why it would never work.  First, our file copy could not copy any file in use. Even though we knew this and would periodically stop our Exchange Server and allow the file copy to occur, it was not enough.  Because Microsoft Exchange interlaces its data with the Windows Registry and the domain controller databases, the Registry and domain controller information could not be copied with a simple file copy.  All of our data that was neatly copied to our file server was useless without the Registry and domain controller databases.

3.  File Copy Cannot Restore a Computer

We embarked on further research into file copying and discovered that file copying had other inherent flaws. Copying files could not copy the registry, it could not copy files in use, and it copied too much data. Later on, this also caused us grief when trying to perform restores because the file copy combined all files at the target location.  We could not tell what data had been deleted in the past and what was currently relevant.  As a result, our 2 GB C:\ partition on the Exchange Server had grown to over 2.5 GB at the file server. We had over 500 MB of garbage at the file server that we would have to pick through by hand when we tried to restore the files.

We performed more research on our file copy strategy and found that not being able to copy and restore the registry was also bad a user restoration situation. Should a user have any sort of problem (hard drive failure, extreme virus damage, etc.), we would have to recreate their computer setups by hand and reinstall every application. Since many applications proliferate files throughout your computer and liter the Registry with entries, we found that a simple file copy could not restore most applications to a working state. Without the registry we had to reinstall everything by hand. And if we changed anything, the data files that could be copied back from our file server, may not be useful.   As a result we concluded that the file copy backup strategy simply has too many holes to rely on it to restore a computer. It may be able to restore a data file or two, but anything more would likely end up a failure.

4.  In Conclusion

We are thankful that we were only testing the restore process - had there really been a disaster and we lost a hard hard drive, the file copy route would not have restored the computer for us.

As a result of our experiment, we did some more research and found the key difference with backup applications is how they actively process the special requirements needed to reassemble a complete computer.  Backup applications such as Backup for Workgroups will backup the Registry, applications and files, allowing a computer to be completely restored precisely as it was as the time of the last backup. Backup for Workgroups can also track the files as they are used, letting you know what files have been deleted so you do not restore any unwanted files from the past.

We want you to know that Backup for Workgroups is a complete backup and disaster recovery solution, not just a file copy program like some backup products.