SQL 2008: Best way to perform backups on Windows Server 2008?

There are many question to be asked before you implement a backup policy. I'm sure all the databases on a server are not of same importance. You should categorize the database based on Service Level Requirements, Size, Role (Production, Dev/Test etc) and Type (OLTP, Data Warehouse, Reporting etc.) then consider the implementation.

As a general rule of thumb, the target should be that critical databases must be backup so that there is no loss of data. That is could be a combination of Full, differential and transaction log backup.

Please see the link below to see how it could be implemented to minimize the loss.

http://www.sqlbackuprestore.com/mainbackuptypes.htm

Thank you, that link explains the differing backup types and their uses very well.  I the best way to schedule the backups using Task Scheduler? or is there a better way of managing the scheduling of the backups?

I use the SQL server agent to schedule jobs. You can create a step to email you an alert using "sp_send_dbmail " in case of a failure with some detail information related to failure or you can use the notification tab to add a group or individual operators to receive failure alerts.


You can also log the  SQL Agent Jobs to a log file and view history.

If you have a Window Server 2008 with a dozen of databases I assume it must serve an enterprise in a production installation. So I would put a second HD and configure a RAID 1 (mirror) array. If there is a problem on one HD, data are at disposition. This would be my first level of back-up and would garantize me to avoid service interruptions. The costs are really low.

About the choice between full and differential, I thanks niaz for the very explanatory link above.

I determine the frequency of back-ups depending on the following criteria (in order of importance):
1 - The importance of the data written to the server. Am I doing accounting or data warehouse, or am I logging web traffic? In the first case I need absolutely all the operations restored, in the second I can accept some loss of data.
2 - The number of operation pro day (or pro hour, minute, second): this will determine the time I need to recover the actual situation in case of data restore (eventually the time I need to manually re-insert the operations that are not in the last back-up). The more operations I have, the often I want to back-up.
3 - The work-load for the server: is the server working near his limits? Are the back-ups slowing down the machine and db-response times? But if my data are very important the solution is to empower the hardware and do more back-ups.

I hope you can understand my bad english.

If you want to go to next level of data protection after RAID implementation and are running mission critical databases and can't afford loss of data or down time for recovery, you should also look into Log Sipping, Mirroring, Replicaion and Clustering. These are some of the solution available within SQL Server for disaster recovery and high availability.

You decision to implement any strategy should be based on the three points listed above by "pieropingi" and the Service Level Requirement (SLR).

If you had to write a t-sql statement to backup every database, how would you do it?  Ideally I would like to write it so that if a new database is created, it will be backed up without having to alter the Job.

I will include the code I have so far:

DECLARE @BackupLocation varchar(255); 

SET @BackupLocation = 'X:\MyBackups\' + REPLACE(CONVERT(VARCHAR(19), GETDATE(), 120),':','.') + ' - Full Backup.bak';

BACKUP DATABASE [DatabaseName] TO DISK = @BackupLocation;

Select allOpen in new window

Pieropingi, thank you for the input, I have this covered.  The system drive is mirrored.  I also have a RAID 5E set up with 4 drives for data storage.  The backups are going to data raid, where they will be then uploaded to an offsite location.