UbuntuでRAIDを構築しようとして、「設定がうまくいかない」「再起動後にRAIDが認識されなくなった」といったトラブルに直面していませんか？
- RAID構築後にシステムが起動しなくなった
- 再起動後、RAIDデバイスが認識されない
- RAID1の同期が終わらない・エラーが出る
こうした症状の背後には、mdadmの設定ミスや構成ファイルの不整合が潜んでいる可能性があります。
RAIDは複数のディスクを使って冗長性を確保し、データの可用性を高める技術ですが、一歩間違えれば起動障害や大切なデータの消失につながるリスクも抱えています。
本記事では、Ubuntu環境でのRAID1構築方法を基礎から丁寧に解説しつつ、構築時や再起動時に頻発するエラーの原因と対処方法を、トラブルの未然防止を含めて詳しく紹介します。
もしトラブルが発生し、自力での修復が困難な場合は、無料で専門診断を実施（24時間365日対応）しておりますので、まずはお気軽にご相談ください。
目次
よくあるエラーの原因
RAID構築時や再起動後に発生するトラブルの多くは、設定ファイルの不備やデバイス認識のずれに起因します。ここでは代表的な原因を紹介します。
RAIDが再起動後に認識されない
/etc/mdadm/mdadm.confにARRAY設定がない、またはmdデバイス名がmd0からmd127に変わってしまうケースがあります。RAIDがassembleされず、起動後に/dev/md0が存在しない状態になることがあります。
mdadm作成時の警告・エラー
「metadata at the start〜bootには不向き」といった警告は、v1.2メタデータ形式の特性によるものです。/boot用パーティションではv0.90を利用するか、別構成にするのが一般的です。また、「既存データあり」警告は誤指定の可能性があるため、fdisk -lでディスク内容を再確認します。
マウントできない・ファイルシステム破損
RAID自体は正常でも、上層のファイルシステムが破損しているケースがあります。誤ってmkfsを実行した場合や、電源断による破損が典型です。fsckなどを不用意に実行すると、障害が悪化する場合があります。
デバイス名やUUIDのずれ
/dev/md0として記載したfstabが、実際のデバイス名md127と一致しないことで起動に失敗することがあります。UUIDが変わった場合は、lsblkやblkidで確認してfstabを修正します。
オンボードRAIDとの干渉
BIOS設定でオンボードRAIDが有効なままmdadmでRAIDを組むと、起動時に不安定になったりディスクが重複認識される場合があります。オンボードRAIDは無効にし、「AHCI」モードを選択して構築するのが安全です。
これらの問題を放置すると、RAID構成が壊れたり、重要なデータが読み取れなくなるおそれがあります。安全に対処するため、次に紹介する方法で設定を見直すことが大切です。
RAID1構築の基本手順
ここでは、Ubuntuで「mdadm」を使ってRAID1を構築する基本的な流れを解説します。2台の空のディスク（例：/dev/sdb、/dev/sdc）を使う想定です。
ディスクの確認
RAID構築前に、対象ディスクが空であることを必ず確認します。誤ったディスクを指定すると、既存データがすべて失われるおそれがあります。
- 接続されたディスクを確認します。
例：lsblk、sudo fdisk -l - 対象ディスクに重要なデータが残っていないか確認します。
- 必要であれば、fdiskなどで既存パーティションを削除します。
mdadmのインストールとRAID作成
mdadmはUbuntu標準リポジトリからインストールできます。インストール後、RAIDアレイを作成します。
- mdadmをインストールします。
sudo apt install mdadm - RAIDアレイを作成します。
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1 - 作成後、状態を確認します。
cat /proc/mdstatまたはsudo mdadm --detail /dev/md0
ファイルシステム作成と自動設定
RAIDアレイを作成したら、ファイルシステムを作成し、自動認識とマウント設定を行います。
- ファイルシステムを作成します。
sudo mkfs.ext4 /dev/md0 - マウントポイントを作成し、マウントします。
sudo mkdir -p /mnt/raid1
sudo mount /dev/md0 /mnt/raid1 - 自動認識用設定を反映します。
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u - 自動マウント設定を追加します。
sudo blkid /dev/md0で取得したUUIDを使い、/etc/fstabに追記します。
もしトラブルが発生し、自力での修復が困難な場合は、無料で専門診断を実施（24時間365日対応）しておりますので、まずはお気軽にご相談ください。
【要注意】自力対応が招くデータ損失のリスク
社内サーバやRAID、NAS、業務用PCが停止したとき、自力で解決しようと不用意に操作を行うのは逆効果です。むしろ状況が悪化するケースも多く、次の経営リスクに直結します。
- 納期遅延や業務停止などが生じ、社内外からの信頼を損なう
- 想定外の復旧費用や負担が雪だるま式に増える
- 誤った判断により取り戻せたはずのデータを失い、復旧が不可能になる
特に内部データやシステム領域に問題が及んでいる場合、正常に動かなくなり、復旧の難易度は一気に上がります。最優先すべきは、これ以上の不用意な操作を止めることです。判断を誤らないためにも、早急にデータ復旧の専門家に相談することが重要です。
早い段階で「専門家」に相談することが重要
デジタルデータリカバリーでは、専門アドバイザーが状況を整理し、復旧可否や優先順位を踏まえ、最適な復旧方針をご案内します。
これまで当社では以下の実績・強みに基づき、多くの法人様にご相談いただいてきました。
- RAIDご相談実績 累計14,949件以上（※1）
- 一部復旧を含む復旧件数割合92.6%（※2）
- 他社で復旧不可とされた機器の対応実績8,000件以上（※3）
- ご依頼の約8割・48時間以内に復旧完了
- ISO27001／ISMS／Pマーク取得済み／データの取り扱いを徹底管理
- NDA（秘密保持契約書）の締結も可能
サーバやNASなど社外持ち出しが難しい機器も、出張診断・オンサイト対応が可能です。当社では24時間365日体制でご相談を受け付けています。操作を重ねて取り返しがつかなくなる前に、まずはご相談ください。
※1：2011年1月～
※2：2025年9月実績。一部復旧：完全復旧に至らなかったが、一部復旧できた場合。完全復旧：復旧希望データを100％復旧できた場合
※3：2011年1月～
よくあるエラーの対処法
RAIDの不具合が発生した場合でも、正しい手順で確認すれば安全に復旧できる可能性があります。ここでは代表的なエラー別に安全な対処法を解説します。
RAIDが認識されない場合のassemble手順
RAIDアレイが再起動後に見えなくなる場合、手動でアセンブルを行い設定を再登録する方法があります。
- RAIDデバイスをスキャンしてassembleを実行します。
sudo mdadm --assemble --scan - 状態を確認します。
cat /proc/mdstatまたはsudo mdadm --detail /dev/md0 - 結果が正しければ、以下で設定を永続化します。
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf - initramfsを更新します。
sudo update-initramfs -u
mdadm作成時の警告・エラー対応
RAID作成時の警告は、メタデータ形式や既存データの残留が原因である場合が多いです。
- メタデータに関する警告が出た場合、/bootで使用するRAIDはv0.90形式を指定します。
例：--metadata=0.90 - 既存データ警告が出た場合、対象ディスクをfdiskで再確認し、本当に初期化してよいディスクか判断します。
- 不要なメタデータを削除する場合は慎重に行い、バックアップがあることを確認します。
マウントできない場合の確認と修復方針
RAIDデバイスが存在してもマウントエラーが出る場合、ファイルシステムが破損している可能性があります。誤った修復操作はデータ消失につながるため、読み取り専用での確認を優先します。
- 読み取り専用でマウントを試します。
sudo mount -o ro /dev/md0 /mnt/raid1 - エラー内容（bad superblockなど）を確認します。
- fsckやxfs_repairなどを実行する前に、ログとエラーメッセージを記録します。安易に修復コマンドを繰り返さないよう注意します。
UUIDずれによる起動失敗の修正
fstabと実際のRAIDデバイスのUUIDが一致しない場合、起動に失敗することがあります。UUIDを再確認し、設定ファイルを修正することで解消できます。
- UUIDを確認します。
lsblk -fまたはsudo blkid - /etc/fstabを編集し、正しいUUIDで再登録します。
- /etc/mdadm/mdadm.confを更新し、initramfsを再構築します。
sudo update-initramfs -u - 再起動して正しくマウントされるか確認します。
オンボードRAIDとの干渉を防ぐ設定
マザーボードのRAID機能（いわゆる「Fake RAID」）が有効な状態では、mdadmとの競合が起きやすくなります。BIOS/UEFIでの設定確認が必要です。
- BIOSまたはUEFIを開き、オンボードRAID機能を無効にします。
- ストレージ設定を「AHCI」に変更します。
- 既存のRAIDメタデータが残っている場合は削除が必要ですが、誤削除は復旧困難になるため慎重に行います。
RAID構築や復旧では、一見単純に見える設定変更でもデータ喪失のリスクが伴います。特に業務データや重要なバックアップを含む場合、自己判断による再構築や修復コマンドの実行は避けたほうが安全です。データ復旧専門業者による診断を受けることで、原因特定と安全な対応が可能になります。少しでも異常を感じたら、今すぐ初期診断をご依頼ください。相談は無料で、専門エンジニアが状況を丁寧に確認し、最適な復旧プランをご提案します。
デジタルデータリカバリーが法人に選ばれる理由
デジタルデータリカバリーは、法人のサーバ・RAID復旧で高い支持を得ています。
実績が証明する「復旧できる」技術力
デジタルデータリカバリーは、他社で復旧できなかった案件の相談が多く寄せられる「最後の砦」として、その技術力が評価されています。
その理由として、次の実績・強みがあります。
- データ復旧専門業者 17年連続データ復旧国内売上No.1（※1）
- 累計50万件以上のご相談実績（※2）
- 他社で「復旧不可」と判断された機器でも、8,000件以上の復旧実績（※3）
- RAIDご相談実績 累計14,949件以上（※4）
- ISO27001／ISMS／Pマーク取得済み／データの取り扱いを徹底管理
- NDA（秘密保持契約書）の締結も可能
こうした実績・強みを背景に、特に法人のRAID復旧では、難易度の高い障害にも対応できる点から多くの企業様に選ばれてきました。
官公庁、国立大学法人、上場企業など、多くのお客様にご利用いただいています。
HDDの復旧技術向上が評価され、2021年には「東京都経営革新優秀賞」を受賞しました。
スピード対応｜約8割を48時間以内に復旧
当社は常時7,300台以上の部品を保有し、ワンフロア体制の自社ラボで対応しているため、スピード対応を可能にしています。
本社ラボ（六本木ヒルズ）への持ち込みも可能｜急ぎの方におすすめ
デジタルデータリカバリーでは、全国のお客様からの持ち込みに対応しています。
特に急ぎでの復旧をご希望の方や、対面で相談したい方には、東京・六本木ヒルズの本社ラボへのご来社をおすすめします。完全予約制でご案内しておりますので事前にご連絡ください。
〒106-6115 東京都港区六本木6-10-1 六本木ヒルズ森タワー15F
- 日比谷線 六本木駅 1C出口から徒歩3分
- 都営大江戸線 六本木駅 3番出口から徒歩8分
- 千代田線 乃木坂駅 5番出口から徒歩10分
- お車でお越しの方は、近隣駐車場の空き状況はこちらから
全国どこでも無料出張診断・復旧サービス対応
社内サーバに障害が発生したとき、以下の理由から対応に困る法人様は少なくありません。
- 機器を停止すると業務が完全に止まってしまう
- 大型・特殊構成のため、社外に搬出できない
- セキュリティや社内ルール上、外部持ち出しが禁止されている
当社では、法人様向けに無料の出張診断・復旧サービスを提供しています。全国どこでもエンジニアが現地へ訪問し、その場で診断・復旧対応を実施。現地で復旧が難しいと判断した場合やキャンセル時も、費用は一切かかりません。まずはお気軽にお問い合わせください。
メーカーや他社で「対応不可」と言われたRAID復旧事例
RAIDやサーバー、NASのトラブルは、電源やランプが正常でも内部で深刻な障害が進行していることがあります。メーカーや他社で「復旧不可」と判断され、不安を抱えたままご相談に至る法人様も少なくありません。
デジタルデータリカバリーでは、RAID相談実績 累計14,949件以上、他社で「復旧不可」とされた機器でも8,000件以上の対応実績があります。
以下は、他社で「復旧不可」と診断されたものの、自社で復旧を成功させた事例です。
事例① DELL PowerEdge R440
| 項目 | 内容 |
|---|---|
| ご相談内容 | PCから接続できず、起動時にブートエラーが発生。 業務システムが完全に停止し、復旧期限が切迫していた。 |
| 使用環境 | DELL PowerEdge R440 SQL Server 2016 Standard RAID10（8本構成） |
| 表面的な症状 | 接続不可／ブートエラー発生 ハードウェアランプは正常表示 |
| 他社で復旧不可と判断された理由 | ・RAID10（8本）＋SQL Serverという業務基幹向け構成 ・ハードウェアが正常に見え、原因特定が極めて困難 ・メーカー手順は環境復旧前提で、データ保全を考慮していない ・再構築や初期化でDB消失リスクが高い ・複数業者が「責任を負えない」と判断 |
| 技術的な難易度 | ・RAID構成を誤ると整合性が完全に崩壊 ・SQL物理データは一部欠損でもDB再構築不可 ・最初の判断を誤ると取り返しがつかない状態 |
| 復旧結果 | SQLデータの復旧に成功。 3日後に業務システムを再開。 |
事例② Buffalo製NAS
| 項目 | 内容 |
|---|---|
| ご相談内容 | 速度低下の兆候後、ある朝から完全にアクセス不能。 業務データに一切触れない状態となった。 |
| 使用環境 | Buffalo製NAS HDD2台／RAID1 Windows（複数台接続） |
| 表面的な症状 | アクセス不可／エラー表示 赤・緑ランプが点灯 |
| 他社で復旧不可と判断された理由 | ・型番やRAID構成すら不明な情報不足の状態 ・RAIDか単体かも分からず、誤操作＝即データ破壊のリスク ・他社で分解・HDD直結を試すも2台とも認識不可 ・個人業者ではRAID解析・物理判断ができず対応断念 |
| 技術的な難易度 | ・RAID情報不明のままの通電・操作は上書きリスク大 ・2台とも障害があり、正常ディスクが存在しない ・個人・簡易復旧では手詰まりとなる典型例 |
| 復旧結果 | 両HDDとも99.9％復旧。 5日でデータお渡し完了。 |
これらのケースは「データ復旧の経験がある」だけでは対応できず、RAID・業務システム・障害進行リスクを同時に判断できる技術力が求められました。
データ復旧は何度も試せるものではありません。技術力のない業者に対応を委ねると、状態悪化し、二度とデータが取り戻せなくなる可能性があります。そのため、最初の段階で技術力のある業者に対応を依頼することをおすすめします。
この点、デジタルデータリカバリーでは他社で「復旧不可」とされた機器で8,000件以上もの対応実績があり、他社復旧不可と診断されたケースでもデータ復旧に至っています。まずはお気軽にお問い合わせください。
※1：データ復旧専門業者とは、自社及び関連会社の製品以外の製品のみを対象に保守及び修理等サービスのうちデータ復旧サービスを提供し、その売上が総売上の50％以上を占める企業のこと。第三者機関による、データ復旧サービスでの売上の調査結果に基づく（算出期間：2007年～2023年）
※2：期間：2011年1月1日～
※3：期間：2016年6月1日〜
※4：期間：2011年1月1日～
