> On Tue, 24 Nov 2020 at 02:20, Simon Matter <simon.matter at invoca.ch> wrote: > >> > On 23/11/2020 17:16, Ralf Prengel wrote: >> >> Backup!!!!!!!! >> >> >> >> Von meinem iPhone gesendet >> > >> > You do have a recent backup available anyway, haven't you? That is: >> Even >> > without planning to replace disks. And testing such >> strategies/sequences >> > using loopback devices is definitely a good idea to get used to the >> > machinery... >> > >> > On a side note: I have had a fair number of drives die on me during >> > RAID-rebuild so I would try to avoid (if at all possible) to >> > deliberately reduce redundancy just for a drive swap. I have never had >> a >> > problem (yet) due to a problem with the RAID-1 kernel code itself. >> And: >> > If you have to change a disk because it already has issues it may be >> > dangerous to do a backup - especially if you do a file based backups - >> > because the random access pattern may make things worse. Been there, >> > done that... >> >> Sure, and for large disks I even go further: don't put the whole disk >> into >> one RAID device but build multiple segments, like create 6 partitions of >> same size on each disk and build six RAID1s out of it. So, if there is >> an >> issue on one disk in one segment, you don't lose redundancy of the whole >> big disk. You can even keep spare segments on separate disks to help in >> case where you can not quickly replace a broken disk. The whole handling >> is still very easy with LVM on top. >> >> > I used to do something like this (but because there isn't enough detail in > the above I am not sure if we are talking the same thing). On older disks > having RAID split over 4 disks with / /var /usr /home allowed for longer > redundancy because drive 1 could have a 'failed' /usr but drive 0,2,3,4 > were ok and the rest all worked n full mode because /, /var, /home/, were > all good. This was because most of the data on /usr would be in a straight > run on each disk. The problem is that a lot of modern disks do not > guarantee that data for any partition will be really next to each other on > the disk. Even before SSD's did this for wear leveling a lot of disks did > this because it was easier to allow the full OS which runs in the Arm chip > on the drive do all the 'map this sector the user wants to this sector on > the disk' in whatever logic makes sense for the type of magnetic media > inside. There is also a lot of silent rewriting going on the disks with > the > real capacity of a drive can be 10-20% bigger with those sectors slowly > used as failures in other areas happen. When you start seeing errors, it > means that the drive has no longer any safe sectors and probably has > written /usr all over the disk in order to try to keep it going as long as > it could.. the rest of the partitions will start failing very quickly > afterwards. > > Not all disks do this but a good many of them do from commercial SAS to > commodity SATA.. and a lot of the 'Red' and 'Black' NAS drives are doing > this also.. > > While I still use partition segments to spread things out, I do not do so > for failure handling anymore. And if what I was doing isn't what the > original poster was meaning I look forward to learning it. I don't do it the same way on every system. But, on large multi TB system with 4+ drives, doing segmented raid has helped very often. There is one more thing: I always try to keep spare segments. Now, when a problem hows up, the first thing is to pvmove the broken raid data to wherever there is free space. One command and some minutes later the system is again fully redundant. LVM is really nice for such things as you can move filesystems around as long as they share the same VG. I also use LVM to optimize storage by moving things to faster or slower disks after adding storage or replacing it. Regards, Simon