電力損失による破損からデータを保護するための最良の保護を提供するファイルシステムはどれですか。

私はx86デバイス上で小型uClibcでbusyboxベースの組み込みシステムを実行しています。私はinitramfsを使用していext3ますが、カスタムのc ++アプリケーションで作成された永続的な測定ログデータを保存するために使用しているIDEモードのコンパクトフラッシュデバイスにカスタムディレクトリをマウントしています。私ext3が読んだいくつかの本（Building Embedded Linux SystemsによるKarim YaghmourとEmbedded Linux PrimerによるChristopher Hallinan）でCFドライブをIDEモードで使用するときの電力損失に対する安全性のために推奨されているので、ファイルシステムを選択しました。これは特に重要であり、データは重要です。

ただし、以前の質問のコメントの一部が原因で、ファイルの書き込み中に停電が発生した場合に破損したext3ファイルを復元する方法と混同しているため、このファイルシステムは、電源によるデータの破損に対する安全性を保証していないようです損失。だから私は知りたいのですが

1. でext3、実際にこのセットアップのために最良の選択？
2. ディスク書き込み操作中の停電は、定期的にファイルに追加しているデータの一部のみを破壊しますか、それともファイル全体を破壊しますか？
3. 停電時に書き込まれていないデータは完全に安全ですか？特に、initramfs.cpioファイルが破損するリスクはありますか？
4. アプリケーションコードでデータを保護するために使用できる方法はありますか（つまり、追加のパーティションを作成し、データをミラーイメージに書き込んで常に2つのコピーが存在するようにします）-アプリケーションにとって速度は実際の問題ではないため、高価なコピー操作です許容されます。

私はこの関連する質問に対する回答を見て読んだことがあります。ジャーナリングファイルシステムは、停電後の破損を保証しますか？、しかしそれは私を混乱させるいくつかのことを完全にはカバーしていません。

私は多くの質問をしていることを認識していますが、多くの資料を読んだにもかかわらず、停電時のデータへのリスクを理解するのに根本的な失敗があったようです。

セキュリティに関連するすべてのものと同様に、保証はありませんが、リスク（およびコスト）と確率のバランスをとる必要もあります。経験から（そして私は暗黒時代から数十の* nix boxenを実行してきました）、電力によるファイルシステムの重大な破損を実際に経験したことはありません。

これらのマシンの一部は、ジャーナリングされていないファイルシステム（通常はufsおよびext2）でさえ実行されていました。それらの一部は埋め込まれ、一部はNokia N900のような携帯電話でした。そのため、優れた電源が保証されていませんでした。

ファイルシステムの破損が発生する可能性があるわけではありません。発生する可能性が十分に低いため、心配する必要はありません。それでも、賭けをヘッジしない理由はありません。

あなたの文字通りの質問に答えて：

1. 少なくとも、あなたが参照した最初の本は以前に書かれたものですext4—著者がを使用することを提案したときext3、彼らは本当に「不安定な、またはジャーナルされていないファイルシステムを使用しないでください」と言っていますext2。試してみてくださいext4。かなり成熟しており、非回転ディスク用の適切なオプションがいくつかあります。これにより、フラッシュデバイスの寿命が延びる可能性があります。
2. ファイル全体ではなく、最後の1〜2ブロックが失われる可能性があります。ジャーナル化されたファイルシステムでは、これが唯一の損失です。ランダムなデータがファイル全体に散らばっているのを見ることができる失敗のシナリオがありますが、それらは、組み込みデバイスを通り抜ける隕石とほぼ同じように思われます。
3. 2を参照してください。100.00％安全なものはありません。

4. 2つ目のIDEチャネルがある場合は、そこに2つ目のCFカードを挿入し、定期的にファイルシステムのバックアップを取得します。これを行うには、いくつかの方法があります：rsync、cp dump、dd、でも使用してmd(4)デバイスを（ソフトウェアRAID）を（あなたは、それが同期させ、時折2番目のドライブを追加し、それを削除する-両方のデバイスはすべての時間のライブであれば、それらは同じ危険を冒しますファイルシステムの破損）。LVMを使用している場合は、スナップショットを取得することもできます。データ収集組み込みデバイスの場合は、2番目のファイルシステムをマウントし、データログにコピーし、すぐにマウント解除するア​​ドホックソリューションを使用します。デバイスに適切なブートイメージがあることを心配している場合は、ブートマネージャーの2番目のコピーと必要なすべてのブートイメージを2番目のデバイスに貼り付け、いずれかのCFカードからブートするようにコンピューターを構成します。

   ストレージデバイスは、安定したファイルシステムよりも故障することが多いため、同じデバイス上の2つ目のコピーを信頼しません。多くのより頻繁に、私の経験では、これまで（仕事で、金曜日の午後のディスク障害の驚くほど高い確率についての苦い半分冗談があった。それはしばらくの間、ほとんど毎週のイベントでした）。ディスクが回転しているかどうかに関係なく、障害が発生する可能性があります。できれば卵を2つのバスケットに入れておけば、データをより安全に保護できます。

   データが特に機密性が高い場合は、定期的にデバイスにアクセスし、バックアップCFを新しいCFと交換して再起動し、fsckすべてのファイルシステムを適切に測定できるようにします。

突然の電源喪失の場合にファイルシステムの実装が達成できることは制限されているように思えます-結局のところ、それは実際にはハードウェアとのインターフェースであるため、データ/命令をハードウェアに送信してからいつ応答が制御不能であることを取得します。この問題を回避できるファイルシステムがあれば、聞いたことがあるでしょう。

そのため、重要なデータを保護する戦略は、無停電電源装置を使用するなど、ハードウェアレベルで行われた決定から最も恩恵を受けます。おそらくこれはあなたの状況ではそれほど実行可能ではありません。

パフォーマンスはそれほど大きな問題ではないので、を慎重に使用してくださいfsync()。

ディスクの書き込み操作中に停電が発生しても、定期的にファイルに追加しているデータの一部のみが破損しますか、それともファイル全体が破損しますか？

私はextNファイルシステムを個人的に使用し、低トラフィックのインターネットサーバーで何年も使用しています。Alexiosのように、電源障害による破損はあまり見られません（ただし、サーバーにはUPSがあり、思い出せません）それらの1つは実際にそのように下降します）。さらに深刻な問題は、ハードウェア障害による破損です。これは、さまざまなファイルシステムが（繰り返して）問題に対処する能力をますます低下させる可能性がありますが、（繰り返します）これは根本的に制御不能であり、防止できません。

ファイルが失われたり、サイズが0に切り詰められたりするのをときどき見ました。これらが何らかの形で回復可能になる可能性は十分にあると思います。彼らがバックアップされたので、これは私にとって必要ではありませんでした。ほとんどの場合、何か問題がある場合はそれfsckを処理するようです。

停電時に書き込まれていないデータは完全に安全ですか？特に、initramfs.cpioファイルも破損するリスクはありますか？

電源障害だけでリスクは本当に低いと思います。ただし、フラッシュストレージの破損は、電源障害に伴う電力サージが原因で発生する可能性があることを除いて、私には経験はありませんが、うまくいけば、そしてこれを研究した。

データを保護するためにアプリケーションコードで使用できる方法はありますか？

fsync（）についてのポイントを繰り返す価値があります。C ++ / iostreamオブジェクトにはこのためのメソッドはありませんが（:: flushと:: syncはfsyncではありません）、必要なのはファイル記述子だけです。

ZFSは間違いなく設計によって破損から保護されたファイルシステムであり、おそらく唯一のファイルシステムです。ただし、uClinuxベースのプラットフォームでのZFS実装（ヒューズベースまたはネイティブ）の可用性についてはよくわかりません。

少なくとも1つの商用ファイルシステムがあり、電源障害が原因でファイルシステムがほとんど破壊されないこと、および電源が切れたときに追加されたデータのみが失われる可能性があることを確認するという、途方もない仕事を行います。

マイナス面は、それが非常に高価であるということです。プラス面では、彼らは素晴らしいサポートを提供します。費用がかかるため、これは実際には高額の賭け金および/または大量の製品に対する唯一の選択肢です。「不確実な」動作条件（例えば、頻繁な停電など）内でシステムの完全性を保証する必要がある、石油やガス生産などの重要な組み込み機器のように。

DataLight（会社）や製品「Reliance NITRO」をチェックしてください。（Relianceは、レガシーで安全ですが、あまり効果的ではないソリューションであり、Reliance NITROに取って代わられました）。このシステムを使用するお金がない場合でも、システムの仕組み、たとえばext3やext4よりも信頼性が高い理由について、かなり良い記事がいくつかあります。

これが広告のように読めば、申し訳ありませんが、オプションを指摘したかっただけです。