How to backup MDADM super blocks and other tips I should know about mdadm?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to backup MDADM super blocks and other tips I should know about mdadm?
My mega Linux Plex server is finally ready for lift off. I'll be using mdadm RAID 6 to build the array but had a question.
One of the things I've read is it's usually a good idea to backup the super blocks of the mdadm RAID. How exactly is this carried out?
I did some google searching and found LOTS of posts about people recovering without the super blocks and people messing up and overwriting the super blocks....... and no matter how I phrased my question, this was the best result i saw:
....... somebody asking the exact same question with no answer.
But, along with that, where are some other mdadm tips? I think I saw it was also a good idea to make a copy of your mdadm.conf file. Any other precautionary steps I should take in case tragedy strikes and I need to reinstall Linux and get my array back up and running?
(My boot drive will be /dev/sda and the array will be on 6, 4TB drives (/dev/sdb-g)
The superblock info is replicated on every drive, so backing it up is not usually a big concern. It does help to have a record in case someone does something dumb. I see nothing wrong with saving the output of mdadm --examine for this.
Other stuff to do:
1) Monitor the health and have a mechanism to email you when there is a problem. I've known people who set up RAID 6 and forgot about it until the 3rd drive dropped out.
2) Also run smartmon from cron to check individual drive health. But don't run the online drive self-tests which can interfere and trigger a RAID failure.
3) Be aware that loss of power during RAID 5 or 6 writes causes loss of data integrity. There is no way to tell which drives are up to date, especially on drives with a large cache. Use a UPS for important (all) data.
The superblock info is replicated on every drive, so backing it up is not usually a big concern. It does help to have a record in case someone does something dumb. I see nothing wrong with saving the output of mdadm --examine for this.
Other stuff to do:
1) Monitor the health and have a mechanism to email you when there is a problem. I've known people who set up RAID 6 and forgot about it until the 3rd drive dropped out.
2) Also run smartmon from cron to check individual drive health. But don't run the online drive self-tests which can interfere and trigger a RAID failure.
3) Be aware that loss of power during RAID 5 or 6 writes causes loss of data integrity. There is no way to tell which drives are up to date, especially on drives with a large cache. Use a UPS for important (all) data.
4) If performance is a concern consider RAID 10.
Thank you so much for the info! The server will definitely be on a UPS.
Fortunately, performance isn't a concern, it's just going to be a Plex server.
As I said in your other thread, keep a copy of /etc/lvm somewhere safe.
I prefer to use LVM to manage the RAID these days - add sufficient separate devices, then define the array, and LVM handles all the messy work of ensuring data and metadata are separated appropriately. Note this is different to the old way of defining LVM over the top of pre-defined mdadm RAID.
You can even define a failure policy, and let LVM handle it for you rather than having a subsequent (boot) failure. Very nice.
Works well on Fedora/RHEL (they are the motivation behind the development) - not sure about other distros.
As I said in your other thread, keep a copy of /etc/lvm somewhere safe.
I prefer to use LVM to manage the RAID these days - add sufficient separate devices, then define the array, and LVM handles all the messy work of ensuring data and metadata are separated appropriately. Note this is different to the old way of defining LVM over the top of pre-defined mdadm RAID.
You can even define a failure policy, and let LVM handle it for you rather than having a subsequent (boot) failure. Very nice.
Works well on Fedora/RHEL (they are the motivation behind the development) - not sure about other distros.
LVM.....something new for me to learn.
Did some quick reading and sorta kinda understood it. Hmmm, LVM needs to be used on TOP of mdadm or with LVM, you don't need mdadm? (Yes, I'm totally confused.)
mdadm and LVM are both (different) abstraction layers that you can insert between your filesystem and the real devices underneath. They have different functions. mdadm you know about - LVM abstracts the devices so you can operate as a storage pool; add/remove/move devices and extend filesystems across devices.
LVM can sit on top of mdadm, or mdadm can sit on top of LVM depending on requirement. Due to recent changes in LVM, it can now manage the mdadm interface transparently. I find it (now) very useful.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.