An Introduction to SQL Server Backup

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