Examples of VSS backup sequences
Following are few examples of backup sequences that support multiple restore scenarios and that you can implement to meet your SQL Server® data protection requirements.
|
• |
Full Database backups only: When requirements guarantee data protection up to the previous day, performing Full Database backups nightly should be sufficient when one or more of the following conditions exist: |
|
• |
Full Database and Differential Database backups: When requirements guarantee data protection up to the previous day and backups must be completed quickly, Full Database backups coupled with Differential Database backups is a valid strategy. For example, Full Database backups are performed every Sunday night at 11:00 P.M., while Differential Database backups are performed Monday through Saturday at 11:00 P.M. Each Differential Database backup includes all the changes since the last Full Database Backup, which is known as the differential base. |
|
• |
Copy-Only backups: When requirements demand that a backup be created without interfering with regular scheduled backup sequences, Copy-Only backups is a valid strategy. Often times, you must create a full backup outside of the regular backup schedule, such as when refreshing your test databases. This process could potentially interfere with the regular backup schedule and throw off subsequent differential backups. The Copy-Only backup allows administrators to run non-regular Full Database backups at any time without interfering with scheduled backups. |
Backing up system databases
The SQL Server® system databases are essential for the operation of a server instance. These backups enable recovery of the SQL Server if a system failure occurs, such as loss of a hard disk.
The system databases that you must always back up include msdb, master, and model. The master and msdb databases have a Simple Recovery Model while the model database has a Full Recovery Model. For replicated databases, you should also back up the distribution database.
|
• |
master: The master database records system-level information for a SQL Server system. For the master database, SQL Server supports only Full Database backups. Quest recommends that you schedule routine Full Database backups of master. |
|
• |
msdb and model: SQL Server uses the msdb database to store data. SQL Server uses the model database as a template when you create a user database. Back up the model and msdb databases whenever they are updated. You can back up the model and msdb databases in the same way that you back up user databases. Quest recommends that you create only Full Database backups of the model database. Because it is small and rarely changes, backing up the log is not required. |
For more information, see Backing Up and Restoring System Databases in SQL Server Books Online.
Backing up replicated databases
Database replication is supported from SQL Server® 2005 onward. Plug‑in for SQL Server supports all three types of replication: Transactional Replication, Merge Replication, and Snapshot Replication.
|
• |
The publication database at the Publisher. |
|
• |
The distribution database at the Distributor. |
|
• |
The subscription database at each Subscriber. |
|
• |
The master and msdb system databases at the Publisher, Distributor, and all Subscribers. These databases should be backed up at the same time as each other and the relevant replicated database. |
For more information, see Strategies for Backing Up and Restoring Snapshot and Transactional Replication, Strategies for Backing Up and Restoring Merge Replication, and Common Actions Requiring an Updated Backup in the SQL Server Books Online.
Reviewing the compression features
Before configuring a backup, review the following information. This information applies to all versions of SQL Server® that the plug-in supports, although some of the features described are not supported by all versions of SQL Server.
|
• |
Use NetVault Backup Low Compression: This method, which is selected by default, provides good compression with minimal processor usage. Quest recommends that you select this option when compression is needed but minimizing processing is more important. |
|
• |
Use NetVault Backup Medium Compression: This method provides better compression but requires additional processor usage. Quest recommends that you select this option when improved compression is needed and additional processor usage during backup is not an issue. |
|
• |
Use NetVault Backup High Compression: This method provides the best compression. Quest recommends that you select this option when compression is the most important factor and processor consumption is not an issue. |
|
• |
Use SQL Server Compression as Set in the SQL Server Instance: This option is only available if the plug-in is connecting to a SQL Server Instance that supports the SQL Server Backup Compression feature. If SQL Server Backup Compression is enabled for this SQL Server Instance, the plug-in uses SQL Server Backup Compression for this instance. If it is disabled for this SQL Server Instance, the plug-in does not use SQL Server Backup Compression. |
|
• |
Use SQL Server Compression: This option is only available if the plug-in is connecting to a SQL Server Instance that supports the SQL Server Backup Compression feature. Specifying this option tells the SQL Server to use a SQL Server Backup Compression algorithm to compress the data stored on backup media. |
|
• |
Do Not Use Compression: To disable compression, select this option. |
To view the compression ratio achieved after a backup job has run, click Job Status in the Navigation pane, and select the completed job, and click View logs. In the log that appears, locate a message that starts with “Compression Ratio.” To view additional information, select the line, and click More info. You can then view the total number of bytes of uncompressed data that was backed up, the number of bytes that was sent to the backup media, and the number of administrative bytes included as a header, which is also included as part of the compressed data statistic but are extraneous to the actual compressed data. The compression ratio that is reported in the log is [[(total uncompressed data) – (total compressed data)] x 100%] / (total uncompressed data). The number of header bytes is usually an insignificant part of the backup size, except when small databases are backed up using multiple NetVault Backup streams.
If you use the SQL Server Backup Compression feature, or if you choose not to use compression, the VDI Streams when NetVault Backup Compression is not used option is enabled.
If you use one of the NetVault Backup Compression methods, the VDI Streams/Compression Threads and Number of Parallel NetVault Backup Streams options are enabled. The VDI threads perform compression. During a backup, each VDI thread or connection accepts data from SQL Server, compresses it, and then writes it to the output device using a NetVault Backup stream. Because higher compression levels are more processor-intensive, consider making effective use of the number of processors available on the system running the NetVault Backup Client, that is, the system running the SQL Server Instance that you are backing up. For example, you might specify a number of VDI threads that is slightly less than the number of processors on your system. However, the number of backup streams should not exceed the number of output devices. For this reason, you must specify the number of VDI streams (VDI Streams/Compression Threads) and the number of NetVault Backup streams (Number of Parallel NetVault Backup Streams) separately. When you access the SQL Server Backup Options tab, the number of VDI streams initially displayed is one less than the number of processors detected on the NetVault Backup Client. The value specified in this field determines the number of VDI devices to be used for storing the backup job. In the default setting, all backup job options have one VDI device set to the job, when Use Virtual Device Interface (VDI) is selected. You can add additional VDI devices; however, the minimum number of VDI devices is 1, and the maximum number cannot exceed 64.
At the bottom of the VDI Backup Options section, the plug-in displays the number of processors on the NetVault Backup Client. If the processors use Hyper-Threading (HT), the number reflects it; a system with four physical processors and with HT enabled is identified as having eight processors. You can use this number when choosing the number of VDI streams if you use NetVault Backup Compression.
For optimal backup times when NetVault Backup Compression is used, base the entry for the Number of Parallel NetVault Backup Streams on the number of backup media. If your media uses striped disks, the fastest backup might occur with the number of backup streams set to the number of stripes. If the backup is writing to different hard drives that are not striped, with each NetVault Backup output device on a different hard drive, set the number of backup streams to the number of hard drives. If you are backing up to one or more VTLs on a single non-striped disk, use only one or two NetVault Backup streams. If you are backing up to a tape library with several tape drives, use no more backup streams, preferably fewer, than there are tape drives.