Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Sed posuere consectetur est at lobortis. Vestibulum id ligula porta felis euismod semper. Donec ullamcorper nulla non metus auctor fringilla. Aenean lacinia bibendum nulla sed consectetur. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Cras mattis consectetur purus sit amet fermentum. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Sed posuere consectetur est at lobortis. Etiam porta sem malesuada magna mollis euismod. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Curabitur blandit tempus porttitor. Sed posuere consectetur est at lobortis.
It also takes even longer than a full backup. My stance is to ditch any incremental backup and just do a full backup every time. I can’t see what an incremental buys me other than just a little disk space at the expense of additional time.
Thanks, but it's actually costing me disk space. I get an incremental the size of a baseline. I am considering returning to Norton Ghost 9.0, which never produced such large incrementals, just unscheduled baselines. They didn't take as long (as you note) and what's more the oldest baseline was deleted, so less disk space was used.
I would first recommend contacting our Customer Support team by visiting the below site to contact our free Customer Support:
http://www.symantec.com/norton/support/selectproduct_ts.jsp
If you have already done this and they could not resolve your issue, please let us know. What is the schedule for your Baseline image to be created? How many incrementals are supposed to be created before a baseline, and what are your settings for consolidating the incremental images? Any additional information you can provide is appreciated. Thanks!
Thanks. Contacting support…
I am experiencing this problem and would like to know if it has been or when it will be fixed. I am, for unexplained reasons, unable to send an e-mail to Tech Support and I am hesitant to initiate a Chat session because they always want to install their software, take over my computer and go through endless meaningless questions instead of just looking up the problem status in a tracking database and telling me the status.
Is there any way I can get the status of this prob;lem?
I contacted support regarding this problem on 1 July 2008 and continue to watch for its recurrence after their action.
The support person connected to my computer remotely. After looking at the status of Norton Ghost and questioning me about the problem he advised me to delete the History and define a new backup. There not being clear instruction in the user manual about this, I asked how. He simply said, "I will delete it." I now know that this means stopping the Norton Ghost service, deleting everything in folder "C:\Documents and Settings\All Users\Application Data\Symantec\Norton Ghost\History" and then restarting the Norton Ghost service. After he had done this, we concluded the session and I agreed to reply later with a status report.
I defined new scheduled backups for my data drives, leaving existing scheduled backups of C: untouched. Norton Ghost did a baseline backup of each drive on schedule as expected. Since that time incremental backups have been taken once daily without a recurrence of this problem.
However, a power blackout occurred on 7 July 2008. After this a backup of each drive involved a lengthy data capture stage of "volume reconciliation" followed by volume copying and verification. For each of my two data drives , the entire volume was copied, while about 80% of my system drive C: was copied. (Not unexpected after the power failure and not a repetition of the problem as reported.) In all cases an incremental image file (.iv2i) was produced. A subsequent incremental backup of each drive has produced small incremental images as expected. I intend monitoring backup activity for the next few days before concluding that the problem (as reported) is actually fixed.
So, in conclusion, the short answer to this problem seems to be to delete everything in the History folder and define scheduled backups anew. The implication is also that one should delete scheduled backups before defining the new ones. However, in the case of C: drive I have not done this, so I might be wrong on this last point.
I spoke too soon. The day after my last post, the problem occurred again. This time, I had a look at the modification date of the file VSNAP.IDX on each volume. The modification date for this file is usually the same as the last shutdown time. However, this time it was not. The date for C: drive was correct, but the date for my data drives was not. The date recorded there was the previous shutdown time.
I deleted VSNAP.IDX on one of my data volumes to no avail. My response to that was to force a base backup of the volume.
So, this problem is not fixed, because Norton Ghost is not always updating VSNAP.IDX on all volumes at shutdown. Strangely C: drive doesn't seem to be affected.
It is occuring on my C: drive (sys+data) and my D: drive (HP recovery partition) so there's nothing magic about the C: drive.
May I assume Support is working the problem? How may we find out if it has been fixed?
If it behaves differently on different computers then it may be hardware-related. I don’t know what Support could do about this. As to finding out, we’d need some advice from a Symantec employee.
Hello. I am quite interested in this topic. I have also experienced very large incremental backups, 20Gb, comparable to the initial recovery point. Target disk is USB, direct connect, no errors reported. I want to run incrementals every day, and clearly a 20Gb incremental b/u, taking 4 hours, is unreasonable. Almost all of the incremental data is static - music files, old documents, system files - that does not change often. Online support was not useful. I spent 4 hours w/ tech support chat yesterday, The tech created a new backup job with the recovery set option selected. I noted that the file extension for the job was .v2i, even though we asked for a new set (which should have created an .iv2i. Right after the set was completed I ran a file and folders backup against the same disk and got an incremental backup of 20Gb. \ Why would an incremental set run right after a recovery set be the same size? The tech was at a loss. Today I deleted all old recovery points, cleared the target disk, deleted all Ghost jobs, stopped the service, deleted the catalog, rebooted. Same thing - file extension of .v2i, large incremental right after the disk backup. Any ideas? Thanks Eliot Rich
I think I found the answer. More knowledgeable folk, please correct if I am wrong.
Disk recovery and file recovery are fundamentally different and INDEPENDENT. The independence is what confused me.
Initial disk recovery points have an extension of .v2i. Subsequent disk recovery points are incremental to the initial, and have an extension of .iv2i. I assume that when a new baseline is created, a new .v2i is created.
It appears that the File Folder backup option operates independently of the disk recovery point. The "File Folder" backup does not use the .v2i files as a baseline. It does not matter when the disk recovery runs or what it contains. The File Folder backup tracks its
Thus, it's not surprising that the File Folder backup (what I incorrectly thought was an incremental copy to the Recovery point) is quite large. It's redundant, as it treats files as separate entities.
This analysis is consistent with my observations, but I might well be missing something.
That doesn’t explain it for me. I don’t use File and Folder backups. I only use Disk Recovery backups (new base Recovery Point every 3 days, and incrementals every night in between).
The definitions of full and incremental backups are pretty straightforward. If a full backs up everything, and an incremental backs up only those files which have changed, the incremental should always be smaller than the full unless every file changed or enough files were added to make the changed files larger than the original full. Even if large files were added they would only affect the size of the next incremental.
Since my full (v2i) (one example) is 7 gig, and my incrementals (iv2i) are 512K, 512K, 768K, 512K, 7 gig(256K more than the full), 512K, and I did not add 7 gig of files one day, Ghost 14 is determining that (probably) every file on the drive has changed.
Since I know that every file did not change, I think I can fairly safely assume that there is a BUG in Ghost 14 and it should be escalated to the developers to fix.
It would certainly behoove Symantec Support to do that and to post to this thread when a resolution is developed and scheduled for implementation.
Thanks.
Hello.
It does sound suspicious - can you confirm that there were no disk-wide operations - defrag, etc - that might have moved sectors around?
Eliot
Certainly not initiated by me.
Carl
I definitely did not manually initiate a defrag, and I do not have any automated defrag utilities that run.
Disclaimer:
I am not now, nor have I ever worked on, the Ghost products. Nor do I use the gui based Ghost product.
Having stated that, my first impression after reading this thread is that something may be touching all of the files on you drive (as carlage) pointed out.
So, do any of the following apply to any of you?
1. Have you run a defrag program?
2. Have you run a spyware scan of any kind?
3. Have you run a virus scan of any kind?
If you have run or scheduled any of the above, do the run/schedule times correspond to the full backups?
IE: If you had run or a schedule ran the above at 7-11-2008, and your next incrememntal backup was at 7-12-2008, and that 7-12-2008 backup produced a full backup.
Defragging will touch almost every file on a drive, and copy/replace the file when it is moved, thus simulating a 'new' file (by timestamp).
Spyware and virus scanners 'may' (Disclaimer on any knowledge of these also) also work in this way, although only the modified attribute should be changed.
I hope this gets the attention of an experienced Norton staffer ...
I think we have established that defrag is not the culprit, and if virus scanning is modifying files something seems very wrong with that.
What should it take to get a developer to look at what's presented here and give an answer?
It's either a bug or a feature.