Bootable rescue/backup/restore CD/DVD software (Paul??)

Excuse me for barging in on thread "Recommendations for painless
upgrade?" ...

On Thu, 30 Dec 2010 17:14:57 -0500, Paul wrote:

Also, I recommend making a backup copy of your working boot
image. The restore should be the "bare metal" restore kind, where
the restoration software can boot the computer itself. That
is to cover you, in case the migration fails for some reason.
You can put all the hardware back, and do a restore, to regain
control. I've only had to do that once, after making a stupid
mistake while moving from old hardware to new hardware. So it
*is* worthwhile to have a backup, even if the odds of needing
to use it are low. On my machines, I use tools like "dd" and
simply image every sector, into a file on a second drive. Along
these lines, while using a Linux LiveCD as a boot system. Since
I have two OSes on the machine (Win2K and WinXP), I can also
switch to the other OS and do it from there, using
http://www.chrysocome.net/dd . I don't always do this from
Linux, but sometimes use Windows to do it. The syntax changes
slightly in Windows, for the raw device specification of
input and output. DD (disk dump) is available in both
worlds.

dd if=/dev/hda of=bigfile.dd

To restore, I'd reverse the direction of transfer, like this.

dd if=bigfile.dd of=/dev hda

That restores everything, including the MBR, partition
boot sectors and the like. It's why I do it that way,
a complete record. With the simplest form of that
command, transfer performance is about 13MB/sec. If
you specify a block size and count parameter, you can
get closer to 40MB/sec. For really large disks, it
pays to learn how to use all available parameters.

Hello Paul,

I have decided that I need to investigate several Linux-based
bootable backup/restore CD/DVD software solutions i.e.
dd, dd_rescue, dd_rhelp, savehd7, and GNU ddrescue.

Could you elaborate a bit on dd usage? I've downloaded dd v.5 from
www.chrysocome.net and haven't managed to find general info on
how to use it. Is it intended to be run only from Windows disk
command line? How does one exit from the command line? Etc, etc.

No doubt there is a command reference somewhere. There are lots
of interesting application (copying) examples.

For example, you can run:

dd if=/dev/hda of=bigfile.dd

from Windows (as opposed to booting a Linux CD)? What exactly
is executed and how, in terms of involved disk devices, partitions,
and files on your system?

Can you point me to good reference doc on bootable rescue/backup/restore
CD/DVD software?

Thx,
P

"Law Without Equity Is No Law At All. It Is A Form Of Jungle Rule."

Puddin' Man wrote:
Excuse me for barging in on thread "Recommendations for painless
upgrade?" ...

On Thu, 30 Dec 2010 17:14:57 -0500, Paul wrote:

Also, I recommend making a backup copy of your working boot
image. The restore should be the "bare metal" restore kind, where
the restoration software can boot the computer itself. That
is to cover you, in case the migration fails for some reason.
You can put all the hardware back, and do a restore, to regain
control. I've only had to do that once, after making a stupid
mistake while moving from old hardware to new hardware. So it
*is* worthwhile to have a backup, even if the odds of needing
to use it are low. On my machines, I use tools like "dd" and
simply image every sector, into a file on a second drive. Along
these lines, while using a Linux LiveCD as a boot system. Since
I have two OSes on the machine (Win2K and WinXP), I can also
switch to the other OS and do it from there, using
http://www.chrysocome.net/dd . I don't always do this from
Linux, but sometimes use Windows to do it. The syntax changes
slightly in Windows, for the raw device specification of
input and output. DD (disk dump) is available in both
worlds.

dd if=/dev/hda of=bigfile.dd

To restore, I'd reverse the direction of transfer, like this.

dd if=bigfile.dd of=/dev hda

That restores everything, including the MBR, partition
boot sectors and the like. It's why I do it that way,
a complete record. With the simplest form of that
command, transfer performance is about 13MB/sec. If
you specify a block size and count parameter, you can
get closer to 40MB/sec. For really large disks, it
pays to learn how to use all available parameters.

Hello Paul,

I have decided that I need to investigate several Linux-based
bootable backup/restore CD/DVD software solutions i.e.
dd, dd_rescue, dd_rhelp, savehd7, and GNU ddrescue.

Could you elaborate a bit on dd usage? I've downloaded dd v.5 from
www.chrysocome.net and haven't managed to find general info on
how to use it. Is it intended to be run only from Windows disk
command line? How does one exit from the command line? Etc, etc.

No doubt there is a command reference somewhere. There are lots
of interesting application (copying) examples.

For example, you can run:

dd if=/dev/hda of=bigfile.dd

from Windows (as opposed to booting a Linux CD)? What exactly
is executed and how, in terms of involved disk devices, partitions,
and files on your system?

Can you point me to good reference doc on bootable rescue/backup/restore
CD/DVD software?

Thx,
P


The Command Prompt window, shares some of this for syntax. This is what
I use for a reference, if I'm making adjustments to my MSDOS boot floppy.
Not everything here, works in a Command Prompt, but this page does
give you some historical perspective.

http://www.vfrazee.com/ms-dos/6.22/help/

The first concept, is execution path. Like many OSes, the path variable
contains the names of multiple folders, where executable code is stored.
If you wanted a program to be accessible anywhere, you'd add the name
of the folder to the path variable. Otherwise, you have to give an
explicit path to the program. If you look in your System Control Panel,
"Advanced", Environment variables, you can find your PATH there. In this
example, the things with percents on either end, are "well known" locations,
which are themselves, environment variables. In this sample "system" Path,
there are three folders to look in.

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\Sy stem32\Wbem

I usually just copy the executable program, into the folder I'm working
in, rather than going to the trouble of modifying Path. I use the
"cd" command, Change Directory, to get there. So if my dd.exe program
is in C:\Downloads, I can do

c: (change to the C: partition)
cd \ (change directory to the top level, but we're already there)
cd Downloads (now I'm at C:\Downloads)
dd.exe --list (I've run my first command. This only works, if the OS
supports executing a program from the current working
directory. In Linux, you'd need "." in your path, to
make that happen.)

So the first step of running programs in Command Prompt, is either setting up
Path the right way, or using "cd" to move to the folder that has the program
in it (on the assumption that "." is implicitly in the executables path).

*******

A well written Command Prompt utility, will be self supporting.
Usually, some variation on the question mark, will give help.

dd /?

In the case of the dd port in question, it looks like it supports
the Linux/Unix conventions for help. I suppose historically, this
might be traceable to GNU.

dd --help

That's how you'd bootstrap yourself, without seeking a separate manual.
The web page for dd, actually has all the info you need to get started,
which makes it less scary to use.

dd is dangerous, and deserves a bit of respect. You can easily erase a
disk in a matter of seconds, before you can press control-c fast enough
to stop it. In general, the Command Prompt is not forgiving when it comes
to typing mistakes (I once had the wrong command in a copy/paste
buffer, pasted it into the Command Prompt window, and lost the contents
of one of my smaller partitions, so s*** happens).

This command

dd --list

is benign, and won't hurt anything. The first thing to notice,
is your C: partition and its details, may not be listed. And that
should be a signal to you, that WinXP isn't going to allow you to
back up the WinXP partition, from the Command Prompt. You'd have to
boot a second Windows OS (I use both WinXP and Win2K on the same machine),
and if I boot Win2K, then "dd --list" and look at the other disk,
I can see the parameters for the WinXP disk. If you don't
have two Windows OSes, you can use the Command Prompt from a
Linux LiveCD, to do exactly the same thing. The only difference,
is the naming conventions for disks.

This raw device specification, points to my entire second disk.

\\?\Device\Harddisk1\Partition0

This specification, points to only the first partition of the second disk.

\\?\Device\Harddisk1\Partition1

And this would point to my entire first disk.

\\?\Device\Harddisk0\Partition0

The size field in that listing output is important, if you want
to use the block size and count parameters. And those parameters
are needed for precise transfers. The "seek" and "skip" options,
operate your disk like a "tape drive", and by using those options,
you can transfer any arbitrary length from the middle of one disk,
to some other arbitrary starting address on a second disk. So
"seek", "skip", "bs", "count" allow you to move blocks just
about anywhere. Using the bs and count variables, you can even do
fractions of a sector (but I haven't tested that). When I
use that command, I generally always work at the 512 byte
sector level, and don't try to get too cute with the command.

This is how I back up my WinXP boot partition. It is the second
partition on the disk. Here, I'm not copying the whole disk. This
is the procedure I use, before doing "something dangerous" to C:
alone. I'd be booted into Win2K, to copy this WinXP C: partition.
If the whole disk was in danger, I'd back up the whole thing.
The product of 129024 * 604031 is 77,934,495,744 bytes,
and that is the exact value listed as the size of C:. The
output specification format in this case, is a file on partition
W:. And W: is NTFS, so it can handle a 77GB single file as output.
So here, I'm storing the entire C: partition (image) as a single
file stored on W:. I use the .dd extension, to remind myself
what kind of image it is.

dd if=\\?\Device\Harddisk1\Partition2 of=W:\winxp.dd bs=129024 count=604031

Generally the idea would be, the block size (bs) should not exceed the limits
of a single transfer command to the storage device. If an IDE drive could
handle a request for 512KB of data, then you'd keep the bs parameter
below 512KB. In my example, it's about 1/4 of that value. I use
a factoring program ("factor" in Linux), if I need to work out values
for those two numbers. By issuing large 129024 byte transfer commands,
it makes the transfer take place up to three times faster, than not
specifying a value.

Anyway, that's not really an introduction to the Command Prompt,
and is just intended to give you some ideas.

If you double click "dd.exe", you might see the Command Prompt window
flash open and close again. So executing a program like that, may
have it associated with the Command Prompt. But the Command Prompt
window will only stay open, if the launched programs keeps "stdout"
open.

On my Windows 7 laptop, I'd type "cmd.exe" in the search box, to
find the command prompt, and that's the name of the Command Prompt program.
That's how you can start it. And then it stays open, allowing
an "interactive session" to take place.

control-c in windows, functions as the Copy shortcut. But in a
command environment, control-c also means "stop". So some
programs will react to that key combo, as a request to quit.
(For example, the TestDisk program, Windows version, responds
to control-c.)

As for the Command Prompt windows itself, if you type "exit"
into it, the window should disappear. This is similar behavior
to Linux shells, where some command is used as a means to say
"I'm done with this shell".

There are many experiences, that can prepare you for the
Command Prompt window. I bought a C-Shell book years ago, and
that was an introduction to shells and typing commands into
windows, and path variables. When I saw my first MSDOS window,
the concepts didn't seem so strange. And I really appreciate
environments, that try to use common analogies (like all the OSes
having trash cans for example). That's very helpful, when you're in
a strange environment for the first time, to have things
work, sort of, the same way.

(The C-Shell book I bought, so I could use a Unix machine at work...)
http://ecx.images-amazon.com/images/...CL._SS500_.gif

"Publisher: Prentice Hall;

Front Corners Bent Up and Dirty edition (April 1986)"

Have fun (and be careful),
Paul

Paul,

Many thanks, that was very much helpful.

Just a few questions ...

dd if=/dev/hda of=bigfile.dd

To restore, I'd reverse the direction of transfer, like this.

dd if=bigfile.dd of=/dev hda

In the above, hda is the "raw device specification" for everything
on one of your disk devices? Did you id "hda" from "dd --list" output?

In the above, of=bigfile.dd specifies a file, but not a disk device?
Where is bigfile.dd stored?

Testdisk on my W2k system yields output like:
Disk /dev/sda - 80 GB / 74 GiB - CHS 9729 255 63, sector size=512 - WDC WD800JB-00FSA0
Disk /dev/sdb - 30 GB / 28 GiB - CHS 3736 255 63, sector size=512 - Maxtor 53073H4

Can I use device specs like sda, sdb with dd? Why aren't such device specs
present in "dd --list" output?

dd --list gives me output like:

Win32 Available Volume Information
\\.\Volume{d8ef0652-64b3-11d8-bbe5-b3e8151a1b61}\
link to \\?\Device\HarddiskVolume1
fixed media
Mounted on \\.\c:

\\.\Volume{7af6bf80-6934-11d8-8708-806d6172696f}\
link to \\?\Device\HarddiskVolume2
fixed media
Mounted on \\.\d:

This is partition-level info. I could conceivably use it like:

dd if=/dev/HarddiskVolume1 of=HarddiskVolume2

to copy all on c: to d: ???

Please forgive so many questions. The examples on:
http://en.wikipedia.org/wiki/Dd_%28Unix%29
might be sufficient if they weren't in (I think) FreeBSD.

Thanks,
P

On Sun, 02 Jan 2011 01:13:41 -0500, Paul wrote:

The Command Prompt window, shares some of this for syntax. This is what
I use for a reference, if I'm making adjustments to my MSDOS boot floppy.
Not everything here, works in a Command Prompt, but this page does
give you some historical perspective.

http://www.vfrazee.com/ms-dos/6.22/help/

The first concept, is execution path. Like many OSes, the path variable
contains the names of multiple folders, where executable code is stored.
If you wanted a program to be accessible anywhere, you'd add the name
of the folder to the path variable. Otherwise, you have to give an
explicit path to the program. If you look in your System Control Panel,
"Advanced", Environment variables, you can find your PATH there. In this
example, the things with percents on either end, are "well known" locations,
which are themselves, environment variables. In this sample "system" Path,
there are three folders to look in.

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\S ystem32\Wbem

I usually just copy the executable program, into the folder I'm working
in, rather than going to the trouble of modifying Path. I use the
"cd" command, Change Directory, to get there. So if my dd.exe program
is in C:\Downloads, I can do

c: (change to the C: partition)
cd \ (change directory to the top level, but we're already there)
cd Downloads (now I'm at C:\Downloads)
dd.exe --list (I've run my first command. This only works, if the OS
supports executing a program from the current working
directory. In Linux, you'd need "." in your path, to
make that happen.)

So the first step of running programs in Command Prompt, is either setting up
Path the right way, or using "cd" to move to the folder that has the program
in it (on the assumption that "." is implicitly in the executables path).

*******

A well written Command Prompt utility, will be self supporting.
Usually, some variation on the question mark, will give help.

dd /?

In the case of the dd port in question, it looks like it supports
the Linux/Unix conventions for help. I suppose historically, this
might be traceable to GNU.

dd --help

That's how you'd bootstrap yourself, without seeking a separate manual.
The web page for dd, actually has all the info you need to get started,
which makes it less scary to use.

dd is dangerous, and deserves a bit of respect. You can easily erase a
disk in a matter of seconds, before you can press control-c fast enough
to stop it. In general, the Command Prompt is not forgiving when it comes
to typing mistakes (I once had the wrong command in a copy/paste
buffer, pasted it into the Command Prompt window, and lost the contents
of one of my smaller partitions, so s*** happens).

This command

dd --list

is benign, and won't hurt anything. The first thing to notice,
is your C: partition and its details, may not be listed. And that
should be a signal to you, that WinXP isn't going to allow you to
back up the WinXP partition, from the Command Prompt. You'd have to
boot a second Windows OS (I use both WinXP and Win2K on the same machine),
and if I boot Win2K, then "dd --list" and look at the other disk,
I can see the parameters for the WinXP disk. If you don't
have two Windows OSes, you can use the Command Prompt from a
Linux LiveCD, to do exactly the same thing. The only difference,
is the naming conventions for disks.

This raw device specification, points to my entire second disk.

\\?\Device\Harddisk1\Partition0

This specification, points to only the first partition of the second disk.

\\?\Device\Harddisk1\Partition1

And this would point to my entire first disk.

\\?\Device\Harddisk0\Partition0

The size field in that listing output is important, if you want
to use the block size and count parameters. And those parameters
are needed for precise transfers. The "seek" and "skip" options,
operate your disk like a "tape drive", and by using those options,
you can transfer any arbitrary length from the middle of one disk,
to some other arbitrary starting address on a second disk. So
"seek", "skip", "bs", "count" allow you to move blocks just
about anywhere. Using the bs and count variables, you can even do
fractions of a sector (but I haven't tested that). When I
use that command, I generally always work at the 512 byte
sector level, and don't try to get too cute with the command.

This is how I back up my WinXP boot partition. It is the second
partition on the disk. Here, I'm not copying the whole disk. This
is the procedure I use, before doing "something dangerous" to C:
alone. I'd be booted into Win2K, to copy this WinXP C: partition.
If the whole disk was in danger, I'd back up the whole thing.
The product of 129024 * 604031 is 77,934,495,744 bytes,
and that is the exact value listed as the size of C:. The
output specification format in this case, is a file on partition
W:. And W: is NTFS, so it can handle a 77GB single file as output.
So here, I'm storing the entire C: partition (image) as a single
file stored on W:. I use the .dd extension, to remind myself
what kind of image it is.

dd if=\\?\Device\Harddisk1\Partition2 of=W:\winxp.dd bs=129024 count=604031

Generally the idea would be, the block size (bs) should not exceed the limits
of a single transfer command to the storage device. If an IDE drive could
handle a request for 512KB of data, then you'd keep the bs parameter
below 512KB. In my example, it's about 1/4 of that value. I use
a factoring program ("factor" in Linux), if I need to work out values
for those two numbers. By issuing large 129024 byte transfer commands,
it makes the transfer take place up to three times faster, than not
specifying a value.

Anyway, that's not really an introduction to the Command Prompt,
and is just intended to give you some ideas.

If you double click "dd.exe", you might see the Command Prompt window
flash open and close again. So executing a program like that, may
have it associated with the Command Prompt. But the Command Prompt
window will only stay open, if the launched programs keeps "stdout"
open.

On my Windows 7 laptop, I'd type "cmd.exe" in the search box, to
find the command prompt, and that's the name of the Command Prompt program.
That's how you can start it. And then it stays open, allowing
an "interactive session" to take place.

control-c in windows, functions as the Copy shortcut. But in a
command environment, control-c also means "stop". So some
programs will react to that key combo, as a request to quit.
(For example, the TestDisk program, Windows version, responds
to control-c.)

As for the Command Prompt windows itself, if you type "exit"
into it, the window should disappear. This is similar behavior
to Linux shells, where some command is used as a means to say
"I'm done with this shell".

There are many experiences, that can prepare you for the
Command Prompt window. I bought a C-Shell book years ago, and
that was an introduction to shells and typing commands into
windows, and path variables. When I saw my first MSDOS window,
the concepts didn't seem so strange. And I really appreciate
environments, that try to use common analogies (like all the OSes
having trash cans for example). That's very helpful, when you're in
a strange environment for the first time, to have things
work, sort of, the same way.

(The C-Shell book I bought, so I could use a Unix machine at work...)
http://ecx.images-amazon.com/images/...CL._SS500_.gif

"Publisher: Prentice Hall;

Front Corners Bent Up and Dirty edition (April 1986)"

Have fun (and be careful),
Paul

"Law Without Equity Is No Law At All. It Is A Form Of Jungle Rule."

Puddin' Man wrote:
Paul,

Many thanks, that was very much helpful.

Just a few questions ...


dd if=/dev/hda of=bigfile.dd

To restore, I'd reverse the direction of transfer, like this.

dd if=bigfile.dd of=/dev hda


In the above, hda is the "raw device specification" for everything
on one of your disk devices? Did you id "hda" from "dd --list" output?

In Linux, a raw device might be /dev/hda.

If I boot Windows, and use the "dd" port, dd --list might give
\\?\Device\Harddisk0\Partition0 as the equivalent of /dev/hda.

Each OS, has its own syntax for raw devices. The Linux one
is a bit more compact.


In the above, of=bigfile.dd specifies a file, but not a disk device?
Where is bigfile.dd stored?

In the current working directory in that example.

bigfile.dd # Relative to current working directory

W:\bigfile.dd # An absolute path specification

Downloads\bigfile.dd # In the Downloads folder below the current
# working directory.

dd supports read/write to block devices ( \\?\Device\Harddisk0\Partition0 )
or to files in the file system ( W:\bigfile.dd ).


Testdisk on my W2k system yields output like:
Disk /dev/sda - 80 GB / 74 GiB - CHS 9729 255 63, sector size=512 - WDC WD800JB-00FSA0
Disk /dev/sdb - 30 GB / 28 GiB - CHS 3736 255 63, sector size=512 - Maxtor 53073H4

Can I use device specs like sda, sdb with dd? Why aren't such device specs
present in "dd --list" output?

I think "dd" is being true to the OS it's running on. The
author is being careful to be consistent.

The author of Testdisk has taken the opposite approach, which is,
to keep the program interface consistent between OSes, and hide the
raw device details.

The author of testdisk would have his program go to
\\?\Device\Harddisk0\Partition0 , while the screen claims
it is /dev/sda.

And, as far as I know, the "s" in sda, stands for "SCSI driver based hard
drive". Hard drives may sometimes use pseudo-SCSI driver
stacks, so the hard drive itself may not be SCSI. But SCSI
provides a convenient intermediate command block format,
which driver writers can use. In Windows, if you design
a new hard drive controller board, you write a pseudo-SCSI
driver for it, because that is the API provided for adding
new controller types.


dd --list gives me output like:

Win32 Available Volume Information
\\.\Volume{d8ef0652-64b3-11d8-bbe5-b3e8151a1b61}\
link to \\?\Device\HarddiskVolume1
fixed media
Mounted on \\.\c:

\\.\Volume{7af6bf80-6934-11d8-8708-806d6172696f}\
link to \\?\Device\HarddiskVolume2
fixed media
Mounted on \\.\d:

I never use the link information in that command. Too confusing.
I suppose you can, because the OS converts such references
as required. I think they may be stored in a "namespace".


This is partition-level info. I could conceivably use it like:

dd if=/dev/HarddiskVolume1 of=HarddiskVolume2

to copy all on c: to d: ???

Perhaps that would work. The question would be, does such
a reference take the whole partition, starting at sector 0
of the partition ?

These are the kinds of things you can experiment with. But
being careful, to only write to safe things. For example,
in your command, you've chosen to write to "of=HarddiskVolume2".
I'd want to learn enough about the command first, based on
using the "read" functionality first. I might test by trying
this, an "unsafe" format for input, a "safe" format for the
output specification. Then see what happens, and how big a file
ends up on W:.

dd if=HarddiskVolume2 of=W:\bigfile.dd

In that example, I'm testing whether the input specification
is valid or not. I'm using an output specification I know
to be valid (based on not erasing any disks so far :-) ).

You might ask "how do you know what is stored inside bigfile.dd".
There is a program for that. It is called "Disktype". I wish
this was ported to Windows, but as far as I know, no one has
prepared a Windows binary for it. I use that program in Linux,
to test images to see what they are. For example, if I did

disktype bigfile.dd

it might report "NTFS file system". And then I'd know I'd
captured an entire partition.

http://disktype.sourceforge.net/

You can point disktype at a block device

disktype /dev/hda

or at a file

disktype bigfile.dd

It treats the contents of the file, as if it was a block
device, then looks at well known locations for things
consistent with various partition types. I can even point
it to a CD or DVD in my optical drive, and it'll tell me
whether the disc has a dual file system or a single file
system on it.


Please forgive so many questions. The examples on:
http://en.wikipedia.org/wiki/Dd_%28Unix%29
might be sufficient if they weren't in (I think) FreeBSD.

Thanks,
P


I was referring to the Windows port page for "dd". I found
the information in there, was useful in learning to use the
Windows version of the command.

http://www.chrysocome.net/dd

If you look at your typical "man page", some of those can
be so terse as to be useless. If the manual page has
some example commands at the end of the page, that
frequently clears the cobwebs.

Paul

On Mon, 03 Jan 2011 16:11:32 -0500, Paul wrote:

Puddin' Man wrote:
Paul,

Many thanks, that was very much helpful.

Just a few questions ...


dd if=/dev/hda of=bigfile.dd

To restore, I'd reverse the direction of transfer, like this.

dd if=bigfile.dd of=/dev hda


In the above, hda is the "raw device specification" for everything
on one of your disk devices? Did you id "hda" from "dd --list" output?

In Linux, a raw device might be /dev/hda.

So, we were discussing Windows systems (and backups thereof), and you rendered
an example using Linux syntax? :-(

If I boot Windows, and use the "dd" port, dd --list might give
\\?\Device\Harddisk0\Partition0 as the equivalent of /dev/hda.

Each OS, has its own syntax for raw devices. The Linux one
is a bit more compact.

I'll say. Have you ever seen a native Windows disk reference like
"Harddisk0\Partition0" save from Linux derivatives like dd?


In the above, of=bigfile.dd specifies a file, but not a disk device?
Where is bigfile.dd stored?

In the current working directory in that example.

bigfile.dd # Relative to current working directory

W:\bigfile.dd # An absolute path specification

Downloads\bigfile.dd # In the Downloads folder below the current
# working directory.

dd supports read/write to block devices ( \\?\Device\Harddisk0\Partition0 )
or to files in the file system ( W:\bigfile.dd ).


Testdisk on my W2k system yields output like:
Disk /dev/sda - 80 GB / 74 GiB - CHS 9729 255 63, sector size=512 - WDC WD800JB-00FSA0
Disk /dev/sdb - 30 GB / 28 GiB - CHS 3736 255 63, sector size=512 - Maxtor 53073H4

Can I use device specs like sda, sdb with dd? Why aren't such device specs
present in "dd --list" output?

I think "dd" is being true to the OS it's running on. The
author is being careful to be consistent.

I don't think I've ever seen a W2k/XP reference to anything like
"Harddisk0\Partition0".

The author of Testdisk has taken the opposite approach, which is,
to keep the program interface consistent between OSes, and hide the
raw device details.

The author of testdisk would have his program go to
\\?\Device\Harddisk0\Partition0 , while the screen claims
it is /dev/sda.

And, as far as I know, the "s" in sda, stands for "SCSI driver based hard
drive". Hard drives may sometimes use pseudo-SCSI driver
stacks, so the hard drive itself may not be SCSI. But SCSI
provides a convenient intermediate command block format,
which driver writers can use. In Windows, if you design
a new hard drive controller board, you write a pseudo-SCSI
driver for it, because that is the API provided for adding
new controller types.


dd --list gives me output like:

Win32 Available Volume Information
\\.\Volume{d8ef0652-64b3-11d8-bbe5-b3e8151a1b61}\
link to \\?\Device\HarddiskVolume1
fixed media
Mounted on \\.\c:

\\.\Volume{7af6bf80-6934-11d8-8708-806d6172696f}\
link to \\?\Device\HarddiskVolume2
fixed media
Mounted on \\.\d:

I never use the link information in that command. Too confusing.
I suppose you can, because the OS converts such references
as required. I think they may be stored in a "namespace".

Great. The OS syntax for dd appears to be somewhat ambiguous, but one
cannot use dd facility like dd --list to identify.


This is partition-level info. I could conceivably use it like:

dd if=/dev/HarddiskVolume1 of=HarddiskVolume2

to copy all on c: to d: ???

Perhaps that would work. The question would be, does such
a reference take the whole partition, starting at sector 0
of the partition ?

These are the kinds of things you can experiment with. But
being careful, to only write to safe things. For example,
in your command, you've chosen to write to "of=HarddiskVolume2".
I'd want to learn enough about the command first, based on
using the "read" functionality first. I might test by trying
this, an "unsafe" format for input, a "safe" format for the
output specification. Then see what happens, and how big a file
ends up on W:.

dd if=HarddiskVolume2 of=W:\bigfile.dd

Paul, what is W: on your system? Please??

In that example, I'm testing whether the input specification
is valid or not. I'm using an output specification I know
to be valid (based on not erasing any disks so far :-) ).

...

I have a new desktop build with 2 identical Samsung 500gb SATA drives.
On disk 1 is Win7 on c:, XP on d: and a data partition e:.
On disk 2 are 3 partitions that I don't need to keep.
Theoretically, I could use dd to duplicate on disk 2 precisely what is
stored on disk 1? If so, how? In all detail save C:H:S and the like.

Thanks,
P

"Law Without Equity Is No Law At All. It Is A Form Of Jungle Rule."

Puddin' Man wrote:
On Mon, 03 Jan 2011 16:11:32 -0500, Paul wrote:

In Linux, a raw device might be /dev/hda.

So, we were discussing Windows systems (and backups thereof), and you rendered
an example using Linux syntax? :-(

Sometimes, when I need an example, I want something compact,
without distractions. If I introduce the Windows raw device
format immediately, it distracts from the "dd if= of=" part
of the example.

Each OS, has its own syntax for raw devices. The Linux one
is a bit more compact.

I'll say. Have you ever seen a native Windows disk reference like
"Harddisk0\Partition0" save from Linux derivatives like dd?

You'll find examples in things like some of the error
messages in Event Viewer. Otherwise, the subject is poorly
documented.


I don't think I've ever seen a W2k/XP reference to anything like
"Harddisk0\Partition0".

And I don't know if I can dig up a Technet reference on the subject,
to help.


Paul, what is W: on your system? Please??


I have eight partitions on my system currently. W: is just a scratch
partition, for really large files. I was using it yesterday, to
store a copy of C: for example. My system has taken to changing
the partition letters again, so any attempt at logical lettering
has gone to hell. I had two partitions that were related to one
another, and were sequential, and now they're G: and M:. I've
given up on being "neat and tidy", and my OS can do whatever it
wants with them. They have labels on them, so I can tell them
apart. The partition letter is no longer important. As long as
C: stays C:, I'm fine.


I have a new desktop build with 2 identical Samsung 500gb SATA drives.
On disk 1 is Win7 on c:, XP on d: and a data partition e:.
On disk 2 are 3 partitions that I don't need to keep.
Theoretically, I could use dd to duplicate on disk 2 precisely what is
stored on disk 1? If so, how? In all detail save C:H:S and the like.

Thanks,
P

First, you have to decide whether "dd" is the right tool for the job.
On the one hand, the output takes more space, than dealing with the
files themselves. So if the disk you want to snapshot is large, the
output file will be equally as big. And don't even think about
compressing it :-) I tried that, and it was a total disaster later,
when I needed to decompress. (Certain pipelined commands I like to use,
wouldn't work, requiring me to use a separate disk to decompress the
file again. And it takes forever to compress those big files.)

On the plus side of the ledger, "dd" takes care of the details.
On a brand new Dell/HP/Acer/Gateway, there can be one or more hidden
partitions. Containing who knows what kind of archive format or file
system. You can spend time learning about them, or with "dd", you
can make an exact copy and never need to know what was in there. If
you ever need to put it back, you're relatively speaking, all set.

To copy the entire disk, you'll do the "dd --list" thing. Then,
look at the "Partition0" entries and size info. A Partition0 reference,
will start at Sector 0 of the disk. The size listed in the --list
output, should reflect the stated capacity of the disk. You can then
craft a command, something along the lines of

dd if=\\?\Device\Harddisk0\Partition0 of=W:\firstdisk.dd

and set the bs= and count= parameters, to account for the
size of the entire disk. When the command completes, it should
report exactly the same value, as the value of count, for how many
blocks were transferred.

If my Harddisk0 was a 320GB disk, then the "firstdisk.dd" file
will also be 320GB. And you should check, by right clicking
and doing properties, that they match. I've caught myself
a few times, making typing mistakes (not typing the bs= and
count= numbers correctly), and ending up with an archive which
is smaller than it should be. By double checking the transferred
file size, I can catch my typing mistakes.

dd.exe will check whether the source ran out of data, or the
destination ran out of storage space. So the command can fail
for either of those reasons. For example, if I selected
infinitely large bs and count, like bs=1000000000 count=1000000000,
then the source disk will run out of data, before all "count" blocks
have been transferred. The status message when the command completes,
is going to quietly be warning you, that you've done the job
incorrectly. I take some amount of care, when crafting bs= and count=
values, to make sure they match the size reported in --list output.

You don't have to use bs= and count=, but if you fail to use them,
the command performance at about 1/3rd the normal rate. So if
I do this, I might see 13MB/sec transfer rate. If I'm headed off
to bed, perhaps I don't care about that. But if its the middle
of the day, I'll probably craft a block size and count for it.

If my source disk was 320GB in size, all I'd have to do with
this syntax, is make sure there was room for a 320GB file on
my W: scratch partition. So you don't have to bother
with the additional parameters, if it's too much trouble.
But I like the command to go a bit faster, if I can
arrange it.

dd if=\\?\Device\Harddisk0\Partition0 of=W:\firstdisk.dd

For file level copying, I use Robocopy for that. Robocopy
is an economical alternative for FAT32 or NTFS *data* partitions.
It means I can copy files and permissions, from one disk to
another. But if I have partitions of unknown type, or hidden
partitions, I might use "dd" for that.

HTH,
Paul