Hello !
Getting up this morning I found more personal answers to my last message to
the list than what I expected. Since all come from readers of tomsrtbt
list, I felt I should add personal comments to it, even if the subject is
perfectly off-topic : please forgive me for this -and forgive my awful &
pedantic English. I felt that more people should benefit from this :
I do not guarantee the accuracy of the following information : all I say
here is based on nothing else than my personal experience as a PC park only
support tech. : so the only warranty is : it works for me.
nc hacks to clone physical disks or partitions are numerous and are nothing
but classical use of unix shell philosophy of pipelining and filters -how
could I survive before learning this ? So one can use any filtering through
pipelining utility with binary data. For example, if you're a samba user,
you can use smbshell/smbmount to dump a disk/partition to a file on a given
samba server with dd if=... | gzip -cv9 | cat
>/smb/myserver/myshare/somefile and backwards cat
/smb/myserver/myshare/somefile | gzip -dv9 | dd of=... : but Hobbit nc's
and L0pht's nc port for MS systems are really great for sending binary data
over a network. If binary data support's not perfect along the transport
chain, use an adequate filetring utility, such as uuencode -If you wish to
send encoded disk images by mail for example :-)
The question about is dd is usable or not in a given case is uneasy, but
the answer is yes most of the time : dd just takes the device source or
target as a stream aka char device and allow you to fix a block size to
emulate some block device characteristics. You're responsible to ensure
what you're doing is right, if you wish to preserve filesystems as a whole.
Most filesystem implement a variable blocksize/clustersize, than can reach
64k for NTFS. If your bs is inferior to the fs cluster size, you might
experiment data corruption on the files/data held by the last clusters of
the fs. The underlying software device (old IDE, ATA, SCSI) may or may not
translate geometry at some level. I do agree with the former really good &
documented contribution from Ed. G. : The general rule is : the bigger the
dd bs -blocksize, the best it works, just because if BS has to be a
multiple of the physically translated device block size and a multiple of
the logical fs cluster size. It also has to be a dividor of the partition
size, but this is marginal. In the case it is not, just round down the
number, and pray that some important data does not resides in the very last
clusters of your fs, or use once more dd with diffenrent bs, count, and
skip options, and blame yourself. the "skip" option can adequately preserve
the partition table, but sfdisk is better for this. skip can also help you
to handle the partition size problems with block sizes bigger than the
partition cluster size, but most of the time one can avoid the problem
thinking twice before. Defragmentation can help for this, if your fs
supports it with some OS of your choice.
For the partition table data in itself, there is generally no problems,
since the partition table lies at the very beginning of the disk. But one
may also prefer to use sfdisk from linux-utils to set it progmatically.
Note that I was wrong talking about pfdisk in my previous mail :-) Also
note that dd ... bs=512 count=1 can handle the boot sector quite efficiently.
If you're not an infortunate OS/2 user, you should really consider using
the underlying fs support instead of device cloning, just because it's far
more comfortable, and allows you to edit the partitions, siff files from
models, save time and add maintenances features unknown to most commercial
maintenance systems. If you wish to blank a partition for which Linux has
no W support, you can either use cat /dev/zero >/dev/somepartition, or,
more adequately, once more, dd : dd if=/dev/zero of=/dev/somepartition
bs=WHATSNEEDED count=WHATNEEDED_OR_TILL_ERROR .
If you can have read support for the source fs and write support for the
target fs, whether they are different or not, you'd prolly better use tar,
instead of dd | gzip, just because tar was made for this :-). Gnu tar
provides zip compression throuh -z option, and can be pipelined. Inferior
tar can be pipelined through gzip. Unfortunately, since linux support of
some FS isn't complete, you might experiment problems with specificities of
your fs -NTFS ACLs for example, and maybe NTFS ADS -clues, anyone : I'm
still experiementing this ?
Some filesystems, such as ext2, have specific or non-specific utilities for
dumping fs such as dumpe2fs, dump, restore.
SMB or NFS support can also be used to dump disks or partitions to a file
intead of disk->disk copy. SMB, as a *connected* protocol aka
FAT-on-the-wire, can prove far more reliable than NFS, and has a better
internal transfer error handling than nc hacks, and can handle on the fly
crypted authentification.
Use of bzip2 instead of gzip is also possible, but bzip2 consumes alot of
CPU and memory and, according to my humble experience, is definitively
slower than using gzip on local networks.
OK folks, please forgive me to have polluted the list with this : hopes
this helps.
---quote---------
#To: [EMAIL PROTECTED]
#From: Pierre MONDIE <[EMAIL PROTECTED]>
#Subject: Re: [tomsrtbt] Restoring/Cloning ?
#>Ed G. wrote:
#>...
#>> drives were identical I simply did a brute force copy from one
#>> machine to the other:
#>> New Machine 192.168.0.240
#>> nc -l -p 7001 | dd of=/dev/hda
#>> Old Machine
#>> dd if=/dev/hda | nc -w 3 -n 192.168.0.240 7001
#>> Worked like a charm.
#
#You might also want to check this to save bandwithdh &or time :
#
#source : dd if=/dev/hda | gzip -c9v | nc -w 3 -n etc..etc...
#target : nc -l -p 7001 | gzip -d9v | dd of=/dev/hda
#
#if this works -it does for me :-), you can gzip on the fly from the source
and ungip on the target. If you use this, you should also ensure that the
unnaffected space on the disk is clean : for example : cat /dev/zero
>./sometemporaryfile; sync; rm ./sometemporaryfile. This might save 50% of
your time, and even a lot more on big almost empty disks.
#
#Forcing some bs or count options in dd may also help. you can also use
/dev/hdan as sources or targets, use sfdisk (the batchable fdisk), dump &
restore, tar, etc, to handle various situations.
#
#Oh yeah of course : this is dangerous : use at your own *real* risks : and
don't forget to pray $DEITY, and maybe think about what you're doing
before. But it happens to work for me, including on NTFS partitions with a
2.2.10 kernel with NTFS RW support.
#
#Also note that nc
#
----EOquote-------
--
Pierre MONDIE : SSR : 74-78
