Responsibility for backups is ultimately whatever the contract says it is. If it's currently not specified in your contract, that needs to change.

That said, primary responsibility for backup is usually with the environment where the data live, since that ultimately controls access to the data (security) and has the simplest and most direct physical access, for good performance and reliability of the backups.

If you're hosting your app in your own cloud or environment, then usually it will be your responsibility to back it up. However, if it's your clients' environment - on-premise, cloud or some hybrid - it will usually be their responsibility.

In cases where it's their responsibility, you should at least specify minimum backups they should perform since even experienced sysadmins can't be expected to know all the details of how your app works and what needs to be backed up. This can be as simple as a set of files in a single folder, or as complex as a physical server computer which has required 3rd-party software licensed to its particular hardware with a copy protection scheme.

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

If you have an RDBMS backend such as SQL Server, you should use or leverage its built-in backup. For SQL Server, its SQL Agent can be configured to perform regular backups. Some enterprise 3rd-party backup programs have agents which are "aware" of various RDBMSs so those can be used as a one-stop backup solution.

If your hosting is virtualized, that adds complexity but can also let you use VM backup software. These typically run on the physical host and can do "smart" (i.e. block level / delta) backups of VMs running on the host machine. I understand Veeam is the 800 lb gorilla in this space. I've used Altaro on one Hyper-V host, that worked well and was not expensive.

*
If you are a small host, some clients will want some sort of business protection for the data you're hosting. For example, you might go out of business; the contract or SLA may specify penalties, but that doesn't help the client if they're down because your app isn't available. Or the client may want changes to the app, which either you can't provide, or only at a prohibitive (for them) cost ("lock-in"). These boil down to the same thing; the client will need or want to migrate to a different application.

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.

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.

*
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.

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.

*
"There are exactly 2 types of people: those who are true believers in backup, and those who are about to become true believers in backup" -- unknown

>Not your problem!
>
>I'm surprised by your answers, yours and Tamar, stating that it is not your problem.
>
>In my case I don't see how we could say to our clients that it's not our problem. The apps are remote desktop so our clients don't have direct access to the data because of the remote thing. So we have to provide backups.
>
>
>>>Anyone have a similar approach? Even is your approach is different, how do you do your backups? Web service that you pay monthly? Zip the data and store it somewhere with FTP?
>>
>>Have the backup clearly stated as the responsibility of the user in the contract. Not my problem thereafter.