Ubuntuでのデータ復旧：初心者向けガイド

【注意】 データが必要な状況では、自己流の復旧作業（通電の繰り返し、書き込みを伴う操作、分解、修復コマンドの実行など）で状態が悪化し、取り返しがつかなくなることがあります。本記事は“被害最小化（ダメージコントロール）”のための安全な初動と判断基準を整理するものです。重要データが関わる場合は、早い段階で株式会社情報工学研究所のような専門事業者への相談を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）。

「消えた…」の瞬間にやりがちな最悪手：まず“書き込み”を止める理由

Ubuntuで作業していて、ファイルが突然見えなくなったり、マウントできなくなったり、あるいは誤ってrmしてしまったり。画面の前で固まったあとに頭をよぎるのは、「とりあえず再起動」「とりあえずfsck」「とりあえずコピー」みたいな“反射”です。

でも、データ復旧の世界では、その反射がそのまま損失に直結します。理由はシンプルで、失われたデータの多くは「消えた」のではなく「上書きされていないだけ」だからです。誤削除なら、実体はまだディスク上に残っている可能性があります。ファイルシステム障害でも、メタデータが壊れて見えないだけで中身は残っていることがあります。ここで書き込みが走ると、残っていた領域が上書きされ、回収可能性が落ちます。

冒頭30秒の“クールダウン”：やること／やらないこと

まずは温度を下げるつもりで、やることを固定します。難しい診断より先に、“被害最小化”を優先します。

• やること：作業を止める／可能ならアンマウントする／そのディスクへの書き込みを止める
• やること：ログや状態を“読むだけ”で採取する（後述）
• やること：重要データなら、ここで専門家に相談する判断をする
• やらないこと：再起動を繰り返す、アプリを入れる、アップデートする（書き込みが増える）
• やらないこと：原本ディスクに対して修復系コマンドを打つ（fsck、btrfs check --repair等）
• やらないこと：「空き容量を作ろう」と削除や整理をする（上書きが進む）

症状 → 取るべき行動（まずは安全側に倒す）

依頼判断ページとしての“判断基準”

次の条件が1つでも当てはまるなら、ここで手を止めて相談するほうが結果的に早く、安く、確実です。

• 復旧対象が業務データで、失うと影響が大きい（契約、会計、顧客情報、設計データなど）
• I/Oエラーや異音がある、SMARTで要注意が出ている、読み取りが極端に遅い
• RAID/NAS/仮想化基盤（LVM、mdadm、ZFS、VMFS等）で構成が複雑
• 暗号化や不正アクセスの疑いがあり、証拠保全も必要

相談先：株式会社情報工学研究所（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）

ここまでが“最初のクールダウン”。次章から、プログラマー視点で腹落ちするように「何が壊れているのか」を切り分け、以降の手順を一本の線でつなげます。

何が壊れたかを切り分ける：論理障害／物理障害／人為ミスの三択

データ復旧で一番ありがちな失敗は、原因が未確定のまま“効きそうなコマンド”を打ってしまうことです。現場の独り言としては、こんな感じです。

「fsckって“直してくれる”やつでしょ。とりあえず走らせれば…」

この感覚は自然です。プログラマーは不整合を見つけたら修正したくなる。でも、復旧の現場では、修正は“情報を捨てる”操作になりえます。まずは、状況を三択に落として、どの枝にいるかだけでも判定します。

三択の考え方（復旧の設計図）

“読むだけ”で取れる証拠（Ubuntuでの最低限）

ここでのポイントは、復旧作業そのものではなく、状態を固定するための観測です。以降の判断材料になり、専門家に渡すときも効きます。

• 接続状況：どのデバイスが見えているか（例：lsblk）
• カーネルログ：I/Oエラーや再試行、切断の兆候（例：dmesg、journalctl -k）
• SMART：物理劣化のサイン（例：smartctl）

コマンド例（いずれも“読むだけ”の範囲で実施し、結果はテキストとして保管します）：

lsblk -f sudo dmesg | tail -n 200 sudo journalctl -k -n 200 sudo smartctl -a /dev/sdX

ここでI/Oエラーや再試行が多い場合は、論理障害に見えても実態は物理劣化が混ざっていることがあります。プログラマー的には「例外が出るからリトライ」ですが、ストレージではリトライがダメージを増やす局面がある。だから次章では、修復より先に“写し”を作る流れに入ります。

状態を固定してから動く：ログ・SMART・dmesgが“復旧率”を左右する

復旧の現場で強いのは、派手なツールを知っている人ではなく、状況を再現可能な形に固定できる人です。プログラムで言えば、クラッシュダンプとログが揃っていない状態で原因究明しようとして泥沼にはまるのと同じです。

Ubuntuのデータ復旧でも、最初に「どこまでが確定情報か」を揃えるだけで、後段の選択肢が一気に明確になります。

観測を“揃える”と、後の判断が速くなる

たとえば、次の3つが揃うだけで分岐が減ります。

• デバイスとファイルシステムの対応（どれがext4で、どれがLVMで…）
• カーネルが何を言っているか（I/O error、reset、timeout、link down等）
• SMARTが出している異常（再割当、保留セクタ、読み取りエラー等）

これらは、専門家に依頼する場合も非常に価値があります。なぜなら、相談の場で「症状の説明」に時間を溶かさず、いきなり“最適な復旧ルート”の話ができるからです。

初心者が踏みがちな“観測の落とし穴”

観測は安全に見えますが、やり方によっては余計な書き込みを生むことがあります。ここは初心者が安心できるよう、落とし穴を先に潰します。

• GUIファイルマネージャで開くと、自動サムネイル生成やインデックス作成で書き込みが発生することがある
• 自動マウントが働く環境だと、意図せずマウントされ、ログやメタ情報が更新される可能性がある
• 不足パッケージを入れようとしてaptが走ると、書き込みが増える（特に同一ディスク上の/var）

安全側に倒すなら、可能であれば別媒体（Live USB等）で起動し、対象ディスクは“読むだけ”の扱いに寄せます。ここまで徹底するのは、技術的に格好をつけるためではなく、上書きリスクと読み取り負荷を減らすためのダメージコントロールです。

この段階で相談に切り替える価値

観測の結果、I/Oエラーや異音、認識不安定が出ている場合は、以降の「自力で読みに行く」行為そのものがリスクになります。さらにRAIDや暗号化、仮想化が絡むと、切り分けだけで時間が消えがちです。

「自分でやれば速いはず」が、データ復旧では逆転することがあります。復旧対象の価値が高いほど、途中からの相談ではなく、早い段階での相談が合理的です。相談先：株式会社情報工学研究所（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）

次章では、観測で得た情報を前提に、「原本を触らずに作業する」ための最重要ステップ、イメージ化（クローン化）へ進みます。

いきなり直さない：アンマウント＋読み取り専用で進める基本手順

ここが復旧の核心です。復旧に慣れている人ほど、修復より先にこう言います。

「原本は触らない。作業はコピー側でやる」

プログラマーの感覚だと、バグがあればソースを直したくなります。でも、復旧での“原本”はソースではなく、事故現場そのものです。現場を荒らすと、証拠も復旧可能性も減ります。

読み取り専用の基本（できるだけ“触らない”）

まず、対象ディスクをアンマウントできるならアンマウントします。マウントが必要な場合でも、原本は読み取り専用で扱うのが基本です。特にファイルシステムのメタデータは、マウントの仕方で更新されることがあります。

「読むだけ」のつもりでも、OSやアプリが裏で何かを書き込む可能性がある。だから、原本を切り離し、別媒体へクローン/イメージを作ってから解析する流れが合理的です。

イメージ化の考え方：ddではなくddrescueが選ばれやすい理由

初心者向けに誤解のない言い方をすると、ddrescueは“魔法の復旧ツール”ではありません。役割は、読める範囲を最大化しながら、読み取りの負荷を制御してコピーを作ることです。特に物理劣化の疑いがある場合、読み取りの順番や再試行の仕方が結果を左右します。

重要なのは、保存先（出力先）は必ず別ディスクにすることです。同じディスクに書き出した瞬間、上書きリスクが爆発します。

実行の概念例（“原本→別媒体”＋“ログファイル”）：

sudo ddrescue -n /dev/sdX /mnt/recovery/disk.img /mnt/recovery/disk.map sudo ddrescue -d -r3 /dev/sdX /mnt/recovery/disk.img /mnt/recovery/disk.map

ここでのポイントは、disk.map（マップファイル）で進捗と未読領域を管理すること、そして段階的に再試行を増やすことです。無限にリトライするのは賢く見えますが、劣化ディスクでは逆効果になることがあります。

“いま直す”より“あとで確実に拾う”へ

イメージ化ができたら、以降の作業は基本的にdisk.img（コピー側）で行います。ここから先は、パーティションの再構成、ファイルシステムの解析、ファイル抽出など、やることが増えます。だからこそ、原本を温存し、失敗してもやり直せる状態にしておくのが、結果的に最短になります。

次章では、パーティション情報が壊れたケースや、ファイルが見えないケースで、どのツールをどう選ぶと“腹落ち”するかを整理します。

まずは“写し”を作る：ddrescueでディスクイメージ化する最短ルート

復旧で一番大事な設計思想は、「失敗してもやり直せる状態」を先に作ることです。現場エンジニアの感覚に寄せるなら、これは“本番DBに直接ALTERしない”のと同じです。原本に対して何かを試すたびに、取り返しのつかない変更が混ざる可能性がある。だから先にスナップショット相当（イメージ）を取ります。

イメージ化は、ディスク全体をファイル（disk.img）として別媒体に写し取る作業です。誤削除でもファイルシステム破損でも、まずここまでできると選択肢が増えます。特に物理劣化が疑われるケースでは、読み取り順序や再試行の制御が結果を左右するため、ddrescueが選ばれることが多いです。

ddとddrescueの違い（“写す”の品質管理）

実行の前に押さえる3点（初心者が事故りやすい場所）

• 保存先は必ず別ディスク：対象ディスクと同じ場所にimgを書いた瞬間に上書きが発生します。
• デバイス名の取り違えを防ぐ：/dev/sda, /dev/nvme0n1 の誤認は致命的です。lsblkで型番やサイズまで確認します。
• “作業用OS”を分ける意識：可能ならLive環境などで起動し、対象ディスクへの不要な書き込みを減らします。

ddrescueの流れ（段階を分けるのがコツ）

ddrescueは、1回で完璧を狙うより、段階的に“読めるところから”取るのが現実的です。典型的には、まずは再試行を抑えて全体を走査し、次に読めなかった場所だけを深追いします。

概念例（/dev/sdX を /mnt/recovery に保存する想定）：

sudo ddrescue -n /dev/sdX /mnt/recovery/disk.img /mnt/recovery/disk.map sudo ddrescue -d -r3 /dev/sdX /mnt/recovery/disk.img /mnt/recovery/disk.map

-n は最初のパスで深追いを抑える意図です。-d はダイレクトI/Oを使う設定として紹介されることがありますが、環境や状況で効果は異なります。重要なのは“マップファイルを残し、段階を分けて再開できる形にする”点です。

“イメージ化できない”ときの現実的な判断

ここで、現場の独り言が出ます。

「コピーが取れないってことは、もう詰み？」

詰みではありません。ただし、物理劣化が進行している可能性が高く、読み取りを繰り返すほど状態が悪化するリスクが上がります。業務データや唯一のデータなら、この時点での相談が合理的です。特にHDDで異音がある、認識が途切れる、I/Oエラーが増えている場合は、ここから先の自力読み取りは“賭け”になりがちです。

相談先：株式会社情報工学研究所（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）

イメージが取れたら、以降はdisk.img（コピー側）で解析します。次章では「パーティションが消えた／ずれた」ケースを、TestDiskで“どう考えると腹落ちするか”で整理します。

パーティションが消えた／ずれた：GPT/MBRをTestDiskで扱う考え方

Ubuntuで「突然マウントできない」「/dev/sdXは見えるのに中身がない」となると、原因はファイルシステムだけでなく、パーティションテーブル（GPT/MBR）側の破損や誤操作も疑います。ここでの大事な視点は、“ファイルが無い”のではなく、“どこをファイルシステムとして解釈すべきか”を見失っている可能性がある、ということです。

プログラマーの比喩で言うなら、ポインタが壊れてメモリ領域の先頭を見失っている状態に近い。データ本体が残っていても、正しいオフセットが分からなければ辿れません。

TestDiskの役割：復旧より“構造の再発見”

TestDiskは、消えたパーティションをスキャンして見つけたり、パーティションテーブルの整合を確認したりするツールとして知られています。ただし、初心者が誤解しやすい点があります。

• TestDiskは“書き戻し”操作ができる（＝原本に変更を加えられる）
• 正しく使えば有効だが、状況次第で取り返しがつかない方向にも進みうる

だから本記事の方針では、まずイメージ（disk.img）に対して解析する流れを推します。原本に書き戻すのは、十分に理解してから、必要性がある場合に限ります。

どのケースでTestDiskが刺さるか（症状別の当たり所）

“修理”より“抽出”を優先する理由

現場では「元に戻したい」という欲が出ます。分かります。復旧後の運用を考えると、構造を直してマウントできる状態にしたい。

でも、目的が「データを取り戻すこと」なら、まずは抽出を優先するのが安全です。構造の修正は、成功すれば気持ちいい反面、失敗すると状況が分かりにくくなります。抽出は“今ある情報を外に逃がす”行為で、後戻りが効きやすい。

そして、RAID/NAS/LVM/暗号化が絡む場合、パーティションだけ直しても解決しないことが多いです。ここで迷うなら、一般論の手順を突き進むより、個別構成を前提にした判断が必要です。相談先：株式会社情報工学研究所（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）

次章では、「ファイルだけ拾いたい」ニーズに直結する“カービング”の考え方を、メリットと限界をセットで整理します。

ファイルだけ拾いたい：PhotoRec/Ext系ツールの得意・不得意を知る

初心者が一番求めているのは、結局ここかもしれません。

「フォルダ構造とかいいから、とにかく中のファイルだけ戻したい」

このニーズに対してよく登場するのがPhotoRecです。PhotoRecは、ファイルシステムの管理情報（ディレクトリ構造やファイル名）に頼らず、ディスク上の“ファイルっぽい並び”を探して復元するタイプのツールとして知られています。

PhotoRecが強い場面（管理情報が壊れているとき）

カービングは、メタデータが壊れている、あるいは削除されて辿れない状況で効きます。特に次のような場面で“最後の出口”になりやすいです。

• ファイルシステムが壊れてマウントできないが、実体データは残っている可能性がある
• 誤削除後にメタ情報の参照が失われた
• パーティション構造が不明瞭で、まずは“何が残っているか”を確認したい

プログラマー視点では、「インデックスが壊れたDBから、レコードっぽいバイト列をスキャンして救う」ようなイメージに近いです。正確な構造は戻らないかもしれないけれど、中身が救えることがある。

ただし、カービングには“仕様上の限界”がある

ここが重要です。PhotoRecがうまくいっても、次の問題が起きやすいです。

• ファイル名やフォルダ構造は戻らないことが多い：結果が大量の連番ファイルになり、仕分けが必要
• 断片化に弱い：ファイルが断片化していると、途中で欠ける／別ファイルと混ざる可能性
• 拡張子と中身が一致しないことがある：“それっぽいヘッダ”で判定するため、後で検証が必要

だから、カービングは「最短の解決」ではなく、「最後に頼る救命艇」になりがちです。業務データでの“完全復元”が必要なら、カービングだけで終わらせるのは危険です。

ext系の“削除復元”ツールを使う前に知っておくこと

ext4を含むext系では、削除後も状況によっては復元の可能性が残ります。ただし、復元ツールは“書き込みを伴う”場合や、ジャーナルやメタデータの状態に強く依存する場合があります。さらに、削除後に書き込みが進んでいると復旧率が落ちます。

ここでのポイントは、ツール名を覚えることより、順番です。

• 最優先：書き込み停止（上書き回避）
• 次：イメージ化（原本温存）
• その上で：コピー側で解析・抽出を検討

「今すぐ戻したい」焦りは自然です。でも、焦って原本に対して操作すると、結果的に戻らなくなる。ここは“クールダウン”を継続する局面です。

一般論の限界と、相談に切り替えるタイミング

カービングや削除復元は、データ種別や断片化状況、書き込み履歴で結果が大きく変わります。特に、DBやVMイメージ、ソースリポジトリ、設計データのように「壊れていると使い物にならない」ものは、回収後の整合性確認まで含めた判断が必要です。

その判断を一般論だけでやるのは難しい。迷ったら、個別案件の構成と価値を前提に、株式会社情報工学研究所のような専門家に相談するほうが、最終的な“被害最小化”につながります（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）。

次章では、ファイルシステムごとの“やってはいけない修復”がなぜ危険なのかを、ext4/xfs/btrfsの違いとして整理します。

ext4/xfs/btrfsで違う落とし穴：ジャーナルとスナップショットの勘所

「マウントできないなら、直せばいい」。そう考えるのは自然です。ただ、Ubuntuでよく遭遇するext4/xfs/btrfsは、設計思想が違うぶん、“直し方”のリスクも違います。ここで大事なのは、ファイルシステムの“機能”ではなく、障害時に何が自動で起きるか（あるいは起きないか）を理解して、被害最小化の判断をすることです。

まず知っておくべき前提：マウント時に起きる“自動処理”がある

ジャーナリングやログ構造のファイルシステムでは、マウント時に整合性のための処理が走ることがあります。これは通常運用ではメリットですが、復旧局面では「未確定の情報が書き換わる」方向に働くことがあります。

そのため、原本を触るなら最低限として読み取り専用、さらに可能であれば「ログのリプレイや回復処理を抑える」マウントオプションを検討します。ただし、ここも環境差があるため、基本はイメージ（disk.img）側で試すのが安全です。

ファイルシステム別：起きがちな罠と安全側の行動

“修復コマンドを打ちたくなる”気持ちへの回答

現場の心の会話はこうです。

「チェックって読むだけでしょ？ なら安全では？」

実際には、ツールによって「読むだけ」のモードと「直す」モードが分かれます。たとえば“検査”でもログの適用やメタデータ更新が絡む場合があり、結果として原本の状態が変わる可能性があります。復旧局面では、状態を変えないこと自体が価値です。

だから方針は一本です。

• 原本は温存（書き込み停止）
• イメージ化して作業対象をコピーへ移す
• 修復より先に抽出（外に逃がす）を優先

一般論の限界が出やすい条件

次の条件が重なるほど、ファイルシステム単体の話ではなくなります。

• LVM（lvdisplay/vgdisplay配下の論理ボリューム）
• mdadm RAID、ZFS、ハードウェアRAID、NAS固有構成
• 暗号化（LUKS/dm-crypt）
• 仮想化ストレージ（qcow2、vmdk、thin provisioning等）

この領域は「正しい層順」を誤ると、正しいデータに到達できません。迷った時点で、個別構成を前提にした判断が必要です。相談先：株式会社情報工学研究所（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）

次章では、復旧できた“つもり”を潰すための整合性チェックと、やりがちな危険コピーを整理します。

復旧できた“つもり”を潰す：整合性チェックと危険なコピー手順

ファイルが取り出せた瞬間、人は安心します。ですが、復旧の失敗が発覚しやすいのはその後です。開けない、途中で壊れている、DBが起動しない、ソースが中途半端に欠けている。ここで再び「じゃあもう一回やり直すか」となると、原本を触ってしまいがちです。

だから復旧は、抽出までではなく検証までがセットです。プログラマーなら、バックアップ復元を“成功”と呼ぶにはアプリが起動して主要機能が通るまで確認するのと同じ感覚で捉えると腹落ちします。

まずは“復旧先”の設計：同じディスクに戻さない

危険な手順の代表は「復旧したデータを同じディスクへ戻す」ことです。これは上書きリスクだけでなく、復旧途中にOSやアプリが動いて追加の書き込みが増えることで、状況が再現不能になります。

• 復旧先は別ディスク、別ボリューム、別マシンを基本にする
• 復旧作業はコピー（disk.img）に対して行い、結果はさらに別の保存先へ吐き出す
• 復旧先の空き容量を十分に確保し、途中で止まらないようにする

整合性チェック：データ種別ごとの“最低ライン”

検証は「全部を完璧に」ではなく、「壊れていると致命的な箇所を優先」すると現実的です。

“危険なコピー”あるある（やりがちな罠）

• 途中でエラーが出ても放置：コピーが完了したように見えて、欠損が混ざる
• 権限/タイムスタンプが崩れる：復旧後の動作検証で別の問題に見える（復旧の問題と運用の問題が混ざる）
• 復旧データをそのまま上書き復元：検証前に本番へ戻してしまい、切り戻しが効かない

検証を通して「どこまで戻ったか」を確定させると、次にやることは2択になります。自力で追加抽出・追加検証を続けるか、ここで専門家に引き継ぐかです。特に業務データの場合、一般論の手順を延々と回すより、個別案件の価値と期限で意思決定したほうが“被害最小化”になります。

相談先：株式会社情報工学研究所（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）

次章（最終章）では、全体を一本の線で回収し、「一般論の限界」と「依頼判断」を自然につなげて締めます。

帰結：復旧はスキルより手順—「止める→写す→読む」と、専門家に渡す判断軸

ここまでの話を、もう一度“一本の線”に戻します。Ubuntuでのデータ復旧は、裏技の集合ではありません。復旧率を左右するのは、ほとんどが最初の判断です。

• 止める：書き込みを止めて、状況の悪化を防ぐ（クールダウン）
• 写す：原本を温存し、失敗してもやり直せる作業対象（イメージ）を作る
• 読む：コピー側で構造を把握し、抽出と検証で“戻った範囲”を確定する

この順番を外すと、途中で何度もやり直しが発生します。そしてやり直しが増えるほど、原本を触る回数が増え、上書きや劣化のリスクが上がります。だから「最初の一手が大事」と繰り返しました。

導入前→導入後（現場の感情の変化）

導入前の心の声は、こうなりがちです。

「自分で何とかできるはず。今は時間がない。とりあえず直せ」

そして深夜、数時間後にこう変わります。

「あれ、何を“直した”のか分からなくなってきた。ログも残してない。状況が再現できない…」

復旧は、根性勝負に見えて、実は工程管理です。工程が崩れると、判断の基準が失われます。だからこそ、最初に“被害最小化（ダメージコントロール）”のルールを置きました。

依頼判断：一般論の手順で進めていいライン／止めるべきライン

本記事で紹介した考え方は、初心者が事故らないための“安全側”です。ただし、すべてのケースで自力対応が合理的とは限りません。ここを明確にします。

次の一歩：小さく始める“依頼判断”

読者が本当に欲しいのは、手順の暗記ではなく、「自分のケースではどこまで自力で、どこから相談すべきか」の線引きだと思います。一般論だけでは、層構造やデータ価値、期限、物理状態で結論が変わります。

だから、迷ったら“今の状況を言語化する”ところだけでもやって、早めに相談するのが現実的です。相談に必要な情報は難しくありません。

• 症状（いつから、何をした直後か）
• 対象（HDD/SSD/NVMe、NAS/RAID、暗号化の有無）
• ログの要点（I/Oエラー有無、SMARTの異常有無）
• データの重要度と期限

これらを揃えたうえで、株式会社情報工学研究所に相談することで、一般論ではなく“あなたの構成”を前提に、被害最小化へ向けた最短ルートを引けます（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）。

現在のプログラム言語各種にそれぞれの注意点（復旧ツールを作る／運用する側の視点）

復旧そのものはツール任せに見えますが、現場では「ログ採取」「イメージの保管」「抽出結果の検証」「自動化」のためにスクリプトや小さなツールを組むことがあります。ここで言語選定や実装の癖が原因で、余計な書き込みや読み取り負荷を増やすことがあります。代表的な注意点をまとめます。

どの言語でも共通する注意点は、原本に対する同時アクセス・過剰リトライ・誤った出力先が事故につながることです。個別の構成（RAID、暗号化、VM、NAS）や物理状態が絡むと、一般的なスクリプトの延長では判断が難しくなります。

読者が具体的な案件・契約・システム構成で悩んだとき、一般論を頑張り続けるより、株式会社情報工学研究所のような専門家に早期相談して“被害最小化”の最短ルートを引くことが、最終的に最も合理的です（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983／電話：0120-838-831）。