Hi

I did a google search on this and there are many, but I'm not sure if those codes applies to SSD or hard drives where the start sector begins at 2048 and not the old standard of 63.

This is the typical code I see

Here is my SSD geometry:

When my Western Digital harddrive died, programs like testdisk or windows repair couldn't fix the boot sector. I don't want to repeat that again. I want to have a backup of the boot sector of this SSD drive so I can restore it back if something goes wrong. As you can see the sector starts at 2048.


Can I still use the code above using bs=512 or do I need to adjust that number for 2048? Thanks

bs = Block size so is the size of each block, not the start of the partition.

Your output shows the sector sizes are 512 bytes so bs=512 is appropriate.

To deal with start and end you change count not bs. Although your boot PARTITION is 300M the boot SECTOR is typically the first one on the partition which is why you see "count=1".

Even if it no longer applies ?. Not a great idea IMHO.
And what about logical partitions ?.

The boot code can be re-installed anytime from a chroot using a liveCD. Much more robust.
As for the partition table, use something that understands it, like sfdisk - dd is dumber than dirt. It's a great tool for what it was designed - this is a mis-use.

What do you mean by "boot sector"?

The partition starting at sector 2048 isn't your PC's boot sector, it's your Linux boot partition, containing /boot.

The following applies to a MBR partitioned scheme:

The "boot sector" itself is the 512-byte sector starting at the beginning of the disk that contains stage 1 of the boot process (and the MBR table).

Sectors 1 to 62 contain stage 1.5 of the boot process.

Sectors 63 to 2047 should contain nothing (these days they're essentially there for 1MiB partition boundary alignment purposes, driven by the introduction of drives with 4096-byte physical sectors).

Then comes your stage 2 /boot partition.

https://en.wikipedia.org/wiki/File:G...isk_drives.svg

So what is it that you want to save?

I would suggest that you probably don't know enough about what you're doing for this backup to be terribly useful. But better to have it and not have a use for it later than need it later but not have it! So, what the heck? Take an image of it if you will. Just don't do it while you have any partitions of this disk mounted (boot up to a LiveCD or another disk or something, and make sure whatever you're using doesn't autodetect swap partitions on that drive - which isn't a problem in this case since you have no swap partition).

Why do I say this?

You don't know the meaning of "2048" above. As others noted, "2048" means it starts on sector 2048, with each sector 512 bytes. So, it starts on byte 2048*512 = 1048576 (or 1MB).

That said, if you're going to do this, do it this way:

This will make a backup of the first 1048576 bytes. Note that the specific bs used is not terribly important so long as bs*count equals 1MB. There are historical reasons why bs was significant for performance reasons involving tape backup, but whatever.

With this image, you can choose to restore the full 2048 sectors or just the first one, if you like. You can do the restore with either of:
The first command will only overwrite the first 512 bytes (the first sector, sector 0). The second command will overwrite the first 1048576 bytes (the first 2048 sectors, sectors 0-2047).

Note that this backup/restore will include the partition table, which has a very good chance of breaking things if something has really gone wrong with the drive or its partitions, or the partition table has changed for any reason. For this reason, I tend to prefer to take an image of the entire drive, including all of its partitions. This sort of image takes forever, but it gets everything.

SSD's are tricky when it comes to how boot sector works. Mechanical is almost always the 512 on older stuff so dd is OK to use. You won't be able to swap the two if you save them. They will only be useful for going back.

There are a few differences between mechanical and ssd too on how installers work.

Could be some issues with how your ssd was initially installed. UEFI?

Some tech info. http://www.linux-mag.com/id/8397/

Sorry for my ignorance...

My SSD is using legacy MBR.

All I want to do is backup my MBR so I can have a backup and restore it when needed.

Since everyone here agrees that bs=512 and count=1, then I will use these values. I appreciate your replies and your knowledge to guide me in the right path.

Thanks to all

Another option is to use a partition imaging application (booting from the application's boot media) which automatically backs up the MBR sector when it images a partition, allowing you at any future point to replace that sector.

I use Macrium Reflect but there are other such programs available.

1 members found this post helpful.

Would you care to elaborate on that? The article you linked to deals with 4KB physical alignment, and the issues would be similar to those for a mechanical disk drive with 4KB physical sectors. I checked all of my SSDs (480GB largest), and they are all 512B physical / 512B logical. I've never seen an SSD that discloses its internal page sizes or erase block sizes, so all you can do is use today's default of 1MB alignment and hope that's adequate for performance. My laptop is currently running with a 480GB SSD that was initially set up by using dd to copy an image from the existing 500GB HDD, with the only adjustment being to free up 20GB from the end of the disk so that everything would fit. Works nicely. Yes, the partitions were already on 1MB boundaries.

The "boot sector" and the "MBR" are the same thing. In a MBR setup, the code in sector 1 of the hard drive loads the BIOS code into memory, and starts the system. It also contains the old-style (vs. GPT) MBR partition table.

You can copy the boot sector as much as you want, without worrying about it being on a running system, or whether there are mounted drives.

The "dd" command in the OP will work fine for the purpose. But SSD drives have controllers that parallelize the reads and writes, because NAND flash is slow. But, if the drive is writing to thousands of different locations simultaneously, it makes the flash memory "seem" faster than a HDD.

For that reason, I do not think it's reliable to assume a SSD will always write where you think it should, to sector 1 for instance, as a HDD will with "dd".

But, I might be incorrect on that last thing.