サポートと今すぐチャット
サポートとのチャット

NetVault Plug-in for SQL Server 12.2 - User Guide

Introducing NetVault Backup Plug-in for SQL Server Planning your SQL Server deployment Installing and removing the plug-in Configuring the plug-in Backing up data
Defining a backup strategy Understanding snapshot-based backups Reviewing the compression features Performing Online VDI backups Performing VSS backups in SQL Server Example of creating a full VDI backup of an AlwaysOn Availability Group on Windows
Restoring data Using the CLI with the plug-in Troubleshooting

Partial Database backup for Online VDI

Partial Database backups are supported by:

•
SQL Server versions: Windows - 2008 and later
•
Recovery models: Simple

Designed to create flexibility for Simple Recovery Model databases, a Partial Database backup is similar to a Full Database backup except that a Partial does not contain all the database’s filegroups. A Partial Database backup contains all the data in the primary filegroup and every read/write filegroup. Optionally, specified read-only files can also be included. However, a partial backup of a read-only database contains only the primary filegroup.

A Partial Database backup is useful when a database contains read-only files that you do not need to include in every database backup. A Partial Database backup can also be used as a basis for a piecemeal restore scenario, which the plug-in does not support.

Differential Partial Database Backup for Online VDI

Differential Partial Database backups are supported by:

•
SQL Server versions: Windows - 2008 and later
•
Recovery Models: Simple

Used only with Partial Database backups, a Differential Partial backup contains only those extents changed in the primary filegroup and read/write filegroups since the previous partial backup. If only some of the data captured by a partial backup has changed, using a Differential Partial backup lets you back up frequently without the overhead of Full Database backups.

For more information on the effect of adding, deleting, or modifying Filegroups on Partial Differential backups, see Differential Partial Backups in the SQL Server Books Online.

Examples of VDI online backup sequences

Following are a few examples of backup sequences that support multiple restore scenarios and that you can implement to meet your SQL Server data protection requirements.

•
Simple recovery model backup sequences
•
Full recovery model backup sequences
Simple recovery model backup sequences
•
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:
•
Backup windows are large.
•
Databases are small.
•
Updates are infrequent across entire database.
•
Databases are only for testing or development purposes.
•
Entire database is read-only.
•
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.
No matter when recovery is performed, the same number of restore jobs is required. For example, if recovery is performed on Tuesday, Sunday’s Full Database backup and Monday’s Differential Database must be restored. Whereas, if recovery is performed on Thursday, Sunday’s Full Database backup followed by Wednesday’s Differential Database backup must be restored.
Even though Differential Database backups increase not only in size but in duration, restores are quicker due to the fewer number of restore jobs that must be run.
•
Full File and Filegroup backups and Partial Database backups: When a Simple Recovery Model database includes secondary read-only filegroups, a valid strategy includes Partial Database backups for the primary and read/write filegroups and Full File and Filegroup backups for read-only secondary filegroups. This strategy ensures recoverability of the entire database without requiring backup of the read-only filegroups every time the read/write filegroups are backed up.
Secondary read-only filegroups only need to be backed up once after the initial load and after subsequent updates. When requirements guarantee data protection up to the previous day for read/write filegroups, performing nightly Partial Database backups should be sufficient.
•
Full File and Filegroup backups and Partial Database and Differential Partial Database backups: When requirements guarantee data protection for read/write data up to the previous day and backups must be completed quickly, Partial Database backups coupled with Differential Database Backups for the read/write data and Full File and Filegroup backup for the secondary read-only filegroups is a valid strategy.
For example, Full File and Filegroup backups are performed for read-only data only after the initial load and subsequent updates. Partial Database backups, which include the primary filegroup and all read/write filegroups, are performed every Sunday night at 11:00 P.M. In addition, Differential Partial Database backups for the same read/write filegroups are performed Monday through Saturday at 11:00 P.M. Each Differential Partial Database backup includes all the changes since the last Partial Database Backup, which is known as the differential base.
No matter when recovery is performed, the same number of restore jobs is required. For example, if recovery is performed on Tuesday, Sunday’s Partial Database backup and Monday’s Differential Partial Database must be restored. Whereas, if recovery is performed on Thursday, Sunday’s Partial Database backup followed by Wednesday’s Differential Partial Database backup must be restored.
Even though Differential Partial Database backups increase not only in size but also in duration, restores are quicker due to the fewer number of restore jobs that must be run.

Full recovery model backup sequences

•
Full Database and Incremental Transaction Log backups: When requirements mandate PIT data protection, performing Full Database backup nightly plus Incremental Transaction Log backups every four to eight hours should be sufficient when one or more of the following conditions exist:
•
Backup windows are large.
•
Databases are small.
•
Updates are infrequent across the entire database.
For example, Full Database backups are performed every night while Incremental Transaction Log backups are performed every four to eight hours. Each Incremental Transaction Log backup includes the transaction logs since the last Full Database or Incremental Transaction Log backup.
Restore sequences that use Incremental Transaction Log backups require that every Incremental Transaction Log backup between the last Full Database backup and the point-of-failure is restored in succession. This process can lead to longer restores and increased intervention to initiate multiple restore jobs. To speed up restores, include Differential Database backups, which reduces the number of Incremental Transaction Log backups that must be restored.
•
Full Database and Differential Database and Incremental Transaction Log backups: When requirements mandate PIT data protection and restores of the complete database must be completed quickly, Full Database plus Differential Database plus Incremental Transaction Log backups is an ideal strategy.
For example, Full Database backups are performed every Sunday night at 11:00 P.M. Differential Database backups are performed Monday through Saturday at 11:00 P.M. Incremental Transaction Log backups are performed every hour. Each Differential Database backup includes all the changes since the last Full Database backup, and each Incremental Transaction Log backup includes the transaction logs since the last Differential Database backup.
Restore sequences that use Incremental Transaction Log backups require that every Incremental Transaction Log backup between the last Full Database or Differential Database backup and the point-of-failure is restored in succession. This process can lead to longer restores and increased intervention to initiate multiple restore jobs. To speed up restores, increase the frequency of the Differential Database backups to every four to eight hours. This increase reduces the number of Incremental Transaction Log backups that must be restored. This strategy provides complete protection of the entire database with the simplest administration while supporting multiple restore scenarios.
•
Full File and Filegroup and Differential File and Filegroup and Incremental Transaction Log backups (Windows only): When requirements mandate PIT data protection and restores must be completed quickly, Full File and Filegroup plus Differential File and Filegroup plus Incremental Transaction Log backups is an ideal strategy. This strategy lets you restore a complete database or the files or filegroups that are damaged. By being able to restore only what is needed, restores are faster and data loss is minimized.
For example, Full File and Filegroup backups are performed every Sunday night at 11:00 P.M. Differential File and Filegroup backups are performed Monday through Saturday at 11:00 P.M. Incremental Transaction Log backups are performed every hour. Each Differential File and Filegroup backup includes all changes since the last Full File and Filegroup backup, and each Incremental Transaction Log backup includes the transaction logs since the last Differential File and Filegroup backup.
Restore sequences that use Incremental Transaction Log backups require that you restore every Incremental Transaction Log backup between the last Full File and Filegroup or Differential File and Filegroup backup and the point-of-failure in succession. This process can lead to longer restores and increased intervention to initiate multiple restore jobs. To speed up restores, increase the frequency of the Differential File and Filegroup backups to every four to eight hours. This change reduces the number of Incremental Transaction Log backups that must be restored. This strategy provides complete protection of the entire database with the flexibility to restore only the files or filegroups that are damaged while supporting most restore scenarios.
 
* 
IMPORTANT: If you are using Linux, you cannot select individual files and filegroups for the backup job.
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択