Chatee ahora con Soporte
Chat con el soporte

NetVault Plug-in for SQL Server 11.2 - User Guide

Introducing Quest® 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 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
Restoring data Troubleshooting

Reviewing SQL Server® recovery models

When a database is created, a recovery model is enabled. Microsoft defines a recovery model as a “database property that controls the basic behavior of backup and recovery of the database.” The database’s recovery model controls how its transactions are logged, whether the transaction log can be backed up, and which kinds of restores are supported. SQL Server provides three different recovery models: Simple, Full, and Bulk-Logged.

•
Simple Recovery Model: With a Simple Recovery Model, log backups are not supported. Therefore, changes since the most recent backup are not protected. In the unfortunate event of failure, these changes must be re-run. PIT recovery is not allowed.
•
Full Recovery Model: Full Recovery Model databases require log backups; therefore, no work is lost due to a lost or damaged data file. PIT recovery is supported, assuming backups are complete up to the point-of-failure.
•
Bulk-Logged Recovery Model: Bulk-Logged Recovery Model databases require log backups. The Bulk-Logged Recovery Model is a variation of the Full Recovery Model that permits high-performance bulk-copy operations. This model reduces log space usage by bulk-logging most bulk operations. If a log is damaged or bulk-operations have occurred since the most recent Transaction Log backup, these changes must be re-run. PIT recovery is not supported for bulk-logged databases.
Choosing the best recovery model

Consider the following when choosing a recovery model for a database:

•
Simple Recovery Model: The Simple Recovery Model should only be enabled for databases that are not updated frequently such as test, development, or databases mostly containing read-only data.
•
Full Recovery Model: The Full Recovery Model should be enabled for transactional databases where full recoverability and preventing work loss in a full range of recovery scenarios is required.
•
Bulk-Logged Recovery Model: The Bulk-Logged Recovery Model should be used temporarily when bulk operations, such as bulk inserts or index creation, are performed on Full Recovery Model databases. The Bulk-Logged Recovery Model increases performance and reduces log space consumption during these operations; you can switch databases back to full recovery immediately after the bulk operations have completed.

For more information, see Recovery Models and Transaction Log Management in the SQL Server Books Online.

Defining an Online VDI backup strategy and reviewing types

After selecting the recovery model that meets your requirements for each database, you can design and implement a corresponding backup strategy. When defining a SQL Server® Online VDI Backup strategy, answer the following questions:

•
Is there a predictable off-peak period for full backups?
•
What is the frequency of updates and changes?
•
Are changes confined to a small or large number of tables in a database?

Answering these questions helps you define the type and frequency of backups that should be implemented.

The plug-in provides the following types of Online VDI Backup:

•
Full Database backup for Online VDI
•
Differential Database backup for Online VDI
•
Copy-Only backup for Online VDI
•
Incremental Transaction Log backup for Online VDI
•
Tail-Log backup for Online VDI
•
Full File and Filegroup backup for Online VDI
•
Differential File and Filegroup backup for Online VDI
•
Partial Database backup for Online VDI
•
Differential Partial Database Backup for Online VDI

Full Database backup for Online VDI

Full Database backups are supported by:

•
SQL Server® versions: All
•
Recovery models: All

A Full Database backup is a backup of the entire database. It also includes part of the transaction log, which enables recovery of the database to the point at which the backup was completed.

Full Database backups consume more space and time per backup and are typically supplemented by differential backups, which are created more frequently. With Full Database backups, you can re-create an entire database in one step by restoring the database.

Differential Database backup for Online VDI

Differential Database backups are supported by:

•
SQL Server® versions: All
•
Recovery models: All

With a Differential Database, back up only the data that has changed since the last Full Database backup is backed up. Differential backups are smaller and faster to create than the full backups.

A Differential Database backup is useful if some of the database’s tables are modified more frequently than others. In this case, Differential Database backups allow you to back up frequently without the overhead of Full Database backups.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación