Bread and Butter of SQL Server DBA - Part 2

Continuing on with his series on the basics of being a DBA, the MAK brings us an article that shows how to restore a backup to a new database.

Auto generate SQL Server restore script from backup files in a directory

One of the ongoing challenges of a DBA is to backup and restore databases. Backups are done on an automated schedule, but restores can take on many different versions, you may need to restore a production database, restore a development or test database or just create another copy of the database somewhere else. There are several ways of automating the restore process and creating a script, but this approach shows a way this can be done by just reading the contents of a directory for the backup files that exist.

Changing the default SQL Server backup folder

Is it possible to change the default directory for backups, so it does not need to be specified each time I run a backup?

Selecting the database recovery model to ensure proper backups

One of the first things that should be done when managing SQL Server is to setup an appropriate backup plan in order to minimize any data loss in the event of a failure. Along with setting up a backup plan there are certain database configurations that need to be setup to ensure you are able to backup databases correctly. In this tip we will look at the different recovery models that SQL Server offers and how to choose a recovery model for your database.

Tuning the Performance of Backup Compression in SQL Server 2008

ckup compression is a new feature in SQL Server 2008 that can help provide smaller sized backups and reduce backup time. This document provides guidance related to tuning options for backup performance. All of the information and test results presented here were done specifically by using the backup compression feature of SQL Server 2008; however, they apply broadly to any backup scenario whether backup compression is used or not

Automatic Restore

Restore a random backup file on a predefined directory to check backup validity.

Named Pipes

Backups

Tail Log Backups

Issues with running backup log with no_log or truncate_only

On my database server I have my databases set to the full recovery model, but the transaction logs get quite big, so I am issuing a BACKUP LOG with NO_LOG. I am not exactly sure if this causes any issues, but I know that I am able to free up space in my transaction log and shrink the file. Is this the correct way to handle this situation?