上司は、ディスクのクローン作成中に、構成が難しいソース ハード ディスクを誤って破損してしまったのではないかと心配しています。
ドライブはあらゆる点で完璧に機能しているように見えるため、破損しているとは思いませんが、アプリケーションは安全性が重要なため、上司にこの考えを正当化する必要があります。疑問の一部は、テスト時に宛先ドライブが正しく動作していたにもかかわらず、クローンの完了時に Acronis True Image がエラーを出したことです。
私の経験では、クローンは失敗するか、完璧に動作するかのどちらかです。また、クローン中にソース ドライブが破損する可能性は非常に低いです。これらの仮定は妥当でしょうか?
これをどうしたら確実に判断できるでしょうか?
プラットフォームは Windows 10 Pro ですが、あらゆる OS 環境に対するアプローチに興味があります。
ありがとう！
コメントへの返信: エラーには「ディスクのクローン作成に失敗しました」と表示されています。言葉どおりではないかもしれませんが、非常によく似た一般的なエラーです。クローン作成を再度実行したら、正確な言葉で更新します。
上司は、テスト中に両方のドライブの OS が非常に不安定になったため、データが変更になった可能性があると考えています。後で気づいたのですが、これはドライブを取り出すときにアース テープを剥がしたためで、アース テープを交換すると両方のドライブの問題は解決しました。
答え1
ディスク上のすべてのファイルに対して sha256 チェックサムを実行できます。唯一の問題は次のとおりです。
- 比較するにはかなりの時間がかかります
- クローン後にどちらかのイメージを起動すると、いくつかのビットが変更されます
したがって、クローン作成後、すぐに sha256 の比較を実行し、どちらのドライブも起動しないでください。
したがって、すべての sha256 が一致する場合、ファイルは同じです。
答え2
バックアップ操作にはソース ドライブの読み取り操作のみが含まれることを知りながら、コピー操作のためにソース ディスクが破損したと上司が推測する根拠は何でしょうか。
私の経験では、クローンは失敗するか、完璧に動作するかのどちらかです。また、クローン中にソース ドライブが破損する可能性は非常に低いです。これらの仮定は妥当でしょうか?
バックアップ操作で、通常の使用では読み出されないドライブのセクターから読み取ろうとしたため、バックアップ操作でソース ドライブに問題があることがわかった可能性があります。このサイトで Rufus プログラムを検索すると、同様の問題が見つかります。Rufus が USB ドライブを破壊していると主張する人がいます。実際には、大量の情報 (大きなイメージ ファイル) が短時間に書き込まれ、ペンドライブのスペースを大量に消費するため、ターゲット ドライブに問題があることがわかったのです。
これをどうしたら確実に判断できるでしょうか?
Acronis True Image で使用していたコピー モード (ファイルまたはパーティション、使用済み領域、または完全なセクタ単位のコピー) を明らかにしていないため、セクタの読み取り可能性とファイル システムの整合性を確認する必要があります。
- smartmontools を実行し、ログ ファイルをここに投稿します。
ログ ファイルをコンパイルする方法については、次の説明を参照してください。
https://forum.cgsecurity.org/phpBB3/viewtopic.php?f=5&t=10910
- ログ ファイルに表示されるパラメータに応じて、ソース ドライブを複製するか、読み取り不可能なセクターを検索する必要があります。最も簡単な方法は、Knoppix、systemrescueCD などが格納された Linux ペンドライブからこれを行うことです。基本的な構文は
ddrescue infile outfile mapfile. のようなものinfileで、outfileパーティションとドライブ、およびファイルを表すことができます。ディスク上でそのコマンドを実行する必要があります。マップファイルには、読み取り不可能なセクターがコード化された読み取り可能な形式で表示されます。
入力ドライブの読み取り可能性を検証する場合、出力ターゲットは/dev/nullas outfile を使用して破棄されます。
- ソースディスクでchkdskを実行する
ソース上で chkdsk を実行すると、元に戻すことはできません。ソース ディスクが破損している疑いがある場合は、chkdsk を呼び出す前に複製が使用可能であることを確認してください。
答え3
クローン技術はハードドライブつまり、物理デバイスです。クローン作成するディスクの読み取りと、クローン作成先のディスクへの書き込みは、他のディスク操作と何ら変わりありません。つまり、ディスクを誤って損傷する可能性は、ファイルをコピーするときと変わりません (もちろん、クローン作成するデータの量に応じて調整されます)。クローン作成中にドライブが故障する可能性はありますが、その場合、通常の操作でもすぐに故障します。このイベントの原因はクローン作成ではなく、ドライブの状態です。
ディスクの物理的な状態は、SMART パラメータを読み取ることで確認できます。SMART は、ディスクに組み込まれた診断データ収集システムです。最も重要なのは、再割り当てされたセクター数と保留中のセクター数が理想的には両方とも 0 であることです。これらのパラメータのいずれかが 0 より大きい場合、ドライブは完全には信頼できないと見なす必要があります。数千の場合、それは時限爆弾です。
SMART が正常であれば、ディスクは損傷していません (ただし、おっしゃったテープのような外部の機械的損傷は除きます)。
次に、論理的な損傷、つまりディスク上の構造 (パーティション テーブルとファイル システム) の破損があります。言い換えると、バイトは正しく読み書きできますが、その値は意味をなさないか、一貫性がありません。このような破損は、ソース ディスクにすでに存在しているか、イメージの処理中に導入されたか、ターゲット ディスクへの書き込み中に発生する可能性があります (ただし、Acronis True Image などのより高度なクローン作成ツールは、セクター単位のクローン作成が有効になっていない限り、最初のケースを検出します)。これは、ソースよりも小さいパーティションにクローン作成する場合にも発生しますが、私の記憶が正しければ、True Image はそれを検出します。
適切なパーティションエディタは、パーティションテーブルに問題があるかどうかを教えてくれるはずです。たとえば、Ubuntu USBなどから起動できる無料のGPartedは、起動時に潜在的な問題について警告します。追加のダイアログなしでメインウィンドウが表示されれば、パーティションテーブルは正常です。次に、表示されたパーティションの横に警告またはエラーアイコンがないか確認します。もしあれば、パーティションを右クリックして情報(GParted の最新バージョンでは、一部のシステム パッケージが欠落している場合、FAT パーティションの横にエラーが表示されます。これはパーティションの問題を示すものではないため、無視できます。)
最後に、パーティション上のファイルシステムが破損している可能性があります。NTFS の場合、ファイルシステムの整合性をチェックするには、Windows またはそのグラフィカル版を使用するのが最適ですchkdsk。このような問題の一部は、これらのツールで修復できます。