Forum Discussion

Pamela_S1's avatar
Pamela_S1
Level 3
12 years ago

VSS & Snapshots on virtual clients with Hyper-V on CSV

Hi everyone, I need a better understanding on snapshots and writers on a Hyper-V backup scenario (CSV with 4 nodes - single policy). As far as i know. Netbackup is installed on the Hyper-V Hos...
7.5
Agent for Microsoft Hyper-V
Agents
Backup and Recovery
NetBackup
  • RLeon's avatar
    RLeon
    12 years ago

    Whether or not it is a VM, for a Windows OS it is normal and quite typical to set at least 10% or more free space on each volume for VSS snapshot operations. (You don't just set it, the free space has to be there too.)

    Having said that, when your policy type is "Hyper-V" and you encounter 156, it is referring to the Hyper-V host, so you troubleshoot on the Hyper-V host level.
    For other policy types such as "MS-Windows" where you are backing from from inside the VM the traditional way using the Nbu client, a 156 in this case refers to the VM, so you troubleshoot from inside the guest OS.
    If you use a Nbu client to backup from inside the VM, effectively you can pretty much take the whole Hyper-V thing out of the picture and just treat it as a physical server backup, and troubleshoot as such.

    Even if you are backing up the VM at the Hyper-V level, for the guest OS you should not disable the VSS snapshot space altogether (or give it very little volume space, like 1%).
    The reason for this is that the VSS provider inside the guest OS is also called during the process. It needs space to create snapshots too, but just long enough for the Hyper-V host's VSS provider to finish creating its, which is a very shot time.
    So short, in fact, changed blocks (if any) would not have enough time to really fill up the VSS space inside the guest OS, before it is deleted.
    (I know this contradicts with what I said earlier about not having snapshots inside the VMs, but digging deeper now.)

    A very good diagram here that explains this process from a source which should not be named, but applicable to NetBackup's and Backup Exec's Hyper-V level backups just the same, nonetheless.

    In short, have space for VSS snapshots on the Hyper-V host, and have space for VSS snapshots inside each VM, and you should have a lot less 156 problems.

     

    Since we are digging deeper, I should add that when I said:

    This snapshot is stored somewhere on the Hyper-V host

    It is also not always true. An exception to this is when you use alternate client offhost SAN volume level snapshot backups (redirect/copy-on-write or split-mirror type snapshots), using special VSS providers from the SAN vendor on the Hyper-V host, the snapshot is not stored on the Hyper-V host, but in the SAN and gets mounted by the alternate client (usually a Nbu media server) for offhost backups.

    Also, when you refer to the diagram linked, you will see that the VSS writers on the Hyper-V host is also called to quiesce the .vhd files, which they then, in turn, call the VSS writers inside the guest OSes (through the Hyper-V Integration Services)... Then, you know the rest. I wrote something about snapshots in general, it's long and crudely written, so only if interested.

RLeon's avatar
RLeon
Level 6
12 years ago

Whether or not it is a VM, for a Windows OS it is normal and quite typical to set at least 10% or more free space on each volume for VSS snapshot operations. (You don't just set it, the free space has to be there too.)

Having said that, when your policy type is "Hyper-V" and you encounter 156, it is referring to the Hyper-V host, so you troubleshoot on the Hyper-V host level.
For other policy types such as "MS-Windows" where you are backing from from inside the VM the traditional way using the Nbu client, a 156 in this case refers to the VM, so you troubleshoot from inside the guest OS.
If you use a Nbu client to backup from inside the VM, effectively you can pretty much take the whole Hyper-V thing out of the picture and just treat it as a physical server backup, and troubleshoot as such.

Even if you are backing up the VM at the Hyper-V level, for the guest OS you should not disable the VSS snapshot space altogether (or give it very little volume space, like 1%).
The reason for this is that the VSS provider inside the guest OS is also called during the process. It needs space to create snapshots too, but just long enough for the Hyper-V host's VSS provider to finish creating its, which is a very shot time.
So short, in fact, changed blocks (if any) would not have enough time to really fill up the VSS space inside the guest OS, before it is deleted.
(I know this contradicts with what I said earlier about not having snapshots inside the VMs, but digging deeper now.)

A very good diagram here that explains this process from a source which should not be named, but applicable to NetBackup's and Backup Exec's Hyper-V level backups just the same, nonetheless.

In short, have space for VSS snapshots on the Hyper-V host, and have space for VSS snapshots inside each VM, and you should have a lot less 156 problems.

 

Since we are digging deeper, I should add that when I said:

This snapshot is stored somewhere on the Hyper-V host

It is also not always true. An exception to this is when you use alternate client offhost SAN volume level snapshot backups (redirect/copy-on-write or split-mirror type snapshots), using special VSS providers from the SAN vendor on the Hyper-V host, the snapshot is not stored on the Hyper-V host, but in the SAN and gets mounted by the alternate client (usually a Nbu media server) for offhost backups.

Also, when you refer to the diagram linked, you will see that the VSS writers on the Hyper-V host is also called to quiesce the .vhd files, which they then, in turn, call the VSS writers inside the guest OSes (through the Hyper-V Integration Services)... Then, you know the rest. I wrote something about snapshots in general, it's long and crudely written, so only if interested.