Raspberry PiのSDカードイメージをddで生成する際のオプション

投稿者: | 2021年3月18日

前回、 Raspberry Pi システム SD のバックアップイメージを検証してみたところ、ファイルシステムエラーが検出されました。日頃より何となく言われるままに付与していた dd の オプション を Raspberry Pi で使う SD カードを対象とする場合にフォーカスしてまとめました。

図1.不健全なイメージより復元されたシステムでカーネルパニック

図1.不健全なイメージより復元されたシステムでカーネルパニック

進捗表示

バッチ処理ではなく手動で操作する場合にあると便利な進行状況確認は、イメージ生成・復元どちらにおいてもpvをパイプで挟まず、ddに用意されている「status=progress」オプションでも可能です。

 

SDカードのイメージを生成する場合

ブロックサイズを大きく取れば短い時間で終わりますが、ファイルシステムに破損がある場合、データをうまく吸い上げることが出来ない可能性があることや、SDカードインターフェイス(カードリーダ含)の転送速度がボトルネックになり大した時間短縮にならないことからも、ブロックサイズは無指定デフォルト(512バイト)とし、さらに「conv=sync,noerror」を付与して、「より正しい」イメージを生成出来るように努めるのが良いようです。cronによるRaspberry Pi システムSDカードの定期バックアップは、次のように登録しました。

 

イメージをSDカードに焼く場合

逆にダウンロードしたOSのイメージをSDカードに焼き込む場合は、ブロックサイズを大きく取っても問題無いと言う理解で良さそうです。Raspberry Pi 公式ドキュメントでも「bs=4M」を推奨として、懸念が有る場合は「bs=1M」がアドバイスされていました。

さらに、「conv=fsync」を付与していたり、dd後にはキャッシュを明示的に反映するために「sudo sync」してからSDカードを取り出すようにも、丁寧に述べられています。また、unzipからオンザフライで焼く方法もわざわざ解説してあるのは嬉しい限り。

以上より、イメージをSDカードへ焼く場合は、

解凍しながら焼く場合は、

7zアーカイブでは次の要領でパイプ渡しすることが出来ます。

実際に実行してみると、2行目のddのステータスは途中で止まりますが(77sec)書き込みは続いていて、根気良く待っていると最終的な結果が出力されて焼き込みは終わります(209sec)。
 

オンザフライ圧縮時にpigzを使う

バックアップ時の容量を小さく収めたり、ネットワークストレージへの転送量を減らす為に、gzipにパイプ渡しすることが多いのですが、マルチコア対応版のpigzを使うことで高速化を望めるようです。

pigzに渡すことでどの程度速くなるのか、i7-2600K搭載のUbuntu18.04LTSデスクトップPCで比較試験してみました。USB2.0接続のカードリーダに挿した、volumio用microSDカード16GBのイメージを生成しながら圧縮してみましょう。まずはpigzのインストール。

はじめはブロックサイズ指定せずに、gzipとpigzそれぞれに渡した場合を比較してみます。

別段、高速でもない普通のUSBカードリーダから読み込むSDカードがボトルネックとなってしまい、マルチコアを活かせていません。次にブロックサイズを上げて同様に比較してみます。

こちらはわずかながらpigzの速さが、と言いたいところですが、Raspberry PiやSDカードと言った領域ではpigzは活かしきれないようです。SATAやUSB3.0の高速インターフェースで繋がるストレージを対象に今回のような試験をすると、pigzの速さを体感出来るようです。
 

障害のあるディスクにはddrescue

障害のあるディスクに対するddの方法を調べていた時に見付けたのがこのddrescue、UbuntuのGNU版ddrescueを使ってみます。

バッドセクタ、リードエラー等の異常検出無しで正常終了してしまいました。ループデバイスに登録してfsckファイルシステムチェックに掛けてみました。

ddで吸い上げた時は、同様にループデバイスからfsckチェック掛けるとエラーが検出されるのですが、ddrescueではノーエラー。もしや、とこのイメージを別のSDカードに焼いて起動させてみましたが、図1のカーネルパニックに変わりはありませんでした、別の要因が残存しているのかも知れません。

普段の定期バックアップもddからddrescueに置き換えた方が良いのではと思ったのですが、ddrescueでは標準出力が出来ません。これは欠点ではなくそもそもの手法がddと異なるからであり、それがrescueと銘打っている所以でもあります。平時のバッチ処理向けではなく、障害時の強力なレスキューツールと考えたほうが良さそうです。

ddrescueについての解説、障害時のレスキュー試行について次の記事が大変参考になりました。ddrescueにはGUIなどの周辺ツールもあるようなので、次回障害発生時に使ってみようと思います。

 

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA