I'm considering writing a software application, that originally was going to be software for a desktop, but now I'm thinking making it a web application and monthly fee based service would be a good idea.

However, the part of making the application work as a web application is making me a little concerned, as I'm worried about database backups, etc. For applications that require the database to have frequent backups, what is the best way to make sure that client's data is not lost?

I'm looking to start small and then build up as clients subscribe, if that is the way that me and my business partner choose to go.

Any thoughts on keeping databases intact and backed up?

You need to establish how critical your backup requirements would be. Would you require long retention and atomic restore policy or can you live with an hour(s) worth of data lost when a restore is carried out?

Depending on many backup solutions you might consider, a one month retention, weekly full, daily incremental and hourly transact/binary log backup model should fit the "best way to make sure that client's data is not lost".

AppLogic (http://www.3tera.com/AppLogic) should do what you need, everything will be redundant and you can also run periodic snapshots of the entire environment. No code changes would be required.

As KualoJo mentioned, it will entirely depend on what your needs are and not all desktop applications will translate well into web based applications.

Converting it will mean you can reach 100% of modern computers out there though - all it requires is a compatible UI.

You say you're worried about backup if you were to convert but why wouldn't you have this worry if it was a desktop application? Do you mean __you__ would be liable for the backup?

If it's simply backup you're concerned about, you can add a slave and backup from the slave.

Have you thought about database replication and data distribution? It may help to give a little more insight towards your application.

Google app engine is very very nice in my experience.