ddで出力したRaspberry Piのディスクイメージをループデバイスで検証

以前記事にした通り、 Raspberry Pi の稼働しているシステムSDカードを dd により、定期的に別のストレージへディスクイメージとしてバックアップしているのですが、その中のファイルシステムに異常は無いのか。物理的にレストアすることなく、 ループデバイス を使って検証する方法をまとめます。

Raspberry Piのシステムが入ったSDカードをネットワーク内のNASへsshプロトコルを通じ、圧縮イメージとしてバックアップする要領は、おおよそ次の通りです（NASとのssh疎通は予め証明書を交わしてパスワードレス）。

この作業が異常終了しない限りは中身のファイルシステムも正常に違いない、と身勝手な理解をしていましたが、はっきりさせたくて今回の検証に至りました。尚、本記事中の作業は全て、Ubuntu 18.04にて行なっています。

 

イメージファイル内のパーティション構成を確認

イメージファイルのパーティション構成は、定番のfdiskの他、 partx でも確認することが出来ます。

単一パーティションにより構成されるイメージファイルの場合は、イメージマウンタでマウント出来ますが、複数パーティションには対応していないので、その場合はターミナルから操作することになります。

オフセットマウント

例えば2番めのパーティションをマウントさせたい場合、 fdisk でそのパーティションの開始セクタ位置とセクタサイズから算出されるオフセット量をオプションに入れて次のように実行します。

しかしながら今回は、 fsck によるファイルシステム検証を行いたいので、マウントしてしまってはむしろ不都合。こんな時に使うのがループデバイスなのだそうです。

 

現在のループデバイスの一覧

まず、 losetup -l で現在のループデバイスの利用状況を確認してみます。Snapが多用しているようです。

 

次の空いているループデバイス名の取得

そして、次に割り当てられる予定のループデバイス名を確認します。

 

ディスクイメージをループデバイスに新規登録

partx -a コマンドでイメージファイルをループデバイスに登録します。その後再びループデバイス一覧を取得すると、確かに loop14 として登録されています。

 

ループデバイスのパーティション構成を確認

登録されたループデバイスに対して fdisk を実行すると、その中の各パーティションに割り振られたデバイス名を確認することが出来ます。

 

ループデバイスに対するファイルシステムチェック

早速、各々のパーティションに対してfsckをかけてみました。まず /boot が入っているFAT32パーティションのエラーは修復されました。しかしながら、ルートが入っているパーティションのエラーは深刻で、実際にはオプションを色々変えながら何度か fsck を走らせましたが、同じエラーが挙がり修復不能です。

 

ループデバイスのマウント

ループデバイスの中身を覗きたい時には、通常のブロックデバイス同様にマウントします。

コマンドでのマウントの他、GUIベースではDisksユーティリティでも物理ディスクと同じように認識されますので、そこからマウントすることも可能です。

ループデバイス登録解除

partx コマンドでループデバイスからイメージファイルを取り外します。あくまでまだ取り外しただけなので、 losetup で次の空き番号をチェックすると未だ loop15 と言われます。

/dev に残っている loop14 を直接 rm コマンドなどで無理やり消去することは出来てしまうものの、 losetup との整合性が取れなくなってしまい、その解消には再起動を要してしまうので止めておきましょう。

 

不要なループデバイスの空箱を消去

losetup コマンドで不要になったループデバイスを消すと、 loop14 が再び使用可能になります。

dd で生成したディスクイメージをループデバイスに登録して検証する一連の作業は以上です。せっかく定期的に作っているバックアップが使い物にならないことほど、虚しいことはありません。ループデバイスを応用してバックアップイメージの検証もバッチ処理で自動化出来れば、障害の早期対処に役立つことでしょう。