Is the programmer of a database program responsible for database backups?

Imagine you sell an application that stores its data in a Microsoft Sql Server database. Some customers are large companies with existing Sql installations and staff to maintain them. Other customers are small companies who get the SQLEXPRESS version installed by a setup program.

The database will soon contain a lot of important data and will need backing up. Whose responsibility is this?

Should the application contain a UI for backing up the database and warn when the backup has not been run?

Or should the application just include instructions for backup in its documentation?

Or is this a problem for the customers to solve and not the programmers?

From stackoverflow

• In most cases I'd expect the customer to handle backups without involving the programmers. There is, of course, nothing wrong if the customer asks you as a programmer to build backup-reminders into the application.

  In some cases where the customer has little or no understanding of the technology they are using I also think it is our responsibility as system developers to inform them of what they are expected to do in terms of maintenance.

  Even with professional customers I fairly often specify minimum backup requirements in documentation, simply because you get what you ask for.

• My personal opinion is that instructions for back up of the data is really important. Most customers should be able to handle making back-ups themselves without needing a GUI, and a GUI will cost some time and money to develop.

  Providing instructions for back up will help make sure that they know what they need to do, and know that it is their responsibility. Good instructions will also (hopefully) reduce the amount of support they will require :) Most non-technical users I know these days at least know they need to back up their important documents to CD's, with some instructions they should be able to back up their database on their own.

  I think a GUI for backups is only essential in special occasions, where the users will not be technically proficient at all, data security is important, and the users wont have access to (or want to spend money on) IT staff.

• It's the customer's responsibility. However,...

  I believe you have three choices:

  1. Mention the database should be backed up.
  2. Give suggestions on how to backup the data.
  3. Offer your services to maintain the backup procedures.

  One or all three of these can be used. It all depends on what the buyer and seller are comfortable with.

• If you are building software that installs SQLExpress, then you should provide the backup functionality. By default, SQLExpress doesn't come with Management Studio, and I would consider it a major usability issue to install Management Studio as part of your app (or ask the customer to do so).

  The BACKUP DATABASE command is simple to execute from your application. There's really no reason not to provide this functionality.

  As for customers who have an IT staff, they can still handle the backups themselves using their existing process.

  Everybody wins.

  John Sansom : A very good point made for SQL Express installs. Simple backups to support your application are indeed simple to implement.

  BTB : But is the BACKUP DATABASE command so simple to execute? If you run it directly from the ui the app will freeze until the backup is complete - and it can take time if its a big db. Also you really need a browse folder dialog that shows the folders on the server - like the one in sqlms.

  Brannon : Is your app a Windows app or a Web app?

  Brannon : Ah, then you really have no excuse :) Execute the command in a worker thread (same as Management Studio). Providing a file/folder browse dialog is practically free.

  BTB : The file browser dialog is hard! You have to show the file system on the server not on the client - and only the folders that the user account running Sql Server can write to

  Brannon : I had assumed SQL Express would be running on the same machine as the UI. You're right, that is problematic, but you could provide a simple UI that you install on the server to handle backups.

  Brannon : It really depends on the type of user you're targetting. If they aren't developers or DBAs don't make them use Management Studio :)

  BTB : I'll add a simple UI on the server for backup - thank you!

• Backups

  From my experience a lot depends on how the database is installed and packaged with the application. If you sell an application to a customer with the database layer implementation details hidden or abstracted, then the typical customer expectation is that a backup solution is provided as part of the software. This expectation is there for a variety of reasons.

  Off the top of my head, one of which is that the IT department supporting the application cannot be confident in how the backup of the db should happen for the application. Sometimes, a DB dump with some vendors can cause locking issues that interrupt normal application operation. I'm sure you can imagine other complaints an IT department might have for an application that bundles a DB.

  As for installs that connect to a existing DB, I think it is a reasonable expectation that the DB admins for those databases handle backups. However, it is very important that you - the application provider document what needs to be backed up. Are there sequences and indexes that need to have their precise order persevered? Are there terabytes of data created that may not be important to your customer if lost? What about the state of the application during the backup (as mentioned above)? Does the application need to be shutdown?

  Restores

  More problematic is restores. What if a partial restore of data is needed? How could this corrupt your data store? Does your application store data anywhere else (files, network) that can be put in an unreliable/broken state as a result of a historical backup?

  Anyways, a long story short - when I'm a customer, I feel a lot better knowing that the application vendor has QAed the backup/restore process and provides support. Actually, the was a requirement of a large customer of my current project. They were more than capable of managing a database, rather they wanted us to take responsibility for our own data and guarantee that the process would be flawless.

  In the end, your mileage may vary depending on the implementation, requirements and industry expectations of your specific application.

• Having the application run a backup solves the problem of "How do I get my data back that I accidentally deleted?", but it does not solve the problem of a crashed hard drive. Your app isn't going to make sure the backup goes to tape and that the tape gets properly stored off-site. Be part of the best solution that forces them to take some responsibility for their data. Don't lead them into a false sense of security because they received a message box indicating the backup is complete.

• If you're providing SQL Server Express it is important to discuss the requirement of backing up with your customers (of course only if that is possible).

  A number of people on here have suggested that you let the users IT deal with the problem. This is of course completely valid however it does have the inherent problem that a worrying number of IT support staff have no idea about database admin and even less idea how to implement a nice back up strategy.

  Consider carefully the needs of your individual customers, and perhaps add automatic backups as a bolt-on, or for free if you're feeling generous. After all this is SQL Express, many customers will not expect to have to know anything about database backups.