Chapter 13: Back Up Database (Differential) Task 166 On the other hand, if we want to perform differential backups on only some of our databases, then we will have to create multiple Maintenance Plans, adding some complexity to our database maintenance. This is because, as we have already learned, the Wizard does not allow us to include multiple instances of the same task within the same Maintenance Plan. At a minimum, we will have to create one Maintenance Plan for those databases that don't require differential backups, and one Maintenance Plan for those databases that do. Alternatively, we can use the Maintenance Plan Designer, which does allow multiple instances of the same task, as described in Chapter 16 onwards. Other parts of the Define Back Up Database (Differential) Task screen are configured in exactly the same way as the Define Back Up Database (Full) Task screen, so I won't discuss them again here. Creating the Job Schedule If you choose to perform differential backups from within a Maintenance Plan created by the Wizard, you will have to carefully think through your backup schedule and how you want to do it. For example, you will have to create a task to perform a full backup once a week (see the previous chapter on how to do this), a separate task to perform daily differential backups, and another task to perform transaction log backups (more on this in the next chapter). What can become a little confusing is how to schedule these three tasks so they don't interfere with each other. For example, let's assume that we want to perform a full backup on Sunday, differential backups on Monday through Saturday, and that we want to take transaction logs once each hour. To do this, we would need to schedule these three tasks so that the full backup always occurs first on Sunday night; once a full backup is made, transaction log backups are made once an hour until Monday night, when the first differential backup is made. Once the Monday night differential backup is made, then we need to have transaction log backups made every hour until the Tuesday night differential backup, and so on, until we get back to the Sunday night full backup. Scheduling all of these tasks within the Maintenance Plan Wizard is dicult, and if your schedules overlap, or are in the wrong order, your Maintenance Plan will most likely fail. If you need to perform differential backups then I think you will find the scheduling process less of a headache if you use the Maintenance Plan Designer instead, which offers much more flexibility. Chapter 13: Back Up Database (Differential) Task 167 Summary The Maintenance Plan Wizard allows us to create differential backups, but using the Backup Database (Differential) task, via the Wizard, is not an easy proposition. My first choice is to avoid differential backups, and to keep my Maintenance Plans as simple as possible. On the other hand, if you need to create differential backups, then I recommend the use of the Maintenance Plan Designer, or the use of T-SQL or PowerShell scripts. 168 Chapter 14: Back Up Database (Transaction Log) Task Earlier, I stated that the Back Up Database (Full) task is the most important maintenance task for DBAs to implement. Now we have come to the second most important task, the backing up of transaction logs, which is implemented using the Back Up Database Transaction Log) task. In order to recover as much data as possible after the loss of a database, and to enable point-in-time recovery of your data, when using the full (or bulk-logged) recovery model, it is essential that you perform regular transaction log backups in addition to full backups (Chapter 12), and possibly differential backups (Chapter 13). The Back Up Database(Transaction Log) task allows you to schedule the backup of your transaction logs as part of the Maintenance Plan Wizard. This task is not relevant (or available) to any databases using the simple recovery model, as you cannot back up the transaction log of a database using this model. Backing up a database's transaction log offers very important benefits. First of all, it makes a backup copy of all the transactions that have been recorded in the transaction log file since the last log backup. These backups, along with any available tail-log backups, help ensure that, should you have to restore your database, you are able to recover all of the data up until the point in time that the failure occurred (or very close to it). Essentially, the log backup files can be applied to a restored copy of a full database backup, and any transactions that occurred after the full backup will be "rolled forward" to restore the data to a given point in time. The second important benefit of backing up your transaction log is that it truncates older data from a database's transaction log, which keeps your transaction log to a reasonable size. In fact, if you don't backup your transaction log, it can grow until you run out of disk space. Note, again, that only a transaction log backup, not a full or differential backup, will truncate a transaction log. Chapter 14: Back Up Database (Transaction Log) Task 169 An Overview of the Backup Database (Transaction Log) Task In order to perform transaction log backups, your databases must use either the full or the bulk-logged recovery models. If a database is set to the simple recovery model, then you cannot back up the transaction log, and it will automatically get truncated at regular intervals, when a database checkpoint occurs. Bear in mind that the master and msdb databases are set to the simple recovery model (which you should not change) and so you cannot back up their transaction logs. A database's transaction log (LDF) file contains a list of entries describing all the actions performed on the data in that database. A transaction log backup makes a copy of the recorded actions in this file (the backup copy), which should be stored separately from the drive on which the live log and data files are stored. Backing up the transaction log generally results in truncation of the live log file, at which point the previously backed-up entries would be removed. Transaction log backups are used in conjunction with full and differential backups to allow point-in-time recovery of data, in the event of disaster. In fact, it is not possible to perform a transaction log backup without first performing at least one full backup. In the event of a disaster, for example a database becoming corrupt, the most current full backup is restored followed by the subsequent chain of transaction log backups. This process "rolls forward" the actions recorded in the transaction log backup files. In other words, it applies them to the full backup in order to rebuild the data as it existed at a certain point in time. If the current transaction log is still accessible, which it may not be if, for example, the disk holding the transaction log has crashed, then the DBA can perform what is called a tail-log backup, in order to capture any actions recorded in the log that had not previously been backed up. The tail-log backup can be restored along with all of the other transaction log backups, minimizing the loss of any data. Managing backups for databases in the bulk-logged recovery model In almost all cases, you should use the full recovery model for your databases. The bulk- logged recovery model is typically only used during times when you are performing bulk operations. If you are managing backups for bulk-logged databases, then I advise you to use T-SQL or PowerShell scripts, rather than the Maintenance Plan Wizard, to perform your database maintenance. Chapter 14: Back Up Database (Transaction Log) Task 170 When the Backup Database (Transaction Log) task runs using its default settings, it executes the following T-SQL code (assuming AdventureWorks is being backed up). BACKUP LOG [AdventureWorks] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\ Backup\AdventureWorks_backup_2009_08_20_111623_3462370. trn' WITH NOFORMAT, NOINIT, NAME = N'AdventureWorks_back up_2009_08_20_111623_3462370', SKIP, REWIND, NOUNLOAD, STATS = 10 The BACKUP LOG T-SQL command is similar to the BACKUP DATABASE command, but produces a transaction log backup file with the extension .TRN, as opposed to .BAK. The name of the database is used as part of the backup file name, along with an appropriate date stamp. When a Backup Database (Transaction Log) task runs, it produces a text report similar to this one. Microsoft(R) Server Maintenance Utility (Unicode) Version 10.0.2531 Report was generated on "HAWAII." Maintenance Plan: User Databases Maintenance Plan Duration: 00:00:16 Status: Succeeded. Details: Back Up Database (Transaction Log) (HAWAII) Backup Database on Local server connection Databases: AdventureWorks Type: Transaction Log Append existing Task start: 2009-08-20T11:11:39. Task end: 2009-08-20T11:11:55. Success Command: BACKUP LOG [AdventureWorks] TO DISK = N''C:\ Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\ Backup\AdventureWorks_backup_2009_08_20_111139_2902370. trn'' WITH NOFORMAT, NOINIT, NAME = N''AdventureWorks_back up_2009_08_20_111139_2892370'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO While the above example only shows a single transaction log backup, all the transaction log backups you select will be shown in your text report. . the following T -SQL code (assuming AdventureWorks is being backed up). BACKUP LOG [AdventureWorks] TO DISK = N'C:Program FilesMicrosoft SQL Server MSSQL10.MSSQLSERVERMSSQL BackupAdventureWorks_backup_2009_08_20_111623_3462370. trn'. 2009-08-20T11:11:55. Success Command: BACKUP LOG [AdventureWorks] TO DISK = N''C: Program FilesMicrosoft SQL Server MSSQL10.MSSQLSERVERMSSQL BackupAdventureWorks_backup_2009_08_20_111139_2902370. trn''. is to avoid differential backups, and to keep my Maintenance Plans as simple as possible. On the other hand, if you need to create differential backups, then I recommend the use of the Maintenance