web-dev-qa-db-ja.com

ビット腐敗/バックアップ戦略を修正する方法

個人ファイルをNAS(btrfsファイルシステムを使用)にバックアップすることを計画しています。これは安価なNASなので、残念ながらECCRAMはありません。私のバックアップ戦略では他のファイルになります。 CrashplanやMegaなどのサービスを使用したファイルのコピー(オンライン)(念のため両方を使用する可能性があります)。冗長性を高めるために、NAS自体をUSB接続を介して外部にバックアップする場合があります。 1つ以上のファイルでデータが劣化します。

安全で機能するコピーはどこかにありますか?以前にCrashplanを使用したことはありませんが、ファイルの変更に気付かないため、元のバージョンを保持する必要があります。

正直少し混乱しているので、自分の戦略が実際に機能するかどうかを理解したいと思います(いつの日か、ECCRAMを搭載したNAS)になるまで)。

どうもありがとう

2
horizonbrave

率直に言って、 ECC RAMを使用したくない、または使用できない場合 ZFS(リンクされたフォーラムの投稿で説明されている)やBtrfsなどの自己修復ファイルシステムの使用は検討しません。

その理由は、RAMの問題がある場合、「自己修復」機能が非常に簡単に「自己破壊」になる可能性があるためです。

代わりに、ECC以外のRAMシステムでは、ext4などの通常のファイルシステムを実行したほうがよいでしょう。今日のBtrfsの状態では(安定し始めていますが、まだスムージングが必要で、実際の展開や障害の経験がまだ見られないラフエッジ)、これにより、はるかに快適に感じることができます。ファイルシステムとして比較的実績のあるZFSでさえ、Linuxにはまだいくつかの不具合があります。ホスト; BtrfsはZFSほど成熟していません。

データチェックサムをネイティブに検証する機能がないファイルシステムでビット腐敗を検出するには、その目的で使用できる多数のツールのいずれかを使用できます。私が提携していないそのようなツールの1つは、 hashdeep で、MD5、SHA1、SHA256、Tiger、Whirlpoolのハッシュを実行できます。これを適度に定期的に実行すると(ZFSまたはBtrfsファイルシステムのスクラブと同じように)、発生する可能性のある劣化を確実にキャッチできます。その後、影響を受けるファイルを、オンサイトまたはオフサイトのバックアップから復元できます。

私はCrashplanに精通していませんが、ファイルメタデータを調べて、ファイルが変更されているかどうかを判断していると思われます。また、ファイルメタデータは影響を受けない可能性が高いため(破損のターゲットにならない限り、これは比較的重要ではないか、ハッシュ検証も失敗します)ファイルへの変更を検出するべきではありません。したがって、破損したファイルはバックアップされるべきではありません。確実にしたい場合は、バックアップソリューションを構成して、1つが破損し、そのような状態でバックアップされた場合に備えて、少なくともいくつかの古いリビジョンを利用できるようにします。

1
a CVn