その暗号化バックアップ、本当に復元できますか？【2026年】

資金について（2026年9月時点）：CypherpunkGuideは監視型広告を載せない。広告ネットワーク、閲覧者を追跡するピクセル、スポンサー記事は使わない。一部の記事には、成果報酬型であることを明示した紹介リンクがあり、そこから紹介料を得る場合がある。この記事に成果報酬型リンクはなく、特定の保存サービスを推奨するものでもない。

写真や手紙、大切な記録は、それを作ったパソコンを買い替えた後も残しておきたい。バックアップの暗号化は、他人に内容を読まれないために役立つ。ただし後から取り出すには、保存先へアクセスできること、暗号を解除できること、必要な版が残っていること、取り出したファイルを読めることも必要になる。

私は、プログラムのコードを公開している暗号化バックアップソフトresticを使い、12個の人工ファイルを6つの条件で復元する実験を設計した。ある条件では、保管領域の通常検査、全データの検査、復元操作がすべて成功したのに、戻ってきたのは予定した12個のうち11個だった。別の条件では12個すべてが戻り、形式の読み取りにも成功したが、1個だけが求めていた版より古かった。

確かめたいのは、残すつもりだった記録を、必要な版で取り出して使えるかどうかだ。その確認を、再現できる実験と、自分のバックアップで安全に試す手順につなげる。実験に使ったのは生成したテスト用ファイルだけで、個人の保存データではない。ドライブの寿命、別の場所に置いたコピーが災害後も使えるかどうか、パソコン全体の復旧は測っていない。

同期・バックアップ・長期保存の役割を分ける

#

同期は作業中のファイルを端末間でそろえ、バックアップは失ったり変更したりしたファイルを取り戻すためのコピーを残す。長期保存では、機器やソフトが変わった後も記録の意味が分かり、読める状態を維持する。一つのサービスが複数の役割を持っていても、それぞれの確認は必要だ。

同期サービスが、ある端末で削除したファイルを別の端末からも消すのは、仕様どおりの動作であり得る。取り戻せるかどうかは、過去の版をどれだけ残すか、削除をどう扱うか、アカウントへ入れるかで決まる。一方、接続を外したディスクには有用なコピーが残っていても、外した後の変更は入っていない。保存先を選ぶ前に、必要な役割を決めておきたい。

米国のサイバーセキュリティ・インフラセキュリティ庁（CISA）は、3-2-1方式を、原本を含む合計3つのコピーを2種類の媒体に置き、1つは離れた場所に保管する方法として説明している。ランサムウェア対策の指針では、オフラインで暗号化したバックアップと、データの検査・復元試験の定期実施も勧めている。オフサイトは保管する場所、オフラインは接続の状態を表す。 別の建物に置いても、侵害された同じアカウントから消せるコピーなら、それだけで独立した備えになるわけではない。CISAのバックアップ資料とランサムウェア対策ガイドを参照できる。

個人の記録なら、まず具体的な事故を書き出す。ノートパソコンの盗難、誤削除、自宅の火災、アカウントに入れなくなること、暗号の解除方法を失うこと。それぞれの後に、どのコピーを使えるか確かめる。個人のプライバシー対策と同じく、一つひとつの対策が何に備えるものなのかを明らかにする作業だ。

故障した環境に頼らず復元できるようにする

#

暗号化は、有効な解除手段を持たない相手からバックアップの内容を守る。解除手段そのものを残したり、アカウントへのアクセスを維持したり、コピーの消失を防いだりする機能ではない。復元の計画では、これらの条件も個別に満たしておく必要がある。

バックアップの場所、使ったソフトと保存形式、必要ならアカウントの復旧方法、権限のある人が解除情報を入手する方法を記録しておく。パスワードなどの秘密情報は保護し、公開する確認表やチャットボットへ書き込まない。「復旧手順は封をした書類にある」と所在を記すことと、秘密の中身を公開することは違う。

resticは、データを暗号化し、パスワードで保護した鍵を使ってアクセスする。データと管理情報を置く領域は、リポジトリと呼ばれる。一つのリポジトリに複数の鍵を持たせることもできる。別の有効な鍵と対応するパスワードが残っていれば、パスワードを一つ忘れただけで永久にデータを失うとは限らない。使える解除手段がすべて失われた場合とは、状況が異なる。この仕組みはresticのリポジトリ作成手順で説明されている。

復元に必要なものが、復元したいデータの中にしかない構成は避けたい。バックアップのパスワードをそのバックアップ内にだけ保存する場合や、パスワードマネージャーの復旧資料が故障したノートパソコンにしかない場合が当てはまる。パスキーの復旧とパスワードマネージャーの移行でも、同じ問題をアカウントへのアクセスから扱っている。

自分でサービスを運営するセルフホスティングでは、運営者が変わるとともに、復旧の責任も自分に移る。自前のサービスと唯一のバックアップを同じパソコンに置けば、その1台を失ったときに両方を失い得る。

検査で確かめられる範囲を知る

#

バックアップの検査は、その検査が対象にした範囲について答える。内部構造の整合性、保存データの読み取り、必要なファイルの復元、内容の一致、ファイルを開けることは、別々の確認だ。一つの成功から、残りも成功したとは判断できない。

2026年9月3日の確認時点で、resticの公式文書は通常のcheckとcheck --read-dataを区別している。通常の検査はリポジトリの構造や参照関係を調べるが、保存されたデータの中身をすべて読むわけではない。resticでは、バックアップのデータをまとめた保存用ファイルをpackと呼ぶ。--read-dataを付けるとすべてのpackを読むため、時間や通信量が大きくなる場合がある。詳細はリポジトリの検査に関する公式文書にある。

内容の変化を調べるために使うのが、ハッシュ値だ。ファイルを構成するバイト列から計算する値で、SHA-256などの方式がある。保存する予定のファイルをまとめた一覧をマニフェストと呼び、サイズやハッシュ値を加えることもできる。残したいファイルから事前に作り、保護しておけば、復元後の比較基準になる。ファイル名自体に個人情報が含まれることもあるため、この一覧もプライバシー対策の対象だ。

バックアップ内の一覧だけを正解にすると、最初から入れ忘れたファイルは見つからない。予定一覧は、バックアップに何が入ったかではなく、何を残すつもりだったかを記録するためにある。

米国議会図書館のデジタル資料管理の用語集も、ビット単位の保存と、将来も利用できるようにすることを区別している。今回の確認では現行ページが取得を拒否したため、2025年9月の保存版を使った。バイト列が一致することには価値がある。しかし、元から形式が壊れていたファイルも、そっくりそのままコピーできてしまう。この違いを実験に含めた。

人工ファイルを使った6条件の復元実験

#

Windows上のrestic 0.19.1で、操作の成功と、必要な記録が戻ることを分けて調べた。保存対象から1個を外した場合も、古い版を選んだ場合も、通常検査・全データ検査・復元はすべて成功した。違いが分かったのは、独立した比較基準と照合したときだった。

対象から何かを除外する前に、7種類の形式で12個のファイルを作った。UTF-8のテキスト、JSON、CSV、XML、ZIP、WAV、TOMLを使い、人工のメモや構造化した記録、ファイルをまとめたZIP、生成した音を用意した。形式に沿って内容を読み取るプログラムをparserという。今回はPythonに標準で付属するparserなどで確認しており、写真閲覧ソフト、オフィスソフト、音声プレーヤーの画面を操作した試験ではない。

各条件で、保存済みのある時点の状態を表すスナップショットを識別番号で指定し、新しい空のフォルダへ復元した。通常検査、全データ検査、復元、予定一覧との照合、ハッシュ値の照合、形式の読み取りは個別に記録している。操作の終了時に返る番号を終了コードといい、0はその操作の成功、0以外はその操作のエラーを示す。個人の保存データ全体に対する合格点ではない。

この6条件を再現すれば、復元の目標をどう確かめるかを学べる。各条件で、処理が正常に終わったことと、必要なファイルが目的の版で戻り、その形式を読み取れたことを区別する。S4の除外とS5の旧版指定は意図的な設定であり、resticはその指定どおりに動いている。

実測結果

#

復元数とハッシュ値の分母は、残す予定だった12個で統一している。形式の読み取りでは、復元されて実際に試したファイルだけを分母にした。欠けたファイルは、読み取る内容自体がないため成功に数えていない。S5のハッシュ値は、古いスナップショットから作った一覧ではなく、事前に記録した「必要な現在の版」と比較した。S6では、元から不正だった入力を比較基準にして、内容の保存と形式の読み取りを区別している。

S4〜S6ではresticの3処理がすべて正常終了する。意図的に除外したファイルは戻らず、指定した旧版はそのまま復元され、元から不正なJSONも同じ内容で戻る。図中は英語表記。数値と分母は上の表に示した。

比較図はSVG・PNGで取得できる。図の生成コードも用意した。

それぞれの失敗が示すこと

#

S2は、間違ったパスワードを一つ試した結果だ。 そのパスワードが拒否されたことは分かるが、別の有効な鍵でも復元できないと示したわけではない。公開しているパスワードは、テスト用と明示したダミー文字列だ。実際のバックアップを守るためには使わないこと。

S3では、周囲の構造を保ったまま、保存データの中身を変更した。 通常検査は成功し、全データ検査と復元は異常を検出した。これは、今回加えた破損についての結果である。通常検査があらゆる破損を見逃すとも、現実の破損で失うファイルが必ず1個に収まるとも言えない。「バックアップの失敗」と一つにまとめると、どの操作が異常に気づいたのか見えなくなる。そのため、私は各操作の結果を分けて残した。

S4は、保存対象の選び方が目的と合っていなかった。 ソフトは指定されたファイルを正常に保存した。しかし、残す予定の一覧にあったdocuments/contacts.csvを、実験では意図的に除外している。有効な除外設定が利用者の希望と食い違っているかどうかを、ソフトが推測することはできない。resticのバックアップ手順を参照し、対象の指定と除外ルールも確認する必要がある。

S5は、選んだ版が目的と合っていなかった。 古いdocuments/status.jsonも正しいJSONであり、復元そのものに問題はなかった。ただし、ハッシュ値は必要な現在の版と異なっていた。数がそろい、読み取れるだけでは、新しさまで確かめたことにはならない。誤削除の前へ戻したいときには、古いスナップショットこそが正解になる。問題なのは古いこと自体ではなく、復元の目的に合う版かどうかだ。

S6では、不正な入力がそのまま保存された。 バックアップを取る前から、documents/records.jsonの形式を意図的に不正にした。resticの3つの操作はすべて成功し、復元した12個すべてのハッシュ値が元の比較基準と一致した。それでもJSONの読み取りは、保存前も復元後も同じファイルで失敗した。原因は元データの状態にあり、復元操作が壊したのではない。残る11個は形式の読み取りにも成功した。

同じ実験を再現する

#

配布する実験プログラムが受け付けるのは、restic 0.19.1の公式Windows amd64版ZIPだけだ。ZIPと実行ファイルのハッシュ値を確認した後、人工ファイルと実験専用のリポジトリを新しく作る。既存の原本フォルダや復元先を指定する機能はない。意図的にデータを壊すのも、その実験内で作ったコピーだけであり、実際に使っているバックアップのリポジトリは受け付けない。

実験方法と限界、結果表、ファイルごとの詳細結果、人工ファイルの予定一覧、公開用に端末情報を除いた実行記録を確認できる。記録したのは生成したファイルだけだ。実行記録では端末固有の識別情報や場所を置き換えているため、端末に表示された文字列を無加工で転載したものではない。

プログラムを読んでから、新しい空の作業フォルダでPython 3.11以降を使って実行する。restic 0.19.1の公式配布ページから対応するZIPを取得し、公式のチェックサム一覧と照合する。その後、次を実行する。

python restore-lab.py --restic-zip restic_0.19.1_windows_amd64.zip

再実行した結果を公開記録と比べるには、比較用プログラムと公開済みの結果を同じ作業フォルダへ保存する。ダウンロードしたresults.jsonは基準として使うため、変更しない。上のrestore-lab.pyを実行した後、表示された実験用フォルダ名で、次のc07-restore-lab-REPLACE-MEを置き換える。作業フォルダから次を実行する。

python .\compare-results.py --results .\c07-restore-lab-REPLACE-ME\results.json

--resultsで指定するのは、再実行によって作られた記録だ。比較するのは、Windows上のrestic 0.19.1を使ったこの6条件の記録内容に限られる。ファイルのハッシュ値を計算し直したり、実際のバックアップの安全性を判定したりする機能はない。一致表示だけで、第三者が実験を再現した証拠にもならない。詳しくは実験方法と限界を参照。

実験用フォルダは、結果を調べられるよう実行後も残る。今回の実行環境はPython 3.12.10だった。小さな人工データと定めた失敗条件を使って仕組みを確かめたもので、故障率の推定やバックアップ製品の比較ではない。ファイルの権限、OS全体の復旧、通信障害、保管場所の独立性、機器の経年変化、利用ソフトの全機能は試験範囲に含めていない。

自分のバックアップを安全に復元確認する

#

新しい空のフォルダへ復元し、原本に変更を加える前に結果を確かめる。目的に合う版を選び、別に用意した予定一覧と内容を照合し、代表的なファイルを普段使うソフトで開く。一部だけを試した結果は、その範囲の確認であり、保存データ全体の合格にはならない。

resticの復元に関する公式文書は、既定の動作で復元先の既存ファイルを上書きすると説明している。他のソフトにも、それぞれの規則がある。使っている版の手順を読み、開始前に復元先を確認すること。試しの復元先に、普段の文書フォルダを指定してはいけない。

1. 何を取り戻したいか決める。 「最後に完了したバックアップまでの手紙と写真」なのか、「昨日削除する前の版」なのかを記録する。必要なフォルダと日付も明らかにする。原本が残っているなら、保存対象の設定とは独立して予定一覧を作り、どの版の一覧かも対応づけておく。バックアップ後に作業中のファイルを更新したなら、保存済みの版と内容が違うのは当然であり、その差だけで復元時の破損とは判断できない。
2. アクセス手段と空き容量を確認する。 バックアップの所在と、有効な解除方法を確かめる。信頼できるパソコン上に、十分な空き容量を持つ別の空フォルダを用意する。復元したファイルは暗号化されていない状態になる場合がある。復元先を保護し、意図しない同期や共有の対象に入れない。
3. 保存済みの版を具体的に指定する。 識別番号と該当する日付を残す。「最新」は並び順に関する指定であり、必要な変更が入っている証明ではない。
4. 公式手順に沿って検査と復元を行う。 内部構造の検査と、全データを読む検査を区別する。復元時だけでなく、元のバックアップ作成時に出た警告やエラーも確認する。スナップショットが存在していても、元ファイルをすべて読めたとは限らない。
5. 目的を満たしたか確かめる。 予定したファイル名と場所、代表的な内容と版、用意してあれば信頼できるハッシュ値を照合する。文書を開き、写真を見て、音声を再生する。その記録を使ううえで必要なソフトの機能も試す。何を確認し、何が未確認なのかを記録する。
6. 検証が済むまで、使えるコピーを残す。 試しの復元が成功しても、ほかに使える唯一のコピーを消す理由にはならない。確認後の試用ファイルは、自分の保管方針に従って保護または削除する。食い違いを調べている途中で、元に戻せない整理をしない。

時間や容量の都合で全体を復元できないなら、まず範囲を限って試し、その制限も記録する。確認範囲は後から広げられる。すでに原本がなく、独立した予定一覧もない場合は、「全部そろっているかは不明」と残す。生き残ったバックアップの件数だけでは、その答えは出ない。

保存場所とともに、読める状態も維持する

#

長期保存では、媒体、接続方法、読み取り機器、ファイル形式、解除手段を定期的に確かめる必要がある。一つの保存素材について示された寿命は、その期間ずっと記録全体を復元できるという保証ではない。

米国議会図書館の個人のデジタル記録に関する案内は、保存したファイルを少なくとも年1回確認し、5年ごと、または必要に応じて新しい媒体へコピーするよう勧めている。媒体の耐久性に関する資料は、寿命の見積もりが不確かになる理由を説明している。この周期は保守の目安であり、次の確認日までドライブが壊れないという約束ではない。データの移行、解除方法の変更、故障の疑いがあったときにも確認する。

「HDDは何年」「SSDは何年」という一律の数字だけで、ディスクを選ぶことはできない。同様に、VerbatimのM-DISCの長寿命に関する説明は光ディスク製品についての主張である。将来も対応ドライブを使え、解除情報が残り、ファイル形式を読み取れることまで保証するものではない。米国国立公文書館も、光ディスクを含む映像用媒体の寿命の不確かさと保管条件を説明している。こうした限界があるからといって、すべての光ディスクが故障するという結論にはならない。

形式やソフトが使いにくくなってきたら、原本を残したうえで、閲覧用のコピーを作って変換内容を記録する。複雑な文書では、変換によって配置や機能が失われることがある。変換すればバイト列も変わるので、新しいハッシュ値が原本と違うこと自体は異常ではない。その記録で重要な内容を保てたか確かめ、変換版と分かる名前を付け、変換版の比較基準を新しく作る。フォルダを整えるために原本を上書きしないこと。

今回の実験では、各操作の結果と並べて、残す予定のファイル、必要な版、読み取りの確認を記録した。欠けたファイルには対象設定の見直しが要る。古い版には、どの時点へ戻すかの判断が要る。元から読めない記録には、その内容を使える形で残す作業が要る。ディスクをもう一台買うだけでは、これらの問題は解決しない。

よくある質問

#

クラウド同期はバックアップになりますか？

#

過去の版や削除したファイルを必要な期間だけ残すサービスなら、一部の復旧機能を担えます。保存期間や削除の規則、アカウントの復旧に必要な条件を確認してください。同期しているだけでは、望まない変更、削除、アカウントを失った場合にも取り戻せるとは言えません。

resticの検査が成功すれば、全ファイルが安全ですか？

#

いいえ。通常の検査は、保存されたすべてのpackの中身を読むものではありません。全データ検査でも、残す予定のファイルをすべて含めたか、必要な版を選んだか、復元後に利用するソフトで読めるかまでは分かりません。

パスワードを忘れた暗号化バックアップは復元できますか？

#

使っているソフトと、ほかに残っている解除手段によります。resticでは、パスワードで保護した鍵を複数持てます。別の有効な鍵と対応するパスワードがあれば、使える可能性があります。保存サービスの事業者なら暗号を解除できると決めつけたり、パスワードが一つ通らなかっただけですべての復旧手段を失ったと判断したりしないでください。

個人の保存データは、どれくらいの頻度で確認すればよいですか？

#

米国議会図書館は、保存したファイルを少なくとも年1回確認するよう勧めています。重要な記録の更新頻度も踏まえて周期を決め、保存先、ソフト、復旧のためのアクセス手段に大きな変更があったときにも試してください。一部だけを確認したのか、全体なのかも記録します。決めた日付に点検したことや、少数のファイルで成功したことだけで、その後も復元できると保証されるわけではありません。

何十年もファイルを残せる記録媒体はどれですか？

#

どの媒体を選んでも、独立したコピー、点検、移行は必要です。媒体そのものに加え、保管条件と、対応する読み取り機器を使えるかを考えてください。長く利用できるかどうかには、形式、ソフト、解除情報も関わります。新しい閲覧用コピーを作るときも、検証済みの原本は残してください。

出典と実験の記録

#

一次資料の確認日は2026年9月3日。実験結果は、記載した実行環境と人工データについての観測である。保存版は資料の履歴を残すために併記しており、主張の確認に使った現行版より古い場合がある。

Cora Aegis

Cora AegisはCypherpunkGuideで、プライバシーとデジタル環境を自分で管理するための方法を書いている。この記事では、人工データによる暗号化バックアップの復元実験を設計・確認し、結果をresticの公式文書と長期保存の指針に照らし合わせた。個人のバックアップデータは使っていない。

Cora Aegisについて →