Clarification on proper practices for backing up SQL Server databases?

Question

Recently I found myself needing to back up a client database running on SQL Server 2008 R2.

Normally I would do this by selecting the "Backup" task in SQL Server Management Studio, which produces a single, portable archive of the database. However, a co-worker said that some customers standard backup practice is to simply create a copy of the .MDF and .LOG files instead. Another then spoke up recommending against such methods, stating that the only 'proper' procedure for this is using the Backup task to produce a file as described above, before backing that up instead. In the event of a problem, restoring this backup file and applying transaction logs allows you to restore service without losing data.

I agree with the recommendation of using the provided task in combination with transaction logs, but I wasn't entirely sure of myself so I kept my mouth shut. Let's be kind and assume that the .MDF/.LOG files were copied when SQL Server itself had been shut down cleanly and completely - is there actually a good reason to use the Backup task instead of copying the raw files, or are we mistaken?

I did some reading on MSDN and found that copying the files and restoring them can result in issues in some cases (see Limitations when using Xcopy deployment), but is that the only difference?

Answer 1

Using the backup task will reset the log files whilst simply copying them will not: this helps with database performance.

Always use the backup task: this can also be scheduled.