sudo dd if=/dev/hda of=/dev/hdb
For fast copying between filesystems on a linux box, try this:
find . -xdev -print0 | cpio -pdvum0 --sparse /dest-dir
Cloning also doesn't let your Tivo use all the available space on the new drive, which I assume is bigger than the old drive.
Just use mfsbackup/mfsrestore. It will also overwrite the XP boot signature.
The backup Tivo image can easily fit on one CD if you use Mfstools.
You can't use the Windows version of Ghost, as booting Windows 2000 or
XP with the Tivo drive attached is a big no-no. (In fact, unplugging
your XP hard drive is a good idea. ) You'll have to use the Ghost
Finaly, the Linux "dd" command is truly a bit-by-bit copy and has been verified to work for Tivo drives.
I used an older version of Ghost to binary copy an 80G TiVo drive. That worked the process was really slow it took over 8hrs. The Linux cp command using DMA was much faster If i recall that took
less then 4 hours. Ghost at least had a process indicator. Back then I
did not know about the dd command back then.
To clone a hard drive of 7G capacity (ATA-33) to a new drive of 40G (ATA-100) with 'dump and restore' commands as follows;
(Remark: old and new drives of unequal capacity)
connect ATA-100 drive as Primary slave
# fdisk -l (to find the partitions on ATA-33 drive, e.g.)
Device Boot System
/dev/hda1 * Linux
/dev/hda3 Linux swap
/dev/hda4 /var Linux
Make partitions on ATA-100 drive same as ATA-33 drive but of different capacity
# fdisk n /dev/hdb
Then make following mount points (still on ATA-33)
# mkdir /mnt/boot
# mkdir /mnt/root
# mkdir /mnt/var
# mount /dev/hdb1 /mnt/boot
# mount /dev/hdb2 /mnt/root
(/dev/hdb3 is swap)
# mount /dev/hdb4 /mnt/var
# dump –f - /boot | (cd /mnt/boot; restore –rf -)
# dump –f - / | (cd /mnt/root; restore –rf -)
# dump –f - /var | (cd /mnt/var; restore –rf -)
Is the command lines correct?
Copied from alma.ch:
Cloning NTFS partitions --> ntfsclone.
It worked perfectly, and was pretty fast (using Gigabit
- The machine to clone which I will boringly call Master.
new clone, unsurprisingly called Slave here, and which is assumed to be
made of identical hardware, particularly the hard disk.
- Gigabit Ethernet.
- A server for the Master disk image
- A Linux "Live CD" (I used Knoppix 3.8.1, which had ntfsclone version 1.9.4).
The Backup:Boot Master from the Linux live CD
Open a root shell
Set my swiss keyboard layout if needed
or in newer versions:
setxkbmap ch fror
setxkbmap ch de
Check if the network is up
It wasn't for me, and DHCP tended to fail for some reason, so I configured it manually:
ifconfig eth0 192.168.1.27
echo nameserver 192.168.1.4 > /etc/resolv.conf
echo search example.lan >&gt; /etc/resolv.conf
route add -net 0.0.0.0 gw 192.168.1.100
The machine displaying a stupid time and time zone, I also did
and pasted the string it suggested on the command line,
TZ='Europe/Zurich'; export TZ
and then set the clock:
was not really necessary, but I noticed that the file times on the
server would be wrong if the client had a wrong time and/or time zone.
And now the real stuff:
Create a mount point
the server's share. I used a share called diskimages on a Samba server,
but it could have been Windows, an NFS server, or whatever.
# mount -t smbfs -o username=my_user_name //server_name/diskimages /tmp/server</pre><br />Check how your live CD called the partitions you want to save<br /><pre># cat /proc/partitions<br />major minor #blocks name<br /><br />8 0 78150744 sda<br />8 1 20482843 sda1<br />8 2 1 sda2<br />8 5 20482843 sda5<br />8 6 37182411 sda6<br />180 0 253952 uba<br />180 1 253936 uba1<br />240 0 1939136 cloop0</pre><br />I want to save that 80 GB disk sda, which has a primary partition sda1,<br />and an extended partition sda2 containing logical partitions sda5 and<br />sda6. So what I want to save is sda1, sda5 and sda6.<br />First I saved the partition table and the Master Boot Record<br /><pre># <code>sfdisk -d /dev/sda >/tmp/server/master-sfdisk-sda.dump<br /># dd if=/dev/sda bs=512 count=1 of=/tmp/server/master-sda.mbr</code></pre><br />and then the partitions:<br /><pre>ntfsclone -s -o - /dev/sda1 | gzip | split -b 1000m - /tmp/server/master-sda1.img.gz_<br />ntfsclone -s -o - /dev/sda5 | gzip | split -b 1000m - /tmp/server/master-sda5.img.gz_<br />ntfsclone -s -o - /dev/sda6 | gzip | split -b 1000m - /tmp/server/master-sda6.img.gz_</pre>This<br />is where I fell into the first trap. My Samba server doesn't seem to<br />accept files larger than 2 GBytes! That is why the output is piped<br />through split. I still don't know why I cannot write files larger than<br />2 GB, and if you do, please let me know. This is a Samba 3.x server<br />running on Debian with a 2.6.x kernel, and the share is on a 36GB ext3<br />partition.<br />(update: <a href="http://www.blogger.com/post-edit.g?blogID=9195951&postID=111424681646035348#c111716005006438346">this comment</a><br />suggests to add the lfs option to smbfs mount. This allowed me to write<br />more than 2 GB, but not more than 4GB. Probably because it's a FAT32<br />partition)<br /><br />Anyway, split solved that problem nicely, chopping<br />the output into 1 GB files, but I had added gzip in the hope of making<br />things faster, and that gzip and split combination bit me later. And<br />I'm not even sure that the gzip overhead is worth the bandwidth saving.<br />Gigabit Ethernet can be really fast. In fact, it can be faster than the<br />hard disks. That may be worth benchmarking some time. (I also tried<br />bzip2, which has better compression, but that was excruciatingly slow).<br /><br />That's it for the backup. Now, to the next part:<br /><h3>The Restore:</h3>Boot Master from the Linux live CD, and proceed as for the backup:<br /><br /><code>setxkbmap fr_CH<br />ifconfig eth0 192.168.1.27<br />echo nameserver 192.168.1.4 > /etc/resolv.conf<br />echo search example.lan >> /etc/resolv.conf<br />route add -net 0.0.0.0 gw 192.168.1.100<br />TZ='Europe/Zurich'; export TZ</code><br /><br /><code>ntpdate pool.ntp.org<br />hwclock --systohc</code><br /><pre>mkdir /tmp/server<br />mount -t smbfs -o username=my_user_name //server_name/diskimages /tmp/server</pre>(I just copied/pasted this whole block into the shell)<br /><br />Check your partitions again, and make sure you will not overwrite some other disk!<br /><br /># <code>cat /proc/partitions</code><br /><br />Now I first restored the partition table and the master boot record<br /><br /># <code>sfdisk /dev/sda < /tmp/server/master-sfdisk-sda.dump</code><br /># <code>dd if=/tmp/server/master-sda.mbr of=/dev/sda</code><br /><br />And<br />then the partitions. Since I had several files produced by split for my<br />primary partition, I needed to take them all, in the right order of<br />course. split adds "aa", "ab", "ac", etc. to the end of the file name.<br /><br /># <code>ls -l /tmp/server</code><br /><br />will help you check which files you need<br /><br />This is where the second trap got me. gunzip's documentation led to believe that I could do something like <code>gunzip -c file1 file2 file3 | ntfsclone ... </code>which would be the same as <code>cat file1 file2 file3 | gunzip -c | ntfsclone ...</code><br /><br />Well, <em>it is not the same</em>, and my first tries would result in the process aborting after a (long) while, with the error "gunzip: unexpected end of file".<br /><br />Eventually, it worked:<br /><pre>cd /tmp/server<br />cat master-sda1.img.gz_aa master-sda1.img.gz_ab master-sda1.img.gz_ac | gunzip -c | ntfsclone --restore-image --overwrite /dev/sda1 -<br />cat master-sda5.img.gz_aa | gunzip -c | ntfsclone --restore-image --overwrite /dev/sda5 -<br />cat master-sda6.img.gz_aa | gunzip -c | ntfsclone --restore-image --overwrite /dev/sda6 -Reboot into your new Windows XP clone.
Now I wonder if there is anything I overlooked with machine IDs (SID?) and such, but I haven't seen a problem so far.
Do I need to do something, to change the SID of the clone?
you don't need to save the image and want to be faster, you could of
course combine this method with netcat and skip the server.
Note:the NFS solution is the easy one ...
but if you want 2 get REAL speed out of your gear you shoud use netcat & DD
the NFS trick got me to max 17MB/sec under gigabit network
netcat does it @ 34MB/sec , over the same gear ... (do the math its 1GB @30 SEC only !!!)
stop using NFS - netbios/SMB are bad 4 you
There is no requirement for ntfsclone to restore to the same size
partition. Other than having enough space of course! Create the
partitions manually if you wish and then restore to the one you want.
that you may have issues if the first block of the partition is in a
different place - ie: if you generated the image from /dev/hda1 and
restored to /dev/hda2... Not sure, but I think windows is a bit dim...
Firstly, use "mount -t cifs". Smbfs is deprecated. And a hack.
you can restore an ntfs image to a larger partition - create it in
fdisk and make sure it has type id of 7 - and then simply use
"ntfsresize /dev/hda1" or whatever. That's magic that is!
restoring a bootable windows to a different partition is slightly
painful. Having a bootable XP/W2K cd will help a lot - fixboot and
bootcfg but you can help yourself by pulling extra lines for partitions
1,2,3,4 in the boot.ini before starting!
I'm not sure if fixboot will fix up the "start offset" in the ntfs partition boot sector but I did it by following this.
you change the dword at offset 1c to give the start sector number (get
it from "fdisk -ul"). Mine was /dev/hda1 and start sector was 63, or
0x3F. So I put the numbers 3f,00,00,00 (little endian order) in from
offset 0x1c. I did it without a hex editor but you don't want to know
how! (dd and vi -b!!!)
Do this with Knoppix here.
To change the SID
Cloning Hard Drives in FreeBSD Linux Windows NetBSD OpenBSD
Ghost sees a Reiserfs partition as if it were full of data wether it is or not. If the partition is 70GB then Ghost will think it has a full 70GB of data on it, even if you have less than 40GB in reality. There are other image-backup apps out there that handle Reiserfs correctly but I've always used Ghost because that is what has been available to me. Ext(x) works fine. I haven't tried other filesystem types. Ext2,Ext3,vfat work like a charm.