|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
How does it work ?
https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service
Desktop Asus TUF X299 Mark 1, CPU: Intel Core i7-7820X Skylake-X 8-Core 3.6 GHz, RAM: 32GB, GPU: Nvidia GTX 1050 Ti 4GB. Display: Four 27" 1080p screens 2 over 2 quad.
It amounts to something like this.
When you begin the backup, the backup program tells the shadow service that it requires a snapshot of the disks that are to be backed up, so that it can work from a non-changing system. The shadow service begins the snapshot at that point, so that for the remainder of the backup, the volumes (logical drives) that are to be backed up will remain in the current state as of that moment. From then on, all writes that are made by the OS or any applications writing to a snapshotted volume (any of them that are to be backed up) are not actually written to the disk (or “disk” in the case of an SSD, since there is no actual disk) normally, but are instead written to a “shadow” snapshot cache that records what the change is and where it goes on the disk. The snapshot cache itself is hidden from applications, including the backup program, which sees the place where the snapshot cache actually resides as blank. If the system contains a decent amount of unused RAM, the cache might also use that, though I am not sure of the specifics.
When the OS or an application reads from the snapshotted volume(s), the read commands are redirected to look for the data from the cache, and if some or all of the data it is trying to read is not there, the shadow service will grab that data from the disk itself and use it to fill in the blanks. This happens behind the scenes, with the shadow service handling the mechanics, and the higher level OS functions and applications not needing to be aware of it.
The system continues doing this for as long as the backup program requires. When the backup program tells the shadow service that it has completed its operation, the shadow service will then commit the changes in the snapshot cache to the disk (write the changes to the locations they were originally meant to go) and release the snapshot fully, returning operations to normal. Once the shadow service confirms that the cached data have been written successfully, the snapshot cache is deleted and turned into the blank space it seemed to be before.
One implication of how this works is that if you make changes to the system after you have started the backup, those changes will not be part of the backup, ad if you were to restore that backup, it would be in the same state that it was when you started the backup, not when you finished the backup.
It’s a good idea not to make any big changes (software installations, updates, stuff like that) when the backup is taking place. All of these changes will go straight to the snapshot cache. If the data written to the cache fills it up before the operation is complete, the shadow service will immediately commit the changes to the disk and inform the backup program that it has done this (in order to protect the integrity of the user’s data), and the backup operation will fail. The cache is of a variable size, but I think it has an upper bound somewhere, by default at least.
This is also the way that the backup program I use in Linux (Veeam Agent for Linux) works. Veeam has a small upper bound for the cache size by default, so it is very easy to fill it up and have the backup fail with a “snapshot overflow” error. I changed the upper bound to be considerably larger, and the problem has not come back.
Some backup programs in Windows have their own implementation of a snapshot system that does the same thing, but does not use the Windows shadow copy service. I am not sure what benefit this is meant to provide, since the Windows service performs quite well. I do remember seeing a backup program that gave the user the choice of Windows VSS or its own version, but I do not remember what program that was.
I may have gotten the exact terminology or the specifics of how it works a bit wrong here, but the general gist of how it works hopefully is more understandable now.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
“Safe” rather than “more safe”. There is always room for errors no matter what you do in computing. 
cheers, Paul
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
Notifications
