Remake SW RAID1 from a new HDD and an old HDD with bad blocks – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, debian, software-raid, mdadm, raid1.
I have a SW RAID1 and I just replaced /dev/sda with a new HDD as the old one failed.
Now, upon trying to recreate the RAID array I discovered that the “good” HDD (/dev/sdb) has bad blocks with prevent mdadm from resyncing the array.
While I could make backups, replace /dev/sdb as well and re-install the server completely I was wondering if there is any way I could “trick” mdadm into resyncing the RAID array and then replace /dev/sdb with a new HDD.
From what I can guess the badblocks are located in an unused area of /dev/sdb which is only used when trying to recreate the RAID array.
Can you verify whether the affected blocks and underlying bad sectors on the disk are reallocated to “spare sectors” area? The bad sector should be reallocated when write operation fails. Verify it with smartctl:
smartctl -a /dev/sdb | grep -i reallocated
The last column should contain a number of total reallocated sectors. If there is zero try to read the bad sector:
hdparm –-read-sector XXXXXXXX /dev/sdb
It should return an I/O error otherwise I would recommend to skip next section.
The error means the sector was not reallocated yet. So you can try to reallocate it forcibly by writing it. Remember that any data stored in this sector will be lost after this step !!!:
hdparm –-write-sector XXXXXXXX --yes-i-know-what-i-am-doing /dev/sdb
By the way, the sector number XXXXXXXX should be possible to obtain from kernel messages (dmesg command or from /var/log/messages). As you had bad blocks during resynchronisation there should be some related messages similar to:
... end_request: I/O error, dev sdb, sector 1261071601
Then, try to verify it with smartctl again. Does the counter increased? If so try to read it with hdparm. Now, it should read it without any error as it is supposed to be reallocated. Done.
Finally, you can continue with mdadm and with adding the disk to your degraded mirror.
A better strategy would be to use ddrescue to copy bad drive to good. This tool tries hard to read entire drive, doing re-reads and “trimming” unreadable blocks. It also produces log, which is used for saving progress, but ultimately will contain the list of bad blocks. You can then parse this list and write to every bad block to see if the drive will survive remapping them all. If it will, you can mdadm –zero-superblock and then just add it as a new drive to your degraded raid1. BTW, for today’s high capacity drives it is pretty normal to produce “soft” bad blocks from time to time. Just do your raid check weekly, and you’ll be ok, unless the same block gets unreadable on two drives, which is very unlikely.