1. Boot a linux floppy (one of many rescue disks available in .img format)
2. Use 'dd' to perform a block-level copy from one drive to another.

dd if=SOURCEDISK of=TARGETDISK bs=1M

Where SOURCEDISK and TARGETDISK are not the same, could be any one of the following examples:

(if SCSI/SATA):
/dev/sda
/dev/sdb
/dev/sdc
...

(or if Parallel or ATA):
/dev/hda
/dev/sdb
/dev/sdc
...

For example: dd if=/dev/sda of=/dev/sdb bs=1M

In this example, /dev/sda is the SOURCEDISK, /dev/sdb is the TARGETDISK. /dev/sdb will be overwritten with the contents of /dev/sda. Also note that /dev/sdb should be either exactly the same size or larger than /dev/sda to ensure it can hold all of /dev/sda. (That said, dd doesn't care about MBRs, partition tables, or filesystems because it operates at the block level and simply moved bytes!).

you understand that your hard drives have to be identical, if you want block for block. Meaning both have to be a same manufacturer and model number.

protip if you are using windows 98 and not NT
to update a MBR using windows 98 the command in dos is FDISK /MBR

Warlord wrote:

you understand that your hard drives have to be... the same manufacturer and model number.
<snip>

This is not true. The target drive simply has to be the same or larger than the source, to ensure a verbatim copy from the 0th byte to the "end" byte of the source block device.

For example, DD'ing from the top-level of the block device (as opposed to any of sub-partitions or slices) will perform a block-exact copy from a say a 20GB ATA-33 Quantum Bigfoot TS to a Samsung 32GB USB stick.
- Every byte, from the 0th position on the Quantum to the last readable byte on the quantum will be byte-exact on the 32 USB stick.
- the Windows 98 MBR will be intact
- the FAT32 partition table will be intact
- the filesystems, their contents, and even their "empty/deleted" space will be exact
- the fragmentation will be the same

The trailing bytes on the Samsung USB stick will simply be left as-is; either available to hold more partitions (if space in the partition table permits), or simply wasted.

You can also 'dd' to a TARGET file, so you can tote-around and image of your HDD as a file, share it, post it to the cloud, and recreate at-will.

dd if=SOURCEDISK of=/some/directory/my_hdd.dd bs=1M

And you restore it:

dd if=/some/directory/my_hdd.dd of=TARGETDISK bs=1M

(Edit: This is how it's been done *nix industry-wide as long as I can remember - for any operating system, storage device (including boot-devices), and filesystems. Windows? Linux? Solaris? BSD? Raspberry Pi? You name it.. If you can boot the hardware with a rescue Linux/BSD image then you're in business (alternatively, you can remove the storage and move it to a machine that /does/ contain Linux/BSD). I personally attest to having done this countless times since about 2001)

I posted earlier about linux/dd and it seems to have not appeared. But yes, this is what i'd use. On a modern box it'd be a usb stick or CD ofcourse, but same method.

You can also do "cat /proc/partitions" to view the devices and their partitions to figure out what your copying where.

Aragorn wrote:

I posted earlier about linux/dd and it seems to have not appeared. But yes, this is what i'd use. On a modern box it'd be a usb stick or CD ofcourse, but same method.

You can also do "cat /proc/partitions" to view the devices and their partitions to figure out what your copying where.

Yup; that's key - figuring out your source and target. After that, for people new to DD wanting to backup their entire physical HDD, they also need to pick the top-level block device as opposed numbered partitions.

cat /proc/partitions

1major minor  #blocks  name
2
3 253        0   16267532 zram0
4   8       16 5860522584 sdb  <-- block device (entire HDD)
5   8       32 5860522584 sdc  <-- block device (entire HDD)
6   8        0  125034840 sda  <-- block device (entire HDD)
7   8        1      16384 sda1
8   8        2     262144 sda2
9   8        3  124755288 sda3
10   8       48 2930266584 sdd  <-- block device (entire HDD)
11   8       64  250059096 sde  <-- block device (entire HDD)
12   8       65  250057728 sde1
13   8       80 2930266584 sdf  <-- block device (entire HDD)
14   8       81 2930265088 sdf1
15   8       96 2930266584 sdg  <-- block device (entire HDD)
16   8       97 2930265543 sdg1
17   8      192 9766404096 sdm  <-- block device (entire HDD)
18   8      193 9766402048 sdm1
19   8      208 9766404096 sdn  <-- block device (entire HDD)
20   8      209 9766402048 sdn1

Another handy tool that identifies drives vs partitions, both by name and rank is lsblk:

1NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
2sda      8:0    0 119.2G  0 disk 
3├─sda1   8:1    0    16M  0 part /boot/efi
4├─sda2   8:2    0   256M  0 part /boot
5└─sda3   8:3    0   119G  0 part /
6sdb      8:16   0   5.5T  0 disk /data2
7sdc      8:32   0   5.5T  0 disk /data3
8sdd      8:48   0   2.7T  0 disk /data4
9sde      8:64   0 238.5G  0 disk 
10└─sde1   8:65   0 238.5G  0 part /ssd_backup
11sdf      8:80   0   2.7T  0 disk 
12└─sdf1   8:81   0   2.7T  0 part /data1
13sdg      8:96   0   2.7T  0 disk 
14└─sdg1   8:97   0   2.7T  0 part /data5
15sdm      8:192  0   9.1T  0 disk 
16└─sdm1   8:193  0   9.1T  0 part /data6
17sdn      8:208  0   9.1T  0 disk 
18└─sdn1   8:209  0   9.1T  0 part /data7
19zram0  253:0    0  15.5G  0 disk [SWAP]

I like to use this https://www.roadkil.net/program.php?ProgramID=22

runs in windows and even works with USB-attached disks or flash

precaud wrote:

I've been using Ghost for cloning hard drives, but learned a couple days ago that it does not in fact make an exact "duplicate". It doesn't copy MBR or boot sector. I want a utility that will exactly duplicate one drive onto an identical one.

Have anything that you like that does this?

All tools are capable of copying MBR/boot sector, but keep on mind that MBR is only copied when you do an entire disk copy (opposed to copying only a partition).

The most exact copy would be using dd in any Unix variant.

precaud wrote:

Bonus points for small and runs from a DOS boot floppy.

The only one that I know for sure that fits in only one floppy is Norton Ghost. Some mini Linux distributions can run from a pair of disks, but you'll have to do the imaging by yourself (i.e.: not GUI for that). If you don't mind booting from CD or USB, you could use Acronis True Image or Clonezilla.

Clonezilla can be told to copy EVERYTHING, and can use the dd approach to do so.

krcroft wrote:

Warlord wrote:

you understand that your hard drives have to be... the same manufacturer and model number.
<snip>

This is not true. The target drive simply has to be the same or larger than the source, to ensure a verbatim copy from the 0th byte to the "end" byte of the source block device.

Geometry DOES matter (number of cylinders/head/sectors), specially when dealing with old OSs or HDDs. If you try to restore an image into a disk that have different number of heads, some OSs will get confused and won't boot.

In disks that use LBA that's not a problem (provided that BIOS accesses it as LBA, not a CHS translation), nor in OSs that doesn't use the BIOS to access the disk (Linux, after boot). That's one of the reason to make "intelligent copies" (storing only size of partition and the files, instead the entire partition block by block)... you can reconstruct the filesystem in a partition suited to your device geometry.

krcroft wrote:

Yup; that's key - figuring out your source and target. After that, for people new to DD wanting to backup their entire physical HDD, they also need to pick the top-level block device as opposed numbered partitions.

cat /proc/partitions

I prefer to use fdisk -l. Keep in mind that in linux..

• /dev/sdx/ and /dev/hdx are disk devices (i.e.: /dev/hda, /dev/sdc). In older distributions PATA devices (including drives connected with a SATA to PATA adapters) used to be /dev/hdx, but they changed to /dev/sdx on later versions.
• /dev/mmcblkn (i.e.: /dev/mmcblk0) are usually eMMC devices, or SD cards through integrated readers (like in laptops). Note that any flash card connected through USB readers will use the /dev/sdx/ notation.
• /dev/srn (i.e.: /dev/sr0) are CD/DVD/BD recorders. You can safely ignore this devices (fdisk should have done it for you).

Partitions are usually the same but finished in a number. Some examples would be:

• /dev/hda2: Second partition from first PATA (IDE) disk.
• /dev/sdb1: First partition from second PATA, SATA or USB disk.
• /dev/mmcblk0p1: First partition from a SD card or eMMC disk. Note that 'p' hanging around.

Does it sound complex? At least we don't have to talk to things like c0t0d2s3 like in other Unix variations...

precaud wrote:

I've been using Ghost for cloning hard drives, but learned a couple days ago that it does not in fact make an exact "duplicate". It doesn't copy MBR or boot sector. I want a utility that will exactly duplicate one drive onto an identical one.

Have anything that you like that does this?

Bonus points for small and runs from a DOS boot floppy.

Err... My experience is that a Ghost 11.5 disk image does include the MBR. Imaged totally blank drives without issue.
Where it can screw with you is it " helpfully" editing your boot.ini to match the partition location on disk because it can't know you'll be hiding partitions.

Newer versions of ghost can do a bit by bit copy of the drive without formatting information

I was able to clone Macintosh drives to non Macintosh drives and even could clone my futura 100’s hard drive
All on my scsi equipped Windows 98 pc

Just some additional information:
There are IDE/SATA/SCSI controllers (particularly RAID ones) that do not make the the whole disk transparent to the OS, and use the first sectors of the drives themselves to store some information, usually RAID configuration data.
If a drive has been used on such a controller, it should be read from such a controller only, or the image read will be corrupt.

The same is valid in the other direction if one wants to prepare a drive for use with such a controller.

Furthermore, I'd advise to zero out a target drive before filling it with the data (if=/dev/zero). If using a larger drive than the original one, random garbage on the unused excess area might confuse partition and formatting utilities, even mislead disk integrity checkers/repair software.

Thanks to all for your replies. Since i don't have access to Linux and can't give time to learn it right now, I'll go with the familiar...

rmay635703 wrote:

Newer versions of ghost can do a bit by bit copy of the drive without formatting information

This would be the most accessible solution for me. Would you mind sharing the command line to do it?

This is the batch file I've been using: GHOST -clone,mode=copy,src=1,dst=2,-szee -sure

I don't know offhand what Ghost version I'm using but its an older one, came on the utility CD with a Soyo mobo I bought in the early 2000's.

EDIT: Oh, and BTW, the source and target HDD's are identical models. I've always bought in pairs in order to have a spare on hand.

what version of ghost were you using?

Warlord wrote:

what version of ghost were you using?

7.0

I use ghost 8.2 it will update the MBR only if the destination drive doesn't have a mbr. If thats any help. If the destination drive already has a MBR it won't touch it, and only updates the PBR.

That's an interesting detail. I guess I should RTFM for this one and see if it behaves the same. Were you using the same command line switches?

I use AOMEI. It's free. Just get in there (Windows GUI), order a partition copy (it sort of resembles disk management in Windows), apply, and it's like a batch file that runs when you restart. Very easy.

And since it's a partition tool you can do whatever the hell you want with partitions right there. Resize active partitions, all the tricks. No wasted space.

Outside of mass imaging systems (like rolling out a new build or fleet of hardware) I don't see any benefit from using command line over the GUI, just increases your chances of a mistake.
Running Gbost32 from a WindowsPE boot will image faster too btw. Hiren's Boot CD 10.6 includes a Windows XP based PE as well as DOS boot with Ghost 11.5.1 available on either. I still prefer a Windows 7 based PE for even faster imaging and its diskpart/Disk Management will 4k align SSDs automatically.

I use clonezilla, though you need to use an old version for full Win9x compatibility. The most recent version I found that worked is 1.1.0-8.
https://sourceforge.net/projects/clonezilla/f … dFiles/1.1.0-8/
I can't remember the exact issue (it's been a few years since I sussed this out), but newer versions would restore the image seemingly without issue, but the system would not boot. It would leave you with a blinking DOS cursor. In fact, I just used this last week to rescue my WinME system from a deal hdd. The system bios was no longer seeing my drive on most boot attempts, but I got it to boot one last time, took an image, then restored it to a working hdd and I'm back up and running.

edit: btw, the latest gparted that supports Win9x is version 0.3.7-7
https://sourceforge.net/projects/gparted/file … stable/0.3.7-7/

Turns out that the Ghost version I've been using (7.0) is a scaled-down "Enterprise" version included as part of a package of "8-in-1" tools they (Symantec) sold (or gave) to mobo manufacturers. Did not come with a manual, but command line options are listed with the -? switch.

In an online manual for the full 2003 version, I see several command line switches that are relevant to exact-image cloning, control copying of MBR and boot sector/track (or not), etc., that are not in 7.0 . It appears as though it should be able to do the job. Will try to find a copy of that version.