Agreed.

Even with SQL Server doing Log Backups, the native version can be so slow that it impacts production servers. We switch to Red Gate, which does it much, much faster. And no, I wouldn't attempt to back up a production dbf-based database, either. I've had to supply backup data to a customer whose backup software wrecked their production database because it ran when the data base being written.

>>>>>What application are folks using to backup VFP application data that is actively being used without having to wait for non-business hours.
>>>>>I have a client that wants backups made during the course of the day, ie, every hour. So not looking for an incremental backup per se that updates files whenever there is a change, but creates a backup "set" at specified times.
>>>>
>>>>Check out https://cleverfoxbackup.com/
>>>
>>>Is it really possible to obtain a consistent backup of a VFP database which is in use ?
>>
>>I would imagine it uses the same OS-level call to lock file state that is used by other backup routines. See method 3 in this: https://www.ultrabac.com/white-paper-open-file-backup
>
>Unfortunately that doesn't really answer the question.
>
>That's an interesting white paper but some of the terminology used makes it a little suspect IMO, unless the author is purposely dumbing it down for a lay audience. I believe what he's referring to as Locked File Backup ("LFB") is what the industry mainly refers to as Volume Snapshot Services (VSS) which has been built-in to Windows since XP/2003.
>
>If you need to back up exclusively opened/locked files, VSS is the only technology I know of capable of doing that. It works at the volume level (i.e. you can't apply VSS just to a given folder or set of folders). It's one "user" at a time; if you have 2 or more backup or other utilities making use of VSS you have to make sure they run at different times and otherwise don't step on each other.
>
>The white paper talks about waiting for a "quiescent" app state before "freezing" files. I take this to mean background monitoring of app activity, then firing up VSS at what is considered a suitable time. If a VFP app is still in use there's no firm guarantee that its tables are in a consistent state when the VSS snapshot is initiated, although a "smart" monitoring background service can probably get it right most of the time.
>
>Some time ago I wrote an automated backup utility for a client. It can't back up exclusively opened files but it does FLOCK() tables one at a time (where possible) and backs them up (both DBC-based and free tables). Each table is internally consistent but there's no guarantee of true database consistency in the RDBMS sense.
>
>In my experience, asking for frequent backups in a VFP app means relatively high-value transactions happening in a less than 100% reliable environment where data have been (expensively) lost in the past. Frequent backups address only symptoms, not the underlying problem(s).
>
>In a perfect world the OP would convert to a true RDBMS backend. A quicker fix might be to address problems in the environment that seem to make frequent backups "necessary". Another option might be to set up an RDBMS backend in parallel with the existing native VFP tables and write CRUD operations to both; that might be simpler than retooling the entire app to work from an RDBMS backend exclusively.