我必须在Ubuntu服务器12.04上设置软件raid（level1）。 它应该通过Samba在networking中提供文件。 该服务器具有以下磁盘： 250GB的SATA硬盘（Ubuntu安装在该驱动器上） 2 TB Sata hdd（RAIDarrays中的第一张磁盘，数据磁盘） 2 TB SATA硬盘（第二个数据磁盘） 我使用Linux raid autodetecttypes在每个数据磁盘上创build了一个分区。 在第二步中，我使用以下命令创build了raid1： mdadm –create /dev/md0 –level=1 –raid-devices=2 /dev/sdb1 /dev/sdc1 之后，我将数组添加到mdconf中： mdadm –examine –scan >> /etc/mdadm/mdadm.conf 问题是：重新引导后，arrays在path/ dev / md0上不可用。 而不是它重新组装为/ dev / md / 0，但它不是很可靠。 有没有人解决这个问题？
是否保证了mdadm（并通过经验值得信赖）是否仅使用xfs_freeze拍摄快照是安全的？ 我遇到了mdadm仍然在后台工作的含糊不清的警告，因此在不拆卸RAID的情况下使快照变得不安全，但我宁愿避免在可能的情况下进行拆卸/重新组装。 快照是通过EBS进行块级别的，但我不太关心快照过程，而不是关于拍摄快照时正确的数据是否一致。 除了mdadm以外的选项，如果它们使得这个过程更加可靠的话，我们可以使用它 – 我们以前使用LVM条纹，但是由于跨磁盘快照的报告不可靠，所以专门切换到了mdadm。 我们也在研究一些组合，例如使用mdadm进行条带化，使用LVM层进行快照。 理想的解决scheme是避免不得不停止从RAID（本例中为Mongo）运行的服务，并且将采用原始数据格式，以便新服务器可以附加已恢复快照的arrays，而不需要额外的步骤按摩数据到位。 （我们已经有了可以将快照重组到新服务器的代码 – 我们只需要可靠地创build这些快照。）
我在这里有一个奇怪的情况。 在一台低stream量的服务器上使用了三年之后，一台RAID1中的两个三星硬盘之一昨天失败了： Personalities : [raid1] md0 : active raid1 sdb1[2](F) sda1[0] 732572608 blocks [2/1] [U_] 由于smartd没有任何报告，我检查了聪明的属性和唯一可疑的读数是不同的sdb（失败）与sda相比是： sda: 191 G-Sense_Error_Rate 0x0022 252 252 000 Old_age Always – 0 sdb: 191 G-Sense_Error_Rate 0x0022 098 098 000 Old_age Always – 27650 服务器机架中的G-sense错误？ 也许传感器失败了？ 但是在这两个驱动器上还有另一个时髦的阅读：最近的短线离线testing是“中断（主机复位）”，如果我用smartctl –test=short /dev/sda启动一个新的testing，select性自检日志显示： SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Self_test_in_progress [90% left] (0-65535) 然而，这个短暂的testing永远不会结束，甚至几个小时后，情况依然如此 […]
我正在运行的Ubuntu服务器12.04。 我做了apt-get升级，并收到了mdadm的警告。 update-initramfs: Generating /boot/initrd.img-3.11.0-24-generic W: mdadm: the array /dev/md3 with UUID e3d153f0:6edf1702:1f51fb89:78ee93fe W: mdadm: is currently active, but it is not listed in mdadm.conf. if W: mdadm: it is needed for boot, then YOUR SYSTEM IS NOW UNBOOTABLE! W: mdadm: please inspect the output of /usr/share/mdadm/mkconf, compare W: mdadm: it to /etc/mdadm/mdadm.conf, and make […]
我有一个Ubuntu服务器，操作系统安装在使用两个500GB设备创build的raid1上。 第二个驱动器失败。 我现在如何更换它，但我现在的目标是将操作系统移动到4 GB USB驱动器上（因为整个服务器安装为1.5 Gb）。 也许它看起来像一个疯狂的事情，但我相信，在两个USB驱动器创build的RAID可以更有效地在我的情况。 这不是一个关键的服务器，用于testing目的，但是目标不是从零重新安装它，并使用操作系统，因为它现在仍然存在于500gb设备中。 任何想法如何做到这一点？
我有一个带有7个工作设备，4个活动和3个备用的RAID10。我想将RAID的空间从4个设备增加到6个。 我使用这个： sudo mdadm –grow –raid-devices=6 /dev/md0 但它给了我这个信息： mdadm :insufficient head-space for reshape on dev/sdb1 谢谢！
我试图挂载设备formsRAID 1（在其他设备上创build），因为我需要从这个磁盘复制数据。 当我试图组装新的数组时，我收到一条消息： foo@bar# mdadm -A -R -v /dev/md23 /dev/sdb3 mdadm: looking for devices for /dev/md23 mdadm: /dev/sdb3 is identified as a member of /dev/md23, slot 32769. mdadm: No suitable drives found for /dev/md23 这是我的检查： foo@bar# mdadm -E /dev/sdb3 /dev/sdb3: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 4bd4d90c:5ca25815:87c31c08:a6288e71 Name […]
我们有一个Synology RS3614rpxs NAS磁头，包含（9）个3TB硬盘，安装RAID 6 + 1热备份。 存储器耗尽，我们添加了一个扩展机箱，其中安装了5TB硬盘驱动器，以创build第二个arrays（也称为RAID 6）。 Synology似乎是使用标准的linux md来形成LVM最上面的RAIDarrays，以形成卷组（由底层md设备组成），然后是逻辑卷。 在引入扩展机箱的过程中，有3个磁盘被意外添加到第一个磁盘arrays（ md2 ）中。 一个问题是我们正在丢失5TB磁盘上的可用空间。 其余的磁盘似乎已被添加到第二个数组（ md3 ）。 md3似乎已被添加到现有卷组vg1. 我们的目标： 从vg1删除md3 ，并根据需要调整逻辑卷的大小。 销毁md3并使其磁盘可用于重新使用。 问题：我们如何才能最好地实现这些目标？ 对于上下文： “df -h”的输出 Filesystem Size Used Available Use% Mounted on /dev/md0 2.3G 637.9M 1.6G 28% / /tmp 1.9G 404.0K 1.9G 0% /tmp /run 1.9G 3.8M 1.9G 0% /run /dev/shm 1.9G 0 1.9G […]
我目前的mdadm.conf如下所示： $ cat /etc/mdadm/mdadm.conf DEVICE /dev/sdb1 /dev/sdc1 ARRAY /dev/md0 metadata=1.2 spares=0 UUID=357ff7cc:55e78d18:9fc7917b:f5b253f2 MAILADDR [email protected] 从2.6.x内核升级到3.x，我注意到块设备在每次启动时都会得到随机的名字。 这个奇妙的新麻烦通常可以通过将UUID分配给文件系统和交换分区并通过fstab和Grub引用来解决; 但是如何从mdadm.conf引用RAID设备成员？ 虽然数组成员通常包含文件系统，但其UUID可能是重复的（raid 1）或不存在。 从我上面的例子来看，如何replace/dev/sdb1和/dev/sdc1 ？
当我尝试安装其中一个硬盘时，无法find硬盘上的文件夹。 这是命令df的输出： Filesystem 1K-blocks Used Available Use% Mounted on rootfs 33000428 119124 32881304 1% / none 33000428 119124 32881304 1% / 198.27.85.63:/home/pub/rescue.v7 886788312 250295096 591423904 30% /nfs 198.27.85.63:/home/pub/pro-power 886788312 250295096 591423904 30% /power 198.27.85.63:/home/pub/commonnfs 886788312 250295096 591423904 30% /common tmpfs 10240 204 10036 2% /dev tmpfs 6600088 72 6600016 1% /run tmpfs 5120 0 5120 […]