How to use volume shadow copy in windows 10 correctly

Performing Restore Operations

vshadow -r=File.xml

vshadow -rs=File.xml

The -r command-line option performs a restore operation.

The -rs command-line option performs a simulated restore operation.

The File.xml file must be a Backup Components Document file for a shadow copy set that was created with the -t or -bc optional flag.

The -r and -rs command-line options are mutually exclusive and cannot be combined with other command-line options.

OptionalFlags is a bitmask of optional flag values from the following table.

Optional Flag Value	Description
-wi=Writer	This optional flag verifies that the specified writer or component is included in the restore. Writer can specify a component path, writer name, writer ID, or writer instance ID.
-wx=Writer	This optional flag verifies that the specified writer or component is excluded from the restore. Writer can specify a component path, writer name, writer ID, or writer instance ID.
-exec=Command	This optional flag executes a command or script between the pre-restore and post-restore events that are sent to the writers. Command can specify an executable shell command or a CMD file. If it specifies a shell command, no command parameters can be specified.
-tracing	This optional flag generates verbose output that can be used for troubleshooting.

Volume Shadow Copy Service Tools

The Windows operating system provides the following tools for working with VSS:

DiskShadow

DiskShadow is a VSS requester that you can use to manage all the hardware and software snapshots that you can have on a system. DiskShadow includes commands such as the following:

list: Lists VSS writers, VSS providers, and shadow copies
create: Creates a new shadow copy
import: Imports a transportable shadow copy
expose: Exposes a persistent shadow copy (as a drive letter, for example)
revert: Reverts a volume back to a specified shadow copy

This tool is intended for use by IT professionals, but developers might also find it useful when testing a VSS writer or VSS provider.

DiskShadow is available only on Windows Server operating systems. It is not available on Windows client operating systems.

VssAdmin

VssAdmin is used to create, delete, and list information about shadow copies. It can also be used to resize the shadow copy storage area («diff area»).

VssAdmin includes commands such as the following:

create shadow: Creates a new shadow copy
delete shadows: Deletes shadow copies
list providers: Lists all registered VSS providers
list writers: Lists all subscribed VSS writers
resize shadowstorage: Changes the maximum size of the shadow copy storage area

VssAdmin can only be used to administer shadow copies that are created by the system software provider.

VssAdmin is available on Windows client and Windows Server operating system versions.

Способ 3: Автоматизация теневого копирования

В начале статьи мы обещали, что расскажем о методе автоматизации теневого копирования. Делается это путем добавления новой задачи через «Планировщик заданий». Тогда в определенный период времени будет вызываться рассмотренная выше команда и выполняться создание новой точки восстановления.

Откройте «Пуск» и через поиск отыщите приложение «Панель управления».
Там выберите раздел «Администрирование».
Запустите модуль «Планировщик заданий».
В блоке «Действия», который находится справа, нажмите по строке «Создать простую задачу».
Введите произвольное имя, чтобы отличить эту задачу от других в списке, а затем переходите к следующему шагу.
Установите триггер для запуска задачи, поставив маркер возле подходящего пункта. Например, можно выполнять новое теневое копирование каждый день или только один раз в неделю.
После этого задайте промежуток для задачи и установите повторение, если это требуется.
В качестве действия отметьте «Запустить программу».
В поле «Программа или сценарий» введите , а для «Добавить аргументы (необязательно)» присвойте , заменив букву диска на нужную.
При завершающем этапе отметьте галочкой пункт «Открыть окно «Свойства» для этой задачи после нажатия кнопки «Готово»».
После открытия свойств назначьте статус «Выполнить с наивысшими правами» и завершите работу над заданием.

Теперь вы можете быть уверены в том, что задача выполнится в назначенный период времени и теневые копии файлов автоматически обновятся. В окне просмотра предыдущих версий можно удалить все точки восстановления. Учитывайте это и периодически осуществляйте данную задачу, чтобы не копить на компьютере ненужные файлы.

Подробнее: Инструкция по созданию резервной копии Windows 10

Complete copy

A complete copy is usually created by making a «split mirror» as follows:

The original volume and the shadow copy volume are a mirrored volume set.
The shadow copy volume is separated from the original volume. This breaks the mirror connection.

After the mirror connection is broken, the original volume and the shadow copy volume are independent. The original volume continues to accept all changes (write I/O requests), while the shadow copy volume remains an exact read-only copy of the original data at the time of the break.

Copy-on-write method

In the copy-on-write method, when a change to the original volume occurs (but before the write I/O request is completed), each block to be modified is read and then written to the volume’s shadow copy storage area (also called its «diff area»). The shadow copy storage area can be on the same volume or a different volume. This preserves a copy of the data block on the original volume before the change overwrites it.

Time	Source data (status and data)	Shadow copy (status and data)
T0	Original data: 1 2 3 4 5	No copy: —
T1	Data changed in cache: 3 to 3′	Shadow copy created (differences only): 3
T2	Original data overwritten: 1 2 3′ 4 5	Differences and index stored on shadow copy: 3

Table 1 The copy-on-write method of creating shadow copies

The copy-on-write method is a quick method for creating a shadow copy, because it copies only data that is changed. The copied blocks in the diff area can be combined with the changed data on the original volume to restore the volume to its state before any of the changes were made. If there are many changes, the copy-on-write method can become expensive.

Redirect-on-write method

In the redirect-on-write method, whenever the original volume receives a change (write I/O request), the change is not applied to the original volume. Instead, the change is written to another volume’s shadow copy storage area.

Time	Source data (status and data)	Shadow copy (status and data)
T0	Original data: 1 2 3 4 5	No copy: —
T1	Data changed in cache: 3 to 3′	Shadow copy created (differences only): 3′
T2	Original data unchanged: 1 2 3 4 5	Differences and index stored on shadow copy: 3′

Table 2 The redirect-on-write method of creating shadow copies

Like the copy-on-write method, the redirect-on-write method is a quick method for creating a shadow copy, because it copies only changes to the data. The copied blocks in the diff area can be combined with the unchanged data on the original volume to create a complete, up-to-date copy of the data. If there are many read I/O requests, the redirect-on-write method can become expensive.

Importing a Shadow Copy Set

vshadow -i=File.xml

The -i command-line option imports a transportable shadow copy set.

Note

This command-line option is supported only on Windows server operating systems.

The File.xml file must be a Backup Components Document file for a transportable shadow copy set that was created with the -t or -bc optional flag.

A shadow copy set is a persistent shadow copy if it was created with the -p optional flag. If the transportable shadow copy set is nonpersistent, it appears for a short time while the shadow copy creation command is running, and is automatically deleted when the command returns. You can import nonpersistent shadow copies only during shadow copy creation, by creating the shadow copy set using the -exec optional flag to execute a CMD file that calls VShadow -i.

The -i command-line option cannot be combined with other command-line options.

OptionalFlags is a bitmask of optional flag values from the following table.

Optional Flag Value	Description
-exec=Command	This optional flag executes a command or script after the shadow copies are imported but before the VShadow tool exits. Command can specify an executable shell command or a CMD file. If it specifies a shell command, no command parameters can be specified.
-tracing	This optional flag generates verbose output that can be used for troubleshooting.
-wait	This optional flag causes the VShadow tool to wait for user confirmation before exiting.

Exposing a Shadow Copy Remotely

vshadow **-er=ShadowCopyId,**UnusedShareName

vshadow **-er=ShadowCopyId,UnusedShareName,**PathFromRootOnShadow

The -er command-line option assigns a read-only share name to the root directory (or a subdirectory) from the shadow copy. Note that the share contents will remain read-only unless you subsequently call vshadow -bw to break the shadow copy set.

Note

Client-accessible shadow copies cannot be exposed remotely.

For example, if {edbed95e-7e8d-11d8-9d01-505054503030} is the GUID of an existing persistent shadow copy, and share_123 is an unused share name, the following command exposes the shadow copy under share_123:

vshadow -er={edbed95e-7e8d-11d8-9d01-505054503030},share_123

The following example shows how to expose only a subtree (named «Folder1\Folder2») of the same shadow copy under the same share:

vshadow -er={edbed95e-7e8d-11d8-9d01-505054503030},share_123,Folder1\Folder2

The -er command-line option cannot be combined with other command-line options.

To transport a shadow copy

Create a transportable shadow copy of the source data on a server.
Import the shadow copy to a server that is connected to the SAN (you can import to a different server or the same server).
The data is now ready to be used.

Figure 3 Shadow copy creation and transport between two servers

Note

A transportable shadow copy that is created on Windows Server 2003 cannot be imported onto a server that is running Windows Server 2008 or Windows Server 2008 R2. A transportable shadow copy that was created on Windows Server 2008 or Windows Server 2008 R2 cannot be imported onto a server that is running Windows Server 2003. However, a shadow copy that is created on Windows Server 2008 can be imported onto a server that is running Windows Server 2008 R2 and vice versa.

Shadow copies are read-only. If you want to convert a shadow copy to a read/write LUN, you can use a Virtual Disk Service-based storage-management application (including some requesters) in addition to the Volume Shadow Copy Service. By using this application, you can remove the shadow copy from Volume Shadow Copy Service management and convert it to a read/write LUN.

Volume Shadow Copy Service transport is an advanced solution on computers running Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, Windows Server 2008, or Windows Server 2008 R2. It works only if there is a hardware provider on the storage array. Shadow copy transport can be used for a number of purposes, including tape backups, data mining, and testing.

Создание набора теневого копирования

vshadow VolumeList

Эта команда создает новый набор теневого копирования.

VolumeList — это список имен томов. VShadow создает одну теневое копирование для каждого тома в списке. При необходимости имя тома можно завершить с помощью обратной косой черты (\). Например, C: и C:\ являются допустимыми именами томов. Можно также указать подключенные папки (например, C:\DirectoryName) или имена GUID тома (например, \\?\Volume{edbed95e-7e8d-11d8-9d01-50505450303030}).

OptionalFlags — это битовая маска необязательных значений флагов из следующей таблицы.

Необязательное значение флага	Описание
-ad	Этот необязательный флаг указывает разностные теневые копии оборудования. Этот флаг и флаг -ap являются взаимоисключающими.
-ap	Этот необязательный флаг указывает лексевые аппаратные теневые копии. Этот флаг и флаг -ad являются взаимоисключающими.
-bc=File.xml	Этот необязательный флаг указывает неперевозмные теневые копии и сохраняет документ компонентов резервного копирования в указанный файл. Этот файл можно использовать в последующей операции восстановления. Этот флаг и флаг -t являются взаимоисключающими.
-exec=Command	Этот необязательный флаг выполняет команду или скрипт после создания теневых копий, но до завершения работы средства VShadow. Команда может указать исполняемую команду оболочки или CMD-файл. Если она задает команду оболочки, параметры команды не могут быть указаны.
-forcerevert	Этот необязательный флаг указывает, что операция теневого копирования должна быть завершена только в том случае, если можно отменить все подписи диска.Windows Server 2003: не поддерживается.
-mask	Этот необязательный флаг указывает, что luN теневого копирования должны маскироваться с компьютера при сломе набора теневого копирования.Windows Server 2003: не поддерживается.
-nar	Этот необязательный флаг указывает теневые копии без автоматического восстановления. Дополнительные сведения об этом параметре см. в документации по флагу VSS_VOLSNAP_ATTR_NO_AUTORECOVERY перечисления _VSS_VOLUME_SNAPSHOT_ATTRIBUTES .
-norevert	Этот необязательный флаг указывает, что подписи дисков не должны быть отменены.Windows Server 2003: не поддерживается.
-nw	Этот необязательный флаг указывает теневые копии без записи. Дополнительные сведения о теневых копиях без участия модуля записи см. в разделе «Сведения о создании теневого копирования». Этот флаг и флаги -wi и -wx являются взаимоисключающими.
-p	Этот необязательный флаг указывает постоянные теневые копии.
-rw	Этот необязательный флаг указывает, что LUN теневого копирования следует выполнять при считывания и записи при сломе набора теневого копирования.Windows Server 2003: не поддерживается.
-scsf	Этот необязательный флаг указывает теневые копии, доступные для клиента.
-script=File.cmd	Этот необязательный флаг создает CMD-файл, содержащий переменные среды, связанные с созданными теневыми копиями, такими как идентификаторы теневого копирования и идентификаторы наборов теневого копирования.
-t=Файл.xml	Этот необязательный флаг указывает переносимые теневые копии и сохраняет документ компонентов резервного копирования в файл, указанный параметром File.xml. Этот файл можно использовать в последующей операции импорта и (или) восстановления. Этот флаг и флаг -bc являются взаимоисключающими.Windows Server 2003, выпуск Standard и Windows Server 2003, Web Edition: переносимые теневые копии не поддерживаются. Все выпуски Windows Server 2003 с пакетом обновления 1 (SP1) поддерживают переносимые теневые копии.
-tr	Этот необязательный флаг указывает, что восстановление TxF должно применяться во время создания теневого копирования.
-tracing	Этот необязательный флаг создает подробные выходные данные, которые можно использовать для устранения неполадок.
-wait	Этот необязательный флаг приводит к тому, что средство VShadow ожидает подтверждения пользователя перед выходом.
-wi=Writer	Этот необязательный флаг проверяет, включен ли указанный модуль записи или компонент в теневое копирование. Модуль записи может указать путь к компоненту, имя модуля записи, идентификатор модуля записи или идентификатор экземпляра записи. Этот флаг и флаг -nw являются взаимоисключающими.
-wx=Writer	Этот необязательный флаг проверяет, исключен ли указанный модуль записи или компонент из теневого копирования. Модуль записи может указать путь к компоненту, имя модуля записи, идентификатор модуля записи или идентификатор экземпляра записи. Этот флаг и флаг -nw являются взаимоисключающими.

Breaking a Shadow Copy Set

vshadow **-b=**ShadowCopySetId

vshadow **-bw=**ShadowCopySetId

The **-b=**ShadowCopySetId command-line option converts each shadow copy in the shadow copy set into a stand-alone read-only volume.

The **-bw=**ShadowCopySetId command-line option converts each shadow copy in the shadow copy set into a stand-alone writable volume.

Note

The -b and -bw command-line options are supported only on Windows server operating systems.

For information about breaking a shadow copy set, see Breaking Shadow Copies.

After the shadow copy set is broken, the shadow copy set and the individual shadow copies no longer exist and cannot be managed using VSS commands.

A shadow copy set is persistent if it was created with the -p optional flag. If the transportable shadow copy set is nonpersistent, it appears for a short time while the shadow copy creation command is running, and is automatically deleted when the command returns. You can break nonpersistent shadow copy sets only during shadow copy creation, by creating the shadow copy set using the -exec optional flag to execute a CMD file that calls vshadow -b or vshadow -bw.

The -b and -bw command-line options are mutually exclusive and cannot be combined with other command-line options.

How a Shadow Copy Is Created

Once a shadow copy (volume snapshot) is created, its size is 0 bytes. When new data is written, the data is written on the disk (where it usually should be), but the old data is written to a shadow copy so you can restore that old data later. The size of the shadow copy grows as a result.

There are two main approaches to writing data when creating a snapshot:

Redirect on write (RoW): Writing new blocks to a snapshot (shadow copy) and saving metadata with information to which blocks on the disk they must be written. This approach involves fast writing of data but slow reading of data. If you need to roll back to the initial state when the snapshot was created, it takes a few seconds by deleting a snapshot (near instantly). The RoW approach is used to create snapshots of VM virtual disks (VMDK) in VMware ESXi and VMware Workstation.
Copy on Write (CoW): Writing new blocks to the needed place on the disk and sending the contents of rewritten blocks to a snapshot. Writing is slow, but reading is fast. Previous snapshots (previous data states) are deleted in a few seconds (near instantly). The CoW approach is used for VSS snapshots.

With so many different applications that can write data on disks, Microsoft created a unified interface with VSS to notify all applications that a snapshot is about to be created after initiating snapshot creation. The idea of the notification message is: A system will create a snapshot – stop your writing activities and flush writing buffers on disks to adopt the data into the consistent state.

The workflow to create a VSS snapshot is as follows:

The VSS requestor checks the available services with which it can communicate, enumerates the writers, and gathers the metadata.
After collecting a list of writers, the requestor communicates with the VSS provider and tells a snapshot which data it wants to create and where the snapshot should be located. In most cases, the snapshot is located on the same volume on the original disk. In alternative cases, SAN hardware providers can create a separate volume for a snapshot called a storage snapshot.
Preparing for backup. This step involves requesting the real status of VSS writers (after getting the metadata) and preparing for the most important operation when writers must act one after another. Writers are notified that they must prepare for snapshot creation. The system buffer is flushed, and the application is frozen to ensure that a consistent data copy can be made. Each writer must fit in its allotted time of 60 seconds by default. Microsoft Exchange Server has only 20 seconds for this operation (this time is set by Microsoft).

Note: 20 seconds is a short period. If an application cannot fit in this time, the writers return an error, and the snapshot is not taken. If the storage performance is not enough to fit in this time limit, you can try upgrading your hardware to fix this issue. For example, you can change HDD to SSD storage devices. Alternatively, you can try to migrate other workloads to another storage and use dedicated storage only for the machine running Microsoft Exchange Server. Check logs to detect which writer failed the snapshot creation task.

If everything is OK, and system activity is frozen, then VSS tells that the provider can create a shadow copy. There are only 10 seconds to create a snapshot. File system I/O requests are temporarily unavailable during this period. This is the time when you can also create a VM snapshot. Once the 10 seconds pass, all writers are unfrozen and input/output (I/O) operations are alive again.

Note: If the VSS providers take longer than 10 seconds to commit the shadow copy, the operation fails.

VSS tells the writers that applications can unfreeze I/O requests and continue writing data to disks. If we use a backup application and a backup using the Windows VSS service has been created, the VSS snapshot can be deleted. This operation can be performed by the backup application itself. Alternatively, you can delete a volume snapshot with diskshadow or vssadmin.

If you have VSS issues, a machine reboot can fix the issues in many cases when other methods don’t work. Some issues related to time limitations (for example, 10 seconds to create a snapshot) can be fixed by upgrading hardware, including disk devices, or by reducing loads.

Try to create a snapshot manually and check whether you fit the 20 seconds allotted (using Exchange Server as an example). In case of failure, reboot, reduce the loads, and try again.

Starting from Windows Server 2012, VSS supports SMB file shares in Windows. The VSS technology is very useful with file shares as files may be continuously written by users and applications, making share backups a challenge without VSS. NAKIVO Backup & Replication 10.7 supports file share backup.

How Shadow Copies Are Used

In addition to backing up application data and system state information, shadow copies can be used for a number of purposes, including the following:

Restoring LUNs (LUN resynchronization and LUN swapping)
Restoring individual files (Shadow Copies for Shared Folders)
Data mining by using transportable shadow copies

Restoring LUNs (LUN resynchronization and LUN swapping)

In Windows Server 2008 R2 and Windows 7, VSS requesters can use a hardware shadow copy provider feature called LUN resynchronization (or «LUN resync»). This is a fast-recovery scheme that allows an application administrator to restore data from a shadow copy to the original LUN or to a new LUN.

The shadow copy can be a full clone or a differential shadow copy. In either case, at the end of the resync operation, the destination LUN will have the same contents as the shadow copy LUN. During the resync operation, the array performs a block-level copy from the shadow copy to the destination LUN.

Most arrays allow production I/O operations to resume shortly after the resync operation begins. While the resync operation is in progress, read requests are redirected to the shadow copy LUN, and write requests to the destination LUN. This allows arrays to recover very large data sets and resume normal operations in several seconds.

LUN resynchronization is different from LUN swapping. A LUN swap is a fast recovery scenario that VSS has supported since Windows Server 2003 SP1. In a LUN swap, the shadow copy is imported and then converted into a read-write volume. The conversion is an irreversible operation, and the volume and underlying LUN cannot be controlled with the VSS APIs after that. The following list describes how LUN resynchronization compares with LUN swapping:

In LUN resynchronization, the shadow copy is not altered, so it can be used several times. In LUN swapping, the shadow copy can be used only once for a recovery. For the most safety-conscious administrators, this is important. When LUN resynchronization is used, the requester can retry the entire restore operation if something goes wrong the first time.
At the end of a LUN swap, the shadow copy LUN is used for production I/O requests. For this reason, the shadow copy LUN must use the same quality of storage as the original production LUN to ensure that performance is not impacted after the recovery operation. If LUN resynchronization is used instead, the hardware provider can maintain the shadow copy on storage that is less expensive than production-quality storage.
If the destination LUN is unusable and needs to be recreated, LUN swapping may be more economical because it doesn’t require a destination LUN.

Restoring individual files (Shadow Copies for Shared Folders)

Shadow Copies for Shared Folders uses the Volume Shadow Copy Service to provide point-in-time copies of files that are located on a shared network resource, such as a file server. With Shadow Copies for Shared Folders, users can quickly recover deleted or changed files that are stored on the network. Because they can do so without administrator assistance, Shadow Copies for Shared Folders can increase productivity and reduce administrative costs.

Data mining by using transportable shadow copies

With a hardware provider that is designed for use with the Volume Shadow Copy Service, you can create transportable shadow copies that can be imported onto servers within the same subsystem (for example, a SAN). These shadow copies can be used to seed a production or test installation with read-only data for data mining.

With the Volume Shadow Copy Service and a storage array with a hardware provider that is designed for use with the Volume Shadow Copy Service, it is possible to create a shadow copy of the source data volume on one server, and then import the shadow copy onto another server (or back to the same server). This process is accomplished in a few minutes, regardless of the size of the data. The transport process is accomplished through a series of steps that use a shadow copy requester (a storage-management application) that supports transportable shadow copies.

How Volume Shadow Copy Service Works in NAKIVO’s Solution

We have explored how VSS works in general. Now let’s look at how the VSS technology works when creating VMware vSphere VM backups with dedicated backup software like NAKIVO Backup & Replication.

In a nutshell, the Volume Shadow Copy Service works as follows: The requestor initiates the VSS provider. The provider redirects the writers to write data into a log file and starts creating the volume snapshot. After the requestor sends the stop signal to the provider (usually after the snapshot is ready), it begins moving data from the log file to the volume.

In this case, NAKIVO Backup & Replication becomes a VSS requestor when backing up a VMware vSphere VM using VSS.

Before the VM backup starts, the NAKIVO solution writes data via its VSS writer.

As the backup starts, NAKIVO Backup & Replication requests the VSS provider to start working. The writer redirects data into the log file while the volume “freezes”.

NAKIVO Backup & Replication starts creating a snapshot on the VM layer. It might take anywhere from a few seconds to several minutes, depending on the VMFS storage load. During this time, the writer continues writing data to the log file.
A snapshot of the VM was created successfully. NAKIVO Backup & Replication, as the requestor, sends the signal to the provider to stop working.

The VSS Provider moves changes from the log file to the volume. NAKIVO Backup & Replication copies the data block of the VM snapshot to the backup repository.

You can configure the application-aware mode for backup data consistency in the wizard at the Options step. This way you enable VSS in a machine running Windows for backing up of this machine.