GianPiero Puccioni wrote:
You wrote
> Hi,These work, with obvious limitations:
> dd if=/dev/sda of=/dev/sdb
> dd if=/dev/sda | ssh other box dd of=/dev/sda
> You don't need to run grub. The MBA and everything, up to the size of
> the source disk, is copied.
Thank you for your prompt answer!
I am not sure what is the best for my setup which is a machine with no
CD reader but only USB (I made the first installation with USB+NFS).
I planned to do the dubbing with a USB for the system and a second one
for the Data. At the moment I have only one machine so I cannot do tests
but I want to be ready. I don't think that the dd method is doable this
way as the data wouldn't fit in a USB key (I suppose I have to dd the
whole partition not only the data) while a tar could do it.
Another possibility is using an external HD with all on it. In this case
I could dd the whole HD (it's only 40G).
Do you think a procedure like this would work
1) prepare a bootable external HD with space to spare
2) boot the test machine from the ExtHD
3) dd if=/dev/sda of="file on the ExtHD"
cp --sparse=always /dev/sda <fileonusbkey>
If you have a 4 Gb key this should fit.
You could also run it through gzip:
dd if=/dev/sda | gzip >"file on the ExtHD"
The real disk in an USB2 should be faster, but there's something that
appeals to me about pulling my 4 Gb Sandisk Cruzer out of my bumbag and
booting it and installing from it!
4) shutdown and boot another machine from the extHD
5) dd if="file on the ExtHD" of=/dev/sda
Probably overkill, copying all 40G for less than 2G of data..
cp --sparse=always will read all the data, and create a file that looks
at first glance to be 40 Gb, but it has big holes in it. They're read as
binary zeros. It won't work well if the source disk has been reused,
unless you clear it first*.
tar and similar will copy only the files. The result will be smaller.
Which is quicker, as always, depends. Navigating filesystems tends to
cause lots of seeking, but then you won't read 30 Gbytes of disk.
tar and similar allow one to change filesystems, but (depending on the
actual system) one can lose metadata such as extended attributes, andthe
results of running 'chattr."
Maybe I could dd only the first partition (/ is 10G) and tar the other 2
/home and /var (it's possible that / will be read-only but this is
another problem). But should I dd /dev/sda1 or /dev/sda with bs=10G
count=1 (or something)? I suppose the last one would copy also the MBR
and partitions so at this point I could just untar in the proper
partition (mkfs first?).
using a larger bs can improve copy speed, but even 100 Mbytes is
probably more than is useful, though I do it;-)
Or maybe the minimal approach would be to dd only the first blocks where
the MBR is, partition the disk with sfdisk, mkfs the partitions, mount
all somewhere and untar the whole stuff in the proper place. This could
be done from a USB key (4G maybe).
If one copies the whole first sector, and have only primary partitions,
then the partitioning is done (unless one doesn't want that setup).
Copying individual partitions using dd (or cp) is possible, provided the
target partition is not smaller. I've only done that with ext{2,3} and
NTFS partitions, not with LVM. It is necessary to run reize2fs or
equivalent after the copy if the destination is larger. Note, it's
possible to shrink partitions during the copy. "man resize2fs" for more.
All of this should be done with minimal intervention so everything must
be in a script but this is not a problem
Scripting is the very best way. Be sure to save ~/.bash_history as the
basis of the script, while you do it manually to find what works.
Just take special care that you don't damage (or can restore) the source
of all this:-) Everything else can be recovered as needed.
* If you didn't clear the disk first, then
dd bs=$((1*1024*1024)) if=/dev/zero of=junk
\rm -f junk
on each partition.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
Please do not reply off-list
