一个错误的电源炸了我的主板，我需要一些帮助。 我有一个闲置的主板，把它挂在硬盘上，看看能不能继续下去。 不幸的是Windows继续蓝屏错误0000007B这似乎是关心新的硬盘驱动器控制器。 我将不得不重新格式化还是有办法让Windows停止使用RAIDarrays并使用新的硬盘驱动器控制器？
尝试在fujitsu S100R5服务器上安装vmware esxi 5（两个驱动器托架）。 我将硬盘作为硬件RAID 1arrays，但vmware在安装时显示两个物理驱动器。 如果我安装到其中一个驱动器，则arrays会降级，并且在启动时显示“无操作系统”，即使重build后也是如此。 据我了解（这是我的第一个裸机vmware安装）vmware是为了显示逻辑arrays作为一个驱动器，你应该安装在此。 我有种想法，有没有人经历过这个？
我的服务器戴尔R210运行Debian挤压硬件RAID1（H200）预先configuration。 但是我注意到有mdadm在运行。 有时在备份或操作系统升级（到Debian 6.0.4），我有这样的消息： W: mdadm: /etc/mdadm/mdadm.conf defines no arrays. W: mdadm: no arrays defined in configuration file. 他们安全地忽略？ 我如何禁用mdadm？ 只是一个/etc/init.d/mdadm stop ，有点观察然后apt-get remove mdadm ？
我们的RAID5（使用Adaptec 3085）停止工作，因为其中一个硬盘坏了。 我怎样才能确定它是哪一个？
我有一个使用软件raid（md）的4个磁盘RAID 5的64位Ubuntu机器。 我已经能够启动一个Ubuntu LiveCD，并用一个简单的mdadm -A /dev/md0识别这个数组。 之后很容易安装，没有什么必须重build。 我现在在这个盒子上安装Gentoo（多启动，非RAID根分区），我在内核中启用了md自动检测function。 当我启动Gentoo时，我得到：arrays中每个驱动器上的“sdd上无效的超级块魔法”。 我启动到Ubuntu，他们没有问题。 我尝试将在Ubuntu中工作的mdadm.conf复制到Gentoo，然后运行mdadm -A /dev/md0但是它报告没有名为md0的数组。 我不想丢失数据（显然），我不希望每次切换操作系统时都要重buildRAID。 任何帮助表示赞赏。 两者都使用mdadm 3.1.4 两者都运行64位内核。 Ubuntu的mdadm -D /dev/md0产生： http : //pastebin.com/5gj2QNkV 更新：重新启动后，我注意到它仍然抱怨无效的块，但cat /proc/mdstat显示与我的RAID相同的磁盘非活动/dev/md127 。 我想挂载它，但是我不想被卡在等待重build或无意中销毁它。 mdadm -D /dev/md127这里是gentoo上的mdadm -D /dev/md127 ： http : mdadm -D /dev/md127 更新II： 关于“无效突袭超级块”的dmesg输出http://paste.ubuntu.com/885471/ 从Ubuntu的fdisk -l ，/ dev / md0没有任何分区，但是我确实已经安装并访问： http : //paste.ubuntu.com/885475/
在RAID4或RAID5的情况下，对于每个条带的数据位，存储奇偶校验位。 例如，如果我将0写入驱动器A，将1写入驱动器B，则将奇偶校验位1存储到驱动器C.在Linux软件的情况下，如果对于每一位数据，位需要计算？ 例如，如果我写一个1GB的文件到RAID5arrays，然后8000000000异或计算需要由CPU执行？
我知道RAID不应该用于备份，但是如何使用它来在物理层面创build备份呢？ 我有一个从所有networking到一台服务器的常规rsync备份设置。 每周一次，所有的备份都被复制到一个外部的硬盘上（直接用dd），硬盘被小心地带回家，防止数据丢失，以防服务器机房出现问题。 现在，拥有一个两个或多个磁盘的RAID1arrays，而不是复制数据是一个好主意 – 只需将磁盘切换到另一个磁盘并重buildarrays？ 事后从磁盘中恢复数据会有问题吗？
最近我在RAIDarrays中失去了一个驱动器（从系统收到一封电子邮件，告诉我这是非常好的），经过一些驱动器的洗牌和换入新驱动器，我都安全可靠。 但一路上，我发现这个线程 ，这让我想到如何实际testing磁盘错误和其他坏事情，而没有他们真正发生。 当我运行build议的tar命令时： tar c /my/raid/device/mount/point > /dev/null 它在几秒钟内完成，这显然不足以让系统实际读取所有文件（远远超过TiB） – 所以我想我的第一个问题是为什么这可能不起作用。 如果我做这样的事情： find . -type f | xargs md5sum 该命令运行得很好，需要很长时间才能完成…但是它也会加载CPU进行所有的求和。 这可能也可能不是比“焦油”更快或更容易 – 我更加好奇，为什么tar命令没有按预期工作。 无论如何 – 第二个问题，更一般地说：是否有办法按照这些方法做一些事情来进行故障注入testing： find（或创build）我不关心的文件… 确定磁盘上的块是用来存储这个特定的文件… 假的软件/操作系统认为这个块是“坏”（我认为标记它不知何故，这是我的知识用完的地方） 运行我的testing脚本和/或错误检查例程 确认数组都报告错误，并执行任何其他纠正措施是必要的… 将该块/扇区再次标记为“好”，以便系统/操作系统正常使用它。 这似乎是可行的，但我没有足够的Linux工具的详细知识，这将允许我标记一个块在设备级别不好，实际上是一个坏块… 这个想法？ 或者，如果有更好的方法来解决这个问题，我很高兴听到这个…
TL; DR如何从损坏的RAID1分区恢复ext4文件系统？ 我的情况 我在Synology DiskStation上有一个属于RAID1arrays的故障磁盘，另一个则丢失。 使用ddrescue我已经将大部分相关数据复制到一个新的磁盘。 分区表依然存在，但是RAID设置必不可less的一些块已损坏。 # fdisk -l /dev/sdd Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes 255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x0003f44a […]
我有一个HP Smart Array P400 RAID控制器，其中有六个物理磁盘，configuration为RAID 5.其中四个物理磁盘处于“OK”状态，一个处于“预测故障”状态，另一个处于“备用”状态： logicaldrive 1 (3.6 TB, RAID 5, OK) physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SATA, 1 TB, Predictive Failure) physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SATA, 1 TB, OK) physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SATA, 1 TB, OK) physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SATA, 1 TB, OK) physicaldrive […]