2

I've made a 1to1 copy of my internal disk using dd. The external disk bootable but since the disks will be sharing the same uuids, the boot process will actually continue from the internal disk.

How to make a fully bootable backup of my internal disk to external disk?

Duplicate uuids seems to result in booting from internal disk rather than external disk. Any solution for this such as a wrapped dd that will keep care of this?

Purpose: first backup to external disk, boot from external disk, apply system upgrades, test upgrades after reboot. And if upgrades are successful, internal disk can be upgraded as well.

Paradox
  • 1,425
adrelanos
  • 1,836
  • 7
  • 30
  • 58
  • Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi) – Philip Couling Mar 12 '19 at 12:15
  • 1
    Please provide following iformation, because the filesystems and diskpartition types matter. cat /etc/fstab |grep -v '#'|grep .; sudo parted /dev/sda print What device label does target external disk get? (e.g. /dev/sdb?) – Manwe Mar 12 '19 at 12:24
  • 1
    Copy the menuentry from grub.cfg to /etc/grub.d/40_custom then change --root=/dev/sdaX to --root=/dev/sdbX in the 40_custom file, update grub. – GAD3R Mar 12 '19 at 13:29
  • There are some useful tips at the following link: Cloning from one drive to another drive – sudodus Mar 12 '19 at 16:01
  • dd is almost certainly the wrong tool for the job. It copies everything, included blank space. You'd better simply use cp, rsync or rdiff-backup; it will be much faster (and in the case of rdiff-backup, will provide incremental backups). – wazoox Mar 14 '19 at 16:13

6 Answers6

4

You are much better to turn off / unplug the internal disk.

But...

You can actually change the UUID of your backup drive after you backup. Remember to do this for every partition. For example /dev/sdb1:

# Generate a random UUID:
cat /proc/sys/kernel/random/uuid
7a5e6fad-4fa2-4177-b8a6-dfeeeb6289df

# Then use this for the partition UUID
tune2fs -U 7a5e6fad-4fa2-4177-b8a6-dfeeeb6289df /dev/sdb1

Then on the backup.... Check the following files for your old UUIDs and replace with the new one. You will need to replace <distribution> with your OS:

/etc/fstab
/boot/grub/grub.cfg
/boot/efi/EFI/<distribution>/grub.cfg

The harder problem will be convincing your BIOS to use the external EFI partition. If you cannot specify which drive to use... You might need to copy your EFI config on your main drive (eg: /boot/efi/EFI/debian/ to /boot/efi/EFI/backup/) and install that in your BIOS.

Philip Couling
  • 18,733
  • +1 for 'You are much better to turn off / unplug the internal disk.' – sudodus Mar 12 '19 at 15:44
  • Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :) – wazoox Mar 14 '19 at 16:10
  • Off the top of my head I can't remember whether or not tune2fs will echo out the new UUID, if not then it's useless to change the UUID if you don't know what the new one is. – Philip Couling Mar 14 '19 at 16:14
1

don't use disk dump. Why, because if you have a 500GB partition with only 1GB of data, dd will grab bit for bit all 500GB when all you truly need is 1GB. It also presents the problem of how you apply 500GB bit for bit to a different disk or partition that is not the same exact size. A better way, which solves your other problems of disk id, and solves the boot problem pointing to incorrect disk id or label is

  1. You are likely not able to correctly capture data off a root / partition of a currently operating Operating System disk. Therefore, you will have this bootable gold disk mounted and some other disk with a linux operating system will be running the computer.

  2. Mount your gold disk, such that if it contained for example,

    • /dev/sdb1 as /boot/efi type VFAT
    • /dev/sdb2 as SWAP
    • /dev/sdb3 as / type EXT4
    • mkdir /mygolddisk_sb1
    • mkdir /mygolddisk_sb3
    • mount /dev/sdb1 /mygolddisk_sdb1
    • mount /dev/sdb3 /mygolddisk_sdb3

  3. Now as root go and tar each partition you care about; if the partition is 1000 GB and you only have 2GB of data, then you will only get a 2GB tar file. Much easier to manage. This however does not make it file system independent, which is to say if your root partition is EXT4 and you untar it to a new disk partition of something other than whatever the original file system type was {EXT4} it will likely not boot. If for example the original root file system was XFS, then make the file system on the new disk XFS, if old disk root partition was EXT2 then make new disk root partition EXT2.

    • cd /mygolddisk_sdb1
    • tar -cf /somewhere_else/mygolddisk_efi_vfat.tar *
    • cd /mygolddisk_sdb3
    • tar -cf /somewhere_else/mygolddisk_root_ext4.tar *

  4. Mount your newor used blank disk; create partition table (preferably GPT)

  5. Make a same type partition as mygolddisk_efi_vfat.tar was made from; you may now make this partition any size as long as it's big enough to hold the data. Do the same for a SWAP partition if you so desire or need to. Same thing for root / partition and you can now make it size of the rest of this new disk. You will now end up with something like

    • /dev/sdc1 as VFAT 200MB in size, mygolddisk_efi_vfat.tar is 15MB.
    • /dev/sdc2 as SWAP as 2GB, could have been whatever size on old disk
    • /dev/sdc3 as EXT4 as remaining size of new disk, could be larger or smaller than root partition as on gold disk but only requirement is it is larger than mygolddisk_root_ext4.tar
    • mkdir /newdisk_Boot_partition
    • mkdir /newdisk_Root_partition
    • mount /dev/sdc1 /newdisk_Boot_partition
    • mount /dev/sdc3 /newdisk_Root_partition
    • cd /newdisk_Boot_partition
    • tar -xf /somewhere_else/mygolddisk_efi_vfat.tar .
    • cd /newdisk_Root_partition
    • tar -xf /somewhere_else/mygolddisk_root_ext4.tar .

  6. At this point you have now copied just the data that is relevant from your old {gold} disk. And it will be have been much faster than doing dd because you did not copy every bit which is HUGELY wasteful. It also won't transfer any file system problems from the old disk. But you are left with the problem of having copied files referencing disk UUID or label of your old disk which is no longer relevant on some new disk.

  7. You simply need to understand the boot process, whether it is EFI or GRUB. As well as if you are using an MBR partition table opposed to EFI, then dealing with MBR will pose an added complexity of having to modify the boot sector of the disk so it will boot {not describing, out of scope}. But using EFI and ELILO as an example for simplicity one would do the following

    • edit /boot/efi/.../elilo.conf
    • find the entry that points to the disk id or label of the old disk and change that to of the new disk
    • don't forget /etc/fstab which will contain the entries pointing to the old disk, change them (disk-id, label, uuid) to that of the new disk

  8. That was for a simple EFI and ELILO setup, that's all that needs to be done. If you are using GRUB2 and have a /boot partition as well as a separate /boot/efi partition then you will need to account for those specifically and modify the necessary GRUB files in a similar manner... just find any references to the old disk and change them to that of the new disk.

  9. When you partition, format, and mount your new disk that is where you will either know or see its new label (because you made it) or its UUID or its scsi id. Copy that UUID or scsi-id or label in place of the old in /newdisk_Root_partition/etc/fstab and in /newdisk_Boot_partition/efi/.../elilo.conf, or if using GRUB then into those relevant files under /newdisk_Boot_partition. Now the new disk will properly boot.

  10. Also know if you reference the disk by-name you can get away by doing this little trick: if boot partition is 1 and root partition is 3 for example, then make all disk references /dev/sda1 and /dev/sda3 respectively. This will only work if this disk gets named as sda and that will happen if it is the one and only disk connected to the computer. So when problems arise using some wrong UUID or scsi-id, just change everything to /dev/sda# and disconnect all other disks to get it to boot, and then fix things one step at a time. There are these ways to reference a disk partition in /etc/fstab and in the ELILO or GRUB boot files each having various pro's and con's: by-name, by-id, by-label, by-uuid, and by-path.
ron
  • 6,575
  • You can efficiently backup your system disk to another one by using cp, rsync or rdiff-backup. That won't require additional disk space for storing big tar files. rdiff-backup will provide incremental backup as a bonus. – wazoox Mar 15 '19 at 15:38
1

I actually did this earlier today! My laptop that I did this on uses legacy MBR-based BIOS boot (ThinkPad X201 Tablet), but most of these steps should be the same between (u)EFI and 'legacy' BIOSes. I have done similar on an EFI-based macintosh in the past.

1. Give partitions on the new drive new UUID's so they can be distinguished.

To update the UUID's of the new disk, boot from the old disk and run (for an ext* type partition):

tune2fs -U `uuidgen` /dev/sdb1

…if /dev/sdb1 is your new disk's partiton-to-re-UUID and you're booted in /dev/sda.

If it gives you an error, then it's probably going to ask you to run a filesystem check prior to renaming. Run the command tune2fs tells you to, and then run tune2fs again.

For other filesystems, you will need to figure out how you are able to change the UUID. Here are two more common ones:

  • btrfs uses btrfstune -U `uuidgen` /dev/sdb1.
  • I think XFS uses xfs_admin -U `uuidgen` /dev/sdb1, but I am not 100% sure on that since I have never used XFS personally.

Repeat that for all the partitions on the new disk.

2. edit new drive's /etc/fstab.

Mount the root partition of the new disk and edit /etc/fstab to replace the old disk's UUID's with the new UUID's. You can check what your new UUID's are by running blkid.

3. Boot to the new drive (with a temporary, stopgap solution) before continuing

At this point, for a temporary, one-time boot to the new drive, you can specify root=/dev/sdb1 (if /dev/sdb1 is your new disk's root partition) in the kernel parameters. In GRUB2, this is as easy as pressing 'e' on the linux boot entry and tacking it to the end of the line starting with linux. If your entire linux install was on one partition (no separate home partition, etc.), then you can do this from the beginning (before changing UUID's).

4. Update the ramdisk with your new fstab for future boots to use the right drive.

Next, we need to actually update the booted ramdisk. For the next step, I highly recommend just removing the original disk, if possible. If you can do that, then upon updating grub you can easily avoid adding the old disk to the available entries in your new disk's boot menu.

In any case, as root, you should run (on debian and derivates; I believe the command is update-initrd on some others):

update-initramfs -u

4.5 update GRUB menu entries (maybe not strictly necessary)

I am not sure if this is actually required, I am ashamed to admit. I did it because "it couldn't hurt," and it didn't on my laptop.

grub-install /dev/sdX

(where /dev/sdX is the drive you want the grub bootloader reinstalled on. Do not specify a partition, such as /dev/sdX1, etc. – only specify the device name).

This got my cloned disk booting without any issues on my first attempt. I've done this process more or less the same way in the past, when I last migrated to a larger drive.

You may have to change the boot priority of your disks in your BIOS/(U)EFI setup, too, to make it automatically use your disk if it's still giving you trouble.

Wyatt Ward
  • 4,032
0

You did not mention the filesystem types, but you can change the UUIDs, and generate random ones:

uuidgen

You can then change it on the parition. For ext-family...

tune2fs -U <output of uuidgen> /dev/sdb1

See this page for much more information.

Note that at this point you would also want to change the boot loader (if grub, then you can edit /boot/grub/grub.cfg in most cases) and also fstab to reflect the UUID changes.

It is my humble opinion that one option would be turning off the internal disk while you use the external. IIRC, there used to be switches for this (e.g. you mount the switch in a 3.5" or 5.25" bay).

number9
  • 1,064
0

I would use LABELS in /etc/fstab. I love having a system setup as such:

/etc/fstab

# <device>        <dir>        <type>        <options>        <dump> <fsck>
LABEL=EFI         /boot        vfat          defaults         0      2
LABEL=SYSTEM      /            ext4          defaults         0      1
LABEL=DATA        /home        ext4          defaults         0      2
LABEL=SWAP        none         swap          defaults         0      0

https://wiki.archlinux.org/index.php/fstab#File_system_labels

This allows you to make clones without worrying about UUID's changing.

Then just each time you would manually boot via the external HDD via your BIOS

FreeSoftwareServers
  • 2,582
0

If you have a Mac, you can go to Disk Utility, insert the drive, along with the drive you want to make. Click the drive you just inserted(not the one you need to copy), and then click the "recover" option. In the drop down menu, select the drive you want to copy, then click the ok button. Then, you should have a bootable drive!

Crypthusiast
  • 1