BACKGROUND:
As recommended here, I have my boot partition (/boot) and GRUB located on an external flash drive. Let's call that drive "sdb", and let's call the boot partition "sdb1".

I made a backup of that drive using "dd if=/dev/sdb of=~/bak/boot.img" and and I made a test copy to another drive with "dd if=~/bak/boot.img of=/dev/sdc" and the computer booted just fine with flash drive sdc.

Of course though "dd if=/dev/sdb of=~/bak/boot.img" copied sdb1 plus everything else, taking up a lot of space even with compression.

So I tried this: "dd if=/dev/sdb1 of=~/bak/sdb1.img" and then for the MBR "dd if=/dev/sdb of=~/bak/mbrsdb.bak bs=512 count=1". Then I backup up like this "dd if=~/bak/mbrsdv.bak bs=446 count=1" and "dd if=~/bak/sdb1.img of=/dev/sdc1" -- which didn't work on the empty drive, which I'm assuming is because there's no previous partition marked as sdx1. I then tried "dd if=~/bak/sdb1.img of=/dev/sdc" which just filled the whole disk space with sdb1 which wasn't what I wanted but I checked to see if it would boot; it didn't so I rewrote the MBR to it just in case sdb1 overwrote the MBR and it still wouldn't boot. I then used GParted to copy sdb1 to sdd1 and once again rewrote the MBR to sdd but it still wouldn't boot. I could go on and on about what I tried and didn't try, but beyond this I don't think it will help you answer my question.

QUESTION:
I want to make a copy of /boot located on sdb1 and sdb's mbr and write it to sdc so that sdc will boot like sdb does. Just in case you didn't understand what I wrote in "BACKGROUND," my /boot partition is on a flash drive as well as GRUB to prevent evil maid attacks.

Sorry if this is an inappropriate forum to post such a question, as I wasn't quite sure where to post backup questions. I considered "Linux - Software" and "Linux - Security" but was unsure so I posted here.

Welcome to LQ !

You can clone or copy the boot partition in question, but you'll have to reinstall grub in the sdc drive so it will properly rewrite the MBR. For that maybe this how to will give you a solution.

Regards

That is why it doesn't make sense to backup /boot using dd.

The only time it makes sense is if you have a small disk (a couple of GB or less). To use dd effectively you must also backup the MBR. Since partitions are separate from the MBR, using dd just doesn't quite work. You CAN use dd on the MBR... but unless the disk has the same partitioning, you cant restore the mbr AND the /boot partition (the block numbers will be different).

Since nearly every restore calls for reinstalling the boot blocks, it doesn't make sense to use dd.

I use tar. When/if I restore /boot (using a recovery CD/DVD with tar) I also reinstall grub. And tar takes up a lot less space.

Is this Grub2 or Grub Legacy?

It shouldn't really matter - reinstalling grub is still the most reliable method.

@Archy why do you copy 512bytes but only replay 446? And if so why dont you create a partition table afterwards?

If so you would at least have an sdc1 where you could put the old boot on.

The mbr contains the partition table so to get back a valid boot loader and a partitions (table) dd'ing the first 512 bytes should work. As dd makes an exact block copy of things the block number should also be the same. Thats the primary reason for using dd. To have an exact block copy of things.

Depends on what you mean with boot block. STage 1 of grub is in the mbr so only stage 2 or stage 1.5 (only grub 1) needs attention. To be on the safe side one should get a whole dd of the mbr and the boot partition. If you just create the boot parition and then copy files I say inodes differ and blocks differ so grub2 can't be found. But with dd should be good. Only thing I can think of is the uuid of the disk itself that would tackle grub.

Way to go I say.


To sum it up. Either dd all of sdb to the end of the boot partition and use that for sdc. Or tar the /boot partition, create new parition table on sdc, copy tar of /boot, rerun grub to sdc.

Depends on where the /boot partition is put. Granted, it is normally the first partition of the disk - but it doesn't have to be (at least, not anymore). Any boot blocks recorded in the MBR (and any extension blocks used) HAVE to match what is actually used. So trying to optimize a 512 byte block against a 4k block device gets to be problematical - the block numbers change.

As far as the UUID goes, that moves with the filesystem information So there, dd helps.

Absolute. I just assumed boot to be the first partition.

Youre having a point here with 512b and 4k blocks. As far as I use dd its with identical drives so I did not think about this also that is totaly the right realm here. Low level operations.

I was refering to the disk id itself not the id of the filesystem. Should have used serial to be clear.

Because i can give accurate instructions to installing Grub Legacy, but i have no idea for Grub2.

you can fill the drive with 0's so that it compresses better

Depends on the size of the partition (and filesystem). Filling with nulls (or any fixed value) does compress better... but the metadata for the file still isn't null, and with filesystems using 512 byte blocks and without extents, that can be a LOT of blocks on a TB disk. And since that metadata is also scattered it also reduces the compression even more.

The most compact storage is a tar file (or cpio). Either one removes all metadata - even that within the bitmap lists, inodes, backup homeblocks, directories, AND unused data.