>When backing up native VFP data you have two main choices: file backup, or use a backup program that is based on VSC/VSS (Volume Shadow Copy/Volume Snapshot Service):
>
>- File backup is possible even if files are open but it requires a VFP-aware backup. It also requires that no-one is using any tables EXCLUSIVEly. It's also possible, but more difficult to back up open database containers (.DBC etc) but as far as I know that requires at least a file lock, which can prevent updates of the VFP data for some time (can be minutes in my testing)
>
>- VSC/VSS can back up any types of files, whether they're open or not. However, if your VFP database is in an inconsistent state at the moment a VSC backup is started, then it will be backed up in that state. The chance of that can be minimized by the design of your app, and choosing backup times when your app is either not busy or not being used at all. One example of backup software that uses VSS is Windows Server Backup; most 3rd party offerings that can do full machine backups also use VSS behind the scenes. https://en.wikipedia.org/wiki/Shadow_Copy
>In that case the client may specify that they want periodic or on-demand access to their data, in an "industry-standard" format. This opens a can of worms; for example, just providing a SQL Server or MongoDB backup isn't enough, an up-to-date schema will also be required. Another option is to specify that all tables are to be written out to .CSV files or similar. Some kind of "backup" like that can be used to migrate data into another application.
>

If dbf is used as backend due to biz/[cost,effort] reasons, backup problems should be integrated in that context. My rules of thumb:

If you cannot force everybody out of the tables for backup/maintainance, this is so strong a hint to move to C/S backend that I shouldn't provide backup, unless porting to C/S is already ordered and the service is only for the interim time (with the interim pain of forcing out everybody, to keep porting order in place). Reason: data and app seem to be very important to run without a break, client is too stingy to pay for best technological solution. Trouble waiting for a set of circumstances to implode your wallet ;-)

Safest and often fastest is a file copy based on directory structures. If you have a huge amount of data seldom/minimally changed, having a mirror DB updated to all timestamped values since last backup is possible - but again an argument for C/S.

>In my limited experience, hosts absolutely hate having to provide this. Some object to the hassle of creating and providing access to the custom "backups", some don't want to give up their DB schemas, others just bloody-mindedly want to lock you in and will not provide any assistance whatsoever if you want to move to some other app. That said, the more important the app is to your clients, the more likely they will be to require something like this, so it pays to think about it in advance and be able to offer something (at an added cost, if necessary) if a new client wants it.

This should be done from the backup to have identical versions of "safe" data and to keep "downtime" small.

>In this era of ransomware, any backup plan should include backups which are offline and preferably also off-site from the primary environment. One way to achieve that is through cloud backups. However, some care may be needed setting those up, to ensure compliance with regulations such as FOIPPA/PIPEDA, and to make sure that any "real-time backup" features they may have don't interfere with the operation of your app during business hours, or adversely affect uplink bandwidth while in operation.
>
The "offline/offsite" is very important - rule of thumb here is that CLIENT has to be responsible as soon as backup reaches him. Either via sending physical backup or electronic transfer with accompanying notice via mail to serve as proof of "duty fulfilled".

If you are hosting client data, you can keep a copy of the backup for faster action in times of trouble, but responsibility for the data should be contractually be in client sphere after receiving backup.

>If you use on-premise Windows Server Backup or similar, back up to external or removable media and rotate those regularly. Bear in mind the effect of the rotation schedule; if you swap once per week, and the currently attached medium gets compromised, then with a severe ransomware attack you will lose on average 3.5 days worth of work, and possibly as much as 7 days.

The beauty of file-saving data directories is that most of the time you can write out online-saved data dirs each work day to an external disc only attached for that purpose and duration, which should take only a few minutes of time span and less than 5 minutes of person working time to minimize that risk at the cost of 2H per month and few external discs which are comparatively cheap. Same goes for FTPing current data to client cloud space into differently named directories.