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.
I'm rather curious why you are running this batch file. What is your reasoning for running this batch file? Ghost does some very good checking of the drive when it creates a backup.
Yes, you are right that it is the /x which is dismounting the drive. And by doing it this way you are forcing things and at best putting the data on the drive into a crash consistent state which is not the goal of a good backup. By doing it this way you are running a very good risk of corrupting data - data that the OS really doesn't know about that is being held by various applications in memory that have files open on the drive.
As for you assertion that this needs to be fixed in Ghost, I do not know what I should suggest to them to fix since a process other than Ghost dismounted the drive. Ghost would not have any idea of what handle to use to remount it. And it can't simply just start mounting things in hopes that it would get the right thing mounted in the right spot.
Johan_Jeffery wrote:I'm rather curious why you are running this batch file. What is your reasoning for running this batch file? Ghost does some very good checking of the drive when it creates a backup.
I didn't know that Norton Ghost does checking file system before backup. And what type of checking he does ? Does he fix a indexes and checking security descriptors ? Or Do I have some choice how enable this checkings ?
In doing some further digging, I find that I'm in error. The disk checks that Ghost does are only on the restore after it lays an image down to ensure that things were laid correctly.
But I also found out why your batch the batch is creating such problems. Ghost, when it starts, checks the mounted drives. Then it runs the batch file. So, it thinks that the drive is there and when it gets control back after running the batch file it is not - the unmounting that chkdsk does has cause the drive to disappear. There are two possible workarounds that the developers suggested to me. 1) run Check disk outside of Ghost on its own schedule or 2) in your batch file script it so that you always ensure that the drive mounted when the batch file ends. Other utilities, such as diskpart, have the ability to mount the drive.
>In doing some further digging, I find that I'm in error. The disk checks that Ghost does are only on the restore after it lays an image >down to ensure that things were laid correctly.
This I know after a backup is there posiibility "Verify check point after creation", but I was not misteken, before creation backup Norton Ghost didn't any checks of the backuped partition or disk.
>But I also found out why your batch the batch is creating such problems. Ghost, when it starts, checks the mounted drives. Then it >runs the batch file. So, it thinks that the drive is there and when it gets control back after running the batch file it is not - the unmounting >that chkdsk does has cause the drive to disappear.
Ok but we have found this out already.
>There are two possible workarounds that the developers suggested to me. 1) run Check disk outside of Ghost on its own schedule >or 2) in your batch file script it so that you always ensure that the drive mounted when the batch file ends. Other utilities, such as >diskpart, have the ability to mount the drive.
Great, this resolving my problem and it's some kind of a quick fix(I can use mountvol.exe too which is in the windows xp installation), but I'm suggesting third possibility how resolve this.
The Norton Ghost's programmer team could add this checks before backuping a partition or a disk to the Norton Ghost program, somewhere in creation dialogs or edit dialog of Backup Jobs(In Advanced - Backup Jobs - right click and Edit settings...).
Norton Ghost is great backup software but this is one of the two things that I lacking.
Thank for reaction.
I can certainly pass along the suggestion. However, I might point out that the intent of having the ability to run a command file at this point in the backup process was for people to be able to run utilities to quiese a database long enough for a snapshot to occur.
Also, the Verify Recovery Point After Creation is not a check on the file system. It is only a verification that the information contained in the .v2i is as it was received in the backup.
I have passed the suggestion to development.
Johan_Jeffery wrote:I can certainly pass along the suggestion. However, I might point out that the intent of having the ability to run a command file at this point in the backup process was for people to be able to run utilities to quiese a database long enough for a snapshot to occur.
I don't understand this, I waiting to the translation :(
Also, the Verify Recovery Point After Creation is not a check on the file system. It is only a verification that the information contained in the .v2i is as it was received in the backup.
I know that Verify Recovery Point After Creation is not a checking the file system.
Sry for my bad english, but at least I know what you wrote(not always and all) and I can answer. ;)
I have passed the suggestion to development.
Great I'm suprised for quick reaction. Thank you.
I presume the phrase "to be able to run utilities to quiese a database long enough for a snapshot to occur" is what is hard to understand. Yes, and looking at it again I can see that it uses a lot of terminology that may not make sense. So, let me try to explain.
When we take a backup of a system that is running, we need to be able to somehow capture a state here we know that things are good, namely there is nothing in the buffers waiting to be written out and applications are not in the middle of some kind of operation that is changing data is the system. If we did not do this, the backup would only be crash consistent or the same as if your machine suddenly powered off in the middle of doing something. In this state most data is good, but you could very easily have some corrupt files or corrupt data in files as all the changes did not get written out before the crash or worse a corrupt filesystem.
Back to the point, we need a good state. This state is not too hard to determine for most apps. However, for high volume apps, e.g. a busy database, that state is very hard to determine. For apps like this you need to have a process to make them quiescent (or still or if you will, think of it as pausing and taking a breath for a moment). So, to quiese a database is to somehow tell it to pause for a moment, flush the write buffers and let someone take a picture or a snapshot of that very brief moment. Then the database can continue and we can make a backup from that snapshot since we know everything that has happened, i.e. we know the good state and we can track and compensate for any changes that occur while we are copying the data out to the backup.
Hopefully, this is a little clearer, if not wordier, than before.
Great now I more understand how it works. Thank you.
Please let my know in this thread if checking of the filesystem before backup will be implemented or when or in which release will be.
It can be in one mount or more of course it depends on development team.
Thank for your time.