Chapter 14: Back Up Database (Transaction Log) Task 171 When and How Often to Back Up Transaction Logs Generally speaking, you want to back up your transaction logs often enough so that you are at minimal risk of losing data (you can't always count on being able to do a tail-log backup), and that the transaction log is kept down to a reasonable size (because backing up the transaction log truncates the transaction log). The more frequently you take log backups, the smaller is your organization's exposure to the risk of potential data loss. On the downside, the more transaction log backups you take, the more administrative effort it requires, and the more server resources are used. While there is no perfect transaction log backup interval, taking transaction log backups on an hourly basis is a fairly good compromise. Of course, if you can't afford to lose an hour's worth of data, and/or your server is very busy and causes the transaction log to grow quickly, then you may want to perform transaction logs more often, perhaps every 15 minutes or so. If you can't decide what transaction log backup interval to choose, I would err on having too many over having too few. Of course, some organizations have policies that determine how much data they are willing to risk losing, and this will directly affect how often you perform transaction log backups. If your company doesn't have such a policy, then you might want to bring this issue to management, along with the pros and cons, and allow them to determine how much data they are willing to risk losing. Configuring the Backup Database (Transaction Log) Task Now that we have a little background on transaction logs, let's take a look at how to use the Define Back Up Database (Transaction Log) Task screen, shown in Figure 14.1. Chapter 14: Back Up Database (Transaction Log) Task 172 Figure 14.1: Configuring transaction log backups is almost identical to configuring full backups. Chapter 14: Back Up Database (Transaction Log) Task 173 At the top of the screen, the Backup type option is set to Transaction Log and is grayed out. As you can see, after that, this screen of the wizard is virtually identical to the screen for full and differential backups, so it will only be described briefly in this chapter. Please refer to Chapter 12 for full details. The first step, as always, is to select the databases on which you wish to perform transaction log backups. I highly recommend that you select the same databases in this screen as you did when you created the Back Up Database (Full) task. While it is possible to create two separate Maintenance Plans, one to do only full backups and one to do only transaction log backups, it would be a lot of extra work for no benefit. One difference that you'll notice on the Database Selection screen is that the System databases option is grayed out, and that under These databases you will only see those databases that are using the full or bulk-load recovery models, since you can't perform transaction log backups on databases that use the simple recovery model. Use separate Maintenance Plans for system and user databases Most SQL Server instances are likely to have some user databases that use the full recovery model, alongside system databases, and other user databases, which use the simple recovery model. While you can create a single Maintenance Plan to cover all these databases, I prefer to create two separate Maintenance Plans, one for the system databases and one for the user databases, with each plan tailored to the specific maintenance needs of each set of databases. Under Backup to you will want to choose disk, and under Create a backup file for every database you should specify the same settings as you did for your full backups. This way, your full backups and log backups will be stored in the same location. In addition, leave the backup file extension to TRN, which is the default extension used for transaction log backups, and select Verify backup integrity, just as you should with all backups. If you have the Enterprise Edition of SQL Server, set the backup compression settings to the same as you did for your full backups. Backing Up the Tail of the Log One setting that is available on this screen, but is grayed out on the full backup and differential backup screens, is Back up the tail of the log, and leave the database in the restoring state. Do not select this option, as it won't work as part of a Maintenance Plan. The reason you see it is because this screen shares code with other parts of SSMS, and it is only from within SSMS that you might use this option to make a tail-log backup when recovering from a damaged database. Chapter 14: Back Up Database (Transaction Log) Task 174 Creating the Job Schedule The last step is setting the schedule for this task. The schedule screen is the same one we have seen many times before, so we don't have to examine it again. Just set the schedule so that transaction log backups occur on the schedule that you determine is best for your SQL Server environment. As I recommended earlier, I schedule transaction log backups at least once an hour, if not more often. You also need to keep in mind that you must perform at least one full backup of a database before you can perform a transaction log backup. Therefore, be sure that your full database backup schedule is set to start before your transaction log backup schedule. If a scheduled transaction log backup is due to start while a full backup is occurring, then the transaction log backup job will wait until the full backup is done, and then it will run. Summary We have learned that the Back Up Database (Transaction Log) task is the second most important maintenance task that can be performed with the Maintenance Wizard, as it minimizes an organization's exposure to data loss, and truncates older data from a database's transaction log, which keeps your transaction log file to a reasonable size. We are now done discussing the three backup maintenance tasks, and next, we will learn how to run the Maintenance Cleanup task, which can be used to help us remove old backup files. 175 Chapter 15: Maintenance Cleanup Task This chapter completes our run through each of the tasks available through the Maintenance Plan Wizard and, perhaps fittingly, is where we clean up after ourselves. If you run regular Backup Database tasks (full, differential, and transaction log) as part of the Maintenance Plans you create using the Maintenance Plan Wizard, then you may find that a lot of backup files are being stored on the local server, and this can very quickly eat up a lot of disk space. In addition, if your Maintenance Plans write a report each time any maintenance task is executed, as I recommended in Chapter 3, then a text file will be created and stored each time. While these text files are generally small, many hundreds of them can be created each week and they can quickly take up a surprising amount of disk space. Unless you regularly clear out older backup and text files, you could run out of disk space, bringing SQL Server to a grinding halt. Perhaps you have an Execute SQL Server Agent Job task that will warn you before you get to that point but, in any event, you must create some sort of plan to remove older files from your disk subsystem on a regular basis. This plan can be implemented using the Maintenance Cleanup task and this chapter will describe how the task works, and how to configure and schedule it using the Wizard. Unfortunately, the Maintenance Plan Wizard implements the task in a somewhat compromised manner, allowing you to only remove one type of file (BAK, TRN or TXT) at a time, within a given Maintenance Plan. As such, we'll discuss ways around this limitation, including use of the Designer (see Chapter 16 onwards). An Overview of the Maintenance Cleanup Task An important part of every DBA's job is to determine a strategy for database backup storage. While you may be making backups to a local drive, this is not where you want them stored long term. If you store backups on the live server and the server suffers disk failure, then you could lose both the live databases and the backups. As such, it is important for the DBA to create a system whereby database backups are copied off the original SQL Server and stored in a safe location, preferably offsite. Ideally, you should be copying backups from your . bringing SQL Server to a grinding halt. Perhaps you have an Execute SQL Server Agent Job task that will warn you before you get to that point but, in any event, you must create some sort of plan to. transaction log file to a reasonable size. We are now done discussing the three backup maintenance tasks, and next, we will learn how to run the Maintenance Cleanup task, which can be used to help us. single Maintenance Plan to cover all these databases, I prefer to create two separate Maintenance Plans, one for the system databases and one for the user databases, with each plan tailored to