Can you ever get proper disk cloning, with Ghost 2003?
I've been using Ghost 2003 for a year or two but have only recently tried using it to clone one whole hard drive to another, on the same PC. Both hard drives were of the same manufacture and identical in capacity.
I've been using Ghost 2003 for a year or two but have only recently tried using it to clone one whole hard drive to another, on the same PC. Both hard drives were of the same manufacture and identical in capacity. The partitions on the source disk numbered four and I'd deliberately left some 500MB of unallocated space on it.
I used the Windows mode for doing the cloning, where you start the process off in Windows, Ghost then exits to PC-DOS and does the cloning, then jumps back into Windows when it's finished. I was careful to turn off and remove the destination drive (fitted in the same PC) before the PC actually had a chance to boot back into Windows. You should, of course, never allow this to happen.
I've subsequently managed to check that the destination drive did get properly written. The destination drive does boot into Windows and mostly looks okay. However, I found that Ghost didn't copy the partitions properly. It didn't accurately reproduce the sizes of the partitions and, in particular, didn't reproduce the unallocated area and instead spread it amongst the partitions.
I'm planning to re-clone the drives. To do that, I'd need to work wholly in PC-DOS, of course. But I'm wondering if I'll get the same result.
If you go to Symantec's website and look for FAQs on cloning with Ghost 2003, there's an article there entitled "How to Perform a Disk-to-Disk Clone" and, in it, it says "The entire contents of the source disk, including partitions and unpartitioned space, overwrite the entire contents of the destination disk". So, is this statement correct, or have those of us with Ghost been seriously misled? Does Ghost work more accurately when you use it entirely in the PC-DOS environment?
I used the Windows mode for doing the cloning, where you start the process off in Windows, Ghost then exits to PC-DOS and does the cloning, then jumps back into Windows when it's finished. I was careful to turn off and remove the destination drive (fitted in the same PC) before the PC actually had a chance to boot back into Windows. You should, of course, never allow this to happen.
I've subsequently managed to check that the destination drive did get properly written. The destination drive does boot into Windows and mostly looks okay. However, I found that Ghost didn't copy the partitions properly. It didn't accurately reproduce the sizes of the partitions and, in particular, didn't reproduce the unallocated area and instead spread it amongst the partitions.
I'm planning to re-clone the drives. To do that, I'd need to work wholly in PC-DOS, of course. But I'm wondering if I'll get the same result.
If you go to Symantec's website and look for FAQs on cloning with Ghost 2003, there's an article there entitled "How to Perform a Disk-to-Disk Clone" and, in it, it says "The entire contents of the source disk, including partitions and unpartitioned space, overwrite the entire contents of the destination disk". So, is this statement correct, or have those of us with Ghost been seriously misled? Does Ghost work more accurately when you use it entirely in the PC-DOS environment?
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
I only use Ghost in dos by either booting from Ghost 2003 CD or the emergency floppy.
You will have better results IMO by using it this way then trying to use it from Windows. In clone mode the destination drive is overwritten and does not even have to be formatted.
You will have better results IMO by using it this way then trying to use it from Windows. In clone mode the destination drive is overwritten and does not even have to be formatted.
Yes, it's possible that the problem's been caused entirely by my starting off the cloning operation in Windows. That's nonetheless supposed to be a perfectly valid method.
I've the intention now to try it entirely in PC-DOS (I'm using Win2K which doesn't have DOS, so Ghost creates a PC-DOS environment instead). However, from what I hear, Ghost will still try to fill up the destination drive and will therefore automatically calculate and apply different (though proportionately-related) partition sizes. In the Ghost manual, however, there's fleeting mention of you being allowed to re-size partitions on the destination, when running in PC-DOS.
I suppose all I can do is experiment. It's a pity Symantec haven't been clearer about this.
BTW, no pre-formatting was necessary and I guess it'll be the same when working 100% in PC-DOS.
If I get the same result, I think I'll have to clone partition-by-partition instead, though I reckon I'll have to delete all existing partitions on the destination drive beforehand, for that to work. Otherwise, I can't see how I can end up with an EXACT copy, including the 500MB of unallocated space (unless PC-DOS is extraordinarily clever and can pre-delete the partitions).
I've the intention now to try it entirely in PC-DOS (I'm using Win2K which doesn't have DOS, so Ghost creates a PC-DOS environment instead). However, from what I hear, Ghost will still try to fill up the destination drive and will therefore automatically calculate and apply different (though proportionately-related) partition sizes. In the Ghost manual, however, there's fleeting mention of you being allowed to re-size partitions on the destination, when running in PC-DOS.
I suppose all I can do is experiment. It's a pity Symantec haven't been clearer about this.
BTW, no pre-formatting was necessary and I guess it'll be the same when working 100% in PC-DOS.
If I get the same result, I think I'll have to clone partition-by-partition instead, though I reckon I'll have to delete all existing partitions on the destination drive beforehand, for that to work. Otherwise, I can't see how I can end up with an EXACT copy, including the 500MB of unallocated space (unless PC-DOS is extraordinarily clever and can pre-delete the partitions).
You can specify the size in Ghost before cloning and I have XP so I just boot from CD then go into the directory on the CD where ghost.exe is and run it.
Not sure if you ever been to this site that link below goes but it is full of stuff about Ghost.
Ghost Radified
Not sure if you ever been to this site that link below goes but it is full of stuff about Ghost.
Ghost Radified
i have used Ghost countless times and it never let me down..
the best way to get the result you want is booting from a ghost bootdisk. run ghost in dos mode, never in windows!!!
im not sure about the 500m allocated space you wanted. if your source disk has it(the 500mb allocation) then i believe ghost will copy it too. if you repartition your target disk first using 100%, then reformatting it ghost will copy the exact image of the source disk. all the patition. everything.
Norton Ghost is a time/life saving tool in this internet cafe..
haven't tried it in NTFS before!!!.
Use the dos mode please.
if you manage to fnd another solution, please let me know..
gud lucks...
the best way to get the result you want is booting from a ghost bootdisk. run ghost in dos mode, never in windows!!!
im not sure about the 500m allocated space you wanted. if your source disk has it(the 500mb allocation) then i believe ghost will copy it too. if you repartition your target disk first using 100%, then reformatting it ghost will copy the exact image of the source disk. all the patition. everything.
Norton Ghost is a time/life saving tool in this internet cafe..
haven't tried it in NTFS before!!!.
Use the dos mode please.
if you manage to fnd another solution, please let me know..
gud lucks...
Hi all,
I've now managed to do a fully-accurate clone of my main hard drive. NTFS partitions, BTW. The secret WAS indeed to do it entirely within PC-DOS. It seems that, if you run it from Windows instead, the cloning process not only approximates the partition sizes but also fills the entire destination drive with partitions, irrespective of anything different you might want.When you run entirely in PC-DOS, you're allowed to change the partition sizes and, for guidance, it even reminds you of the existing partition sizes on the source.
Another distinct advantage I've found of the PC-DOS method is that, unlike in the Windows method, you're given the opportunity to quit from PC-DOS and to turn off the computer and remove the destination drive. You might know that, if you allow both drives to attempt to boot back into Windows on the same machine, the system will be confused and you're likely to corrupt the operating systems on the two drives.
I've tested the destination drive since doing it, of course, and it boots okay and programs open okay, etc.
Actually, during the first post-cloning bootup of the destination drive, my System BIOS flashed up a warning message about boot sector information being changed and asked my approval for that. There was, of course, no option but to agree to that. Subsequently, I've found that in the initial part of the bootup into Windows - the very first screen that says "Starting Up .... Windows 2000 Professional" and which has the blue progress bar - it spends far, far longer there than is the case in the source drive. Any idea why? Is it something to do with the MBR having been changed? Is this perhaps one other side-effect in Ghost of which we're unaware? Would it have been better for me to have written 0s all over the destination drive first, as it had the wrongly-cloned partitions on it before I re-cloned?
I've now managed to do a fully-accurate clone of my main hard drive. NTFS partitions, BTW. The secret WAS indeed to do it entirely within PC-DOS. It seems that, if you run it from Windows instead, the cloning process not only approximates the partition sizes but also fills the entire destination drive with partitions, irrespective of anything different you might want.When you run entirely in PC-DOS, you're allowed to change the partition sizes and, for guidance, it even reminds you of the existing partition sizes on the source.
Another distinct advantage I've found of the PC-DOS method is that, unlike in the Windows method, you're given the opportunity to quit from PC-DOS and to turn off the computer and remove the destination drive. You might know that, if you allow both drives to attempt to boot back into Windows on the same machine, the system will be confused and you're likely to corrupt the operating systems on the two drives.
I've tested the destination drive since doing it, of course, and it boots okay and programs open okay, etc.
Actually, during the first post-cloning bootup of the destination drive, my System BIOS flashed up a warning message about boot sector information being changed and asked my approval for that. There was, of course, no option but to agree to that. Subsequently, I've found that in the initial part of the bootup into Windows - the very first screen that says "Starting Up .... Windows 2000 Professional" and which has the blue progress bar - it spends far, far longer there than is the case in the source drive. Any idea why? Is it something to do with the MBR having been changed? Is this perhaps one other side-effect in Ghost of which we're unaware? Would it have been better for me to have written 0s all over the destination drive first, as it had the wrongly-cloned partitions on it before I re-cloned?
I'm still wondering why Windows takes much longer to boot up now, using the cloned drive. Anyone got any ideas? The bootup spends around FIVE times as long in the "Starting Up...Windows 2000 Professional" screen than with the original drive. About a minute, I'd say. In hardware terms, the drives are identical.
A number of factors came into play when doing the cloning, and I wonder whether one or more of them might be responsible for the slowness. For instance:
1) In order for Windows (and therefore any programs under Windows) to recognise the existence of a new drive, I had to run the Win2K "Write Signature and Upgrade Disk" wizard, prior to running Ghost (see Microsoft article 837160). Just the write signature bit, you understand. I don't recall ever needing to do that with the original drive and is presumably a more recent feature of Win2K. But presumably that signature would have been overwritten, anyway, when I finally did the cloning?
2) Throughout the cloning process, and later when testing the destination drive on its own to see if it booted into Windows, the drive was used on the Primary SLAVE IDE channel. Would that be why the bootup is so slow?
3) When first booting with the destination drive that'd now had the complete copy of the original disk on it, my System BIOS generated an alarm signal to say that the boot sector information would be changed. Has this got anything to do with it? Remember, it's currently on the SLAVE channel and is on its own.
4) Generally, could there have been some other changes made to the MBR that could now account for the slowness?
5) I also observed that, once the destination drive had first booted fully into Windows, it showed a Windows message indicating that not all hardware information had been loaded and that I needed to restart the PC again. Obviously, I did that. But why was there a need for that? Surely, if this was a straight copy of the other drive, the hardware drivers should have been copied across as already embedded?
6) Has the slowness got anything to do with the fact that a specific portion of the destination disk was left as deleted by the cloning process (enabling a 500MB unallocated space)? My guess is that when existing partitions are deleted under these sorts of circumstances, the deletion is done by raising a flag, rather than by 0s been written over the partitions.
Obviously, if later I had to use the destination disk in earnest, I'd bring it out of storage, change its jumpering to Master and then fit it in place of the existing drive. In other words, normally, I would use the drive on the Primary MASTER channel.
A number of factors came into play when doing the cloning, and I wonder whether one or more of them might be responsible for the slowness. For instance:
1) In order for Windows (and therefore any programs under Windows) to recognise the existence of a new drive, I had to run the Win2K "Write Signature and Upgrade Disk" wizard, prior to running Ghost (see Microsoft article 837160). Just the write signature bit, you understand. I don't recall ever needing to do that with the original drive and is presumably a more recent feature of Win2K. But presumably that signature would have been overwritten, anyway, when I finally did the cloning?
2) Throughout the cloning process, and later when testing the destination drive on its own to see if it booted into Windows, the drive was used on the Primary SLAVE IDE channel. Would that be why the bootup is so slow?
3) When first booting with the destination drive that'd now had the complete copy of the original disk on it, my System BIOS generated an alarm signal to say that the boot sector information would be changed. Has this got anything to do with it? Remember, it's currently on the SLAVE channel and is on its own.
4) Generally, could there have been some other changes made to the MBR that could now account for the slowness?
5) I also observed that, once the destination drive had first booted fully into Windows, it showed a Windows message indicating that not all hardware information had been loaded and that I needed to restart the PC again. Obviously, I did that. But why was there a need for that? Surely, if this was a straight copy of the other drive, the hardware drivers should have been copied across as already embedded?
6) Has the slowness got anything to do with the fact that a specific portion of the destination disk was left as deleted by the cloning process (enabling a 500MB unallocated space)? My guess is that when existing partitions are deleted under these sorts of circumstances, the deletion is done by raising a flag, rather than by 0s been written over the partitions.
Obviously, if later I had to use the destination disk in earnest, I'd bring it out of storage, change its jumpering to Master and then fit it in place of the existing drive. In other words, normally, I would use the drive on the Primary MASTER channel.
