If I understand your requirements correctly, I think I've done this sort of thing before. Like Evan said, you can use backup software that doesn't do file locking (like Stac's Replica backup software or other more industrial-strength software). Of course, that only helps you when the backup software runs thru that particular database and even then it'll make a backup of the corrupt databases and you have the same problems with your backups as you do with your 'live' data.

If you are wanting a more 'hands-on' approach then you can do what we do with EXTREMELY critical data (in the 911/Fire/Police dispatch fields). Everytime a record is written or changed, we write it again to a duplicate database in another location on another computer. That duplicate is then duplicated to a remote location. Everything is time-stamped and verified at each duplication stage. The entire hour (or day or week, etc.) can be replayed in detail from these backups. You can either do these duplicates from the client machine each time a record is created/changed (time consuming and complicated) or you can make a program located on the 'server' that looks for inserted/changed records and directst the duplication process itself (my personal choice). As you can see, this gives you, the programmer, complete control over how things get backed-up. It also gives you an automatic fail-over mechanism in case something goes wrong by reconstructing the corrupt databases if need be.

- A Hilton


>Hi,
>
>We ARE using mirrored disks .... but these backups are for a different purpose. They are triggered by the load of data from messages arriving randomly onto the (NT) server (averaging every 10 minutes). At the same time users are browing/upating data. We need to guarantee 100% that in case of any kind of failure (eg db corruption, software error, hardware error) we can recover to a consistent point prior to a message load and replay messages and user updates from that point. We also retain two previous backup points.
>
>The problem is actually very rare and we assume it is when an update or record lock by a user happens at the same time as the filecopy. But note that we cannot simulate the problem.
>
>We have just changed the "filecopy" to "copyto". We will see if this avoids the problem.
>
>What is the best method to handle this kind of requirement baring in mind that we must guarantee recovery.
>
>Best Wishes
>
>Richard Schneller