|
Group: Forum Members
Posts: 3.6K,
Visits: 27K
|
Yes, VSS was developed by Microsoft and is therefore only available in Windows -- but not only is there no VSS in Linux, there isn't a full equivalent to it either. I'm not sure why that is. System Restore does indeed rely on VSS snapshots, but the use cases for VSS snapshots extend far beyond that. Windows Server versions (and the client version of Windows 7) use VSS snapshots to enable a Previous Versions / Shadow Copies function that allows you to retrieve previous versions of files that are maintained thanks to VSS snapshots. And then VSS not only takes snapshots of volumes but coordinates with applications before doing so, it can enable reliable backups even of files (and in the case of Hyper-V hosts, entire VMs) that are open and running during the backup, without risk of capturing the data in an inconsistent and therefore corrupted state. I wrote a PM to someone explaining in a medium level of detail how VSS works and is able to guarantee capture of data in a consistent state in scenarios like this if you're curious:
- An application like Reflect requests a VSS snapshot.
- Windows notifies all applications that have registered themselves as VSS-aware that a snapshot has been requested. They start queueing new writes intended for the disk to memory instead, and then their VSS writers do whatever they're programmed to do in order to get the data that's actually on disk into a consistent state. This might include committing certain data currently in memory to disk and sometimes even deleting data. Windows Search deletes its own index database in VSS snapshots, for example, because it can grow quite large and can be recreated automatically if it's lost anyway. Hyper-V either tells its running guest VMs to perform their own VSS snapshots so they get their own VMDKs into a consistent state, or for guests that don't support that, it briefly pauses the VM and captures an "application-consistent" snapshot, which includes the contents of the VM's memory space (which can take a while to create). This is why you can run a backup of a Hyper-V host and guarantee consistent data backups even of running VMs.
- When the each writer has got its data tidied up on disk, it notifies Windows that it's ready for a snapshot to be taken. When all registered VSS writers have confirmed they're ready for a snapshot, Windows takes the snapshot. It then notifies VSS-aware applications that they can start writing to disk again rather than queueing in memory (and that Hyper-V can resume any paused VMs), and finally notifies the original requesting application (like Reflect) that the snapshot is ready for use.
In terms of how new data is written afterward, it doesn't get redirected to a delta file anywhere. Instead, for any write that will modify existing data, the current data on disk is copied to the snapshot area before the new write is committed -- hence the term "copy-on-write". As a result, a VSS snapshot isn't created as a fixed entity at the time of the original capture; it's actually a living entity that grows after it's established -- until the next VSS snapshot occurs, whenever that is. Because of this design, and the fact that the amount of space allocated to storing VSS snapshots is limited (by default it's 10% of the volume size), if you have an application like Reflect that's trying to read from the snapshot, and you also had a ton of write activity going on while the backup was running, it's possible that that single snapshot could exceed the entire allocated storage area, even after purging older snapshots. If that happens, Windows will delete the VSS snapshot, and the Reflect would fail with an error explaining that. But the advantage of this design is that you don't have to redirect writes to deltas anywhere and commit them later; you instead just archive the current data before you modify it. It's weird to think that Reflect can capture a consistent backup by working from a snapshot that's evolving as Reflect is reading from it, but that's how VSS works.
|