Microsoft sql vss server

The next sections describe the snapshot creation process from the SQL writer point of view. For more information on these steps and for details of the VSS framework interfaces, see the documentation on Volume Shadow Copy Service.

It is assumed that the reader is familiar with the VSS framework and backup creation process in general. These sections are provided as supplemental information about how the SQL writer participates in the VSS backup creation process. To more fully understand the basic tasks involved in performing a backup, it is useful to break down this overview into the following phases:. During this phase of the backup the requestor backup application binds to the snapshot interface IvssBackupComponents and initializes it in preparation for the backup.

This phase is also referred to as Metadata Enumeration. The Writer Metadata Document is a document that contains information that is passed from the writer to the requestor backup application. The Writer Metadata Document contains the following information:. In this phase, a requestor examines the Writer Metadata Document and creates and fills a Backup Component Document with each component that needs to be backed up.

It also specifies the needed backup options and parameters as part of this document. For the SQL writer, each database instance that needs to be backed up is a separate component. This is an XML document created by a requestor using the IVssBackupComponents interface in the course of setting up a restore or backup operation.

The Backup Components Document contains a list of those explicitly included components, from one or more writers, participating in a backup or restore operation. It does not contain implicitly included component information. In contrast, a Writer Metadata Document contains only writer components that may participate in a backup. Prebackup tasks under VSS are focused on creating a shadow copy of the volumes containing data for backup.

The backup application will save data from the shadow copy, not the actual volume. Requestors typically wait on writers during preparation for backup and while the shadow copy is being created. If the SQL writer is participating in the backup operation, it needs to configure its files and also itself to be ready for backup and shadow copy.

The SQL writer will detect torn databases with backing volumes outside the snapshot set and fail the backup during the PostSnapshot event. In this phase, the requestor can move the data to a backup media, if needed. Interactions in this stage are between the requestor and the VSS framework.

The SQL writer is not involved. This is also the time at which the SQL writer can commit the backup as a differential base, if the current backup is a full backup of the database and not a copy-only backup. The requestor should send this event Backup Complete event explicitly to allow the SQL writer to commit differential base backups. If this event is not received, the backup that is created will not be an eligible "differential base" backup.

The requestor should save the Backup Component Document and each component backup metadata along with the data backed from the snapshot. The only extension of the component set structure in SQL Server is the introduction of full-text catalogs. Full-text catalogs are container directories, which cannot be expressed as the VSS database or log files, given that the VSS database and log files do not have recursive specification.

The snapshot creation phase is fast less than 60 seconds , to prevent blocking of all writes to the database. Post-snapshot If autorecovery is needed for the snapshot, the SQL writer will do the autorecovery for each database that has been selected to be in the snapshot.

For a detailed explanation, see Auto-Recovered Snapshots. The following figure shows the dataflow diagram during a VSS restore operation. To more fully understand the basic tasks involved in performing a restore, it is useful to break down this overview into the following topics:.

Between these two phases, the backup application is responsible for moving the relevant data around underneath SQL. During the initialization phase of a restore, the requestor needs to have access to the stored Backup Components Documents. The Backup Component Document that is generated during the backup operation, is stored as part of the backup data.

The backup application needs to pass this data back to the VSS framework. The SQL writer obtains access to this data at the beginning of the restore process. In preparing for a restore, a requestor uses the stored Backup Components Document to determine what is to be restored and how. The requestor will select the components to be restored and set appropriate restore options as needed.

If a backup application intends to apply differential or log backups on top of the current restore operation i. The SQL writer will examine the supplied Backup Component Document to identify the appropriate databases, deleting any additional files created since the backup time. It also checks disk spaces and closes any opened database file handles so that the requestor can copy the needed data during the Restore phase.

This phase allows any early error conditions to be detected before the requestor does the actual file copying. SQL Server will also put the database in restoring state. From this point on, the database cannot be started until a successful restore.

This is purely a requestor-specific action. It is the responsibility of the requestor backup application to copy the needed database files or copy relevant ranges of data for differential restores to the appropriate places.

The SQL writer is not involved in this operation. Once all the data is restored to the right places, a call from a requestor notifying that the restore operation has been completed IvssBackupComponents::PostRestore , will let the SQL writer know that Post Restore actions can be started. The SQL writer at this point will do the Redo phase of crash recovery. If recovery is not requested that is, SetAdditionalRestores true is not specified by the requestor , the undo phase of the recovery step is also carried out during this phase.

The SQL writer could be involved in the volume shadow copy creation process outside the context of backup and restore because the db files' backing volume s have been added into the volume snapshot set. The SQL writer supports full backup and restore operations in both noncomponent-based mode and component-based mode.

In a noncomponent-based backup and restore, the requestor specifies a volume or a folder tree to be backed up and restored. All the data in the specified volume and folder is backed up and restored. In a noncomponent-based backup, the SQL writer implicitly selects databases by using the list of volumes in the snapshot set. The writer checks for torn databases, raising an error if found. Privacy policy.

Applies to: SQL Server all supported versions. This article describes the new log introduced by SQL Server For example, if instances of, say,SQL Server Local instances and versions will benefit from the new SQL Server It also implies that only SQL Server The following paragraphs describe the situation starting with SQL Server Earlier SQL Server You can benefit from the new logging without any manual change. You can open, or get a copy of, the main SqlWriterLogger. That is, even if these operations take place successfully the log file will record detailed entries.

If any of these problems occur and you want to obtain more information, you do not have to repeatedly run the backup application. You can use the VSS administrative command-line tool Vssadmin. To make sure that you use the same credentials and settings that are used by VSS, follow these steps to run the simulation exercises. When the specified time is reached, a new command prompt appears. It resembles the following:. Note If a problem occurred with the metadata enumeration, the writers will not be listed.

You must make sure that the correct writer is listed in the Vssadmin output with no errors. This must occur before a backup application can use a writer during the snapshot creation process. The typical entries you will notice are listed below. This is an informational message only. No user action is required.

This is an informational message; no user action is required. With specific protocols configured, there may be times when the server does not listen. Sometimes, even if you have configured a specific set of protocols for the server to listen on, the server might not be able to listen on all of them. This could be due to environmental issues on the server. So you will need to take a look at the protocols that you have configured for this particular instance of SQL Server to listen on.

Now we will move onto the client portion of protocol configuration. There are two client configuration points you need to keep in mind. The first one is the list of enabled client protocols. The other one is the order in which the client protocols are used for connection. The default settings differ on various operating systems and for the different versions and editions of SQL Server.

See the appropriate Books Online topics for details on what is the default setup. The key point to understand here is that there should be at least one client protocol enabled that matches the server protocol. The only way that you can force the connections from the writer to go through a specific protocol is to configure an alias on the server.

Neither the VSS framework nor the writers have any configuration settings where you can supply any connection-specific or authentication-specific information for the client computer's use. Try 1 month free. Was this information helpful? Yes No. Thank you! Any more feedback? The more you tell us the more we can help. Can you help us improve? Resolved my issue.

Clear instructions.