Sharepoint 2010 : How to Back Up a SQL Server 2008 Database (part 2)

Database Recovery Models

SQL Server offers three types of recovery models for each database it hosts: Full, Simple, and Bulk-Logged. The main differentiating factor between the three recovery models is how the transaction logs for a database are managed and backed up. By default, a database uses the same recovery model as the SQL Server system-level “model” database, which should be Full if the setting is not changed after installation. Of course, SharePoint is a bit of an exception to that rule. Because SharePoint’s installers and tools create its databases, those databases follow a different set of rules than databases created directly in SQL Server. Each section that follows notes which SharePoint databases are created with the related recovery model. If you want to change the recovery model of a SharePoint database once it is created, you can modify it in the SQL Server Management Studio via the database’s properties or via a T-SQL command.

Full Recovery Model

As its name implies, the Full recovery model protects data about every transaction made in the database by requiring that a backup of the database’s transaction log be made along with one of the database. By including a backup of every transaction for the database, the Full recovery model is the only model that allows for a database to be restored to a specific time in its history. You should use the Full recovery model if your data is mission critical and you need the ability to restore backups to a specific point in time. For the Full recovery model to be completely effective, you must make regular backups of both your database’s data and log files. By default, SharePoint’s Configuration database, the databases associated with the Central Administration site, and any content databases created through Central Administration, PowerShell, STSADM, or the SharePoint object model are set with the Full recovery model.

Simple Recovery Model

The Simple recovery model retains the least amount of information about the database being backed up. No transaction logs are backed up, meaning that the database can only be restored to the most recent full or differential database backup, not to a specific point in the database’s transactional history. The Simple recovery model is ideal when your data is not critical (such as a development environment), is not subject to frequent change (not a likelihood for a Share-Point database), or is not a requirement to recover all transactions since the last backup. By default, databases associated with SharePoint Service Applications, such as the Search databases, are set with the Simple recovery model.

Bulk-Logged Recovery Model

The Bulk-Logged recovery model represents a middle-ground option between the Full and Simple recovery models. Like the Full recovery model, the Bulk-Logged recovery model requires the database’s transaction log to also be backed up, allowing it to track transactions made in the database. The Bulk-Logged recovery model is designed to reduce the logging of bulk operations such as data imports and index management actions to a minimum, providing some of the performance benefits of the Simple recovery model. Microsoft recommends only using the Bulk-Logged recovery model in specific circumstances, switching to it prior to bulk operations and then returning to the Full or Simple models once the bulk operations are completed.

Database Backup Types

SQL Server 2008 offers several types of backups that can be made for the databases hosted in an instance: full, differential, partial, and transaction log. Each option is designed to provide a unique set of benefits to meet a variety of needs and use cases, but each comes with its own unique set of drawbacks as well. When considering which backup type to use for each of your SharePoint databases, consider these attributes in conjunction with the use of the specific database. Some databases may need to be restored quickly, for example, in which case it may make sense to use full backups on a frequent basis. On the other hand, differential backups typically require less storage space than full backups, but they often take longer to restore. This is just one example of a trade-off you must consider. The selection and application of backup types in your environment can have serious implications on the effectiveness and cost of your SharePoint implementation.

The list that follows defines each backup type within the context of SQL Server and discusses its common use cases.

• Full. A full database backup backs up the entire database, including its full data files and the transaction log components necessary to allow the whole database to be recovered. Because a full backup encompasses everything associated with a database, its output requires the most storage space. Additionally, a full backup of a database is required before any other type of backup can be made for that database.

• Differential. A differential backup of a SQL Server database only includes the data in the database that has changed since the last full backup was made of the database. Differential backups can be requested for a database or one of its files or file groups. The biggest advantage of a differential backup is that it doesn’t take up as much space as a full backup and can be completed more quickly. As noted in the previous bullet, you must first perform a full backup of a database before the differential option becomes available.

  Note

  To restore a differential backup, you must first restore its associated full backup set or include that full backup set in the requested restore operation.

  
  

• Partial. Partial backups are designed to provide a smaller and faster backup alternative for large databases with multiple file groups. Partial backups always include the database’s primary file group and any other file groups set as writeable. If a database is set to be read-only, a partial backup of that database includes only the primary file group. The partial backup option was originally designed for read-only databases using the Simple recovery model, but you can also use it with read-write databases and the Full and Bulk-Logged recovery models.

• File. You can back up a database’s data file (or files) individually. If a single file is corrupted or deleted, backing up the individual files can allow for a speedier recovery because only the affected file has to be restored. This can become complex if your database has a large number of files associated with it or overdo it if you have only one file for your database, so you should only use it in when your database environment has specific needs or requirements for file backups.

• Copy-only. Most types of SQL Server backups have an actual impact on the source database, affecting how the backup (as well as subsequent backups) are restored. One method that is an exception to this is the copy-only backup, which is specifically intended to not modify the target database in any way when the backup is made—hence the use of the term copy. Usually, making a backup changes the database and affects how later backups are restored. Normal backup types change a database’s log archive point, which creates a need to properly sequence backups so that you can properly apply transaction logs when restoring these backups. Copy-only backups remove the need for that sequencing, so if it or the ordering of the backup files for it is interrupted, you can still restore the database.

• Transaction log. A transaction log backup creates a backup copy of the log files detailing all the modifications that have been made to a database over time. Transaction log backups are available only with the Full and Bulk-Logged recovery models; because the Simple recovery model does not offer the ability to recover to a specific point in time, there is no need to track changes that have been made to a database. Transaction logs are also important to preserve because of the role they can play in other SQL Server high availability (HA) functionality, such as database mirroring and log shipping. Additionally, transaction log backups play a vital role if you are using the Full recovery model for your database; to do a full recovery with that model, you must have completed a full backup and at least one transaction log backup of your database. Performing frequent transaction log backups also keeps the database’s transaction logs from taking up too much space on the database because they are truncated as part of the backup process, allowing SQL Server to delete them and reclaim disk space.

Backup Expiration Settings

In the Backup Set section of the General page in the Back Up Database dialog box, you can configure specific expiration settings for your database backup. Depending on the radio button you select, your backup can expire after a specified number of days or on a specific date. The option button for the After option is selected by default in the Back Up Database dialog box, and the Days field value is set to 0. You can modify this default value by configuring the media retention setting within SQL Server’s configuration options. If you are backing up your database via a maintenance plan or regularly scheduled backup, specifying a value for this setting prevents SQL Server from overwriting your backup file until the number of days or date threshold has been met.

Backup Destinations

Unlike SharePoint, SQL Server can back up its databases directly to a tape storage location attached to the server in addition to a server’s hard disk. In the Destination section of the General page in the Back Up Database dialog box, you can enter up to 64 paths by clicking the Add button and navigating to the desired storage location. This allows you to simultaneously create multiple copies of your backup files without manual intervention. You can also remove a backup path from the list by selecting it and clicking the Remove button. Selecting a path and clicking the Contents button displays summary information for the backup and a list of the backup sets associated with it.

Overwrite Existing Backup Media

The Overwrite Media section of the Options page in the Back Up Database dialog box allows you to determine how SQL Server handles any existing files in the backup storage location that were created by a previous backup operation. (See Figure 7.5 for an example of the Options page.) You have the option to add your current backup’s data to the existing backup media set or create a new backup media set and have SQL Server erase the previous files. If you chose to use the current media set, you still can decide whether to append your data to the existing files in the media set or overwrite it. You are also given the option to have SQL Server look for potential naming and expiration date conflicts between the media sets by selecting the Check Media Set Name and Backup Set Expiration check box and entering a media set name in the text field. If you chose to create a new media set, you must enter a new name for the media set in the associated text field.

Reliability Checks

SQL Server 2008 also offers the ability to check a backup media set when the operation is finished to confirm that the output of the operation is viable. In the Reliability section of the Options page in the Back Up Database dialog box, you have the option to require SQL Server to verify the backup files when the operation is completed as well as to request a checksum verification of the backup before it is written to its storage media. The backup file verification confirms that the media set has been written to its storage media without error. The checksum verification confirms that the data within the backup media set is consistent with any checksums associated with the database to ensure that valid data is being written to the storage media and has not become corrupted.

Database Snapshots

Originally introduced with SQL Server 2005, database snapshots offer administrators another option for creating a point-in-time view of a database on top of SQL Server’s normal backup functionality. Database snapshots capture a fixed viewpoint of a target database, including all of its state and content except for any uncommitted transactions. Database snapshots are attractive because they can take up much less storage than a backup file by only tracking the changes made to a database after a snapshot is made, but this is not always the case, especially for databases that are frequently updated (such as heavily trafficked SharePoint collaboration content databases). According to Microsoft, snapshots are best used as a reporting resource (creating a view of the database at a specific point in time for later analysis) or for immediate protection of a database prior to a major update, but not as a regular or scheduled backup solution.

Unlike previous versions of the platform, SharePoint 2010 includes native support for SQL Server database snapshots. You can explicitly create, delete, and manage snapshots through PowerShell and custom code that is written against the SharePoint object model. In addition, a number of platform functions include support for leveraging database snapshots in their operations.

For example, the Backup-SPSite PowerShell cmdlet includes a -UseSqlSnapshot switch that allows you to perform a site collection backup against a snapshot of a content database rather than the actual database. Using a snapshot for this operation removes the need to lock the site collection to prevent update and write operations to the database when the backup is being performed. When the backup operation is complete, the cmdlet takes care of cleaning up the database snapshot that was used. The net effect is that users can continue to operate as they normally would without interference from the backup operation.

Snapshots are not a replacement for backup and restore operations, but you can leverage them to enhance or improve the overall administrative experience associated with these types of tasks.

Mirrored Backup Media Sets

Another feature only available in the Enterprise SKU for SQL Server 2005, 2008, and 2008 R2 but relevant to the topic of disaster recovery is mirrored backup media sets. Mirrored backup media sets allow a database to be backed up to multiple backup storage locations with a single operation, adding greater redundancy to backup operations and protection from storage hardware failure. Mirrored backups can use either disk or tape as the target storage medium, but the same type of hardware must be used for all mirrored targets in a given operation. A single operation can include up to four mirrors of the database, and restoration of mirrored backup sets allows for every mirror within the set to be used as the source for the restore. Mirrored backup media sets provide an additional option for increasing the redundancy of your SQL Server DR solution, but they can easily come with an additional cost, thanks to the requirement for additional storage media, not to mention the SQL Server Enterprise Edition license.

What’s New in SQL Server 2008 Backup

Microsoft added several new features and enhancements to the SQL Server platform with its 2008 release. These include spatial data types for integrating geographical data into applications, the ability to manage multiple SQL Server 2008 hosts from a single location using policy-based management, and data compression to reduce the amount of storage database files need and improve disk input/output (I/O) and memory utilization.

Backup compression is a feature completely new to SQL Server 2008. It was not possible in SQL Server 2005 to compress database backups in any way with the out-of-the-box tools available for SQL Server. In SQL Server 2008, backups can be automatically compressed when they are created without impacting the targeted database. Compression is available for all types of database backups, including log backups. Additionally, when a compressed backup is restored into SQL Server 2008, the data stored in it is automatically uncompressed. This means that the restore process for compressed backups is no different from the restore process for uncompressed backups.

It may seem that the biggest advantage of this backup compression feature is its ability to use less storage space to retain a backup, allowing you to reduce your storage usage and costs. Although this is definitely a benefit, there is another gain that can be equally valuable to your environment, if not greater: reduced disk I/O. When you compress the backup file, it takes less time to write the backup file to your disk and frees up that I/O for more critical activities, such as writing uploaded documents into a SharePoint content database or updating a Search crawl database. Depending on the resources available for your database servers, this can positively affect your performance over uncompressed backups. This is true especially if, once these smaller files are created, you can transfer them more quickly than uncompressed backups via a network connection that may have restrictions on its bandwidth, such as a local area network (LAN), WiFi, or a wide area network (WAN), to a remote storage repository.

Keep in mind, though, that this new feature in SQL Server 2008 has some drawbacks. First and foremost, a performance trade-off happens during compression: although your disk I/O impact is reduced, the CPU utilization that is necessary increases to allow the server to perform the compression function. The good news is that, overall, the usual result from backup compression is better overall performance, but you need to keep an eye on CPU and disk performance metrics in your environment to understand exactly what the benefits of using backup compression are for your SharePoint databases and if they are worth the cost.

To enable compression of a backup for a database, locate the Compression section on the Options page of the Backup Database dialog box, and select the desired option from the Set Backup Compression pull-down menu. For an example of the Compression section, see the bottom of Figure 7.5. By default, compression is not enabled for databases in SQL Server 2008. You must select to compress the database in the dialog box’s Options page, configure it as a setting in a T-SQL backup script, or change the default setting for the entire SQL Server instance if you want to use the function.

Finally, you should note some limitations to the use of backup compression prior to implementing it in your environment. Make sure you closely review the list that follows and understand how its points can apply to your SharePoint environment and its use of SQL Server 2008 before you take advantage of backup compression.

• SQL Server 2008 license. Backup compression is available only with the Enterprise SKU for SQL Server 2008. The good news is that if you are running SQL Server 2008 R2, backup compression is available with both the Standard and Enterprise SKUs.

• Backups lack compatibility with previous versions of SQL Server. You cannot restore compressed backups created with SQL Server 2008 into older versions of SQL Server such as SQL Server 2005 or 2000.

• Lacks compatibility with Transparent Data Encryption (TDE). If your database has TDE enabled, you cannot compress its backups.

There is another new feature in SQL Server 2008 that may not seem to be directly related to the topic of backup and restore, but it does provide some interesting implications and circumstances to consider in your disaster recovery planning for your SQL Server 2008 databases: Remote Binary Large Object (BLOB) Storage, or RBS for short.

A BLOB is commonly backed by a variable-length SQL Server column data type that allows for large amounts of binary data, such as a Microsoft Word document or an encrypted file, to be stored directly in a SQL Server database table rather than in a file system directory. Traditionally, SharePoint has made heavy use of BLOB columns in its database tables, storing documents uploaded into a site directly in these columns. SharePoint 2010 is no different in that regard. BLOBs offer much flexibility so that SharePoint can handle a range of file types and sizes, but they can also consume a great deal of storage space and computational resources on a SQL Server instance.

To try to alleviate the pressure that BLOB usage can place on SQL Server, Microsoft introduced the RBS feature with SQL Server 2008, which allows BLOB data to be stored in a remote location but still be accessed via SQL Server. RBS enables SQL Server to designate external content addressable stores (CAS) as dedicated storage repositories for BLOB data that still present to client applications, such as SharePoint, as if it were stored in a database table directly. RBS uses a flexible provider model so that different storage solutions can be chosen to meet the specific requirements of your environment. SQL Server provides its own RBS provider, the SQL FILE-STREAM provider, for use with SQL Server 2008, but third-party providers such as Metalogix’s StoragePoint, EMC, and AvePoint’s DocAve Extender are also available. RBS can be used with any edition of SQL Server 2008, but a storage solution other than storage locally attached to the host server can be used only with the Enterprise edition. The FILESTREAM provider is included with SQL Server 2008 at no additional cost, but it does have some limiting factors to consider: it can only work with a SQL Server host’s local drives, it doesn’t support database snapshots or mirroring, and it doesn’t support TDE, just to name a few.

In the case of SharePoint 2010, awareness of SQL Server’s RBS capability was added as a new feature. This allows SharePoint to be configured consistently regardless of how SQL Server’s storage is configured; at the same time, it allows SharePoint administrators and DBAs to have some flexibility in how SharePoint uses its storage. Although it may seem like this is a feature that would appeal only to the largest of enterprises, it also provides smaller organizations with appealing flexibility. One major change to the database situation for SharePoint 2010 is that it is no longer possible to create databases of unlimited size using the free Windows Internal Database included in a basic install of Windows SharePoint Services (WSS). The only free database option for SharePoint 2010 is SQL Server Express, but its databases are limited to 4GB (SQL Server 2005 and 2008 Express) or 10GB (SQL Server 2008 R2 Express). You can overcome that size limitation with the use of RBS because content stored with RBS does not count against the total size of the database.