3

I want to copy/clone my current linux system as it is to another notebook because I'm afraid my current one will die sooner or later and I loose all of my linux setup, tools and file structures.

I heard about rsync but am quite unsure if this tool will really do what I want to. The main part is to install the snapshot of my current linux to another machine.

xetra11
  • 546
  • tbh it's not really an option because I'm using a refreshed T400 which now really seems to go down. My next machine should contain at least a SSD and therefore no physical movement :/ – xetra11 Sep 17 '16 at 22:26
  • 1
    My take would be to copy the system whilst it is shutdown. i.e. by using a liveCD. Yet, a lot depends on how your current machine is configured: single disk? multiple disks? several partitions? do you want the disk partitions to be the same on the new machine? MBR boot or UEFI? Same boot system on both machines? That would be useful info to make an objective answer. – grochmal Sep 18 '16 at 20:27

2 Answers2

2

The easy way

The easy way is to boot from a live installation on a machine where both the old disk and the new disk are connected and copy the data wholesale with cat. For example, assuming that the old disk is /dev/sdo and the new disk is /dev/sdn (make sure you get the device names right — if you copy to the old disk, your data will be lost!):

cat /dev/sdo >/dev/sdn

This assumes that the new disk is at least as large as the old disk. Then enlarge the partition(s) on the new disk to fill it as you see fit.

Some ways that give you more control

If the new disk is larger, you might prefer to first create a partition table, then copy each partition (e.g. cat /dev/sdo1 >/dev/sdn1). You can skip swap partitions and call mkswap instead (e.g. mkswap /dev/sdn1). Once you've copied a filesystem, if the target partition is larger, you'll need to enlarge the filesystem to match to benefit from the added size (resize2fs /dev/sdn1 if /dev/sdn1 contains an ext4 filesystem).

Alternatively, you can copy a partition by copying all of its files. You'll need to create a filesystem on the target partition, mount both the source partition and the new partition (e.g. at /media/old and /media/new respectively) and run

cp -ax /media/old /media/new

This may be slower or faster than copying the raw partition depending on how many files it contains.

If you don't copy the disk wholesale, you'll need to install the bootloader on the new disk. A typical way to do this is to mount the new installation on e.g. /media/new and run

chroot /media/new
grub-install /dev/sdn

but that depends on your bootloader and on your disk configuration. Another possible approach which may be the least painful is to use the “recover bootloader” option from your distribution's installer, if it has one.

Once you've done the copy

Follow the steps in Moving linux install to a new computer to make the installations different. If you don't do that, you may run into trouble if you keep using the old installation.

0

rsync behaves more like scp, copying small files over a network connection. it would be far easier to pull the hard drive out, and use it as an external to your new computer and clone from there. that said, the best tool for that specific purpose might be tar and ssh, since it avoids the individual file checks that rsync and scp preform:

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'
  • 1
    This does not answer the question at all. The problem with copying a full linux system are paths like /dev and the bootloader. – grochmal Sep 17 '16 at 23:45
  • you can copy those system files, like any other file directory, if you really want to completely copy 1:1 you can use dd, but exercise with extreme caution – Vince Moosetaffy Sep 18 '16 at 01:43
  • 1
    No, you can't copy /dev (or /proc//sys). Copying the file does not make sense for those files. – grochmal Sep 18 '16 at 01:48
  • Seems there is no way to do it then? – xetra11 Sep 18 '16 at 07:14
  • I use rsync --info=progress2 -aAXHS --exclude={"/mntusb/dev/*","/mntusb/proc/*","/mntusb/sys/*","/mntusb/tmp/*","/mntusb/run/*","/mntusb/mnt/*","/mntusb/media/*","/mntusb/lost+found"} /mntusb/* /mnt where /mntusb has the source filesystem and /mnt has the destination filesystem. Feel free to adapt to your situation! – cylgalad Sep 18 '16 at 08:35
  • it doesnt make sense because many of those mounts are created dynamically, for example, dev does not exist when your computer is off, or at least, its empty. if you cant copy it, its not a file, but an ioctl to sysctl, in which case you shouldnt copy those to a new computer – Vince Moosetaffy Sep 19 '16 at 14:54