Re: [CentOS] RAID questions
On 15.02.2017 03:10, TE Dukes wrote: > > >> -Original Message- >> From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of John R >> Pierce >> Sent: Tuesday, February 14, 2017 8:13 PM >> To: centos@centos.org >> Subject: Re: [CentOS] RAID questions >> >> On 2/14/2017 5:08 PM, Digimer wrote: >>> Note; If you're mirroring /boot, you may need to run grub install on >>> both disks to ensure they're both actually bootable (or else you might >>> find yourself doing an emergency boot off the CentOS ISO and >>> installing grub later). >> >> I left that out because the OP was talking about booting from a seperate > SSD, >> and only mirroring his data drive. >> > Thanks!! > > I'm only considering a SSD drive due to the lack of 3.5 drive space. I have > unused 5.25 bays but I'd have to get an adapter. > > I probably don't need to go the RAID 10 route. I just need/would like some > kind of redundancy for backups. This is a home system but over the years due > to HD, mainboard, power supply failures, I have lost photos, etc, that can > never be replaced. Backing up gigabytes/terabytes of data to cloud storage > would be impractical due to bandwidth limitations. > > Just looking for a solution better than what I have. A simple mirror is more > than I have now. I'd like to add another drive for redundancy and go from > there. > > What should I do? RAID is *not* a backup. If a virus or buggy program or an accidental "rm -rf *" in the wrong directory deletes files on a RAID then these files are obviously gone on the replicas as well. If you want to prevent the loss of files then instead you should add a second disk to the system and simply backup data on a daily basis to that disk. A RAID array is not the appropriate way to go for you scenario described above. Regards, Dennis ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] usb drives & Orico ORICO 9548U3-BK
> > I decided to build an archive server for the purpose of backing up > other fedora/centos desktops at the office. I built a machine and > have > installed Centos 7.3 on it with all updates current. I also > purchased > a 3.0 usb sata drive cabinet (Orico ORICO 9548U3-BK) and installed > two > 5T black WD drives. There was no problem installing the usb cabinet > or the drives. I formatted each drive with xfs as /dev/sdc and > /dev/sdd, and then combined them into a software mirrored raid with > mdadm as /dev/md0. I've always thought that the perceived wisdom is to not try and do software raid across USB - especially when both drives are at the other end of the same USB cable. Sure USB 3 is faster and there's a better chance it will appear to work at a reasonable speed, but it's not something I would contemplate. > > Everything was working perfectly until I removed the terminal, > keyboard > and mouse and tried to reboot the machine. It took a while to figure > out, but when the mouse and keyboard were removed the boot process > assigns the usb drives differently which makes /dev/md0 created by > mdadm fail. Which means that the drive letters are explicitly mentioned in /etc/mdadm.conf - you can change it to be wildcarded or leave mdadm to figure it all out itself. See 'man mdadm.conf'. > > My fstab file looks like : > > /dev/mapper/centos_poar-root /xfsdefaults 0 > 0 > UUID=f915a354-28bf-4110-bec9-3767ef1fe52c /boot xfsdefaults 0 > 0 > /dev/mapper/centos_poar-home /homexfs defaults 0 > 0 > /dev/mapper/centos_poar-u /u xfs defaults 0 > 0 > /dev/mapper/centos_poar-swap swap swapdefaults 0 > 0 > /dev/sda /u0 btrfs defaults 0 > 0 > # entries below were combined into one mirrored raid system > #/dev/sdc/u1 xfs defaults 0 > 0 > #/dev/sdd/u2 xfs defaults 0 > 0 > /dev/md0 /u1 xfs defaults 0 > 0 Another likely issue is that you explicitly mention /dev/sda in the fstab - if the drives are re-ordered, then /dev/sda will not be what you think it is. It's a much better idea to use UUIDs when mounting drives. You can find the UUID with lsblk --fs /dev/sda BTW, are you really using partitionless disks - is it really /dev/sda and not /dev/sda1 ? > > > This works perfectly when a usb mouse and a usb keyboard are > attached, > but when I remove the mouse and keyboard the system will not boot > because the usb drives are relabeled as /dev/sda and /dev/sdb. I would have thought that any SATA drives would have been processed before the USB drives - certainly it looks that way on my system. Try going through the output of dmesg to see if you can see what is really happening when in the boot sequence. > > > My thought is that if I could force the usb drives to be labeled as > /dev/sdc and /dev/sdd whether the mouse and keyboard are attached or > not, I might be able to fix the problem It's much easier to make sure you don't explicitly use drive letters - because, as you've found out, they can change. Use filesystem labels or UUIDs or disk IDs. The disk IDs can be found in /dev/disk/by-id and they should remain the same. P. - Pete, Thank you for such excellent help; I appreciate your wisdom and challenges. The machine I am working on is still at the 'lab' stage so everything can be changed at this point. I don't have the benefit of much 'perceived wisdom' in that most of my knowledge comes from mistakes I have made or mistakes others on this list have made that Ican learn from. So thanks again. Here are some of my thoughts... right or wrong. #1. 3.0 USB drives I originally performed some testing on a small usb passport 3T drive and was amazed by the response and access times. I stumbled across the Orico cabinet during a NewEgg search, and decided to give it a try. I was even more impressed with the response and access times. I decided to attempt a mdadm raid on the the Orico and everything has worked better than expected except for the problems I have had with device assignments. I did have an electrical failure at my home related to weather of which the ups powered down after 30 minutes that caused one of the raid 5T drives to become corrupted. I reformatted the drive and rebuilt the raid with mdadm, and everything worked a lot better than I expected. I will only be using this system to store *.tar.gz backup files from other systems. What should cause me to fear the USB 3.0 connection. #2. /etc/mdadm.conf The tutorials I read about how to use mdadm did not include mdadm.conf, and this was not created when I installed mdadm. I will take a look at the man pages thank you. #3. UUID's Thanks for the suggestion to use names instead of device addr
[CentOS] mdadm vs raidcheck
Hi all! I don't religiously follow everything that pops up in the selinux alerts, but now and then I go back and look at some of them. (I'm on an up to date Centos-7). Today I noted an error that seems to occur during a weekly raid check, from /etc/cron.d. the selinux alert is: SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-fcshome.log.lockless. so I go look at that file and find that it contains, down in the middle of commands run, a series of errors: 2017-02-19 01:30:03 Relax-and-Recover 1.17.2 / Git 2017-02-19 01:30:03 Command line options: /usr/sbin/rear checklayout 2017-02-19 01:30:03 Including /etc/rear/os.conf 2017-02-19 01:30:03 Including conf/Linux-i386.conf 2017-02-19 01:30:03 Including conf/GNU/Linux.conf 2017-02-19 01:30:04 Including /etc/rear/local.conf 2017-02-19 01:30:04 Running 'init' stage 2017-02-19 01:30:04 Including init/default/01_set_drlm_env.sh 2017-02-19 01:30:04 Finished running 'init' stage in 0 seconds 2017-02-19 01:30:04 Using build area '/tmp/rear.oaWHSvnwNFddStm' 2017-02-19 01:30:04 Running checklayout workflow 2017-02-19 01:30:04 Running 'layout/precompare' stage 2017-02-19 01:30:04 Including layout/precompare/default/11_check_layout_file.sh 2017-02-19 01:30:04 Finished running 'layout/precompare' stage in 0 seconds 2017-02-19 01:30:04 Running 'layout/save' stage 2017-02-19 01:30:04 Including layout/save/GNU/Linux/10_create_layout_file.sh 2017-02-19 01:30:04 Creating disk layout 2017-02-19 01:30:04 Preparing layout directory. 2017-02-19 01:30:04 Including layout/save/GNU/Linux/15_save_diskbyid_mappings.sh 2017-02-19 01:30:05 Saved diskbyid_mappings 2017-02-19 01:30:05 Including layout/save/GNU/Linux/20_partition_layout.sh 2017-02-19 01:30:06 Saving disk partitions. 2017-02-19 01:30:08 Including layout/save/GNU/Linux/21_raid_layout.sh 2017-02-19 01:30:08 Saving Software RAID configuration. /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 44: let: sparedevices=-: syntax error: operand expected (error token is "-") /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 65: [: : integer expression expected /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 44: let: sparedevices=-: syntax error: operand expected (error token is "-") /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 65: [: : integer expression expected /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 44: let: sparedevices=-: syntax error: operand expected (error token is "-") /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 65: [: : integer expression expected /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 44: let: sparedevices=-: syntax error: operand expected (error token is "-") /usr/share/rear/layout/save/GNU/Linux/21_raid_layout.sh: line 65: [: : integer expression expected 2017-02-19 01:30:09 Including layout/save/GNU/Linux/22_lvm_layout.sh 2017-02-19 01:30:09 Saving LVM layout. 2017-02-19 01:30:11 Including layout/save/GNU/Linux/23_filesystem_layout.sh 2017-02-19 01:30:11 Begin saving filesystem layout 2017-02-19 01:30:11 Saving filesystem layout (using the findmnt command). 2017-02-19 01:30:16 End saving filesystem layout 2017-02-19 01:30:16 Including layout/save/GNU/Linux/24_swaps_layout.sh 2017-02-19 01:30:16 Saving Swap information. 2017-02-19 01:30:16 Including layout/save/GNU/Linux/25_drbd_layout.sh 2017-02-19 01:30:16 Including layout/save/GNU/Linux/26_crypt_layout.sh 2017-02-19 01:30:16 Saving Encrypted volumes. 2017-02-19 01:30:16 Device Mapper name No not found in /dev/mapper. 2017-02-19 01:30:16 Including layout/save/GNU/Linux/27_hpraid_layout.sh 2017-02-19 01:30:16 Including layout/save/GNU/Linux/28_multipath_layout.sh 2017-02-19 01:30:16 Did not find multipath device No in the expected location. 2017-02-19 01:30:16 Including layout/save/default/30_list_dependencies.sh 2017-02-19 01:30:16 Including layout/save/default/31_autoexclude_usb.sh 2017-02-19 01:30:16 Including layout/save/default/31_include_exclude.sh 2017-02-19 01:30:16 Including layout/save/default/32_autoexclude.sh 2017-02-19 01:30:17 Disk /dev/sdb is not used by any mounted filesystem. Excluding. 2017-02-19 01:30:17 Disk /dev/sdc is not used by any mounted filesystem. Excluding. 2017-02-19 01:30:17 Including layout/save/default/33_remove_exclusions.sh 2017-02-19 01:30:17 Including layout/save/GNU/Linux/34_false_blacklisted.sh 2017-02-19 01:30:18 Including layout/save/default/34_generate_mountpoint_device.sh 2017-02-19 01:30:18 Includin
Re: [CentOS] usb drives & Orico ORICO 9548U3-BK
> -Original Message- > From: CentOS [mailto:centos-boun...@centos.org] OnBehalf Of Gregory P. > Ennis > Sent: Sunday, February 19, 2017 12:31 PM > To: centos@centos.org > Subject: Re: [CentOS] usb drives & Orico ORICO9548U3-BK > > > > > > I decided to build an archive server for thepurpose of backing up > > other fedora/centos desktops at theoffice. I built a machine and > > have installed Centos 7.3 on it with all updatescurrent. I also > > purchased a 3.0 usb sata drive cabinet (OricoORICO 9548U3-BK) and > > installed two 5T black WDdrives. There was no problem installing > > the usb cabinet or the drives. Iformatted each drive with xfs as > > /dev/sdc and /dev/sdd, and then combined theminto a software mirrored > > raid with mdadm as /dev/md0. > > I've always thought that the perceived wisdom is tonot try and do software > raid across USB - especially when both drives are atthe other end of the > same USB cable. Sure USB 3 is faster and there's abetter chance it will appear > to work at a reasonable speed, but it's notsomething I would contemplate. > > > > > Everything was working perfectly until Iremoved the terminal, > > keyboard and mouse and tried to reboot themachine. It took a while > > to figure out, but when the mouse and keyboardwere removed the boot > > process assigns the usb drives differentlywhich makes /dev/md0 > > created by mdadm fail. > > Which means that the drive letters are explicitlymentioned in > /etc/mdadm.conf - you can change it to be wildcardedor leave mdadm to > figure it all out itself. See 'manmdadm.conf'. > > > > > My fstab file looks like : > > > > /dev/mapper/centos_poar-root /xfsdefaults 0 > > 0 > > UUID=f915a354-28bf-4110-bec9-3767ef1fe52c/bootxfsdefaults 0 > > 0 > >/dev/mapper/centos_poar-home /homexfs defaults 0 > > 0 > >/dev/mapper/centos_poar-u /u xfs defaults 0 > > 0 > >/dev/mapper/centos_poar-swap swap swapdefaults 0 > > 0 > >/dev/sda /u0 btrfs defaults 0 > > 0 > > # entries below were combined into one mirroredraid system > #/dev/sdc > >/u1 xfs defaults 0 > > 0 > >#/dev/sdd/u2 xfs defaults 0 > > 0 > >/dev/md0/u1 xfs defaults 0 > > 0 > > Another likely issue is that you explicitly mention/dev/sda in the fstab - if > the > drives are re-ordered, then /dev/sda will not bewhat you think it is. It's a > much better idea to use UUIDs when mounting drives.You can find the UUID > with > > lsblk --fs /dev/sda > > BTW, are you really using partitionless disks - isit really /dev/sda and not > /dev/sda1 ? > > > > > > > This works perfectly when a usb mouse and a usbkeyboard are attached, > > but when I remove the mouse and keyboard thesystem will not boot > > because the usb drives are relabeled as/dev/sda and /dev/sdb. > > I would have thought that any SATA drives would havebeen processed > before the USB drives - certainly it looks that wayon my system. Try going > through the output of dmesg to see if you can seewhat is really happening > when in the boot sequence. > > > > > > > My thought is that if I could force the usbdrives to be labeled as > > /dev/sdc and /dev/sdd whether the mouse andkeyboard are attached or > > not, I might be able to fix the problem > > It's much easier to make sure you don't explicitlyuse drive letters - because, > as you've found out, they can change. Usefilesystem labels or UUIDs or disk > IDs. The disk IDs can be found in /dev/disk/by-idand they should remain the > same. > > P. > >- > > Pete, > > Thank you for such excellent help; I appreciate yourwisdom and challenges. > The machine I am working on is still at the 'lab'stage so everything can be > changed at this point. I don't have the benefit of much 'perceivedwisdom' in > that most of my knowledge comes from mistakes I havemade or mistakes > others on this list have made that Ican learnfrom. So thanks again. > > Here are some of my thoughts... right or wrong. > > #1. 3.0 USB drives > I originally performed some testing on a small usbpassport 3T drive and was > amazed by the response and access times. I stumbled across the Orico > cabinet during a NewEgg search, and decided to giveit a try. I was even > more impressed with the response and accesstimes. I decided to attempt a > mdadm raid on the the Orico and everything hasworked better than > expected except for the problems I have had withdevice > assignments. I did have an electrical failure at my home related to > weather of which the ups powered down after 30minutes that caused one > of the raid 5T drives to become corrupted. I reformatted the drive and > rebuilt the raid with mdadm, and everything worked alot better than I > expected. Iwill only be using this system to store *.tar.gz backup file
