質問ddやその他のツールを使用する場合、デバイスが重要なハイブリッドディスクであるか、またはすべてのタスクがHDDと同じように実行されるという事実ですか？
コンテキスト
デバイスはSeagate ST1000LM014です。修理のためにノートブック（サウンドカード）を送信する前に、次のコマンドを使用してバックアップを実行しました。dd if=/dev/sdb conv=sync,noerror bs=64K | gzip -c | split -b 2000m - ./sdb_backup.gz.
予想通り、HPサービス担当者はまさにその理由のためにドライブをフォーマットしました。私は彼らがそれを交換したと疑う理由はありません（まだ）。データを回復しました。cat sdb_backup.gz.* | gunzip -c | dd of=/dev/sdb conv=sync,noerror bs=64K
他のWindowsで見ることができるのは回復パーティションだけですgdisk -l /dev/sdb。
保護MBRを持つ有効なGPTを見つけてください。
ディスク /dev/sdb: 1953525164 セクタ、931.5 GiB
論理セクタサイズ：512バイト
ディスク識別子（GUID）：{{削除しました}}
パーティションを分割したテーブルには最大128のエントリを含めることができます。
最初の使用可能なセクターは 34 で、最後の使用可能なセクターは 1953525130 です。
パーティションは 2048 セクタ境界に整列されます。
利用可能な合計スペースは14,851セクタ（7.3MiB）です。
番号付け開始（セクタ）終了（セクタ）サイズコード名
1 2048 1333247 650.0MiB 2700 基本データパーティション
2 1333248 1865727 260.0MiB EF00 EFIシステムパーティション
3 1865728 2127871 128.0MiB 0C01マイクロソフト予約...
4 2127872 1907614565 908.6 GiB 0700 基本データパーティション
5 1907615744 1909415935 879.0MiB 2700
6 1909415936 1953513471 21.0 GiB 0700 基本データパーティション
gpartedは、最初の4つのパーティションが「不明」タイプで表示されます。 sdb4は少なくともntfsでなければなりませんが、このようにマウントされません。あるいは、ntfs-3gは次のものをmount -r -t ntfs-3g /dev/sdb4 /media/myusername/sdb4提供します。
NTFS署名がありません。 '/dev/sdb4' をマウントできません: 無効なパラメータ "/dev/sdb4" デバイスに有効な NTFS がないようです。
しかし、私の考えにはそれだけでも十分な背景知識だ。このエラーを解決するためにいくつかの方法を試しましたが、解決できませんでした。私はここで解決策を探していません。
ベストアンサー1
あなたが何をしているのかを知っているようです！以前に動作していた場合sdb（Linuxで）、説明したように復元を実行した後は、確実に再び機能します。これが発生した場合は、ユーザーのエラーの種類が疑われます。しかし、それにもかかわらず、私は何が間違っているのかわかりません。たとえば、gunzipが間違った順序でファイルを入力すると（おそらく）知っている恐ろしい警告メッセージが生成されます。
SSDはドライブが別々に公開され、キャッシュはソフトウェアによって処理されるという内容を読み取ったようです。しかし、私はこれが初期のハッキングであり、一時的な方法だったと思います。このドライブは、PlaystationやMacでも簡単にアップグレードできると宣伝されています。特別なソフトウェア設定は言及されていません。私はそれが通常のハイハイブリッドドライブと同じように動作すると期待しています。
私はあなたがもはやバックアップを調査する興味や能力を持っていないかもしれないことを理解しています。ただし、これらのバックアップを確認するには、余分なハードドライブまたはテラバイトの空きディスク容量が必要になることがわかりました。パイピングは、dd conv=sparse of=single.img元のドライブに書き込まれなかったブロックを割り当てずにイメージファイルを生成します。たとえば、losstupを使用してイメージファイルにディスクとしてアクセスできますlosetup -P --show -f single.img。 （splitコマンドが与えられると、これらのイメージファイルはvfat / FAT32で作成できないことに注意する必要があります。）
原則として、回復を事前にテストしていないようです。実際にオペレーティングシステムのイメージバックアップをテストする方法は、それを同じハードウェア（そして実際に起動可能であることを確認するためのEFIブート変数）に復元することです。これはあまり現実的ではありません。これは、イメージのバックアップがどのように行われないかを示しています。一般的に言えば説明したような状況を除いて、非常に便利です。
（Linuxのインストール時にEFIを実行する方法を知っているようです。Windowsの場合... Linuxを使用して正確な設定をバックアップしたい、またはefibootmgrあなたのために設計されたCloneZillaなどのツールで練習してみてください。）素晴らしいです。）
つまり、できる画像内のファイルにアクセスする機能が検証されました。この手法を使用すると、イメージのバックアップに対してある程度の自信を持つことができ、ユーザーファイルを回復する能力についてもほぼ完全な自信を持つことができます。