You've got a three-way mirror there: each drive has a complete copy of all data. Assuming the drive you want to remove is /dev/sdc, and you want to remove it from all three arrays, you'd perform the following steps for /dev/sdc1, /dev/sdc2, and /dev/sdc4.
Step 1: Remove the drive from the array. You can't remove an active device from an array, so you need ...
It's because the device nodes no longer exist on your system (probably udev removed them when the drive died). You should be able to remove them by using the keyword failed or detached instead:
mdadm -r /dev/md0 failed # all failed devices
mdadm -r /dev/md0 detached # failed ones that aren't in /dev anymore
If your version of mdadm is too old to do ...
I found out the answer by asking on the mailing-list.
btrfs doesn't do RAID per-volume, but rather on a per-chunk basis. The filesystem reserves "raw" space in (p.e.) 1GB chunks. Initializing the fs with raid1 means that every time it tries to allocate a chunk, it tries to allocate a copy of this chunk on another device.
This architecture allows mixed-size ...
An identical copy of your data is stored on each disk (provided the array is not "dirty"—e.g., if power is lost after writing to disk 0, but before writing to disk 1). However, the metadata is different; it allows mdadm & md to tell the two disks apart.
Can you swap the cables around?
You can swap the cables on the two disks. When you (or your distro's ...
We have configured all of our servers to run regular selftests with the following line in /etc/smartd.conf:
# DEVICESCAN matches all hard disks found in /dev/ and applies the following
# options to them.
# Default options from Debian:
# -d removable don't exit when the device when a device vanishes
# -n standby don't wake a device up that is ...
What I ended up doing was using mknod like @derobert suggested to create the devices that mdadm was looking for. I tried the major/minor numbers mdadm was telling me it couldn't find with the different drive letters I was trying to remove until it worked.
mknod /dev/sde1 b 8 17
Then I had to use the --force option to get it remove the component.
You can check the current state of the array with cat /proc/mdstat. In this example, that's where the data comes from.
So let's assume we have md127 with 3 disks in a raid1. Here they're just partitions of one disk, but it doesn't matter
md127 : active raid1 vdb3 vdb2 vdb1
102272 blocks super 1.2 [3/3] [UUU]
We need to offline one of the ...
Turns out that this is a limitation of btrfs as of beginning of 2017. To get the filesystem mounted rw again, one needs to patch the kernel. I have not tried it though. I am planing to move away from btrfs because of this; one should not have to patch a kernel to be able to replace a faulty disk.
Click on the following links for details:
Kernel patch ...
Have a look at this question. I assume that is familiar to your problem.
Recreating and even syncing a RAID-1 should not destroy data. Obviously the MD device starts at another offset now. Thus where mount looks for a superblock there is data. This can have happened in at least two ways:
You (or rather: the default setting) have created the new array with ...
There's metadata at the start of the partition. If you do a
mdadm -E /dev/sda1
you'll see where the data starts (Data Offset). That will be where your FS starts. You could use fdisk (for MBR-type partitioning) or gdisk (for GPT), to move the start of sda1 to the location of that Data Offset.
For instance, if it says:
Data Offset : 16384 sectors
While what Emmanuel Rosa quoted from the Wiki is technically correct (and he's also right by the way, check the wiki, and if you're feeling really adventurous, the list archives for the email@example.com mailing list, there's lots of useful info there), there are two things which I would like to point out which are (unfortunately) a bit big to fit ...
Look at the reshape status:
Update Time : Wed May 22 17:58:37 2019
State : clean, reshaping
Reshape Status : 5% complete
Delta Devices : 1, (2->3)
You won't get any extra storage until it's completed, and the report you've provided shows that it's currently at only 5% complete.
DO NOT interrupt the process or try to change the shape ...
As you have a hardware limitation with 2 separate USB technologies:
USB2.0 has a maximum signalling rate of 480Mbps
USB3.x has a maximum signalling rate of 5120Mbps (5.0 Gbps)
setting up the RAID-1 using mdadm (multi device administrator) will have some draw-backs.
Option 1: Add hardware.
Add a USB 3.x port splitter / USB 3.x HUB and connect both HDDs ...
I couldn't find a solution with an already created RAID 1 configuration, so backup your data, because for this solution I'll give you'll need to delete your RAID 1 first. Actually, I just deleted the virtual machine I was working with and created a new one.
So this it's going to work with Debian 10, and with a clean machine
Create a new clean ...
You can do that. You need to be a bit careful, but this is not dangerous¹ if you are very careful not to mistype anything and it doesn't leave any gotchas in the setup.
I highly recommend not doing any of the manipulations on a live system. It's possible in some cases but requires extra care. Boot from a liveCD/liveUSB such as Parted or SystemRescueCD.
Answer to question 1 - How to start after one drive failing
I could restore the RAID 1 by doing the following steps:
I took a somehow formatted drive (say C) and plugged it to the same SATA port where the defective drive B was before.
After that I started the computer and in the boot menu I pressed e to edit the command before booting according to wiki....
You say you've spoken to Hetzner, who say it has software RAID. The problem is, it doesn't. Your cat /proc/mdstat says something like
Personalities : [raid1]
unused devices: <none>
Which means no software RAID. If you had a broken software RAID, it would look something like
Personalities : [raid1]
md0 : active raid1 sdb1 (F) sda1
I switched from long selftests to select,cont tests. It's like the long selftest, but only one slice of disk at a time. So while the long selftest may take well over a day (with an otherwise busy 3TB disk), the selective test can run every night when the server is the least busy and actually finish, without harming performance in the more busy hours.
Apparently you just created the array. The copying of files has nothing to do with it. Both disks are supposed to always contain the same data, so when you first create the array, the entire contents of the first drive has to be copied to the second to ensure they are identical. After that finishes, then writing data just writes to both drives at the same ...
At the beginning of the RAID-1 there is some information that cannot just be inserted into your exiting non-boot drive. The way to proceed is as follows:
partition the new drive with one huge partition
create a RAID-1 on the new drive with one drive defunct:
mdadm --create /dev/md0 --level=raid1 --raid-devices=2 /dev/sdb1 missing
if it says you don't have ...
I would suggest using the variant with dup instead of putting multiple partions on the same device and raiding those. The raid variant is bad because the raid requests both copies to be read while data is accessed (this is good for normal multi-device raid because if either device is faster the data is available sooner). With single device rotational device ...
The first message means that your RAID array went into an inconsistent state, because apparently the sdb drive was detected as failing (second message). The current status looks like the array was restored, but you may want to check the output of smartctl --all /dev/sdb to get the current health status (which is printed before the drive parameters and the ...
I have no first hand experience with this, but I was able to find this article which discusses TRIM as being part of the issue/concern when setting up SSDs in a RAID-1 configuration.
Solid State Drives in IRST RAID 1 may have degraded performance
You may notice that the read/write speeds of your Solid State Drives (SSD's) in a RAID 1 ...
THIS ENDED UP BEING A HARDWARE ISSUE
Switching to the new shielded cables did not help, but replacing the old card with this one: http://www.amazon.com/gp/product/B000NTM9SY did get rid of the error messages and the strange behavior. Will post something new if anything changes.
IMPORTANT NOTE FOR SATA ENCLOSURES:
Even after doing the above, any drive ...
I usually use this simple check which is defined per drive and not globally per system (with DEVICESCAN option) - I'm interested in overall SMART health status and whether there are any pending sectors reallocation and any faulty sectors since last SMART test. Any suspicious events are mailed to my smart catch-all address then:
/dev/sda -H -C 0 -U 0 -m ...
I figured it out.
First, I installed mdadm.
sudo apt-get install mdadm
Then I added an entry to /etc/mdadm/mdadm.conf (copied from the old system).
Then I ran mdadm --assemble /dev/md0.
Once that was done, lvdisplay showed my volume, and I could mount it with /etc/fstab.
In RAID-5, unless your write was large enough to cover all data chunks for a given parity chunk, it has to read the missing data chunks in order to be able to recalculate and update parity. Thus a relatively small write on a RAID-5 can turn into a large read operation.
RAID-1 does not need such additional reads, as there is no parity, it just writes to all ...
The disks are not 100% identical. Each linux softraid device contains a metadata block with a uniq guid. So dd might not work.
The ports don't matter though. You can even put your drive into an extrernal usb box and it will still work. Doesn't work with hardware raid of course.
RAID is resyncing HDD
There are 2 hints:
"State : active, resyncing"
"Rebuild status : 17% complete"
It seems that your system is rebuilding your array (or it did not finished syncing it during installation).
It should be bootable again once the array is finished rebuilding.
For the time being, you could ty to boot in degraded mode at least. You can use ...