How can I make a backup of an EFI System partition?












6















Before I start making changes to the ESP I want to make a backup of it. Can I just copy the files and directories within it, let's say with my file manager, or cp, or do I have to use some tool like dd. Also, does it matter what filesystem I put my backup on? If I do it the first way, using thunar or cp, do I have to put it on a FAT32 filesystem?



Thanks.










share|improve this question



























    6















    Before I start making changes to the ESP I want to make a backup of it. Can I just copy the files and directories within it, let's say with my file manager, or cp, or do I have to use some tool like dd. Also, does it matter what filesystem I put my backup on? If I do it the first way, using thunar or cp, do I have to put it on a FAT32 filesystem?



    Thanks.










    share|improve this question

























      6












      6








      6


      2






      Before I start making changes to the ESP I want to make a backup of it. Can I just copy the files and directories within it, let's say with my file manager, or cp, or do I have to use some tool like dd. Also, does it matter what filesystem I put my backup on? If I do it the first way, using thunar or cp, do I have to put it on a FAT32 filesystem?



      Thanks.










      share|improve this question














      Before I start making changes to the ESP I want to make a backup of it. Can I just copy the files and directories within it, let's say with my file manager, or cp, or do I have to use some tool like dd. Also, does it matter what filesystem I put my backup on? If I do it the first way, using thunar or cp, do I have to put it on a FAT32 filesystem?



      Thanks.







      partitioning uefi backup copy






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 17 '15 at 3:15









      hockeykonghockeykong

      49110




      49110






















          2 Answers
          2






          active

          oldest

          votes


















          7














          You can just copy everything inside it (i.e. e.g. sudo cp -R /boot/efi /path/to/backup is fine, however personally I'd suggest to use tar: sudo tar cfz /path/to/backup/ESP_backup.tar.gz /boot/efi);



          The filesystem in which to store the backup is irrelevant; the only concern might be the permissions, but the UEFI firmware doesn't cater for Linux permissions (in fact FAT32 doesn't even support them), so that's not a concern at all.






          share|improve this answer
























          • Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

            – hockeykong
            Nov 17 '15 at 4:13











          • @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

            – kos
            Nov 17 '15 at 4:22













          • Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

            – hockeykong
            Nov 17 '15 at 4:41













          • @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

            – kos
            Nov 17 '15 at 5:00











          • @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

            – kos
            Nov 17 '15 at 5:01



















          2














          Kos's answer is a good one. I want to bring up one more point, though: If you back up the ESP to a FAT partition on a USB flash drive, you may be able to boot using the backup in an emergency. That is, suppose that the ESP is accidentally trashed without your knowledge and you shut down the computer. When you power it up, the computer will no longer boot. If you plug in your backup, though, you may be able to boot from it, without using any other emergency recovery tools, and then copy the backup back to the ESP. For this to work, though, you'll need one of two things:





          • A fallback boot loader -- The filename EFI/BOOT/bootx64.efi (or equivalent for other architectures) on a FAT partition is the fallback filename, which the firmware uses if no other NVRAM-specified option works, or when booting from removable media. Some OSes (like Windows) automatically put a copy of their boot loaders under this name, in addition to their regular name. Ubuntu doesn't do this, but you can create such a copy easily enough -- just copy the EFI/ubuntu directory (on the ESP or on your backup) to EFI/BOOT and then rename shimx64.efi (or grubx64.efi, if shimx64.efi is absent) in the EFI/BOOT directory to bootx64.efi.


          • Firmware support for booting from an arbitrary file -- Some EFIs provide a way for you to boot from an arbitrary file. You pick a "boot from file" option in the firmware setup utility or boot manager, whereupon the EFI shows you a file-selection tool. You use that tool to browse to the boot loader you want to use -- EFI/ubuntu/shimx64.efi (for Secure Boot support) or EFI/ubuntu/grubx64.efi in this case.


          You can set up your backup with a fallback boot loader filename yourself, so the first approach will work on any EFI-based computer. The second depends on the features provided by the manufacturer, though, so you should check to see if this feature is available before you rely on it. Either way, testing your ability to boot in this way may be worth doing.



          If your backup is in some other form (like a tarball or buried deep in a directory tree) or on a filesystem other than FAT, and if the ESP is damaged to the point where you can't boot, you'll need to use an emergency system (an Ubuntu "live CD," a rEFInd image on removable disk, etc.) to boot either an emergency system or your regular installation, from which you can restore the backup. This isn't a huge hassle, of course, although if you don't have such a tool handy already it could be a nuisance, especially if you don't have another computer on which to download and prepare the recovery tool. Keeping the backup in the form of a removable disk might therefore make things go just a little bit more smoothly.






          share|improve this answer
























          • Great remarks. Indeed backing up to a drive has its added values.

            – kos
            Nov 17 '15 at 14:38











          • Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

            – hockeykong
            Nov 17 '15 at 19:48











          • I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

            – Rod Smith
            Nov 17 '15 at 20:48











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "89"
          };
          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: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          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%2faskubuntu.com%2fquestions%2f698980%2fhow-can-i-make-a-backup-of-an-efi-system-partition%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          7














          You can just copy everything inside it (i.e. e.g. sudo cp -R /boot/efi /path/to/backup is fine, however personally I'd suggest to use tar: sudo tar cfz /path/to/backup/ESP_backup.tar.gz /boot/efi);



          The filesystem in which to store the backup is irrelevant; the only concern might be the permissions, but the UEFI firmware doesn't cater for Linux permissions (in fact FAT32 doesn't even support them), so that's not a concern at all.






          share|improve this answer
























          • Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

            – hockeykong
            Nov 17 '15 at 4:13











          • @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

            – kos
            Nov 17 '15 at 4:22













          • Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

            – hockeykong
            Nov 17 '15 at 4:41













          • @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

            – kos
            Nov 17 '15 at 5:00











          • @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

            – kos
            Nov 17 '15 at 5:01
















          7














          You can just copy everything inside it (i.e. e.g. sudo cp -R /boot/efi /path/to/backup is fine, however personally I'd suggest to use tar: sudo tar cfz /path/to/backup/ESP_backup.tar.gz /boot/efi);



          The filesystem in which to store the backup is irrelevant; the only concern might be the permissions, but the UEFI firmware doesn't cater for Linux permissions (in fact FAT32 doesn't even support them), so that's not a concern at all.






          share|improve this answer
























          • Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

            – hockeykong
            Nov 17 '15 at 4:13











          • @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

            – kos
            Nov 17 '15 at 4:22













          • Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

            – hockeykong
            Nov 17 '15 at 4:41













          • @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

            – kos
            Nov 17 '15 at 5:00











          • @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

            – kos
            Nov 17 '15 at 5:01














          7












          7








          7







          You can just copy everything inside it (i.e. e.g. sudo cp -R /boot/efi /path/to/backup is fine, however personally I'd suggest to use tar: sudo tar cfz /path/to/backup/ESP_backup.tar.gz /boot/efi);



          The filesystem in which to store the backup is irrelevant; the only concern might be the permissions, but the UEFI firmware doesn't cater for Linux permissions (in fact FAT32 doesn't even support them), so that's not a concern at all.






          share|improve this answer













          You can just copy everything inside it (i.e. e.g. sudo cp -R /boot/efi /path/to/backup is fine, however personally I'd suggest to use tar: sudo tar cfz /path/to/backup/ESP_backup.tar.gz /boot/efi);



          The filesystem in which to store the backup is irrelevant; the only concern might be the permissions, but the UEFI firmware doesn't cater for Linux permissions (in fact FAT32 doesn't even support them), so that's not a concern at all.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 17 '15 at 4:04









          koskos

          25.8k871121




          25.8k871121













          • Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

            – hockeykong
            Nov 17 '15 at 4:13











          • @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

            – kos
            Nov 17 '15 at 4:22













          • Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

            – hockeykong
            Nov 17 '15 at 4:41













          • @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

            – kos
            Nov 17 '15 at 5:00











          • @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

            – kos
            Nov 17 '15 at 5:01



















          • Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

            – hockeykong
            Nov 17 '15 at 4:13











          • @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

            – kos
            Nov 17 '15 at 4:22













          • Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

            – hockeykong
            Nov 17 '15 at 4:41













          • @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

            – kos
            Nov 17 '15 at 5:00











          • @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

            – kos
            Nov 17 '15 at 5:01

















          Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

          – hockeykong
          Nov 17 '15 at 4:13





          Thank you @kos. I've looked around here in help sections but could not find how to indicate question closed, answered properly.

          – hockeykong
          Nov 17 '15 at 4:13













          @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

          – kos
          Nov 17 '15 at 4:22







          @hockeykong You're welcome; you may "accept" the answer by clicking the grey mark under the votes count; that's your way to state that the answer was the most helpful to solve your problem (this also has the side effect of showing the bottom circle on the side of the question in the question list as green, visually indicating that the question was "accepted"): also have a read here for more informations about this

          – kos
          Nov 17 '15 at 4:22















          Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

          – hockeykong
          Nov 17 '15 at 4:41







          Any particular reason why you prefer having it compressed? I figure in this case the content is small (34MB) and I won't need a special tool to read the content if it's not. I always worry I won't have some needed tool. But then again maybe gzip or some other program to make compressed tarballs is omnipresent in todays linux systems. I don't know about Windows-7 though. I haven't done much with it except play a couple of games.

          – hockeykong
          Nov 17 '15 at 4:41















          @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

          – kos
          Nov 17 '15 at 5:00





          @hockeykong No, that's just a personal preference. I think archiving them is useful in order to move them around with ease and restore them with a single command; compressing them allows to move them around with more ease, after all the overhead of decompressing, expecially in this case, is usualy moderate, you're usually more IO bound. However no, no particular reason. Tar is part of GNU so I think it's present in the vast majority of GNU/Linux distributions, although technically the same can't be said for gzip (but my bet is gzip is just as much widespread).

          – kos
          Nov 17 '15 at 5:00













          @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

          – kos
          Nov 17 '15 at 5:01





          @hockeykong As for Windows, I don't know if the latest versions of Windows support compressed tarballs natively, but in any case 7-zip should.

          – kos
          Nov 17 '15 at 5:01













          2














          Kos's answer is a good one. I want to bring up one more point, though: If you back up the ESP to a FAT partition on a USB flash drive, you may be able to boot using the backup in an emergency. That is, suppose that the ESP is accidentally trashed without your knowledge and you shut down the computer. When you power it up, the computer will no longer boot. If you plug in your backup, though, you may be able to boot from it, without using any other emergency recovery tools, and then copy the backup back to the ESP. For this to work, though, you'll need one of two things:





          • A fallback boot loader -- The filename EFI/BOOT/bootx64.efi (or equivalent for other architectures) on a FAT partition is the fallback filename, which the firmware uses if no other NVRAM-specified option works, or when booting from removable media. Some OSes (like Windows) automatically put a copy of their boot loaders under this name, in addition to their regular name. Ubuntu doesn't do this, but you can create such a copy easily enough -- just copy the EFI/ubuntu directory (on the ESP or on your backup) to EFI/BOOT and then rename shimx64.efi (or grubx64.efi, if shimx64.efi is absent) in the EFI/BOOT directory to bootx64.efi.


          • Firmware support for booting from an arbitrary file -- Some EFIs provide a way for you to boot from an arbitrary file. You pick a "boot from file" option in the firmware setup utility or boot manager, whereupon the EFI shows you a file-selection tool. You use that tool to browse to the boot loader you want to use -- EFI/ubuntu/shimx64.efi (for Secure Boot support) or EFI/ubuntu/grubx64.efi in this case.


          You can set up your backup with a fallback boot loader filename yourself, so the first approach will work on any EFI-based computer. The second depends on the features provided by the manufacturer, though, so you should check to see if this feature is available before you rely on it. Either way, testing your ability to boot in this way may be worth doing.



          If your backup is in some other form (like a tarball or buried deep in a directory tree) or on a filesystem other than FAT, and if the ESP is damaged to the point where you can't boot, you'll need to use an emergency system (an Ubuntu "live CD," a rEFInd image on removable disk, etc.) to boot either an emergency system or your regular installation, from which you can restore the backup. This isn't a huge hassle, of course, although if you don't have such a tool handy already it could be a nuisance, especially if you don't have another computer on which to download and prepare the recovery tool. Keeping the backup in the form of a removable disk might therefore make things go just a little bit more smoothly.






          share|improve this answer
























          • Great remarks. Indeed backing up to a drive has its added values.

            – kos
            Nov 17 '15 at 14:38











          • Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

            – hockeykong
            Nov 17 '15 at 19:48











          • I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

            – Rod Smith
            Nov 17 '15 at 20:48
















          2














          Kos's answer is a good one. I want to bring up one more point, though: If you back up the ESP to a FAT partition on a USB flash drive, you may be able to boot using the backup in an emergency. That is, suppose that the ESP is accidentally trashed without your knowledge and you shut down the computer. When you power it up, the computer will no longer boot. If you plug in your backup, though, you may be able to boot from it, without using any other emergency recovery tools, and then copy the backup back to the ESP. For this to work, though, you'll need one of two things:





          • A fallback boot loader -- The filename EFI/BOOT/bootx64.efi (or equivalent for other architectures) on a FAT partition is the fallback filename, which the firmware uses if no other NVRAM-specified option works, or when booting from removable media. Some OSes (like Windows) automatically put a copy of their boot loaders under this name, in addition to their regular name. Ubuntu doesn't do this, but you can create such a copy easily enough -- just copy the EFI/ubuntu directory (on the ESP or on your backup) to EFI/BOOT and then rename shimx64.efi (or grubx64.efi, if shimx64.efi is absent) in the EFI/BOOT directory to bootx64.efi.


          • Firmware support for booting from an arbitrary file -- Some EFIs provide a way for you to boot from an arbitrary file. You pick a "boot from file" option in the firmware setup utility or boot manager, whereupon the EFI shows you a file-selection tool. You use that tool to browse to the boot loader you want to use -- EFI/ubuntu/shimx64.efi (for Secure Boot support) or EFI/ubuntu/grubx64.efi in this case.


          You can set up your backup with a fallback boot loader filename yourself, so the first approach will work on any EFI-based computer. The second depends on the features provided by the manufacturer, though, so you should check to see if this feature is available before you rely on it. Either way, testing your ability to boot in this way may be worth doing.



          If your backup is in some other form (like a tarball or buried deep in a directory tree) or on a filesystem other than FAT, and if the ESP is damaged to the point where you can't boot, you'll need to use an emergency system (an Ubuntu "live CD," a rEFInd image on removable disk, etc.) to boot either an emergency system or your regular installation, from which you can restore the backup. This isn't a huge hassle, of course, although if you don't have such a tool handy already it could be a nuisance, especially if you don't have another computer on which to download and prepare the recovery tool. Keeping the backup in the form of a removable disk might therefore make things go just a little bit more smoothly.






          share|improve this answer
























          • Great remarks. Indeed backing up to a drive has its added values.

            – kos
            Nov 17 '15 at 14:38











          • Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

            – hockeykong
            Nov 17 '15 at 19:48











          • I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

            – Rod Smith
            Nov 17 '15 at 20:48














          2












          2








          2







          Kos's answer is a good one. I want to bring up one more point, though: If you back up the ESP to a FAT partition on a USB flash drive, you may be able to boot using the backup in an emergency. That is, suppose that the ESP is accidentally trashed without your knowledge and you shut down the computer. When you power it up, the computer will no longer boot. If you plug in your backup, though, you may be able to boot from it, without using any other emergency recovery tools, and then copy the backup back to the ESP. For this to work, though, you'll need one of two things:





          • A fallback boot loader -- The filename EFI/BOOT/bootx64.efi (or equivalent for other architectures) on a FAT partition is the fallback filename, which the firmware uses if no other NVRAM-specified option works, or when booting from removable media. Some OSes (like Windows) automatically put a copy of their boot loaders under this name, in addition to their regular name. Ubuntu doesn't do this, but you can create such a copy easily enough -- just copy the EFI/ubuntu directory (on the ESP or on your backup) to EFI/BOOT and then rename shimx64.efi (or grubx64.efi, if shimx64.efi is absent) in the EFI/BOOT directory to bootx64.efi.


          • Firmware support for booting from an arbitrary file -- Some EFIs provide a way for you to boot from an arbitrary file. You pick a "boot from file" option in the firmware setup utility or boot manager, whereupon the EFI shows you a file-selection tool. You use that tool to browse to the boot loader you want to use -- EFI/ubuntu/shimx64.efi (for Secure Boot support) or EFI/ubuntu/grubx64.efi in this case.


          You can set up your backup with a fallback boot loader filename yourself, so the first approach will work on any EFI-based computer. The second depends on the features provided by the manufacturer, though, so you should check to see if this feature is available before you rely on it. Either way, testing your ability to boot in this way may be worth doing.



          If your backup is in some other form (like a tarball or buried deep in a directory tree) or on a filesystem other than FAT, and if the ESP is damaged to the point where you can't boot, you'll need to use an emergency system (an Ubuntu "live CD," a rEFInd image on removable disk, etc.) to boot either an emergency system or your regular installation, from which you can restore the backup. This isn't a huge hassle, of course, although if you don't have such a tool handy already it could be a nuisance, especially if you don't have another computer on which to download and prepare the recovery tool. Keeping the backup in the form of a removable disk might therefore make things go just a little bit more smoothly.






          share|improve this answer













          Kos's answer is a good one. I want to bring up one more point, though: If you back up the ESP to a FAT partition on a USB flash drive, you may be able to boot using the backup in an emergency. That is, suppose that the ESP is accidentally trashed without your knowledge and you shut down the computer. When you power it up, the computer will no longer boot. If you plug in your backup, though, you may be able to boot from it, without using any other emergency recovery tools, and then copy the backup back to the ESP. For this to work, though, you'll need one of two things:





          • A fallback boot loader -- The filename EFI/BOOT/bootx64.efi (or equivalent for other architectures) on a FAT partition is the fallback filename, which the firmware uses if no other NVRAM-specified option works, or when booting from removable media. Some OSes (like Windows) automatically put a copy of their boot loaders under this name, in addition to their regular name. Ubuntu doesn't do this, but you can create such a copy easily enough -- just copy the EFI/ubuntu directory (on the ESP or on your backup) to EFI/BOOT and then rename shimx64.efi (or grubx64.efi, if shimx64.efi is absent) in the EFI/BOOT directory to bootx64.efi.


          • Firmware support for booting from an arbitrary file -- Some EFIs provide a way for you to boot from an arbitrary file. You pick a "boot from file" option in the firmware setup utility or boot manager, whereupon the EFI shows you a file-selection tool. You use that tool to browse to the boot loader you want to use -- EFI/ubuntu/shimx64.efi (for Secure Boot support) or EFI/ubuntu/grubx64.efi in this case.


          You can set up your backup with a fallback boot loader filename yourself, so the first approach will work on any EFI-based computer. The second depends on the features provided by the manufacturer, though, so you should check to see if this feature is available before you rely on it. Either way, testing your ability to boot in this way may be worth doing.



          If your backup is in some other form (like a tarball or buried deep in a directory tree) or on a filesystem other than FAT, and if the ESP is damaged to the point where you can't boot, you'll need to use an emergency system (an Ubuntu "live CD," a rEFInd image on removable disk, etc.) to boot either an emergency system or your regular installation, from which you can restore the backup. This isn't a huge hassle, of course, although if you don't have such a tool handy already it could be a nuisance, especially if you don't have another computer on which to download and prepare the recovery tool. Keeping the backup in the form of a removable disk might therefore make things go just a little bit more smoothly.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 17 '15 at 14:27









          Rod SmithRod Smith

          35.5k43970




          35.5k43970













          • Great remarks. Indeed backing up to a drive has its added values.

            – kos
            Nov 17 '15 at 14:38











          • Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

            – hockeykong
            Nov 17 '15 at 19:48











          • I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

            – Rod Smith
            Nov 17 '15 at 20:48



















          • Great remarks. Indeed backing up to a drive has its added values.

            – kos
            Nov 17 '15 at 14:38











          • Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

            – hockeykong
            Nov 17 '15 at 19:48











          • I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

            – Rod Smith
            Nov 17 '15 at 20:48

















          Great remarks. Indeed backing up to a drive has its added values.

          – kos
          Nov 17 '15 at 14:38





          Great remarks. Indeed backing up to a drive has its added values.

          – kos
          Nov 17 '15 at 14:38













          Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

          – hockeykong
          Nov 17 '15 at 19:48





          Am I right in assuming that on a fat32 formatted block device (a usb key for example) I don't need to make a separate fat32 partition to put this on, with nothing else on it? i.e. I could simply make a directory named "EFI" and create subdirectories: /BOOT, /ubuntu, /Microsoft, etc. and put what's needed in there? Thanks again for the wealth of info. I'm sure it will be useful to others also. UEFI only systems will apparently become more common and it's easy to get mixed up will all the advices given that involve MBR and BIOS, when it's not always explicit. None of that in my case.

          – hockeykong
          Nov 17 '15 at 19:48













          I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

          – Rod Smith
          Nov 17 '15 at 20:48





          I'd recommend partitioning the drive if you do this, even if it's just to create a single FAT32 partition. I say this because the specs talk about the EFI System Partition. I don't recall if they say anything explicit about booting from an unpartitioned disk. To be sure, it might work; I've just never tried it. Also, even if it does work on one system, it might fail on another -- or even on the same system if a firmware update changes the way the computer reacts to an unpartitioned disk.

          – Rod Smith
          Nov 17 '15 at 20:48


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Ask Ubuntu!


          • 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%2faskubuntu.com%2fquestions%2f698980%2fhow-can-i-make-a-backup-of-an-efi-system-partition%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

          Questions related to Moebius Transform of Characteristic Function of the Primes

          List of scandals in India

          Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?