How to make a fully bootable backup of my internal disk to external disk? Issue with duplicate UUIDs












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.










share|improve this question

























  • Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi)

    – Philip Couling
    Mar 12 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 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 at 13:29













  • There are some useful tips at the following link: Cloning from one drive to another drive

    – sudodus
    Mar 12 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 at 16:13
















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.










share|improve this question

























  • Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi)

    – Philip Couling
    Mar 12 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 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 at 13:29













  • There are some useful tips at the following link: Cloning from one drive to another drive

    – sudodus
    Mar 12 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 at 16:13














2












2








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.










share|improve this question
















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.







boot backup






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 19 at 2:48









Paradox

209214




209214










asked Mar 4 at 15:04









adrelanosadrelanos

24731338




24731338













  • Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi)

    – Philip Couling
    Mar 12 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 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 at 13:29













  • There are some useful tips at the following link: Cloning from one drive to another drive

    – sudodus
    Mar 12 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 at 16:13



















  • Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi)

    – Philip Couling
    Mar 12 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 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 at 13:29













  • There are some useful tips at the following link: Cloning from one drive to another drive

    – sudodus
    Mar 12 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 at 16:13

















Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi)

– Philip Couling
Mar 12 at 12:15







Do you know if you are using EFI or legacy boot? (Check if you have a /boot/efi)

– Philip Couling
Mar 12 at 12:15






1




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 at 12:24







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 at 12:24






1




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 at 13:29







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 at 13:29















There are some useful tips at the following link: Cloning from one drive to another drive

– sudodus
Mar 12 at 16:01





There are some useful tips at the following link: Cloning from one drive to another drive

– sudodus
Mar 12 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 at 16:13





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 at 16:13










6 Answers
6






active

oldest

votes


















4





+50









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.






share|improve this answer


























  • +1 for 'You are much better to turn off / unplug the internal disk.'

    – sudodus
    Mar 12 at 15:44











  • Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

    – wazoox
    Mar 14 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 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.






share|improve this answer
























  • 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 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.






share|improve this answer

































    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).






    share|improve this answer


























    • Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

      – Philip Couling
      Mar 12 at 12:27











    • True, you would need to change the boot loader and fstab. I will add that in.

      – number9
      Mar 12 at 14:01



















    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






    share|improve this answer































      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!






      share|improve this answer























        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "106"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });














        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504278%2fhow-to-make-a-fully-bootable-backup-of-my-internal-disk-to-external-disk-issue%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        6 Answers
        6






        active

        oldest

        votes








        6 Answers
        6






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        4





        +50









        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.






        share|improve this answer


























        • +1 for 'You are much better to turn off / unplug the internal disk.'

          – sudodus
          Mar 12 at 15:44











        • Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

          – wazoox
          Mar 14 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 at 16:14
















        4





        +50









        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.






        share|improve this answer


























        • +1 for 'You are much better to turn off / unplug the internal disk.'

          – sudodus
          Mar 12 at 15:44











        • Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

          – wazoox
          Mar 14 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 at 16:14














        4





        +50







        4





        +50



        4




        +50





        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 12 at 13:18

























        answered Mar 12 at 12:26









        Philip CoulingPhilip Couling

        2,2901022




        2,2901022













        • +1 for 'You are much better to turn off / unplug the internal disk.'

          – sudodus
          Mar 12 at 15:44











        • Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

          – wazoox
          Mar 14 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 at 16:14



















        • +1 for 'You are much better to turn off / unplug the internal disk.'

          – sudodus
          Mar 12 at 15:44











        • Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

          – wazoox
          Mar 14 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 at 16:14

















        +1 for 'You are much better to turn off / unplug the internal disk.'

        – sudodus
        Mar 12 at 15:44





        +1 for 'You are much better to turn off / unplug the internal disk.'

        – sudodus
        Mar 12 at 15:44













        Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

        – wazoox
        Mar 14 at 16:10







        Go the short way: tune2fs -U $(cat /proc/sys/kernel/random/uuid) /dev/sdb1 :)

        – wazoox
        Mar 14 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 at 16:14





        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 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.






        share|improve this answer
























        • 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 at 15:38
















        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.






        share|improve this answer
























        • 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 at 15:38














        1












        1








        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 14 at 1:32









        ronron

        1,1702817




        1,1702817













        • 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 at 15:38



















        • 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 at 15:38

















        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 at 15:38





        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 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.






        share|improve this answer






























          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.






          share|improve this answer




























            1












            1








            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.






            share|improve this answer















            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 14 at 2:01

























            answered Mar 14 at 1:53









            Wyatt8740Wyatt8740

            1,7692817




            1,7692817























                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).






                share|improve this answer


























                • Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

                  – Philip Couling
                  Mar 12 at 12:27











                • True, you would need to change the boot loader and fstab. I will add that in.

                  – number9
                  Mar 12 at 14:01
















                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).






                share|improve this answer


























                • Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

                  – Philip Couling
                  Mar 12 at 12:27











                • True, you would need to change the boot loader and fstab. I will add that in.

                  – number9
                  Mar 12 at 14:01














                0












                0








                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).






                share|improve this answer















                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).







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 12 at 14:01

























                answered Mar 12 at 12:17









                number9number9

                56527




                56527













                • Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

                  – Philip Couling
                  Mar 12 at 12:27











                • True, you would need to change the boot loader and fstab. I will add that in.

                  – number9
                  Mar 12 at 14:01



















                • Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

                  – Philip Couling
                  Mar 12 at 12:27











                • True, you would need to change the boot loader and fstab. I will add that in.

                  – number9
                  Mar 12 at 14:01

















                Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

                – Philip Couling
                Mar 12 at 12:27





                Just a note that simply changing the UUID, won't fix the config set to boot from the old UUID.

                – Philip Couling
                Mar 12 at 12:27













                True, you would need to change the boot loader and fstab. I will add that in.

                – number9
                Mar 12 at 14:01





                True, you would need to change the boot loader and fstab. I will add that in.

                – number9
                Mar 12 at 14:01











                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






                share|improve this answer




























                  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






                  share|improve this answer


























                    0












                    0








                    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






                    share|improve this answer













                    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







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Mar 13 at 23:09









                    FreeSoftwareServersFreeSoftwareServers

                    1,00931941




                    1,00931941























                        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!






                        share|improve this answer




























                          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!






                          share|improve this answer


























                            0












                            0








                            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!






                            share|improve this answer













                            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!







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Mar 17 at 23:15









                            CrypthusiastCrypthusiast

                            1




                            1






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Unix & Linux Stack Exchange!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504278%2fhow-to-make-a-fully-bootable-backup-of-my-internal-disk-to-external-disk-issue%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                How to make a Squid Proxy server?

                                Is this a new Fibonacci Identity?

                                19世紀