我尝试从mdadm raid灾难中恢复，这是从Ubuntu 10.04服务器迁移到12.04时发生的。 我知道dmesg日志中设备的正确顺序，但是给出这些信息，我仍然无法访问这些数据。
超级块看起来很混乱; mdadm – 在每个磁盘上检查askubuntu上的这个问题
通过检查后备存储的原始内容，我发现我的数据（在我的情况下是LUKS容器）的开始位置相对于raid中第一个分区的开始位置0x22000。
问题：为了重新创build以给定偏移量开始的mdadm，发给“mdadm –create”的选项的组合是什么？ 位图大小？
PS。 当系统健康的时候系统日志中的相关信息被粘贴在这里。
看来，没有必要使用任何工具来设置任何给定偏移量的RAID有效载荷的启动。 这个问题是由于在3.00以上的mdadm版本之间的偏移量的变化引起的。 目前看来，由于偏移量不同，从3.00以上的版本（我试过3.24）的mdadm不能重新创build由旧的mdadm所做的布局。 一个需要使用旧的。
这个问题首先出现在Ubuntu 12.04内核中的一个已知错误，在某些情况下（例如在分发升级过程中发现的）会覆盖超级块。 解决方法是使用避免从3.2.0-22.35到3.2.0-24.37的内核，这些内核偶然包括在Ubuntu 12.04 Mini-cd安装程序中使用的内核。
这是在[email protected]邮件列表中的对话，其中罗宾·希尔先生给我的解决scheme：
看起来像你遇到了这里提到的错误： http : //neil.brown.name/blog/20120615073245
你已经获得了大部分所需的数据来重新创build数组。 这只是我想的块大小。 这可能是512K，因为arrays使用1.2超级块，但如果您使用的是旧的mdadm版本，则可能是64K。
您的数据偏移量为272个扇区，这意味着您需要使用较旧的mdadm版本来重新创buildarrays。 较新的版本使用2048个扇区，但是看起来版本3.0使用272个，所以如果可能的话就拿一个副本。
假设您的驱动器编号与先前的顺序相同，则创build命令将是：
mdadm -C /dev/md5 -e 1.2 -l 5 -n 5 /dev/sd{b,f,c,e,d}6 \ --assume-clean --uuid=a3945c40:73237cd6:3d61998e:8f773d03和
mdadm -C /dev/md6 -e 1.2 -l 6 -n 5 /dev/sd{b,f,c,e,d}5 \ --assume-clean --uuid=2a8fd2df:3ad53552:e8b80ecf:a46d93a2确保使用大括号格式来列出磁盘而不是方括号 – 这将确保订单得到维护。 还要确保
--assume-clean被用来防止重build开始，并丢失数据。重新创build数组后，在数组上运行
fsck -n来检查细节是否正确。 如果没有，请停止arrays并尝试再次重新创build，添加“-c 64”将块大小设置为64K。一旦你得到了他们，fsck显示干净，你可以使用
mdadm -G /dev/mdX --bitmap=internal重新添加位图。请先阅读Neil的博客文章，因为可能有些东西我错过了。
所以从XUbuntu 10.04 Live CD启动后，我能够用给定的命令成功地重新创build数组，并获得我所有的数据。
重要的是要注意，旧的mdadm只需要重新创build数组。 该arrays可以正常访问12.04 live CD（使用通常的mdadm --assemble --scan ）。
如果想要改变raid的布局（偏移2048扇区），path很长：
我知道更新现有arrays中的偏移位置的唯一方法是逐个使磁盘失效，将超级块置零，然后使用新的mdadm将它们重新添加到数组中。 当它重新join时，它将使用新的偏移位置。 如果您有一个备用磁盘和足够新的内核版本，则可以使用先发制人的replace选项，这将防止在没有完全可用的奇偶校验的情况下运行。
…希望这篇文章能保持至less一个系统pipe理员从10.04升级到12.04心脏病发作;-)
请参阅askubuntu上的相关问题： 在10.04 – > 12.04升级后，mdadm失败 。