Hello all,

 I have made clones of identical disks in the past (using dd) and this
worked fine for me. The problem I have now is that the target disk is
a different type (much larger) than the source disk.
 I think cloning with dd will not work in this case since disk
geometry is different...
 Question1: How this can be done?

 I was thinking about reading the source partition table and create
the partitions on the target disk by hand. The I will dd each source
partition to the coresponding target partition. Finally I will copy
over the MBR of the source disk to the the target disk.
 Question2:Do you see any problems related to this approach?

Best regards,
Mihail

Meserije wrote:

>  I think cloning with dd will not work in this case since disk
> geometry is different...

Disk cloning will work just fine with dd, only you will have space not 
allocated to a partition towards the end of the disk.

Andreas

Meserije wrote:

> Hello all,
> 
>  I have made clones of identical disks in the past (using dd) and this
> worked fine for me. The problem I have now is that the target disk is
> a different type (much larger) than the source disk.
>  I think cloning with dd will not work in this case since disk
> geometry is different...
>  Question1: How this can be done?

10 Use tar or cpio or cp.
Perhaps there are even more dedicated tools for this.
 
>  I was thinking about reading the source partition table and create
> the partitions on the target disk by hand. The I will dd each source
> partition to the coresponding target partition. Finally I will copy
> over the MBR of the source disk to the the target disk.
>  Question2:Do you see any problems related to this approach?

Not really, but the filesystems will not be enlarged.
goto 10

Eric

On Mon, 12 Jul 2004 12:46:06 -0400, Sarah Tanembaum staggered into the
Black Sun and said:

Please don't top-post.  Message rearranged for easier reading.

> "Eric Moors" <scare.crow@oz.land> wrote in message
> news:ccu6e5$jql$1@voyager.news.surf.net...
>> Meserije wrote:
>> > I have made clones of identical disks in the past (using dd) and
>> > this worked fine for me. The problem I have now is that the target
>> > disk is a different type (much larger) than the source disk.  I
>> > think cloning with dd will not work in this case since disk
>> 10 Use tar or cpio or cp.
>> Perhaps there are even more dedicated tools for this.

partimage might work, or use dump/restore if it's an ext[23] filesystem.

> Please correct me if I'm wrong, I don't think you can use tar since it
> won't do /dev directory.

Modern versions (basically anything released in the last 7 years) of GNU
tar will stat() all files before trying to read them.  If this stat()
says that a file is a symbolic link, FIFO, or device node, it gets
handled specially.  I made a directory with regular files and device
nodes in it, tarred it up, and was able to untar it without problems.
Just remember to exclude /proc from your archival process, since it
takes a long time to copy all the junk in there and it's totally useless
to archive /proc.  HTH,

-- 
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin /    mail: TRAP + SPAN don't belong
http://www.brainbench.com     /                Hire me! 
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume

Eric Moors <scare.crow@oz.land> writes:

> Meserije wrote:
> 
> > Hello all,
> > 
> >  I have made clones of identical disks in the past (using dd) and this
> > worked fine for me. The problem I have now is that the target disk is
> > a different type (much larger) than the source disk.
> >  I think cloning with dd will not work in this case since disk
> > geometry is different...
> >  Question1: How this can be done?
> 
> 10 Use tar or cpio or cp.
> Perhaps there are even more dedicated tools for this.

First format the filesystem on the new parition/disk.
Use "cp -ax".  The -a preserves most things and makes the cp
recursive.  The -x keeps cp to one partition.

Using cp has the advantages that you can have a different target disk
size (larger, but even smaller if the files themselves can fit) and
different filesystem format (while ext2 can easily be converted to
ext3 in-place, conversion to reiserfs, jfs, xfs requires copying).

tar has trouble with special files in /dev.  Otherwise, tar is a good
choice.  E.g., if you want to move/adjust /home, you can tar up all of
/home, put that in /usr or what have you, then you can reformat the
old home, copy the tar file to another machine, etc.

I am not sure about cpio, never having used it.  Usually you select
files with "find" and pipe the list to "cpio".  The find|cpio combo is
more powerful at picking only certain files than tar (shell file
globbing is not very good at recurision and subdirectories), but seems
to have a few more options and certain is more long winded in
invocation.

> >  I was thinking about reading the source partition table and create
> > the partitions on the target disk by hand. The I will dd each source
> > partition to the coresponding target partition. Finally I will copy
> > over the MBR of the source disk to the the target disk.
> >  Question2:Do you see any problems related to this approach?
> 
> Not really, but the filesystems will not be enlarged.
> goto 10
> 
> Eric

-- 
Johan KULLSTAM <kullstj-nn@comcast.net> sysengr

Please correct me if I'm wrong, I don't think you can use tar since it won't
do /dev directory.

Thanks.


"Eric Moors" <scare.crow@oz.land> wrote in message
news:ccu6e5$jql$1@voyager.news.surf.net...
> Meserije wrote:
>
> > Hello all,
> >
> >  I have made clones of identical disks in the past (using dd) and this
> > worked fine for me. The problem I have now is that the target disk is
> > a different type (much larger) than the source disk.
> >  I think cloning with dd will not work in this case since disk
> > geometry is different...
> >  Question1: How this can be done?
>
> 10 Use tar or cpio or cp.
> Perhaps there are even more dedicated tools for this.
>
> >  I was thinking about reading the source partition table and create
> > the partitions on the target disk by hand. The I will dd each source
> > partition to the coresponding target partition. Finally I will copy
> > over the MBR of the source disk to the the target disk.
> >  Question2:Do you see any problems related to this approach?
>
> Not really, but the filesystems will not be enlarged.
> goto 10
>
> Eric

Andreas Stieger <Andreas.Stieger@gmx.de> wrote in message news:<slrncf54bo.8ul.Andreas.Stieger@tux.wh-hms.uni-ulm.de>...
> Meserije wrote:
> 
> >  I think cloning with dd will not work in this case since disk
> > geometry is different...
> 
> Disk cloning will work just fine with dd, only you will have space not 
> allocated to a partition towards the end of the disk.
> 
> Andreas

Hi again,

Some unallocated space is not a problem for me. Having the system up
in "no time" is more important than few loose GB :)

There is something else I don't really understand: A partition record
in the partition table look as this (so they say):
 
Offset  Size    Description
 00h    BYTE    boot indicator (80h = active, 00H = inactive )
 01h    BYTE    partition start head
 02h    BYTE    partition start sector (bits 0-5)
 03h    BYTE    partition start track (bits 8,9 in bits 6,7 of sector)
 04h    BYTE    operating system indicator (see below)
 05h    BYTE    partition end head
 06h    BYTE    partition end sector (bits 0-5)
 07h    BYTE    partition end track (bits 8,9 in bits 6,7 of sector)
 08h    DWORD   sectors preceding partition
 0Ch    DWORD   length of partition in sectors

If my target disk has a different C-H-S layout than the source HDD, I
can't imagine how the cloning operation with dd can possibly be
successful.

Mihail

Andreas Stieger <Andreas.Stieger@gmx.de> wrote in message news:<slrncf54bo.8ul.Andreas.Stieger@tux.wh-hms.uni-ulm.de>...
> Meserije wrote:
> 
> >  I think cloning with dd will not work in this case since disk
> > geometry is different...
> 
> Disk cloning will work just fine with dd, only you will have space not 
> allocated to a partition towards the end of the disk.
> 
> Andreas

Hi again,

Some unallocated space is not a problem for me. Having the system up
in "no time" is more important than few loose GB :)

There is something else I don't really understand: A partition record
in the partition table look as this (so they say):
 
Offset  Size    Description
 00h    BYTE    boot indicator (80h = active, 00H = inactive )
 01h    BYTE    partition start head
 02h    BYTE    partition start sector (bits 0-5)
 03h    BYTE    partition start track (bits 8,9 in bits 6,7 of sector)
 04h    BYTE    operating system indicator (see below)
 05h    BYTE    partition end head
 06h    BYTE    partition end sector (bits 0-5)
 07h    BYTE    partition end track (bits 8,9 in bits 6,7 of sector)
 08h    DWORD   sectors preceding partition
 0Ch    DWORD   length of partition in sectors

If my target disk has a different C-H-S layout than the source HDD, I
can't imagine how the cloning operation with dd can possibly be
successful.

Mihail

Meserije wrote:

> I�have�made�clones�of�identical�disks�in�the�past�(using�dd)�and�this
> worked fine for me. The problem I have now is that the target disk is
> a different type (much larger) than the source disk.

.... http://www.partimage.org/
..
-- 
<<   http://michaeljtobler.homelinux.com/   >>
FOOLED you!  Absorb EGO SHATTERING impulse rays, polyester poltroon!!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

In comp.os.linux.misc Meserije <radum@web.de> suggested:
> Andreas Stieger <Andreas.Stieger@gmx.de> wrote in message news:<slrncf54bo.8ul.Andreas.Stieger@tux.wh-hms.uni-ulm.de>...
>> Meserije wrote:
>> 
>> >  I think cloning with dd will not work in this case since disk
>> > geometry is different...
>> 
>> Disk cloning will work just fine with dd, only you will have space not 
>> allocated to a partition towards the end of the disk.
[..]

> Some unallocated space is not a problem for me. Having the system up
> in "no time" is more important than few loose GB :)
[..]

> If my target disk has a different C-H-S layout than the source HDD, I
> can't imagine how the cloning operation with dd can possibly be
> successful.

It's likely that you can't clone the whole device in one go with
'dd' if disks are different. You could setup the same partitions
on the new disk and copy one partition after another with dd
over. But then you could do the same with cp/tar/cpio.

-- 
Michael Heiming (GPG-Key ID: 0xEDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA84IFAkPEju3Se5QRAhOKAJ0XQwxVGKRzjdK5n0R2U6jyjvw6ugCfR2Rf
ucJQdH+7pswIPrnY8zPv10U=
=CCa1
-----END PGP SIGNATURE-----

Nedavno Meserije pise:

|  I have made clones of identical disks in the past (using dd) and this
| worked fine for me. The problem I have now is that the target disk is
| a different type (much larger) than the source disk.
|  I think cloning with dd will not work in this case since disk
| geometry is different...
|  Question1: How this can be done?

While searching for solution for the same problem I came across the
article that helped me do exactly what you need (with a difference that
for me downtime was not important, so I booted up Knoppix, and did the
partition creation and copying like that). Hire it is:

-----------------------------------------------------------------------

 The following sequence of commands copies the 5 file systems from an 
 old hard disk to a new.  I chose to partition the new hard disk in the 
 SAME ORDER, such that, the device names were the same.  Meaning, hda8 
 was root, hda1 was /boot, etc.  This meant I did not have to edit or 
 modify any configuration files. (A discovery after my first few 
 attempts) 

 While running from the old hard disk, most of the setup and copying can
 be performed.  Only the last step, rewriting of the boot sector on the
 new hard disk, was done from the Linux Rescue mode.

 Old Hard Disk Layout:  Master, Primary IDE.
 /dev/hda1 /boot ext2   25 Mb
 /dev/hda5 /usr ext2 4300 Mb
 /dev/hda6 /home ext2 4300 Mb
 /dev/hda7 /var ext2  256 Mb
 /dev/hda8 / ext2  256 Mb
 /dev/hda9 swap  256 Mb (256 DRAM installed)
 unused   ~356 Mb

 My reasons for this hard disk upgrade was that /var was at 93% usage,
 and /var/qmail and /var/httpd would fill it up.  When this happened,
 Apache and qmail stopped functioning.  Further, a mysql upgrade would 
 not complete because of little /var space.  /home was at 85% usage
 (100+ users).  Following this upgrade, /var/qmail and /var/httpd logs
 will be moved so this can be minimized.

 New Hard Disk: Master, Secondary IDE
 partitioned using: cfdisk /dev/hdc
 /dev/hdc1 /boot ext2    25 Mb
 /dev/hdc5 /usr ext2  2000 Mb
 /dev/hdc6 /home ext2 20000 Mb
 /dev/hdc7 /var ext2 13000 Mb
 /dev/hdc8 / ext2  4400 Mb
 /dev/hdc9 swap   512 Mb (2x DRAM size)

 Once partitioned, each partition must be "formatted" before mounting.
 Don't forget disk label !!!
 $ mke2fs -c -L /boot /dev/hdc1
 $ mke2fs -c -L /usr  /dev/hdc5
 $ mke2fs -c -L /home /dev/hdc6
 $ mke2fs -c -L /var  /dev/hdc7
 $ mke2fs -c -L /     /dev/hdc8
 $ mkswap -c          /dev/hdc9

 BE CAREFUL not to screw with any device from hdaX, since that's the old
 hard disk we are copying from.

 Now that each partition is formatted, each of these "file systems" may
 be mounted under a mount point, and the content copied on to them.  I
 downed my server during this process, to minimize various daemons
 changing the content of the old disk, during the copy.

 $ shutdown now
 $ mkdir /mnt/new
 $ mount /dev/hdc8 /mnt/new

 Copying the old root from hda8 to hdc8 creates the other mount points
 for: boot, usr, home and var.

 $ cd /
 $ find / -xdev | cpio -admpv /mnt/new

 Repeat the process for the remaining file systems

 $ mount /dev/hdc1 /mnt/new/boot
 $ cd /boot
 $ find /boot -xdev | cpio -admpv /mnt/new/boot

 $ mount /dev/hdc5 /mnt/new/usr
 $ cd /usr
 $ find /usr -xdev | cpio -admpv /mnt/new/usr

 $ mount /dev/hdc6 /mnt/new/home
 $ cd /home
 $ find /home -xdev | cpio -admpv /mnt/new/home

 $ mount /dev/hdc7 /mnt/new/var
 $ cd /var
 $ find /var -xdev | cpio -admpv /mnt/new/var

 Savvy Linux people may spot that changing into a directory before
 issuing the find is unnecessary.  This may be true, but I am relaying
 the ACTUAL commands I used, with success, in this endeavor.

 At this point, the files are all copied.  I used the reboot command to
 make sure everything was flushed to disk.  Then, when I saw the machine

 had reset, and was about to boot again, I shut the power down.  I 
 disconnected my Old Hard Disk and set it aside.  I moved my New Hard 
 Disk from the Secondary IDE (master) to the Primary (master).  I stuck 
 in my RedHat Linux Boot CD (I'm sure a boot floppy would work) and 
 booted into "Linux rescue" mode.

 I recreated the mount point, and ran LILO to write the new boot sector.
 Mounting /usr, /home and /var may not be required.  I did it just to be
 thorough.

 $ mkdir /mnt/new
 $ mount /dev/hdc8 /mnt/new
 $ mount /dev/hdc1 /mnt/new/boot
 $ mount /dev/hdc5 /mnt/new/usr
 $ mount /dev/hdc6 /mnt/new/home
 $ mount /dev/hdc7 /mnt/new/var
 $ cd /mnt/new
 $ sbin/lilo -v -v -r /mnt/new
 $ exit

 Entering exit causes a reboot.  I removed the RedHat Linux Boot CD, and
 allowed it to boot from the New Hard Disk.  Everything checked out.

------------------------------------------------------------------------

I hope it helps.


-- 
      ___   ____
     /__/  /    \      ** Registrovani korisnik Linuksa #291606 **
    /  / \/  /\  \     ** http://counter.li.org/ **
   /__/\____/--\__\    ** Reply at: ivica - at - ptt - dot - yu **

In article <slrncf5feo.8ca.danSPANceswitTRAPhcrows@samantha.crow202.dyndns.org>,
Dances With Crows  <daSPANnceswithcroTRAPws@usa.net> wrote:

> I made a directory with regular files and device
> nodes in it, tarred it up, and was able to untar it without problems.
> Just remember to exclude /proc from your archival process, since it
> takes a long time to copy all the junk in there and it's totally useless
> to archive /proc.  HTH,

The "l" (ell) option to tar might be useful; like "-xdev" to find, it tells
tar not to cross mount points.  If you use that you'll have to name mounted
filesystems that _should_ be copied explicitely.  Handy because it makes tar
ignore any mounted CDs or floppies.

-- 
-eben    ebQenW1@EtaRmpTabYayU.rIr.OcoPm    home.tampabay.rr.com/hactar

 They that can give up essential liberty to obtain a little temporary
      safety deserve neither liberty nor safety. -- Ben Franklin

On 2004-07-13, Hactar <ebenONE@tampabay.ARE-ARE.com.unmunge> wrote:
> In article <slrncf5feo.8ca.danSPANceswitTRAPhcrows@samantha.crow202.dyndns.org>,
> Dances With Crows  <daSPANnceswithcroTRAPws@usa.net> wrote:
>
>> I made a directory with regular files and device
>> nodes in it, tarred it up, and was able to untar it without problems.
>> Just remember to exclude /proc from your archival process, since it
>> takes a long time to copy all the junk in there and it's totally useless
>> to archive /proc.  HTH,
>
> The "l" (ell) option to tar might be useful; like "-xdev" to find, it tells
> tar not to cross mount points.  If you use that you'll have to name mounted
> filesystems that _should_ be copied explicitely.  Handy because it makes tar
> ignore any mounted CDs or floppies.

There's another way to prevent tar from backing up mounted
CDs, mounted floppies, or sockets.  I use -X followed by the
name of file that contains a list of paths I don't want
backed up.  I exclude the following (among others):

../dev/pts
../dev/shm
../dev/gpmctl
../dev/log
../home/*/.Trash
../home/*/.mozilla/*/*/Cache
../home/*/.nautilus
../home/*/tmp
../mnt
../proc
../sys
../tmp
../var/spool/postfix/public
../var/spool/postfix/private
../var/spool/postfix/dev/log

The leading ./ may be needed or not needed, depending on the
other options and arguments you use.

Good luck.

Robert Riches
spamtrap42@verizon.net
(Yes, that is one of my email addresses.)

In article <slrncf88he.ft1.rob@one.localnet>,
Robert M. Riches Jr. <spamtrap42@verizon.net> wrote:
> On 2004-07-13, Hactar <ebenONE@tampabay.ARE-ARE.com.unmunge> wrote:
> > In article <slrncf5feo.8ca.danSPANceswitTRAPhcrows@samantha.crow202.dyndns.org>,
> > Dances With Crows  <daSPANnceswithcroTRAPws@usa.net> wrote:
> >
> >> I made a directory with regular files and device
> >> nodes in it, tarred it up, and was able to untar it without problems.
> >> Just remember to exclude /proc from your archival process, since it
> >> takes a long time to copy all the junk in there and it's totally useless
> >> to archive /proc.  HTH,
> >
> > The "l" (ell) option to tar might be useful; like "-xdev" to find, it tells
> > tar not to cross mount points.  If you use that you'll have to name mounted
> > filesystems that _should_ be copied explicitely.  Handy because it makes tar
> > ignore any mounted CDs or floppies.
> 
> There's another way to prevent tar from backing up mounted
> CDs, mounted floppies, or sockets.  I use -X followed by the
> name of file that contains a list of paths I don't want
> backed up.

Sure, good idea, if you're not doing this as a one-off deal.

> I exclude the following (among others):
....
> ./home/*/.Trash
> ./home/*/.mozilla/*/*/Cache
> ./home/*/.nautilus
> ./home/*/tmp

Good idea.  You may want to include (in that list) /var/spool too.

-- 
-eben    ebQenW1@EtaRmpTabYayU.rIr.OcoPm    home.tampabay.rr.com/hactar
CAPRICORN:  The stars say you're an exciting and wonderful person...
but you know they're lying.  If I were you, I'd lock my doors and
windows and never never never never leave my house again.  -- Weird Al

On 2004-07-13, Hactar <ebenONE@tampabay.ARE-ARE.com.unmunge> wrote:
>
>> I exclude the following (among others):
> ...
>> ./home/*/.Trash
>> ./home/*/.mozilla/*/*/Cache
>> ./home/*/.nautilus
>> ./home/*/tmp
>
> Good idea.  You may want to include (in that list) /var/spool too.

Perhaps some branches of /var/spool could or should be
excluded, but I _do_ want to back up /var/spool/mail and
perhaps a few other branches.

Robert Riches
spamtrap42@verizon.net
(Yes, that is one of my email addresses.)

In article <slrncf89op.sv7.rob@one.localnet>,
Robert M. Riches Jr. <spamtrap42@verizon.net> wrote:
> On 2004-07-13, Hactar <ebenONE@tampabay.ARE-ARE.com.unmunge> wrote:
> >
> > You may want to include (in that list) /var/spool too.
> 
> Perhaps some branches of /var/spool could or should be
> excluded, but I _do_ want to back up /var/spool/mail and
> perhaps a few other branches.

I guess it depends how often you back up.  I run a private news server, and
the files in /var/spool/news would be out of date if I backed them up.  I'd
be better off starting fresh.

-- 
-eben    ebQenW1@EtaRmpTabYayU.rIr.OcoPm    home.tampabay.rr.com/hactar
LEO:  Now is not a good time to photocopy your butt and staple
it to your boss' face, oh no.  Eat a bucket of banana pudding
and wash it down with a gallon of strawberry Quik.  -- Weird Al

>>>>> "Meserije" == Meserije  <radum@web.de> writes:

    Meserije> If my target disk has a different C-H-S layout than the
    Meserije> source HDD, I can't imagine how the cloning operation
    Meserije> with dd can possibly be successful.

In that case,  don't clone the whole disk  (/dev/hda, /dev/hdb, etc.).
Partition  the new  disk with  fdisk (or  others) and  then  clone the
*partitions*.  (e.g.  dd if=/dev/hda1 of=/dev/hdb1).  You have to make
sure  the destination  partition  has more  capacity  than the  source
partition.  After that, resize  the filesystem (for ext2/3, reiser) on
the destination partition.   Then, for the sake of  safety, do an fsck
on these  partitions.  For  unresizable filesystems, you  simply waste
the  space at  the end  of the  partition.  (Swap  needn't  be cloned.
Simply mkswap on the new partition.)


-- 
Lee Sau Dan                     +Z05biGVm-                          ~{@nJX6X~}

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

On Mon, 12 Jul 2004 06:19:32 -0700, Meserije wrote:

> Hello all,
> 
>  I have made clones of identical disks in the past (using dd) and this
> worked fine for me. The problem I have now is that the target disk is
> a different type (much larger) than the source disk.
>  I think cloning with dd will not work in this case since disk
> geometry is different...
>  Question1: How this can be done?
> 
>  I was thinking about reading the source partition table and create
> the partitions on the target disk by hand. The I will dd each source
> partition to the coresponding target partition. Finally I will copy
> over the MBR of the source disk to the the target disk.
>  Question2:Do you see any problems related to this approach?
> 
> Best regards,
> Mihail

I have used the Hard Disk Upgrade HOWTO
http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/index.html with little
problem.  This is an alternative for you if you have not ruled it out.