>>WINZip protects me in this critical area. So I just paid for it and its done. What do you do for backups in 24x7 environments? Kick everyone off?
>
>I've never been involved with a 24x7 multi-user environment (23.9x7 yes).
>
>But I have this comment: Lets say you don't kick everyone off. You have a process that changes 10 tables. One user begins this process. Another user starts the backup. The backup copies 4 of the tables before the (other user's) process and 6 of the tables after the (other user's) process. Now, is that backup any good? Is it a good set of data?
>

You've hit one of the nails on the head - it gets worse when you consider memo fields and .CDX files. And if you don't shut down tables or force flushes, you may have inconsistant information in a table; in theory at least, the header of a file could be out of sync with other parts of a large file.

Now consider that your backup may not be done by one of the processes accessing the table programmatically; an example might be a system where the backup is done by a backup server, or a backup process on a file server, or even a different process running in parallel on one of the user stations.

In at least some mission-critical systems I've worked on, the database is locked (IOW all tables have FLOCKs acquired in VFP terms) and then mirrored out to another file system. The mirrored tables are then backed up; no users are accessing the mirrored tables, so that a consistent state is maintained, even though other users may continue to access the database for lookups while the data is mirrored in preparation for backup. In any case, there is some period of time where updates to the database are deferred or denied, in order to guarentee that the data backup is valid.

>I have never had to worry about this because we make backups when users are not using the data, but I am wondering how you backup data when users are in the midst of making multi-table changes.
>
>Joe