I’ve used this simple SQL Server backup script a number of times to backup sql server to a file or network drive. It’s ideal if you are running SQL Server Express for example which does not come equipped with maintenance plans.  This script can be used in conjunction with SQLCMD to backup SQL Server from the command line.

So let’s take a look at this.

What we want to achieve here is a way of executing the same backup database command for each database in SQL Server. The “bare bones” T-SQL used might look like this. In this example, I am using my local drive as the backup destination.

BACKUP DATABASE dbname TO DISK =
'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\BACKUP\dbname.bak';

I say bare bones because the above command will backup a database to disk for you but there are a wide selection of different options which can be used to customize the backup. For more on that visit this link

We can query SQL Server for a list of the databases installed on the instance. You can filter out the databases which you are not interested in backing up.

SELECT Name FROM sys.databases WHERE Name NOT IN ('Model','TempDb');

So I get back this list..

Name
------------------------------
AdventureWorks2012
master
msdb
ReportServer$SQL2012
ReportServer$SQL2012TempDB
Test

I now want to write a simple loop to run through each of these names and execute the BACKUP DATABASE command producing a file on disk. For this, you could use a CURSOR or a WHILE LOOP. I’ll show you both ways.

Which one you choose is a matter of preference. Note that by default if you backup to the same file on disk, each backup is appended to the backup file. If you want to overwrite your backup files, use WITH INIT. Refer to the link above for more information on the syntax.

Backup SQL Server databases using a cursor

DECLARE @dbName VARCHAR(50)
DECLARE @backupPath VARCHAR(256)
DECLARE @backupFileName VARCHAR(256)

SET @backupPath =
'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\Backup\'

DECLARE backup_cursor CURSOR FOR
SELECT Name FROM sys.databases WHERE Name NOT IN ('Model','TempDB');
OPEN backup_cursor
FETCH NEXT FROM backup_cursor INTO @dbname
WHILE @@FETCH_STATUS = 0
BEGIN
SET @backupFileName = @backupPath + @dbName
BACKUP DATABASE @dbName TO DISK = @backupFileName
FETCH NEXT FROM backup_cursor INTO @dbname
END
CLOSE backup_cursor
DEALLOCATE backup_cursor

Backup SQL Server databases using a while loop

DECLARE @dbName VARCHAR(50)
DECLARE @backupPath VARCHAR(256)
DECLARE @backupFileName VARCHAR(256)
DECLARE @id INT

SET @backupPath =
'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\Backup\'

SET @id = (SELECT MIN(database_id) FROM sys.databases WHERE Name NOT IN ('Model','TempDB'))
WHILE @id IS NOT NULL
BEGIN
SET @dbName = (SELECT Name FROM sys.databases WHERE database_id = @id)
SET @backupFileName = @backupPath + @dbName
BACKUP DATABASE @dbName TO DISK = @backupFileName
SET @id = (SELECT MIN(database_id) FROM sys.databases WHERE Name NOT IN ('Model','TempDB') AND database_id > @id)
END

(Apologies if this code looks a little messy. I am looking for a better code formatting plugin – any suggestions? 🙂 )

Once you have customized the script to your needs, wrap it inside of a stored procedure. Depending on what version of SQL Server you running, you can either schedule this using SQL Server Agent or via the windows task scheduler by calling SQLCMD.

Backing up SQL Server using SQLCMD at the command line

Start a command prompt and type SQLCMD /? to get the help options up.

Connect to your SQL Server instance using the options available and then run the backup to test that it works ok.

You can set up a windows batch file to call SQLCMD. I could add the following line to a batch file and I am now ready to schedule this using windows task scheduler.

SQLCMD -E -S MACHINE\INSTANCE -Q "exec master.dbo.usp_backupDatabases"

Next Steps

It’s important that you get the right plan in place for your server. What I have provided is just a basic script, call it a template if you will. You can customize it to include differential backups, transaction log backups, different file locations, multiple backup sets, multiple files etc.

Have a read of the BACKUP DATABASE documentation to get a idea for what is possible. Communicate with the business to agree requirements, write a backup plan and test whatever code you write thoroughly to ensure that it is meeting the backup plan requirements.

Finally

Backing up using scripts is very handy for editions of SQL Server which do not come equipped with maintenance plans and SQL Server Agent. If you are running one of those editions that does have those features, then you might decide to choose those tools instead. Using backup scripts however still remain highly viable and are preferable to some DBA’s.

Before I get into this post on SQL Server backup, I must make something really clear without sounding like I am stating the obvious. 😐

Having a fully tested backup and restore plan in place for your SQL Server databases is one of, if not, THE most important job that you have to ensure you get right as a DBA.

Getting it wrong could mean huge financial costs to your company, potentially leaving your companies reputation in tatters and leaving you out of a job.

The important thing to bear in mind is that your database backups are only good if you can restore them correctly. If you do not have a tested disaster recovery plan in place, don’t put it off any longer, get one setup and test it regularly.

SQL Server Backup types

There are a number of different ways to backup your database and I will expand on these in later posts. For now here is a summary:

• Full – a complete database backup which truncates the transaction log of inactive records
• Differential – a backup of all of the changed data pages since the last full backup. Usually smaller than a full backup, assuming that not all pages have changed
• Log– transaction log backup containing all transactions since the last transaction or full backup. Also truncates the log of all inactive log records
• File – a way to backup individual database files
• Filegroup – a way to backup a group of files contained inside of a filegroup
• Copy-Only – a backup which can be taken without disrupting the log chain. Great for taking a copy of a production database for development purposes
• Mirror – allows you to backup to more than once device simultaneously
• Partial – similar to filegroup but will backup the primary, all read/write filegroups and optionally, read only filegroups

SQL Server Backup – which recovery model should you choose?

This is an important decision to make when setting up your databases. The recovery model determines whether you can perform point in time recovery or not. It also affects transaction log size.

There are 3 types of recovery model:

• Full
• Simple
• Bulk-Logged

Full recovery model

If your database is enabled with a full recovery model, it means that the transaction log will only be truncated upon completion of a FULL backup or upon completion of a transaction log backup.

This recovery model is necessary for log shipping, database mirroring and transaction log backups to provide point in time recovery.

Point in time recovery is vital if you cannot tolerate much data loss. How often you backup your transaction log will determine how much data you can recover in the event that you have a disaster.

Backing up the transaction log is far superior than setting up differential backups every 30 minutes as a differential will backup all the changed data pages taken since the last full backup. This could take some time to complete and consume lots of disk space.

In comparison, a transaction log backup will simply backup the transactions written to the log since the last log backup – a much quicker and less disk space hungry operation 🙂

It is advised that if you implement the FULL recovery model, that you do also put in place a policy to backup your transaction logs regularly. Failing to do this on a busy system could mean that your transaction log disks run out of disk space very quickly!

Simple recovery model

With simple recovery, the transaction log is truncated on each checkpoint.

What this means is that if a transaction is committed to disk, the space used by that transaction inside of the transaction log, is emptied leaving space within the transaction log file.

If you are not concerned about point in time recovery or any of the other processes associated with the full recovery model, then this is a handy option to enable and requires less management of the transaction logs because the log is always truncating.

Bulk logged recovery model

Finally we have the bulk logged recovery model. For this option, it is still possible to backup the transaction log but it does not permit point in time recovery. The advantage with this recovery model is that it uses minimal logging in the transaction log.

This is not only faster because less is being written to the log but it also means that the transaction log will not grow as large compared with the full recovery model.

If the business requirements allow you to switch from full logging to minimal logging, you might choose to enable this during maintenance windows when index rebuilds are happening. This will help to reduce the transaction log growth and upon completion, switching back to the full recovery model for example.

You can make this switch because the log chain is intact. The bulk logged recovery model will preserve the log chain and not require you do take another full backup. However as the transactions recorded during the time when the database was in bulk recovery are only minimally recorded, you cannot restore your database to a point in time when the bulk recovery model was enabled.

Only a restore point before or after the recovery model was enabled will be possible for point in time recovery.

As the transactions could suffer data loss under this recovery model, it is advisable to only make this switch during periods when the users are not updating the database or when you are able to recover the transactions which were otherwise lost by some other means. So for example, you might have an SSIS package importing a bunch of files which could easily be re-imported.

Scheduling and retention of your SQL Server backup

It’s possible to implement scheduling of your backups using the SQL Server Agent. What you choose to implement will depend on the data retention requirements for your business. A very simple example of a schedule might look like this:

1. Take a weekly FULL backup
2. Take daily DIFFERENTIALS
3. Take regular transaction log backups, for example every 30 minutes.

This schedule might repeat each week to a point when the backups are a certain age, they would no longer be kept in storage and re-used. This will depend on your business requirements.

In SQL Server, backup schedules can be put in place which are customized to your needs and available backup capacity. The available options provide great flexibility as everything can be done at the database level.

You may have databases which are critical to the business which need frequent backups and you may also have databases which do not change, for example read-only databases. You may only back these up very rarely in this instance but retain those backups for long periods of time.

Backup storage – what to use

I can think of some options:

1. Backup to local disk
2. Backup to network share or SAN
3. Backup to tape
4. Combination of disk/network/SAN plus tape – you may keep aged backups on tape and recent backups on disk for example.
5. Backup to cloud – there are companies now which provide this service.
6. Backup to FTP location

Ensure that whatever option or options to decide upon that there is redundancy there to help protect your backups.

A word on backing up to local disk

Where I work, we have a 3rd party solution which takes care of our backups. It authenticates to the SQL Servers and takes regular backups to a large SAN. Those backups are then copied to tape and the tapes are taken offsite.

The key to this is that the backups are stored external to the SQL Servers and not locally. The issue with local backups is that if your server dies for any reason, you can potentially lose your backups and you are in trouble.

You can backup locally and it could perform better than backing up over a network for example but you’ve got to make sure that you have copies of those backups made somewhere else to safeguard your data.

A word on backing up to tape

Similar to local disk backups, these backups are only as good as the tapes and device you put them on. So ensure you have copies made of your backups. I personally would not put a backup solution in place which consisted purely of tape backups.

A word on database snapshots

It’s possible to take a snapshot of a database in SQL Server. This is a great way of taking a cut of the database which you might choose to do some reporting on for example. It’s also possible to revert a database back to a snapshot however do not rely on snapshots for your database backups.

Snapshots exist on the same database server as the source database. If you lose your drives, you lose your source database and database snapshots! You may as well then go clear our your desk and hand in your security pass. 😐

SQL Server backup software

Now it would be foolish of Microsoft not to supply you with the tools to do this and thankfully, it has long been possible to completely manage your backup and restores using SQL Server Management Studio and the SQL Agent for scheduling.

The tools which are available to you do a pretty good job but as your backup requirements grow, you may decide it is time to invest in some backup software to help manage your SQL Server backups.

I’m going to be looking at some backup software for SQL Server in a future post.

Summary

I hope this provides you with some information on where to start with your SQL Server backup plan. In future posts, I will be going into more of the how to aspects of running backups and restores inside of SQL Server. For more information you can visit this link