Multiple methods for scheduling a SQL Server backup automatically

SQL Server backups are an essential part of every good disaster recovery strategy. That is the good. But setting up such backups to run effortlessly, is the goal. In this article, we’ll review the types of backups, recommended practices and three different methods for automatically setting up SQL Server backups on a schedule. Note: these solutions can also be used in combination with one another

Different types of SQL Server backups

See also: Understanding SQL Server Backup Types

Full. This is the most common backup type and it includes everything including objects, system tables data, and transactions that occur during the backup. With a full backup, you can restore your database to the state, when it was backed up. Full backups won’t truncate your transaction log but if your database is in full recovery you. should also consider transaction log backups

See also: A walk through the SQL Server 2016 full database backup

Differential.This type of backup offers a means to maintain a complete history of your database but without storing redundant data. A differential backup retains data since the last full backup. A differential backup is only useful if used in tandem with a full backup, but allows you to delete/remove previous differential backups as they are redundant

Transaction log.This backup type will backup all of the transactions that have occurred since the last log backup or truncation, then it will truncation the transaction log. This will capture all transaction information, both DML and DDL, that has occurred on the database. With a transaction log backup, you can restore a database to a particular point in time aka point-in-time recovery, like right before a data loss event

See also: Understanding SQL Server database recovery models

File-group and File: This type of backup is best for larger databases. This type of backup will store all related data in files or file groups (one or more). To use file backups to successfully restore a database, the transaction log also has to be backed up to cover all of the file groups from beginning to end.

See also: Database Filegroup(s) and Piecemeal restores in SQL Server

Copy-only.This backup type is usually used on an ad-hoc basis and as not to disturb and existing process of database backups, since the transaction log copy-backup will ignore the copy backup. Otherwise, this is the same as a full database backup. Copy backups can’t be used for differential backups and transaction log backups

Backup best practices Location

Separating the location where backups reside from the server where the database, itself, exists is critical, because otherwise, some failures that affect the database might also mitigate your ability to use the backups to recover from it, for example physical drive failure.

Without explicit guidance for the file location as to where to store the backups, SQL Server will use the default database location.

Please note that simply changing the default file location, will have no effect on previously saved backup files, it will only determine the location where new backups are stored.

Automating and scheduling backups

Getting a database successfully backed up, to the file location and with the configuration settings you want is just a first step. Once accomplished, you will want to be able to replicate this process over and over again, automatically and on a schedule. Scheduling automated backups is critical for ensuring database continuity while reducing the manual effort required to achieve this.

Regular database backups not only are a great insurance policy against accidental data loss and other disaster type scenarios, they also provide point-in-store capability (for transaction log backups) and reduced downtime, if you do have to restore (shorter backup windows > less data loss)

How often should I schedule backups? This depends on your business requirements and Recovery Point Objectives (RPO), for example, if your standard is no more than 15 minutes of data can be lost, then then backups need to be scheduled every 15 minutes

Note: If your database is in full recovery mode you can use ApexSQL Log to avoid full restores. ApexSQL Log can isolate and reverse rogue transactions, mitigating the damaged data without having to do a full restore. It can also replay previous transaction to restore data that was lost

You can also use ApexSQL Data Diff to compare the current database to the last database backup (without even restoring it), identifying different/damaged rows and surgically repairing them with a synchronization script, again, without having to restore the backup.

Restoring and testing backups

A backup is only good if it can be restored successfully and this must be verified, and continuously re-verified to ensure your backup and restore strategy can be executed successfully when needed. Backups must be restored in a test environment and fully verified to ensure they meet all business requirements and various permutations, contingencies and contexts of the company recovery strategy

When testing backups many variables existing including environment, data, recovery time frames and data loss windows, application downtime and maximum acceptable threshold for data loss

Verifying backups

SQL Server backup verification includes the following checks

The backup was created successfully It is currently intact, physically and that all the files not only exist but are also readable The backup can be restored, when it is needed All the transactions are consistent

Note that verifying a backup doesn’t ensure the integrity or completeness of all of the data but if the original backup was created with WITH CHECKSUMS, that allows WITH CHECKSUMS to be used to verify the data, at an aggregate level, to give a reasonable confidence level that no data was lost. Let’s look at a few backup cases below to provide some practical examples

with T-SQL:

When we include the CHECKSUM statutement we can later ensure the integrity of the data, when the backup is complete and written to file. To accomplish this, see the following example:

BACKUP DATABASE [CurrencyExchange] TODISK = N'G:\DatabaseBackups\CE.bak' WITH CHECKSUM;

SSMS provides the facility for backup verification using CHECKSUM when creating a backup task

Two options are available in SSMS to implement this functionality including Verify backup when finished and Perform checksum before writing to media . These options are meant to bullet-proof your database backup process and identify any failures

It is important to include this functionality in your automatically scheduled backups as well

We’ll demonstrate, in this article, how to automatically create and schedule a SQL Server backup using SQL Server Agent jobs, Maintenance plans and a 3 rd party tool for managing SQL Server backups, ApexSQL Backup

Creating a scheduled backup using SQL Server