Chat now with support
Chat with Support

NetVault Plug-in for SQL Server 14.0 - User Guide

Introducing NetVault 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 Removing a SQL Server Instance
Restoring data Using the CLI with the plug-in Troubleshooting

Differential Database backup for Online VDI

Differential Database backups are supported by:

•
SQL Server versions: Windows - 2008 and later; Linux - 2017 and later
•
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.

Copy-Only backup for Online VDI

Copy-Only backups are supported by:

•
SQL Server versions: Windows - 2008 and later; Linux - 2017 and later
•
Recovery models: All

Copy-Only backups are independent of the normal sequence of backups. A Copy-Only backup cannot serve as the base backup for a series of differential backups as a Full Backup can. Performing a Copy-Only backup does not affect what is backed up by the next differential backup. Copy-Only backups are ideal for situations that require special purposes, such as creating test environments or standby databases.

Incremental Transaction Log backup for Online VDI

Incremental Transaction Log backups are supported by:

•
SQL Server versions: Windows - 2008 and later; Linux - 2017 and later
•
Recovery Models: Full or Bulk-Logged Only

SQL Server Transaction Logs are essential to data recovery and must be backed up regularly. With Transaction Log backups, you can recover the database to a point-of-failure or specific point.

An Incremental Transaction Log backup captures all the transaction logs including those logs generated since the last Full Database/File or Filegroup, Differential Database/File or Filegroup, or Incremental Transaction Log backup. An Incremental Transaction Log backup should not be performed in the following conditions:

•
Until a Full Database or Full File and Filegroup backup has been created because the transaction log contains changes made to the database after the last backup was created.
•
After the transaction log has been manually truncated, until a Full Database or Differential Database backup has been performed. Microsoft strongly recommends against manually truncating transaction logs.

Tail-Log backup for Online VDI

Tail-Log backups are supported by:

•
SQL Server versions: Windows - 2008 and later; Linux - 2017 and later
•
Recovery models: Full Only

A Tail-Log backup captures the transaction logs that have not yet been backed up and is the last backup restored in a restore sequence. SQL Server requires you to back up the tail of the log before restoring a database that is attached to the SQL Server Instance. Therefore, a Tail-Log backup is the first step in most restore sequences.

A Tail-Log differs from an Incremental Transaction Log in the following ways:

•
You can try to run a Tail-Log backup even if the database does not start, for example if the database is damaged or is offline. If the database is damaged, a Tail-Log backup succeeds only if the log files are undamaged, the database is in a state that supports Tail-Log backups, and the database does not contain any bulk-logged changes.
•
A Tail-Log might contain incomplete metadata if the database is damaged because some of the metadata normally available for log backups may be unavailable in a Tail-Log backup. However, the captured log is complete and usable.

A Tail-Log's data might not be fully self-contained if the database is not online and undamaged at the time of the Tail-Log backup. Transactional data from a Tail-Log is always complete and usable, but if the Tail-Log backup is initiated while the database is damaged or offline, metadata might be only partially captured. If this issue occurs, a recovery from the Tail-Log leaves the “backupfilegroup” table missing some information about filegroups, and the “has_incomplete_metadata” column of the “backupset” table is set to 1.
 
* 
WARNING: Because Tail-Log backups place the databases in Offline Mode, only perform a Tail-Log backup if you are preparing to perform a restore and recovery. Tail-Log backups should not be used as a substitute for regular or unplanned Incremental Transaction Log backups.
•
If you are working with an AlwaysOn Availability Group, use SQL Server Management Studio to remove the primary and secondary databases from the group before completing a Tail-Log backup. After the databases are removed from the group, their status changes to Restoring, and they are owned by the SQL Server Instance assigned the Primary Role in the group. To complete the Tail-Log backup, select the databases under the SQL Server Instance.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating