Well, a developer for Ghost would need to look at this forum to initiate anything more than I can offer.
I can only offer troubleshooting/narrowing down help, since I have no intimate knowledge of the product.
Do any of you have a common spyware/virus app running?
NIS, NAV, N360, 3rd party apps?
If you enable date created, date modified, and date accessed details to file/folder options and apply to all folders, are all of the date modifieds the same (indicating that something is touching the files) ?
Edit:
This will slow down you folder browsing, so remember to undo it after testing.
Message Edited by Dave_Hauser on 07-15-2008 06:39 PM
1 Like
Results of further research into the function of the file VSNAP.IDX as it relates to this problem.
It appears that the file VSNAP.IDX is used by Norton Ghost uses to track changes to disk drive content. This file is updated just prior to halting the processor at shutdown. If the hardware was a bit premature in killing the power this would be a potential hazard.
To find out whether or not flushing takes place, I examine the modification date of each copy of VSNAP.IDX on the system. This is a hidden, system file in the root of each disk being backed up. This file is not created until an incremental backup is defined for the drive and then only at the following system shutdown. Thereafter it is modified at each shutdown. Comparing the modification times with the time of the previous shutdown shows whether or not the files were updated at that time. If the time on the file is earlier (usually for an earlier shutdown) then you can be sure that on the next incremental backup for that drive, volume reconciliation will occur and a larger than expected incremental image will result.
I recently took to using the front panel button on my desktop PC to intitiate shutdown. This might be the cause of the hazard and I have now reverted to using the "soft" shutdown exclusively. Since doing that no ocurrence of a failure to update VSNAP.IDX has been observed and this problem has not occurred again. I am going to continue to use the "soft" shutdown option from the OS and monitor VSNAP.IDX after every system startup to be more confident of my findings.
VSNAP.IDX is also modified whenever Chkdsk is run on the associated disk drive. I thought that this might also trigger the problem. However, I found that Norton Ghost 14.0 is unaffected by this in two cases out of three. The third case was observed after repairs were made to the system disk by Chkdsk during a reboot. In this case volume reconciliation took place followed by generation of a large incremental image, about 50% of full size. This must be because it was done outside normal OS operation, Norton Ghost being unable to track this process.
File backup is independent of all this. It just produces .fbf files in subfolders of a subfolder named "File Backup Data" in the directory you nominate for file backup. The nice thing about it is that you have access to multiple versions of the same file.
1 Like
RobertJ.
Disable your NTBackup system state job for a while and then let the incrementals run. That'll be the cause.
Ell.
Thanks for the tip, Ell. I'll try that if it happens again. I've had no more unexpectedly large incremental backups since my last post.
JR.
Robertj: Any news to report?
I'm seeing the same symptoms and can't believe that I'm modifying that much data. I've always used the os supplied methods to shutdown gracefully and have noticed that VSNAP.IDX doesnt get updated at each shutdown. By the time the os signals the hardware to power-down, one would think that by then, all file buffers should have been flushed to disk.
Good news and bad news.
I used "Process Monitor" (sysinternals) to look at this. This showed me that the operations on VSNAP.IDX all took place within the last second before power to the system was cut. My guess (and it is only a guess) is that it is something to do with how ACPI (Advanced Configuration and Power Interface) is implemented in the BIOS and hardware. I think in my case power was being cut before the write operation to the disk drives was complete. I've had no problems (good news) with large incremental backups since I stopped using the front panel button to initiate shutdown. My conclusion (bad news) is that this problem is hardware related, so I can't vouch for any hardware other than my own.
I'm continuing to monitor this...
I find that this problem is not solely attributable to the failure to update VSNAP.IDX.
In an attempt to correct a scheduling anomaly with drive backup of C: I deleted all its associated recovery points, schedules and history. After doing this I generated a base recovery point for C:. The next time the backups for D: and L: ran, volume reconciliation took place with the generation of a large incremental point for D:. I cancelled the backup of L: and forced generation of a base recovery point (much faster). This occurred even though VSNAP.IDX was up-to-date. One can only conclude that there are other factors causing this problem, among them my deletion of the history for C: drive.
My remedy as suggested in a previous post serves only to reduce the incidence of this situation in my particular case. In the absence of expert advice from Symantec, I can't say what else causes this problem, just this one of failure to update VSNAP.IDX.
Have you tried a controlled test of your theory that the deletion of the history causes a large incremental backup? I’ve had the same suspicion, but I’ve not had the time to test it yet.
I haven’t tried such a test. I have deleted the history twice now. In the latter case I deleted the history for one drive only. In both cases I established new schedules after deleting the old ones. My suspicion is that history deletion is more likely to lead to generation of a base recovery point, but I can’t justify this. My observations so far suggest no correlation between the history deletion and unusually large incremental backup.
Are you distinguishing between a large incremental backup and a base image by the file extension?
Yes. The incremental backup images have extension "iv2i" and the base images have extension "v2i".
Incidentally I found some of my old backup history in some copies of earlier backups on DVD. I found that when support deleted all my history (see earlier post) my scheduled backup produced a base image instead of an incremental. However, I deleted the history for one drive a couple of days ago and established a new schedule for that drive, leaving the schedules for the other drives intact. That gave me volume reconciliation and a large incremental image for each of the other drives. So, I don't think that there is any correlation between history deletion and incremental backup image size.
Possible causes for large incremental backups:
1) System state backup - NTBackup/Backup Exec etc.
2) Drive defrag.
3) BESR/Ghost service interruption....sometimes....
4) Antivirus/Antispyware scan.
Basically anything that kicks off in between jobs and references many files during its run. There's a threshold for the amount of files that needs to be changed for Ghost/BESR to decide that a baseline backup is required as opposed to an incremental. It seems that this threshold has been reduced as of late, hence the issues you're having. Symantec will only get you to delete the history and journal files when you experience schedule cockups....or to get you off the phone. Symantec are useless as resolving issues. It's always the contributers in the forums that figure out how their product works....or doesn't as is usually the case.
robertj wrote:
Yes. The incremental backup images have extension "iv2i" and the base images have extension "v2i".
OK. I've been having a problem on my Ghost 12 http://community.norton.com/norton/board/message?board.id=other&thread.id=2720 that I thought might be related to yours, but now I see it is not. Mine is creating new base images when it should be doing incremental.
Back to your problem. Have you tried scheduling the incremental image to run, say every 5 or 10 minutes, and just make a change to a single file in between incrementals? It will take some time and energy, but if it does create the large incremental, then take a look at the Windows Event Viewer for that time interval and see if something occurred to trigger it.
Message Edited by Vincenzo on 07-28-2008 08:53 AM
Now that I think about it, you can probably do not need to change a file in between incrementals, the test should still be valid even if there are no changed files.
There's another symptom that seems to coincide with the large incrementals (have you seen this too?)......
If you open the "Progress and Performance" window, does it show: "Reconciling volume" for a very long time? In my case, Ghost spends about 50% of the total elapsed time in this phase before the actual backup starts.
Per chance, I stumbled unto the following knowledge base article that also refers to VSNAP.IDX
http://service1.symantec.com/SUPPORT/powerquest.nsf/0/3b710b693a1ef4a2ca256fe0007ab029?OpenDocument&seg=hm&lg=en&ct=us
Its labeled for an older version of Ghost but this might be worth a try.
I've seen this article before. I tried deleting VSNAP.IDX on one of my data volumes to no avail. The next incremental backup of the volume proceeded with volume reconciliation and a large incremental image. That's what prompted me to have a closer look at VSNAP.IDX.
I can confirm what you see in the "Progress and Performance" window. It sits there for about 40% of the elapsed time saying it is 1% complete. Then it goes into the actual backup, producing an incremental image (iv2i) the size of a base image (v2i).
e-charge wrote:
Possible causes for large incremental backups:
1) System state backup - NTBackup/Backup Exec etc.
2) Drive defrag.
3) BESR/Ghost service interruption....sometimes....
4) Antivirus/Antispyware scan.
Basically anything that kicks off in between jobs and references many files during its run. There's a threshold for the amount of files that needs to be changed for Ghost/BESR to decide that a baseline backup is required as opposed to an incremental. It seems that this threshold has been reduced as of late, hence the issues you're having. Symantec will only get you to delete the history and journal files when you experience schedule cockups....or to get you off the phone. Symantec are useless as resolving issues. It's always the contributers in the forums that figure out how their product works....or doesn't as is usually the case.
I don't think that anything that references many files is going to affect Ghost as it is sector-based. It's just doing a physical copy of allocated sectors on the drive. Defraggers will certainly affect it, but something that changes timestamps won't in my view; it'll only affect the sector in which the timestamp is stored. I've tested this by renaming a large file. NtBackup copies the whole thing (the archive bit is set), but the corresponding Ghost image is miniscule.
Vincenzo wrote:
Now that I think about it, you can probably do not need to change a file in between incrementals, the test should still be valid even if there are no changed files.
I did two incremental backups two minutes apart without incident. I followed this up some time later (45 minutes) with 10 incremental backups in 20 minutes. Nothing of unexpected size. The images for which no changes were recorded all came in at 512 KB (524,288 bytes). Where I made changes the image size was as expected.
The day after my last post on 07-29-2008 at 06:35 PM a small image was generated as expected. The day after that (two days after my last post) the fault occurred again. VSNAP.IDX was OK, so I searched the event log in vain for anything that might have triggered it. I can only say now that the failure to update VSNAP.IDX is but one cause of this problem.
I still suspect that the fault is hardware-related. Do all Ghost/BESR/NSR users see it? I don't think so.
When it occurs like this (without evident cause), it doesn't happen to my system drive (primary partition on a SATA-connected drive). It only occurs on my data drives (IDE connected via a RAID controller). Both controllers are on the main-board.
I'm going start backing up another SATA-connected drive to see if the fault occurs with that...
10 Likes
So what kicked off on your machine during that one day period? Reboot?..service hump?..full moon?