|27 Sep 2012||#11|
| || |
But my problem diagnosis and speculation is made all that much more difficult because there are NO ENTRIES IN THE Windows 7 EVENT LOG INDICATING ANY PROBLEM WHATSOEVER!
If I had an event code with an ID, that would be helpful. But all I have is VSSADMIN LIST WRITERS showing most of the writers "timed out", to support NovaBackup's mention that "VSS failed".
Again, in contrast there is ZERO such nonsense from Macrium Reflect's use of VSS, which appears to still be working perfectly.
I'm just going to turn off VSS in my NovaBackup jobs. They start faster, and no files other than those 30 or so Microsoft Security Essentials and EHOME files on C which have been producing "client file is busy". So I'll also un-check those files (or parent folders), as I have no interest in backing them up anyway... since I use Macrium Reflect's system image (taken weekly) as my true recovery from a genuine Windows 7 C-partition disaster.
No other files off of C (on my other normal "data" backups using NovaBackup) have ever been involved with "client file is busy". So turning VSS off for those other partitions will have nothing but positive beneficial speeding-up effect on the backup for that partition.
I'm giving up.
|My System Specs|
|05 Nov 2012||#12|
| || |
Apparently, the problem was insufficient space on one drive!
Well, I do believe I have now resolved my VSS failure problem.
Because of a motherboard that died on one of my two machines, I was forced to rebuild that machine entirely. This included a new motherboard, CPU and memory, and a fresh install of Windows.
Because the new machine was "bigger and stronger" than my other still operating machine which was currently in use as my HTPC and primary work computer, I decided to swap the "bodies" of the two machines... i.e. reverse the physical locations of the two machines, double-transplanting the two "brains" into the opposite location cases while leaving the two "bodies" at the original locations.
Because the HTPC machine "brain" had a large number of copy-protected WTV recordings on its hard drives, I had to bring the existing C-drive and installed Windows 7 along with its hard drives containing recordings to the other location where I would then be able to continue WMC playback of those copy-once recordings using WMC on that machine. In the meantime, the newly built and installed HTPC would inherit all of the copy-freely recordings from the old HTPC, as well as start all over with a whole new set of copy-protected content.
Anyway, in the process I once again used NovaBackup extensively, including creating a whole new set of initial backups taken after the new machine was finally completely constructed and installed.
And imagine my surprise when VSS again failed (but only intermittently), even on this brand new system!
However it did give me an opportunity to pause and examine things, and finally understand what was causing the problem:
I had insufficient "free space" on one of my partitions for the shadow copy to be takenThat's all it was! One of my small partitions (J, about 4GB) had been loaded full of data, so that there was maybe only 100MB left of free space. And in fact it was THIS partition which was causing my "daily incremental" backup's VSS usage to fail, since J was part of the partitions scanned by the backup.
In fact, even the standalone [monthly] FULL backup of J failed its VSS usage, which is what really tipped me off as to what was the very likely cause of the VSS failure on my "daily incremental" backup covering all my partitions.
So I experimented by removing J from the "daily incremental" definition, and sure enough the "daily incremental" backup's VSS usage NOW WORKED AGAIN! Put J back in the backup job definition, and VSS usage NOW FAILED AGAIN!
Ok. The solution was now easy. Just enlarge the J partition (by a few GB probably would have been enough, but I just doubled it in size as it was small to begin with)! Now I had about 4GB free space on that partition, and VSS now was able to run normally!
So, by increasing the free space on that one partition its FULL backup now runs with VSS working, and its participation in the daily INCREMENTAL backup now causes no problem and VSS also works.
Apparently, the space used for VSS shadow copies are on the partition itself... not in some other available place.
Now I'm not sure if this is available in Windows 7, but in Windows Server there is a "VSSADMIN ADD SHADOWSTORAGE" command whose purpose I believe is to define shadow storage for VSS that is on a different volume than the volume being shadowed:
vssadmin add shadowstorage /for=<ForVolumeSpec> /on=<OnVolumeSpec> [/maxsize=<MaxSizeSpec>]So perhaps theoretically if this also is available in Windows 7 I could have solved the "no free space on J" problem this way.
Anyway, doubling the size of J in order to add 4GB of free space is far simpler to understand, and that also solved the problem.
Apparently, this case is now closed.
|My System Specs|
|Similar help and support threads for2: Suddenly, VSS mis-behaving|
|Executables not behaving properly.||General Discussion|
|Olevia TV not behaving properly...||Graphic Cards|
|Behaving like key/button is stuck!||General Discussion|
|how to make WMC behaving as well as VLC||Media Center|
|Laptop behaving very strange||BSOD Help and Support|
|Recommended update not behaving||Windows Updates & Activation|
|MCE remote behaving strangely||Hardware & Devices|