|
No, you cannot rely on system or NTFS backups as an appropriate disaster recovery strategy for SQL Server. If all your current solution is doing is backing up the database files (i.e. mdf, ldf, ndf) and if you needed to revert to those "backups", then you could potentially run into a horrific situation where SQL Server can't use those database files. You need to ensure that you're taking SQL Server backups (full, differential, transaction log [unless you're in simple recovery]). This will provide you with the correct way to recover from disaster in the event you need to do a restore. A few notes:
| |||||
|
|
Unless you are running all of your databases in simple recovery mode, you are eventually going to run out of transaction log space. Read some good write-ups about transaction log management. As transaction log management is fundamental a topic of managing an Sql Server, I'd recommend you to pick up a book about the subject too. For example, Microsoft Press training kit for 70-642 examn is decent an introduction. The conventional wisdom about backups is to use Ola Hallengren's scripts. Both system and user databases need to be backed up. Use Acronis or whatever to back up the DB backups to secure a location. | |||
|
|
|
Just tell me that you don't have databases on the system drive. :) Seriously, what they said. If your databases aren't in simple recovery, they must have transaction log backups or the log will grow until it eventually consumes the disk. (Which is why I said "not the system disk." One of my lesser colleagues once installed software, including SQL databases, on the system drive, and it ate Windows.) Also, there's no guarantee that those .mdf, .ndf, and .ldf files will attach off your backup, especially if there's any kind of time difference between when they were backed up. (They might, but it's not supported, and they might not.) So... what Thomas Stringer and vonPryz said. Back up through SQL. Run DBCC CHECKDB. (Reindex, even.) Back up the backup files with Acronis. | |||
|
|
