02-27-2011 04:15 PM
With Ghost 14, I'm trying to create a new recovery point set for my P: drive. However, the option is grayed out and I have the message "The recovery point set option is disabled because you have already assigned a selected drive to an existing recovery point set backup job. you can only have one recovery point set defined for each drive."
This P: drive is the same partition that used to have a different drive letter and different volume name. I removed the job for that archaic volume name from within the Run or Manage Backups window. I also deleted all the backup files from within the Manage Backup Destination window.
Evidently, this wasn't enough.
I searched C:\Documents and Settings\All Users\Application Data\Symantec\Norton Ghost .pqh files having the archaic volume name. I found one that could have been second generation archaic. That is, a name prior to the most recent prior name. I hid that file by renaming X.pqh to ---X.pqh---. This was still not enough.
I also rebooted once or twice between steps.
How do I make this sucker forget about the old backup job, WITHOUT having to uninstall and reinstall Ghost, and set up all my many complicated backup jobs again?
02-27-2011 05:21 PM - edited 02-27-2011 05:28 PM
You were close. Try stopping the Norton Ghost service in services.msc before nuking the .pqh file. I think you will have to nuke the .pqj file too.
02-28-2011 05:39 AM
I don't follow, exactly. I did a reboot, which should have stopped and restarted the Norton Ghost service. Are you saying that the service is tracking my rename and still able to find the file? Why would I need to stop the service BEFORE nuking the .pqh file?
Also, I've looked through the .pqj files, and they agree in count and content with the jobs I see within Ghost. And none of these refer to the volume (partition) in question.
The machine is busy right now, so I can't try some of these things. I copied my volume content somewhere else, deleted the partition, created the partition again, and am currently formatting it. After that, I'll try Ghost directly again, to see if I shook the bulldog's grip on the volume lose yet. If not, I'll try to follow through with stopping the service, not simply renaming but copying to backup then deleting the specific .pqh file. If that doesn't work, I might backup then delete ALL the .pqh and .pqj files to see if it will shake lose. Then, hopefully, I'll be able to copy some of these files back to recover my many complicated jobs.
02-28-2011 06:27 AM
redk9258, I indeed thank you for helping, but in a friendly and humerous manner I reply, the comment about changing the oil with the engine running really doesn't help at all. I can change the brake lights, even transmission fluid on a manual, and many other things while the engine is running on my car. This relates back to wondering if the service tracks the filename changes.
Anyway, I might have the problem resolved. First, deleting and recreating the partition didn't help. I then stopped the service, copied all the files in C:\Documents and Settings\All Users\Application Data\Symantec\Norton Ghost elsewhere as backup, deleted ALL the files under History and Schedule. Started the service. Ran Ghost. Cancelled the automatic first-time backup setup. Created a recovery point for my partition in question, and it let me do a new recovery point set. I then exited Ghost and stopped the service again. I then copied most of the saved files back to where they came from. Started the service again. Ran Ghost again. I can now see from within Ghost all my old plus one new job. I can also see the history of when those jobs backed up, and when all will occur in the future.
One exception. When copying the history back, there was one filename collision, for which I did NOT overwrite. This means that when I ran Ghost having an empty History folder, it created a new filename. I believe this file related to my new job, and I believe I recall looking inside and seeing my volume name. Meanwhile, the backup version with the same name contained a volume name corresponding to my boot volume (which is on the same physical disk as my new volume in question).
One of two things has happened. Perhaps this .pqh filename collision points out the fact that I had not successfully removed the offensive .pqh file before. That is, while I had identified two other .pqh files that might be causing Ghost to remember my volume and refuse to allow me to create a new recover point set job, this may have been the actual one causing the trouble. Due to the content not appearing as I expected, I didn't find it and didn't nuke it. I am NOT going to go back and reproduce the situation, to confirm this, because I need to move on to my actual work needs.
Alternatively, this filename collision is a red herring. This would mean there's still something magical (technology sufficiently advanced being indestinguishable from magic and all that) about stopping the service first, rather than merely rebooting after running the engine with no oil for a moment. This would also mean that the .pqh filename creation is neither a unique process nor specifically tied into the volume properties -- which I doubt.
Therefore, I really suspect that the first situation is the case, and I didn't really need to stop the service, but just nuke the correct .pqh file. This doesn't mean that stopping the service wasn't a good idea.
So, hopefully there backups will actually OCCUR, and I don't have some other magical setting messed up. I'll find out soon enough.
In the mean time, I sincerely thank you, redk9258, for your help. You led me to a solution.
02-28-2011 06:57 AM
I'm surprised that Ghost doesn't lock those files with the Ghost service running. Maybe the contents of those files were in memory while the Ghost service was running and were rewritten after you deleted them. I'm not sure. I just remember reading a post that suggested stopping the Ghost service before removing those files.