<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title><![CDATA[PCと解 掲示板 - 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
		<link>https://pctrouble.net/bbs/topic/477/</link>
		<atom:link href="https://pctrouble.net/bbs/feed/rss/topic/477/" rel="self" type="application/rss+xml" />
		<description><![CDATA[誤ってゼロフィルし直後に停止したHDDからのサルベージ の中の最新の投稿]]></description>
		<lastBuildDate>Mon, 04 Jul 2022 16:48:32 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Re: 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1462/#p1462</link>
			<description><![CDATA[<p>得られた結果を整理してみると、Recuvaとファイナルデータではファイル名、日時などの情報込みで復元可能なものは検索においては同等で、PhotoRecから得られたファイルとの比較でこれらが重ならないファイルは数において初期に書き込まれた約1/4に集中していることがわかりました。</p><p>重複ファイルの中でハッシュ値などで同じとはみなされない、言い換えればPhotoRecによって正常に復元されなかったファイルは15くらいありましたが、それらはRecuvaにおいて正常に復元されました。ファイナルデータはバイナリエディタで先頭をいくつか比較した限りでは同じでした。</p><p>重複しないファイルはRecuvaで復元が不可能なので、PhotoRecに頼らざるえないのですが、これらのファイルの中でZARで得られた情報と合わないファイルは4くらいでファイナルデータのファイル情報のない回収ファイルとファイルサイズで比較しましたが、同じサイズのものはありませんでした。4ファイルはそれなりに断片化したもの、前後かがわずかに欠けたもの、2分割されたものなどで、最終的に回収に困ったのは2分割の1ファイルでしたが、こちらは2K未満足りないようで、PhotoRecでTSファイル限定としていたため、フィルターにかかったようです。</p><p>これらの結果から考えると、ゼロフィルでおそらく先頭から1/4のファイルに関するMFTが消えたと考えてよさそうです。Recuva、ファイナルデータではこれらのMFTを参照しているから1/4のみ復元できないのでしょう。</p><p>ZARはこれらのものとは別のアルゴリズムをつかっているのでしょうし、ディレクトリエントリなどを参照しているにしても、データのポインタなどがゼロフィルで埋められた領域であるならば、なぜぞれぞれ別の領域になっているのかは謎ですが、ZARの情報がなければ、1/4のファイルの復元はかなり不確実性の高いものになったため、その意味では役立ちました。まあ、ZARが損傷のないMFTの参照がないこと、Recuva、ファイナルデータがディレクトエントリらしき情報を参照していないか無視なのかなどの理由はわかりませんけれども、それぞれ簡単にでもアルゴリズムを明らかにしてくれればありがたいですが、企業秘密だから難しいでしょうね。</p><p>ファイナルデータでの解析データをロードすると、画像のように同じものが重複するのですが、バグでしょうか。商品版と試用版が異なるからなのか原因がわかりませんでしたので、大量にスクリーンショットをとることになりました。</p>]]></description>
			<author><![CDATA[null@example.com (cm)]]></author>
			<pubDate>Mon, 04 Jul 2022 16:48:32 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1462/#p1462</guid>
		</item>
		<item>
			<title><![CDATA[Re: 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1441/#p1441</link>
			<description><![CDATA[<p><a href="https://pctrouble.net/caution_bbs.html" target="_blank" rel="ugc noopener">私はすべての質問に答えるつもりはない</a>ので、本件に対する回答は最後にします。</p><br /><p>多分、MSRは関係ありません。<br />MSRはWindowsのシステム用の領域で、別の1つのパーティションです。<br />ファイルシステムはパーティション（というよりボリューム）に紐付いているので、<br />別のパーティションであればファイルシステムも別です。<br />本件はGPTディスクなので、パーティションテーブルもそのまんまGPTです。</p><p>GPTにはバックアップがありますが、それでもファイルを認識できないようですので、<br />私はMFTが上書きされていると判断しています。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>ゼロフィルでMFTが埋められた場合でディレクトリエントリが残っているということはあるのでしょうか。</p></blockquote></div><p>あります。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>ディレクトリエントリがどこにあるのかわかりませんが、管理情報であるなら、こちらも先頭であるように思われます。</p></blockquote></div><p>それがルートディレクトリエントリのようなものであるMFTです。<br />MFTが先頭にあるのは、ドライブの接続時に毎回最初に必ず読み込まなければならないからです。</p><p>ディレクトリツリーというように、ファイルシステムも同じような木構造をしています。<br />木に枝分かれしている節がいくつもあるように、ディレクトリエントリもいくつもあります。<br />各ディレクトリエントリの場所は、必ずしも領域の先頭にある必要はありません。<br />ディレクトリ内のファイルにアクセスしなければ、そのディレクトリエントリを参照する必要もないからです。</p><p>逆に、ファイラーで別のフォルダを表示するとHDDのシーク音が聞こえることがありますが、<br />これは別のディレクトリエントリを読みに行ったことによるものと考えられます。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>ディレクトリエントリのデータの大きさ、ファイル名、位置情報が残っていたとしてデータが単一の場合はそれで復元可能かもしれませんが、データが単一でない場合のTSファイルはどうやって復元できているのでしょうか。</p></blockquote></div><p>だから、ディレクトリエントリの情報をもとにしてファイル名を含めたファイルの復元をしても、<br />ファイルの復元が不完全になっているのだと思いますが。<br />私は一部のファイル名が復元されるのは残っているディレクトリエントリを参照しているからだと考えているだけで、<br /><strong>初回の回答から一貫して、ファイル名をもとにしたファイルの復元は前提にしない方向で話をしています</strong>。<br />本件には適していないからです。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>これは暫定表示で完了後には表示されていなかったファイルが表示されるのでしょうか。また、スキャンの途中で停止した場合、そこまでの検出結果は表示に反映されるのでしょうか。</p></blockquote></div><p>時間と結果は何をどう設定してスキャンしたのかによりますが、途中キャンセルしても結果は表示されます。<br />ただし、動画ファイルのプレビューはできないと思います。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>よくわからないのですが、PhotoRecで復元するファイル名を選択できるのでしょうか。それともファイルの種類を選択ということでしょうか。</p></blockquote></div><p>もちろん、ファイル名の選択はできません。<br />ファイル名を選択するとも書いていません。<br />何度も書くようですが、ファイル名を基準にしていないので。<br />拡張子によるファイルの種類の選択です。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>私はあまり特定ファイルの復元というのはないのですけれども、ファイル名指定があればそれほそれで便利なのでしょうね。</p></blockquote></div><p>便利というより、<strong>得られる結果が変わる</strong>のです。<br />拡張子の選択と、それに適した設定にすることにより、復元できるファイルとファイルの状態が変わります。<br />これは元のデータの状態が悪い場合には、とても重要なことです。<br />ファイル復元ソフトなので、目的のファイルを使える状態で復元できなければ意味がありませんからね。</p><p>ファイル名に基づく復元は、どのファイル復元ソフトでもスキャンは早いと思いますが、<br />ファイルを削除してすぐ等、論理障害が皆無の状態でしか有効に機能しません。<br />それは結局、現状のファイルシステムにかなり依存した復元方法だからです。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>前々から疑問には感じていましたが、普通のファイル削除とファイル共有からのファイル削除は異なる処理になるでしょうか。</p></blockquote></div><p>同じだと思います。</p><br /><p>本件はHDD自体は正常動作しているようですので、<br />いくらでもテストできるのが不幸中の幸いなのかもしれません。<br />いや、大変ですけどね。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Sat, 21 May 2022 15:24:47 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1441/#p1441</guid>
		</item>
		<item>
			<title><![CDATA[Re: 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1439/#p1439</link>
			<description><![CDATA[<p>管理人さま、返答ありがとうございます。</p><p>＞従って、MFTの上書きは数秒もあれば十分です。<br />存在していたファイルに関する大元の情報は失われていると考えるべきです。</p><br /><p>このあたりがよくわからないのですが、MiniTool Power Data Recoveryなどでは16MBのMSR領域が表示されるので、ゼロフィルの場合、最初にこちらがゼロで埋められるとおもうのですが、ゼロフィルがMSRで留まった場合、どうなるのでしょう。いまひとつMSRの役割がよくわからないのですが、パーティションテーブルの役割を担っているとすると、MSRの破壊のみでの症状という可能性もあるのでしょうか。</p><p>ゼロフィルでMFTが埋められた場合でディレクトリエントリが残っているということはあるのでしょうか。ディレクトリエントリがどこにあるのかわかりませんが、管理情報であるなら、こちらも先頭であるように思われます。ディレクトリエントリのデータの大きさ、ファイル名、位置情報が残っていたとしてデータが単一の場合はそれで復元可能かもしれませんが、データが単一でない場合のTSファイルはどうやって復元できているのでしょうか。</p><br /><p>&gt;高度な復元 &gt; 設定 &gt; ファイルの種類 &gt; サウンド／ムービー &gt; TS - 動画ファイル<br />とあります。</p><br /><p>私はファイナルデータには詳しくないのでよくわからないのですが、高度な復元というのはスキャン後でないと駄目なように思われます。プレビューやサムネイルなどが確認できればある程度先頭が正しい可能性を判断できるのですが、短時間のスキャンでは対象ファイルがみつからず、他の正常ディスクのファイルではプレビュー対象ではないとされました。</p><p>MFTの不完全性から失われたファイル情報の可能性も否定できないので、その可能性とファイナルデータの復元性確認でクラスタスキャンをはじめてみたのですが、他のソフトウェアよりかなり長い時間がかかるようです。設定でTSファイルに限定したからか、一日程度でMFT領域を当に越えたと思われるものの、検出されたファイルは謎の数字のファイル名が一つのままです。これは暫定表示で完了後には表示されていなかったファイルが表示されるのでしょうか。また、スキャンの途中で停止した場合、そこまでの検出結果は表示に反映されるのでしょうか。（Recuvaなどはフルスキャンは数時間程度ですが、途中で停止だと結果に反映されません。）</p><br /><p>＞・復元するファイルを選択してからスキャンする</p><p>・スキャンしてから復元するファイルを選ぶ</p><p>私がよく使うのは前者です。<br />ファイナルデータ、PhotoRecは両方ともできますが、</p><br /><p>よくわからないのですが、PhotoRecで復元するファイル名を選択できるのでしょうか。それともファイルの種類を選択ということでしょうか。</p><p>私はあまり特定ファイルの復元というのはないのですけれども、ファイル名指定があればそれほそれで便利なのでしょうね。</p><p>前々から疑問には感じていましたが、普通のファイル削除とファイル共有からのファイル削除は異なる処理になるでしょうか。もちろん容量が小さいものはゴミ箱に収容された後でゴミ箱から削除される場合です。私はMacから削除することがほとんどなのですけれど、なんとなくこれらは異なるのではと思うのですが、どうなのでしょうか。</p><p>＞ファイルが同じかどうかは、ハッシュ値で比較すればいいと思います。</p><p>その手がありましたね。。。昔、PCI拡張ボックスでデータ転送したファイルのハッシュ値が異なって、使えなかったということがトラウマになって忘却になっていたのかもしれません。</p><p>全復元なのでファイル数は多いので大変ですが、確実ではありますね。</p>]]></description>
			<author><![CDATA[null@example.com (cm)]]></author>
			<pubDate>Tue, 17 May 2022 22:40:16 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1439/#p1439</guid>
		</item>
		<item>
			<title><![CDATA[Re: 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1437/#p1437</link>
			<description><![CDATA[<p>まず、存在するのはMFTのバックアップではなく、MFTのミラーです。<br />これはエラーをロールバックするためにあるもので、上書きを防ぐものではありません。<br />頻繁にアクセスするため、両方とも領域の先頭部分に位置しています。<br />従って、MFTの上書きは数秒もあれば十分です。<br />存在していたファイルに関する大元の情報は失われていると考えるべきです。<br />領域内には、縁の切れたデータが散在している状態です。<br />また、MFTは上書きされていても、ディレクトリエントリの情報は残っていると思います。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>管理人さまはバージョンアップに関して何か基準をお持ちでしょうか。</p></blockquote></div><p>よく使うソフトは旧バージョンのインストーラ等も保存していますね。<br />現在のHDDの容量からすれば、大したデータサイズでもないので。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>ファイナルデータは試用版でもプレビューできるとあったので試用してみましたが、TSファイルは対象外でした。</p></blockquote></div><p>ファイナルデータはTSファイルにも対応しています。<br />たとえば、<br />高度な復元 &gt; 設定 &gt; ファイルの種類 &gt; サウンド／ムービー &gt; TS - 動画ファイル<br />とあります。</p><br /><div class="quotebox"><cite>cm さんのコメント:</cite><blockquote><p>どちらも実際には中身は同じように思うのですが、これだけ大規模な復旧は久々で、管理人さまは複数のソフトの場合、優先順位はどのようにお考えでしょうか。</p></blockquote></div><p>基本的に、複数のソフトの併用はしません。<br />試してみることはありますが、適していないと判断すれば使いません。<br />サイトでも書いているとおり、基本はファイナルデータ、データの取得が主ならPhotoRecです。<br />これには理由があります。</p><p>ファイル復元ソフトには、大きく分けて2通りのものがあります。<br /></p><ul><li><p>復元するファイルを選択してからスキャンする</p></li><li><p>スキャンしてから復元するファイルを選ぶ</p></li></ul><p>私がよく使うのは前者です。<br />ファイナルデータ、PhotoRecは両方ともできますが、<br />基本的には<strong>設定してからスキャンする</strong>、つまり前者のファイル復元ソフトです。<br />一方、最近商業的に成功していると思われるファイル復元ソフトは、<br />全自動でスキャンした結果からファイルを選ぶものが多いです。<br />誰にでも使いやすい面はありますが、逆はできなかったりします。</p><p>ファイルシステムの破損が進んだ状態では、データの優先度がはっきりしません。<br />データの優先度がわかるのは、その記憶装置を使っていたユーザーだけです。<br />事前に優先すべきファイルがわかっていれば、<br />特定のファイルのデータのみを優先して、それ以外のデータは無視することができます。<br />領域が重複しているデータも、優先度がはっきりします。<br />この前提がないと、あれもこれも確保する折衷案を取らざるを得ません。<br />結局、得られるデータは中途半端になります。<br />これはファイル名に関しても同じで、<br />ファイル名を優先すれば、ファイル名の情報は残っていても、<br />ファイルとしては意味のないデータが検出されることになります。<br />だからファイナルデータの高度な復元では、異なる手法のスキャン結果を後で照合しているみたいですけどね。</p><p><strong>データが重要であれば、対象のファイルだけを選択して復元することが極めて有効</strong>です。<br />優先度とはそういうものです。<br />ファイルが同じかどうかは、ハッシュ値で比較すればいいと思います。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Mon, 16 May 2022 17:44:47 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1437/#p1437</guid>
		</item>
		<item>
			<title><![CDATA[Re: 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1435/#p1435</link>
			<description><![CDATA[<p>管理人さま、返答ありがとうございます。</p><p>とりあえず、PhotorecとZARで回収をはじめました。Photorecですべて読み出し、ZARで読み出したファイルとサイズを照合して、接合の有無を確認するため、接合した場合に生じるドロップを確認したところ、元々転送したファイルでは数ファイル以外は正常でした。正常でないファイルは元々上書きなどのファイルと思われます。少数あった直に複数同時録画のものは多少断片化していることもあり、正常なものは復元できませんでした。</p><p>＞ZARはよく知りませんが、ちょっと調べてみた限りでは機能が中途半端なように思います。</p><p>私もZARは10年くらい使用しているのですが、マニュアルも読んだこともなく、設定は不良セクタの扱いの設定を意識していたくらいで、日本語化もされていないからかあまり解説サイトもなかったように思います。</p><p>これを機にメーカーサイトでマニュアルを読んだのですが、本来、スキャンでは自動的にクィックスキャンの後に必要ならフルスキャンとなるのですが、今回はクィックスキャンのみで終了していました。過去の経験ではクィックスキャンのみで終了したのはありませんでした。</p><p>そこで手動でフルスキャンしてみると、MFTを含むファイル構造は先頭にあるのみで、フルスキャン後に回収されたファイルの中身もクィックスキャンと変わらないようでした。</p><p>使用していたバージョンは2015年のBuild11だったので、最新版のものをインストールしてみてスキャンしてみたのですが、どういうわけか同じパラメータ設定でもスキャンのリードレートがどうやっても2015年の半分程度でまたクィックスキャンの領域も長めで2015年のものでは30分程度だったのが、最新版では2時間半もかかりました。</p><p>それで結果がよければいいのですが、回収対象の同時録画のファイルなども2015年のものでは多少断片が接合した程度のものもゼロファイルとなり、今回に限れば改善となっていませんでした。</p><p>原因が取捨の基準が厳しくなったのか、アルゴリズム自体に大きく変更があったのかわかりませんが、今回だけで断定はできないものの、バージョンアップが今回には適していないようです。</p><p>これは危惧していたことなのですが、一般的にソフトウェアのバージョンアップは必ずしも性能の改善とはならず、復元ソフトもバージョンアップで何が改善されたのかわかりにくく、例外ではないと思っていたのですが、ZARの場合は最初に使っていたものに比べて2015年のものは復元能力が大幅に向上していて、多言語対応で日本語ファイル名などの復元可能になったこともあって、バージョンアップに迷いはありませんでした。しかし、今回の件でバージョンアップが正しいのか疑問です。</p><p>PhotorecやTestDiskもバージョンアップでソフトウェアのサイズが減少したときもあり、長時間や空き容量などを要することもあって、復元能力が向上しているのか否か比較や判断も難しく、毎回どのバージョンを使うべきか考えてしまいます。管理人さまはバージョンアップに関して何か基準をお持ちでしょうか。</p><p>ファイナルデータは試用版でもプレビューできるとあったので試用してみましたが、TSファイルは対象外でした。MiniTool Power Data Recoveryは1GBまで復元可能というので試してみましたが、試用版は復元不可に変更されたようです。</p><p>ZARが無料版でも4フォルダまでファイル数制限なしというのも太っ腹なのかもしれませんが、試用版で全く復元できないのでは性能をみることもできずでは商業的な面もあるのでしょうが、性能に関して判断できませんでした。</p><p>PhotorecとZARで可能なことはやったので、できるだけMFTを変更しないと思われるクィックフォーマットを行い、ZARの2005年のものでスキャンしたところ、ファイル構造の変化はあったものの、復元されたファイルに関しては結果は変わらないようでした。</p><p>フォーマットでRecuvaでスキャン可能になったので、フルスキャンしたところ、7割強のファイルが回収できました。その中にはPhotorec、ZARで復元できなかったファイルのほとんどは復元できたので、おそらく復元が不完全な1、2ファイル以外は完全に回収できたようです。</p><p>問題はこれらの再構成ですが、Photorecはデータを書き出しに近いので、日付などの変更も大変でやや不安な面もあり、Recuvaは上書きなどの情報もあり、その分、復元率も低くなるのですが、復元ファイルは一定の信頼はあるものの、やはり復元なのでどちらを優先するか考えてしまいます。どちらも実際には中身は同じように思うのですが、これだけ大規模な復旧は久々で、管理人さまは複数のソフトの場合、優先順位はどのようにお考えでしょうか。</p><p>わからないのはゼロフィルの影響です。それによってファイル構造が破壊されたのはわかるのですが、Photorecで回収されたファイルの総容量と大まかな記憶がおそらくほぼ同じであることから考えると、大きくゼロで埋められたとは思えず、ZARではデータの指定先が間違ってはいるものの、ゼロで埋められているのであればまったく復元できないでしょうし、正確なサイズでとりあえず復元されています。</p><p>RecuvaはZARほど復元率が高くないため、7割くらいもMFTがゼロで埋められた影響なのかというと回収されたファイルの総量から疑問です。ただMFTに問題がないならフォーマット後もZARでうまく回収できなかったのもよくわからず、単にソフトウェアの設計の違いともいえますが、あらためてMFTがどのような設定なのかと思いました。</p><p>ゼロフィルでファイルシステムが壊れているため、MFTのバックアップから復元される処理が行われず、そのあたりをソフトウェアによって読みにいくかいかないかの違いのようにも思ったりもしますが、MFTに関しての理解が浅いため、推測の域をでません。</p><p>管理人さまはどのようにお考えでしょうか。</p>]]></description>
			<author><![CDATA[null@example.com (cm)]]></author>
			<pubDate>Fri, 13 May 2022 23:45:00 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1435/#p1435</guid>
		</item>
		<item>
			<title><![CDATA[Re: 誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1424/#p1424</link>
			<description><![CDATA[<p>ファイルシステムに関する重要な情報は領域の先頭部分に集中しているので、<br />ゼロフィルを実行したのであれば、短時間であったとしても元通りには戻せないと思います。<br />もちろん、TestDiskを使ってもです。</p><p>本件はMFTがかなり上書きされているでしょうから、<br />ファイル復元ソフトを使うにしても、MFTの情報をもとにしたファイルの復元は避けるべきです。<br />データの完全性を求めるのであればなおさら。<br />これはつまり、ファイル名やフォルダ構造の復元はあきらめることを意味します。</p><p>従って、書かれているようにPhotoRecを使ってファイルを復元することをおすすめします。<br />ZARはよく知りませんが、ちょっと調べてみた限りでは機能が中途半端なように思います。<br />このケースでは、いわゆるクラスタスキャンに特化したツールであるPhotoRecが最善だと思います。</p>]]></description>
			<author><![CDATA[null@example.com (web404)]]></author>
			<pubDate>Wed, 27 Apr 2022 15:11:50 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1424/#p1424</guid>
		</item>
		<item>
			<title><![CDATA[誤ってゼロフィルし直後に停止したHDDからのサルベージ]]></title>
			<link>https://pctrouble.net/bbs/post/1421/#p1421</link>
			<description><![CDATA[<p>HDDをゼロフィルフォーマットしようとして、別のHDDをフォーマットしてしまいました。いつもは何度も確認するのですが、起きて間もない頭は確認はしたものの起きていなかったようです。その前に再起動やらいろいろやったので大丈夫かと思ったのですが、甘かったようです。</p><p>対象のHDDは動画のTSファイルの倉庫でGPT NTFS 1パーティションです。停止まで数秒なので数MBか数十MBだと思いますが、管理領域を埋めるには十分でエクスプローラーから開けなくなりました。</p><p>TestDiskで「EFI GPT」選択でみると画像のようにMS Dataとなっていてファイルは読めません。駄目元で一応Deeper Searchをやりましたが、やはりファイルが読めるようなパーティションはみつかりません。</p><p>当方はファイルサルベージはだいたいRecuvaかZARなのですが、Recuvaはファイルシステムの破損からフォーマットしないと無理なので、ZARを使ったら、スキャンの段階ではほとんどのファイルはサルベージできそうだったのですが、サルベージしてみると多くのファイルが開始終了などがずれているか異なるようになっています。</p><p>ファイルシステムの破損から管理領域の指定からずれている印象なので、試しにPhotoRecで数百GB読み出すとZARのものと全く同じサイズの正しい動画が回収できます。（ZARの同じサイズのものは正常な復元ではありません。）そういう意味ではファイルシステムさえ何とかできればZARで割と簡単にサルベージできそうなのですが、ファイルシステムを修復となるとクィックフォーマットでいいようにも思うのですが、必要以上に書き換えそうでどうしたものかと思います。TestDiskで適切な変更は可能でしょうか。</p><p>このHDDは直に録画ではなく、ほかのHDDからの転送なのでPhotoRecで数百GBみた限りでは詳細に確認したわけではありませんが、20GB超の動画も含めてほとんどはサルベージできている印象です。（過去の経験からこのようなときのために断片化を防ぐために極力そのようにしています。）なのでファイルシステム破損からのずれを何とかできなければ、PhotoRecとZARからのファイルをつき合わせてになりそうですが、これで完全に復旧できるかはわかりません。</p><p>したがってできればファイルシステムの破損からのずれを修復したいのですが、可能でしょうか。</p>]]></description>
			<author><![CDATA[null@example.com (cm)]]></author>
			<pubDate>Sat, 23 Apr 2022 18:33:45 +0000</pubDate>
			<guid>https://pctrouble.net/bbs/post/1421/#p1421</guid>
		</item>
	</channel>
</rss>
