バックアップを考えるとき、多くの場合は「どの HDD を使うか」「S.M.A.R.T. が正常なら安心か」「外付け HDD を遠隔地保管に使ってよいか」「2.5-inch HDD と 3.5-inch HDD のどちらが信頼できるか」という媒体単体の問題から話が始まる。この問いは間違っていない。実際、媒体の種類、接続方式、電源、筐体、温度、S.M.A.R.T. 属性、short test、long test、error log、代替セクター数、pending sector、uncorrectable error は、バックアップ運用において無視できない。しかし、そこだけを見ていると、バックアップ・リカバリー戦略の本質を取り違える。なぜなら、最終的に必要なのは「媒体が健康であること」ではなく、「必要な時点で必要なデータを復元できること」だからである。
媒体が正常でも、バックアップとしては失敗している場合がある。S.M.A.R.T. が PASSED でも、誤削除後の状態だけが同期されていれば過去へ戻れない。HDD が物理的に読めても、checksum がなければ保存内容が正しいか確認できない。外付け媒体が無事でも、暗号化パスフレーズや LUKS header を失っていれば復号できない。クラウドにコピーがあっても、アカウントに入れない、課金が止まっている、削除保持期間が短い、復元速度が遅すぎるという問題が起こり得る。本番業務であれば、ファイルが戻っても、データベース、証明書、秘密情報、DNS、systemd unit、cron、監視、ログ、権限、依存ソフトウェアが戻らなければサービスは復旧しない。つまり、媒体の健康状態は必要条件の一つであって、復元可能性そのものではない。
| 一見安心に見える状態 | それだけでは足りない理由 | 本当に確認すべきこと |
|---|---|---|
| S.M.A.R.T. が PASSED である。 | 媒体の自己診断が通っているだけで、ファイル内容、世代、暗号鍵、復元手順までは保証しない。 | OS ログ、checksum、backup verify、リストアテストまで確認する。 |
| 外付け HDD にコピーがある。 | 最新状態だけの上書きコピーでは、誤削除や破損後の状態も保存される。 | 世代管理、照合履歴、遠隔地保管、復元手順を確認する。 |
| 暗号化済み媒体がある。 | 媒体が残っていても、パスフレーズ、キーファイル、LUKS header、物理鍵を失えば復元できない。 | 論理鍵、物理鍵、ヘッダーバックアップ、復号確認日を管理する。 |
| クラウドにも保存している。 | アカウント停止、課金停止、削除同期、帯域制約、認証喪失が起こり得る。 | 削除保持期間、復元テスト、暗号化方式、アカウント復旧手順を確認する。 |
| バックアップ成功ログがある。 | 取得処理の成功を示すだけで、必要な状態へ戻せることまでは示さない。 | 実際に別環境へ復元し、権限、設定、アプリケーション起動まで確認する。 |
物理媒体管理で本当に管理すべきものは、ディスク単体ではなく、データが生き残るための構造である。媒体は壊れる。接続も壊れる。USB ブリッジも、ケーブルも、電源も、ファイルシステムも壊れる。暗号鍵は失われる。保管場所には火災、水害、盗難、紛失がある。人間は誤って削除し、誤って同期し、古いバックアップを上書きし、台帳更新を忘れ、リストア手順を忘れる。さらに、ソフトウェアは更新され、ファイル形式は変わり、バックアップツールの使い方も時間とともに忘れられる。したがって、物理媒体管理とは「壊れにくいディスクを探す作業」ではなく、「壊れることを前提に、複数の媒体、複数の場所、複数の世代、複数の検証手段、複数の復元経路を組み合わせ、復元可能性を維持する運用系を設計する作業」である。
この観点に立つと、S.M.A.R.T. の short test や long test の位置づけも明確になる。short test は短時間で明白な異常を拾う軽量検査であり、long test はより広い領域を読む深い検査であり、error log や self-test log は過去の異常履歴を見るための材料である。しかし、これらは媒体の状態を見る手段であって、保存されたファイルの意味内容や復元手順を保証するものではない。外付けモバイル 2.5-inch HDD で long test が Aborted by host になりやすい場合でも、それだけで媒体本体が不良とは限らない。USB ブリッジ、省電力制御、バスパワー、ホスト I/O、OS の自動アクセスが影響することがある。逆に、long test が通る 3.5-inch SATA HDD であっても、同一拠点にしか存在しなければ火災や盗難には弱い。検査結果は重要だが、それだけで媒体の役割を決めてはいけない。
| 検査・確認 | 見ている対象 | 見ていない対象 |
|---|---|---|
| short test | 短時間で検出できる明白な媒体異常を見る。 | 媒体全域の読み出し、保存ファイルの正しさ、復元手順の成立性は見ない。 |
| long test | 媒体全体に近い範囲を読み、表面上の異常を深く確認する。 | USB 接続系の安定性、checksum、世代管理、暗号鍵、アプリケーション復旧は見ない。 |
| error log / self-test log | 過去の ATA error、UNC、timeout、検査失敗履歴を見る。 | 現在のバックアップ内容が正しく復元できるかは見ない。 |
| checksum / backup verify | ファイル内容やバックアップリポジトリの整合性を見る。 | 復元先でサービスが起動するか、鍵や手順が揃っているかは見ない。 |
| リストアテスト | 媒体、鍵、ツール、手順、権限、環境が揃って実際に戻せるかを見る。 | 媒体の将来故障そのものを予測するものではない。 |
バックアップ設計では、媒体の性質と運用上の役割を分ける必要がある。常設 3.5-inch SATA HDD は、安定電源、放熱、SATA 直結、long test、scrub、S.M.A.R.T. 監視に向くため、ローカルバックアップや短い RTO を支える媒体として有効である。一方、外付けモバイル 2.5-inch HDD は、小型、軽量、筐体保護、可搬性、遠隔地保管に向くため、同一拠点喪失への対策として有効である。クラウドは地理分散や一部ファイルの迅速な復元に強いが、アカウント、課金、帯域、削除保持、暗号化、サービス依存を管理しなければならない。つまり、どの媒体が絶対的に優れているかではなく、どの媒体にどの役割を割り当てるかが重要になる。
また、バックアップは同期、ミラー、アーカイブとも区別しなければならない。同期は現在状態を揃える仕組みであり、誤削除や破損も同期する。ミラーは現在状態の代替コピーとして有用だが、世代がなければ過去へ戻れない。アーカイブは長期保存に向くが、媒体寿命、読み出し装置、ファイル形式、暗号鍵、台帳を維持しなければ将来読めなくなる。バックアップは、過去時点へ戻るための設計であり、世代管理、検証、鍵管理、リストアテストを必要とする。外付け HDD に最新状態だけを上書きコピーする運用は、媒体故障には一定の効果があるが、誤削除や論理破損には弱い。過去へ戻れる構造を持って初めて、バックアップはバックアップとして機能する。
| 区分 | 主な目的 | 弱点 | 必要な補完 |
|---|---|---|---|
| 同期 | 複数場所の現在状態を揃える。 | 誤削除、破損、暗号化済みファイルも同期される。 | 世代管理、削除保持、リストアテストを組み合わせる。 |
| ミラー | 同一内容の代替コピーを持つ。 | 過去状態へ戻れず、論理破損には弱い。 | snapshot、日次・週次・月次世代を持たせる。 |
| バックアップ | 過去時点へ戻れるようにする。 | 容量管理、検証、復元手順が必要になる。 | checksum、backup verify、台帳、リストアテストを行う。 |
| アーカイブ | 長期保存する。 | 媒体寿命、読み出し装置、ファイル形式、暗号鍵を失いやすい。 | 定期読み出し、形式移行、鍵管理、媒体更新計画を持つ。 |
本稿では、バックアップ・リカバリー戦略における物理媒体管理を、媒体選定の話に閉じず、復元可能性を維持する運用設計として整理する。まず、S.M.A.R.T.、short test、long test、error log の役割を分け、3.5-inch SATA HDD と外付けモバイル 2.5-inch HDD の違いを役割分担として捉える。次に、S.M.A.R.T. 以外に見るべき OS ログ、checksum、ファイルシステム検査、scrub、backup verify、restore test を整理する。そのうえで、3-2-1 ルール、3-2-1-1-0、想定障害、同期・ミラー・バックアップ・アーカイブの違い、RPO / RTO、復元可能性の構成要素、退役基準、媒体台帳、暗号化と鍵管理、検査頻度、リストアテスト、個人利用から本番業務までの実用構成を順に扱う。
終盤では、少し抽象度を上げる。情報は抽象的なものに見えるが、実際には常に物理媒体、符号化方式、ファイルシステム、暗号鍵、読み取り装置、解釈するソフトウェア、復元手順に依存して存在している。保存とは、情報を何らかの物理状態として固定することであり、バックアップとは、その物理的実装を単一媒体に閉じ込めず、複数の媒体、場所、世代、鍵、手順へ分散し、未来のある時点で再び意味ある構造として再構成できるようにすることである。この視点から、既稿で扱った意味論、履歴論、構造論とも接続し、バックアップを「データの生存管理」として位置づける[1]。
結論を先取りすれば、物理媒体管理で守るべきものはディスクそのものではない。守るべきものは、データが未来において再び読み出され、復号され、検証され、解釈され、必要な状態として復元される可能性である。そのためには、壊れない媒体を探すのではなく、壊れても戻せる構造を作る必要がある。S.M.A.R.T. も、checksum も、遠隔地保管も、暗号化も、媒体台帳も、リストアテストも、すべてその構造を支える部品である。本稿の目的は、物理媒体管理をディスク健康管理の話から引き上げ、バックアップ・リカバリー戦略全体の中で、復元可能性を維持するための実務的かつ構造的な考え方として整理することである。
1. 物理媒体管理はデータの生存管理である
物理媒体管理という言葉からは、まず HDD や SSD の健康状態を確認する作業が連想される。温度、通電時間、代替セクター数、pending sector、S.M.A.R.T. の自己診断結果、エラーログを見ることは、たしかに重要である。媒体が物理的に劣化していれば、保存されたデータを読み出せなくなる可能性が高まる。したがって、物理媒体の状態監視はバックアップ運用の入口であり、無視してよいものではない。
しかし、バックアップ・リカバリー戦略においては、媒体の健康状態だけを見ても不十分である。バックアップの目的は、HDD や SSD を正常に保つことそのものではなく、障害時に必要なデータを復元できる状態を維持することである。ここを取り違えると、S.M.A.R.T. が正常だから安全である、ディスクが複数あるから十分である、外付け HDD にコピーしているからバックアップできている、という誤った判断につながる。
媒体が正常でも、データが復元できない状況は普通に起こり得る。たとえば、S.M.A.R.T. が正常でも、誤って削除した状態が同期済みであれば、削除前の状態には戻れない。HDD が物理的に読めても、checksum や verify を行っていなければ、保存済みファイルが過去の内容と一致しているか確認できない。暗号化された外付け HDD が正常に認識されても、パスフレーズ、キーファイル、LUKS header などを失っていれば復号できない。バックアップファイルが存在していても、実際にリストアしたことがなければ、必要な環境、権限、依存ソフトウェア、手順が揃っているとは限らない。
| 管理層 | 見るもの | それだけでは足りない理由 |
|---|---|---|
| 媒体状態 | S.M.A.R.T.、温度、通電時間、代替セクター、pending sector、uncorrectable error、エラーログを見る。 | 媒体が正常でも、ファイル内容、バックアップ世代、保管場所、暗号鍵、復元手順の正しさは保証されない。 |
| データ内容 | checksum、verify、全ファイル読み出し、バックアップツールの check によって、保存された内容が読めるか、過去の内容と一致するかを見る。 | 内容が正しくても、誤削除前の世代へ戻れるとは限らず、遠隔地保管やオフライン保管がなければ同時喪失にも弱い。 |
| 保存構造 | 複数コピー、世代管理、遠隔地保管、オフライン保管、媒体ローテーション、保管場所、媒体台帳を見る。 | コピーや世代が存在しても、検証されていなければ壊れている可能性があり、どの媒体に何があるか分からなければ復元に使えない。 |
| 復元手順 | リストアテスト、暗号鍵、パスフレーズ、キーファイル、LUKS header、権限、依存ソフトウェア、復元手順書を見る。 | 媒体、データ、コピーが残っていても、復元手順が成立しなければ、必要な時点の状態を実際に再構成できない。 |
このため、物理媒体管理の単位はディスク単体ではない。媒体本体だけでなく、接続経路、電源、筐体、ファイルシステム、暗号化、保管場所、バックアップ世代、検証手順、復元手順までを含めて考える必要がある。S.M.A.R.T. は媒体を見るための重要な手段であり、checksum や verify は内容を見るための手段であり、世代管理は過去時点へ戻るための手段であり、遠隔地保管やオフライン保管は同時喪失を避けるための手段であり、リストアテストは全体が実際に機能するかを確認する手段である。
したがって、バックアップ・リカバリー戦略における物理媒体管理とは、ディスクを長持ちさせるための作業ではなく、データを復元可能な状態で生存させるための管理である。媒体はそのための基盤であり、健康状態を監視すべき対象ではあるが、最終的に守るべきものは媒体ではない。守るべきものは、必要な時点で意味あるデータ構造を再構成できる可能性である。
2. S.M.A.R.T. は重要だが万能ではない
S.M.A.R.T. は、ストレージデバイス自身が内部状態や故障兆候を報告する仕組みである。HDD や SSD は、内部で発生した読み取りエラー、代替処理、温度、通電時間、自己診断結果、エラーログなどを一定の形式で保持している。smartmontools は ATA / SATA、SCSI / SAS、NVMe などのデバイスから S.M.A.R.T. 情報を取得し、smartctl と smartd によって手動確認と常時監視を行える代表的なツールである[2][3]。この意味で、S.M.A.R.T. は物理媒体管理の入口として非常に重要である。
特に HDD では、Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable、Reported_Uncorrect、UDMA_CRC_Error_Count、温度、通電時間、自己診断履歴、error log が重要な確認対象になる。SSD や NVMe SSD では、同じ S.M.A.R.T. という言葉を使っていても、見るべき指標は HDD と同一ではない。NAND の消耗、予備領域、media error、unsafe shutdown、controller error、critical warning など、媒体の仕組みに応じた読み替えが必要になる。つまり、S.M.A.R.T. は単一の数値を見るものではなく、媒体種別ごとの故障モードを前提に読むべき情報群である。
ただし、S.M.A.R.T. の正常判定は「この媒体は安全である」という意味ではない。S.M.A.R.T. の overall-health が PASSED であっても、それはデバイスが定義するしきい値をまだ超えていないという意味に近い。すべての故障を予測したという意味ではないし、バックアップとして復元可能であるという意味でもない。突然死する SSD は存在する。HDD でも、S.M.A.R.T. 上は深刻に見えないまま読み取り不能が発生することがある。USB ブリッジ、ケーブル、電源、ハブ、OS 側の省電力制御による I/O error は、媒体内部の S.M.A.R.T. 値だけでは説明できない場合がある。
また、S.M.A.R.T. は媒体内部の自己申告である。したがって、S.M.A.R.T. が見ているのは、基本的にはデバイスが自分自身について把握している状態である。これは重要な情報だが、ホスト OS から見た実際の I/O 挙動とは別である。たとえば、USB 接続の外付け HDD で long test が Aborted by host になる場合、それは必ずしも媒体面の不良を意味しない。USB-SATA ブリッジ、バスパワー、省電力、UAS、ホスト側 I/O の介入によって、自己診断が中断されることがある。この場合、S.M.A.R.T. だけではなく、dmesg や journal に USB reset、timeout、disconnect、I/O error が出ていないかを見る必要がある。
| 観点 | S.M.A.R.T. で分かること | S.M.A.R.T. だけでは分からないこと |
|---|---|---|
| 媒体内部の状態 | 代替セクター、pending sector、uncorrectable error、温度、通電時間、自己診断履歴、エラーログを確認できる。 | 媒体が今後突然故障しないことまでは保証できない。 |
| 劣化傾向 | Reallocated_Sector_Ct や Reported_Uncorrect などの増加傾向を追跡できる。 | 単発値だけでは、安定した過去の傷なのか、進行中の劣化なのかを判断しにくい。 |
| 自己診断 | short test や long test の成否、失敗 LBA、過去のテスト履歴を確認できる。 | USB ブリッジ、電源、ケーブル、ホスト側 I/O による中断や不安定性までは切り分けきれない。 |
| 接続経路 | UDMA_CRC_Error_Count など、一部の転送エラー兆候を確認できる。 | USB reset、disconnect、kernel timeout、ファイルシステム側の I/O error は OS ログで確認する必要がある。 |
| バックアップの成立性 | 媒体が物理的に危険な兆候を持っているかを判断する材料になる。 | ファイル内容の同一性、バックアップ世代の妥当性、暗号鍵の有無、リストア手順の成立性は分からない。 |
このため、S.M.A.R.T. を読むときは、絶対値と履歴を分ける必要がある。たとえば、Reallocated_Sector_Ct が 0 でないディスクは、過去に不良セクターを代替した履歴を持つため、完全にきれいな媒体ではない。しかし、その値が長期間増えておらず、Current_Pending_Sector と Offline_Uncorrectable が 0 で、long test が完走し、dmesg に I/O error がないなら、複数コピーの一つとしては運用できる場合がある。逆に、値が小さくても増加傾向がある場合、あるいは pending sector や uncorrectable error が出ている場合は、保存用途から外す判断が必要になる。
つまり、S.M.A.R.T. で重要なのは、PASSED という一語ではなく、どの属性が、どの時点で、どのように変化しているかである。媒体管理では、初回取得時の値を基準値として記録し、その後の変化を見る必要がある。Reallocated_Sector_Ct が 23 で固定されているのか、23 から 24、25 と増えているのかでは意味が違う。Reported_Uncorrect が過去の 5 件で止まっているのか、現在も増え続けているのかでも判断は変わる。S.M.A.R.T. は一回読むものではなく、履歴として読むものである。
さらに、S.M.A.R.T. はデータ内容を検証しない。媒体が正常でも、コピーが途中で失敗している可能性はある。同期によって誤削除が反映されている可能性もある。暗号化媒体の鍵を失っている可能性もある。バックアップツールのリポジトリが壊れている可能性もある。したがって、S.M.A.R.T. の確認は、checksum、verify、ファイルシステム検査、バックアップツールの check、リストアテストと組み合わせなければならない。
結論として、S.M.A.R.T. は物理媒体管理の重要な第一層である。S.M.A.R.T. を見ない運用は危険であり、媒体劣化の兆候を見逃しやすい。しかし、S.M.A.R.T. だけを見る運用も危険である。S.M.A.R.T. は媒体の健康診断であって、データの復元可能性の保証ではない。媒体管理では、S.M.A.R.T. を入口として、OS ログ、接続経路、ファイルシステム、checksum、バックアップ verify、リストアテストへ段階的に進む必要がある。
3. short test、long test、log の役割を分ける
S.M.A.R.T. を運用に使うときは、short test、long test、error log、self-test log を同じものとして扱わないことが重要である。これらはすべて S.M.A.R.T. 周辺の情報だが、見ている対象が違う。short test は短時間で明白な異常を拾うための軽量スクリーニングであり、long test は媒体全体をより深く読むための検査であり、error log と self-test log は過去に何が起きたかを確認するための履歴である。したがって、どれか一つが正常であることをもって、媒体全体やバックアップ全体が安全であるとは判断できない。
short test は、ディスクの基本動作に明らかな異常がないかを短時間で確認するための検査である。HDD であれば、コントローラー、ヘッド、シーク動作、内部診断、表面の一部読み取りなどを短時間で確認する。SSD でも、デバイスが自己診断として確認できる範囲の異常を短時間で検査する。ここで重要なのは、short test は軽い検査であり、媒体全域を読む検査ではないという点である。short test が通ったという事実は、「この時点で明白な故障兆候は検出されなかった」という意味であって、「すべてのデータ領域が読める」という意味ではない。
long test は、short test よりも深い検査であり、HDD では媒体表面の広い範囲、実質的には全域に近い読み取り検査として使われる。Seagate の診断ツール文書でも、short test は多くの場面で十分な簡易診断として扱われ、より包括的な確認には long generic や long DST のような各セクター読み取りを伴う検査が示されている[4]。Western Digital の診断ツールも、ドライブのテスト、温度監視、ヘルスチェックを行うものとして位置づけられている[5]。ただし、long test も万能ではない。long test は媒体の自己診断であり、ファイル内容の正しさ、バックアップ世代の妥当性、暗号鍵の有無、復元手順の成立性までは検査しない。
log は、short test や long test とは性質が違う。error log は過去に発生した ATA error、UNC、timeout、read failure などの履歴を見るためのものであり、self-test log は過去に実行した short test や long test が成功したか、中断されたか、どの LBA で失敗したかを見るためのものである。つまり、log は現在の検査そのものではなく、履歴監査である。現在の S.M.A.R.T. overall-health が PASSED でも、error log に過去の UNC が残っていれば、過去に訂正不能読み取りエラーが発生したことは分かる。ただし、そのエラーが現在も再現するのか、代替処理済みなのか、単発で止まっているのかは、Current_Pending_Sector、Offline_Uncorrectable、Reallocated_Sector_Ct の増減、self-test log、OS ログと組み合わせて判断する必要がある。
| 手段 | 見ているもの | 使い所 | 誤解してはいけない点 |
|---|---|---|---|
| short test | 短時間で検出できる明白な故障兆候、基本動作、内部診断、表面の一部読み取りを見る。 | 接続直後、移設後、コピー前、日常点検、long test 前の予備確認で使う。 | 通ったとしても、媒体全域が読めることや保存データが正しいことは保証しない。 |
| long test | 媒体全体またはそれに近い範囲を読み取り、読み取り不能領域や表面上の異常を検出する。 | 常設 HDD、疑義発生時、定期保守、保存媒体として使い始める前の検査で使う。 | 通ったとしても、ファイル内容、バックアップ世代、暗号鍵、復元手順までは保証しない。 |
| error log | 過去に発生した ATA error、UNC、timeout、read failure などの異常履歴を見る。 | 過去に何が起きたか、同じ異常が再発しているか、エラー発生時期が古いか新しいかを見る。 | 古いエラーが残っているだけで現在も不良とは限らず、増加傾向と現在の属性値を合わせて見る必要がある。 |
| self-test log | short test や long test が完走したか、中断されたか、失敗 LBA が記録されているかを見る。 | 検査履歴を追跡し、検査が継続的に通っているか、同じ箇所で失敗するかを確認する。 | Aborted by host は必ずしも媒体不良ではなく、ホスト側、USB ブリッジ、電源、省電力、I/O 介入の影響もあり得る。 |
この使い分けを誤ると、判断が極端になる。short test が通っただけで安心すると、媒体全域の読み取り不能やサイレントな破損を見逃す可能性がある。一方で、外付け USB HDD の long test が Aborted by host になっただけで即故障と判断すると、USB ブリッジ、省電力、バスパワー、UAS、ホスト I/O、OS の自動アクセスといった接続系の要因を媒体不良と誤認する可能性がある。short test、long test、log は、それぞれ別の事実を示しているため、結果の意味を分けて読む必要がある。
常設の 3.5-inch SATA HDD では、long test が完走しやすく、S.M.A.R.T. self-test log も比較的素直に解釈しやすい。そのため、定期的な long test、S.M.A.R.T. 属性の増減確認、dmesg の I/O error 確認を組み合わせる運用が向いている。これに対して、外付けモバイル 2.5-inch HDD では、short test は通っても long test が Aborted by host になりやすいことがある。この場合、long test の完走性だけにこだわるのではなく、S.M.A.R.T. 属性、dmesg、全ファイル読み出し、checksum 照合を重視するほうが現実的である。
判断基準としては、単発の検査結果ではなく、複数の情報を組み合わせる。望ましい状態は、short test が通り、可能なら long test も完走し、Current_Pending_Sector と Offline_Uncorrectable が 0 であり、Reallocated_Sector_Ct、Reported_Uncorrect、ATA Error Count が増えておらず、dmesg に I/O error や reset が出ておらず、実データの checksum 照合が通る状態である。逆に、long test が read failure で失敗する、pending sector が出る、uncorrectable error が出る、エラー値が増える、OS ログに I/O error が出る、checksum が一致しない、といった場合は保存用途から外す判断が必要になる。
つまり、short test は軽量確認、long test は深掘り検査、log は履歴監査である。さらに、checksum や restore test はデータと復元手順の検証である。これらを同じものとして扱うのではなく、役割を分けて使うことで、媒体の状態、接続経路の安定性、過去の異常、データ内容の正しさ、復元可能性を段階的に評価できる。S.M.A.R.T. の運用で重要なのは、検査コマンドを実行することそのものではなく、それぞれの結果が何を意味し、何を意味しないかを区別して読むことである。
4. 3.5-inch SATA HDD と外付け 2.5-inch HDD は役割が違う
3.5-inch SATA HDD と外付けモバイル 2.5-inch HDD は、単純にどちらが信頼できるかで比較すると判断を誤る。両者は、同じ「物理記憶媒体」ではあるが、前提にしている運用条件が違う。3.5-inch SATA HDD は、筐体内やドライブベイに固定し、安定した電源と放熱を確保し、SATA 直結で継続的に監視する運用に向いている。一方、市販の外付けモバイル 2.5-inch HDD は、持ち運び、収納、遠隔地保管、短時間接続によるコピーと照合に向いている。したがって、両者は同じ評価軸で優劣を決める媒体ではなく、バックアップ・リカバリー戦略の中で別の役割を持つ媒体として扱うべきである。
3.5-inch SATA HDD の強みは、常設運用における検査可能性である。SATA 直結であれば、OS から見た接続経路が比較的単純であり、USB-SATA ブリッジやバスパワー、USB autosuspend、UAS、外付けケース固有の省電力制御の影響を受けにくい。安定した電源と放熱を確保しやすく、S.M.A.R.T. の long test も完走しやすい。そのため、S.M.A.R.T. 属性、self-test log、error log、dmesg、ファイルシステムログを組み合わせて、異常の原因を切り分けやすい。これは、ローカルバックアップや常設アーカイブのように、定期的に検査しながら保存する用途に向いている。
一方で、3.5-inch SATA HDD は持ち運び媒体としては弱い。裸のドライブは基板や端子が露出しており、静電気、落下、端子破損、基板接触、保管中の物理ストレスに弱い。さらに本体が重いため、落下時の衝撃エネルギーも大きくなる。専用ケースに入れて運ぶことはできるが、もともと頻繁な持ち運びを前提にした製品ではない。したがって、3.5-inch SATA HDD を遠隔地保管用のローテーション媒体として使うことは不可能ではないが、実運用としては手間が大きく、継続性を損ないやすい。
外付けモバイル 2.5-inch HDD の強みは、可搬性と保管性である。市販の外付け HDD は、筐体によって基板や端子が保護され、USB ケーブル 1 本で接続でき、小型軽量で収納しやすい。製品によっては耐衝撃構造、ラバー筐体、内部ダンパー、非動作時の落下耐性をうたうものもある。もちろん、動作中の衝撃に強いという意味ではなく、HDD は回転体とヘッドを持つため、通電中やアクセス中の落下は避けるべきである。それでも、裸の 3.5-inch HDD を持ち運ぶより、市販の外付けモバイル 2.5-inch HDD のほうが、遠隔地保管や持ち出し媒体として現実的である。
ただし、外付けモバイル 2.5-inch HDD は、検査可能性では不利になる場合がある。USB-SATA ブリッジ、USB ハブ、ケーブル、バスパワー、UAS、省電力制御、OS 側の自動マウントやインデクサーが関与するため、S.M.A.R.T. の long test が Extended offline Aborted by host になることがある。メーカーの診断ツールでも short test と long test の性質は明確に分かれており、すべての USB 外付け環境で long test が常に安定して完走するとは限らない[6]。この場合、long test が完走しないことだけで即座に媒体不良と判断するのではなく、S.M.A.R.T. 属性の増減、dmesg の USB reset や I/O error、実ファイル読み出し、checksum 照合を組み合わせて判断する必要がある。
| 観点 | 3.5-inch SATA HDD | 外付けモバイル 2.5-inch HDD | 運用上の判断 |
|---|---|---|---|
| 常設運用 | 安定電源、放熱、SATA 直結を確保しやすく、継続監視と定期検査に向いている。 | USB 接続、バスパワー、省電力制御に依存し、常設監視では接続系の要因が混ざりやすい。 | ローカルバックアップや常設アーカイブでは 3.5-inch SATA HDD を優先しやすい。 |
| 検査可能性 | long test を完走させやすく、S.M.A.R.T.、self-test log、dmesg の切り分けもしやすい。 | long test が Aborted by host になりやすい場合があり、USB ブリッジや電源の影響を受けやすい。 | 3.5-inch SATA HDD では long test 中心、外付け 2.5-inch HDD では checksum と実読み出し中心にする。 |
| 可搬性 | 裸のドライブは基板、端子、重量、静電気、衝撃の面で持ち運びに不利である。 | 筐体で保護され、小型軽量で、遠隔地保管や持ち出し媒体として扱いやすい。 | 遠隔地保管や災害対策コピーでは外付けモバイル 2.5-inch HDD が現実的である。 |
| 障害切り分け | 媒体、SATA ケーブル、電源、OS ログの関係が比較的単純で、原因を絞り込みやすい。 | 媒体本体、USB ケース、USB ケーブル、ハブ、ポート、電源管理が絡み、原因を分けて見る必要がある。 | 外付け HDD の異常では媒体本体だけでなく接続系を必ず疑う。 |
| 保管性 | 耐衝撃ケースや収納方法を別途用意しないと、裸のドライブとしては保管しにくい。 | 製品筐体に入っており、ポーチや保管ケースと組み合わせて管理しやすい。 | 持ち出しや別拠点保管を継続するには、扱いやすい媒体を選ぶことが重要である。 |
この違いを踏まえると、3.5-inch SATA HDD は「検査しながら守る媒体」として位置づけられる。安定した環境に置き、定期的に S.M.A.R.T. 属性を確認し、short test と long test を実行し、dmesg やファイルシステムログを確認し、必要に応じて checksum や scrub を行う。これは、日常的に更新されるローカルバックアップや、すぐ復元したいデータの保管先として有効である。
一方、外付けモバイル 2.5-inch HDD は「分散して守る媒体」として位置づけられる。遠隔地に置けること、持ち運びやすいこと、収納しやすいこと、必要なときだけ接続して更新できることが強みである。その代わり、long test の完走性だけに強く依存せず、コピー後の checksum 照合、全ファイル読み出し、short test、S.M.A.R.T. 属性の増減確認、dmesg の確認を中心にする。外付け 2.5-inch HDD では、検査の主役を媒体自己診断から実データ検証へ少し移す必要がある。
つまり、3.5-inch SATA HDD と外付けモバイル 2.5-inch HDD は、信頼性の種類が違う。3.5-inch SATA HDD は、接続経路が単純で検査しやすいという意味で信頼しやすい。外付けモバイル 2.5-inch HDD は、持ち運びや遠隔地保管を継続しやすいという意味で信頼しやすい。前者は検査可能性に強く、後者は可搬性と分散性に強い。したがって、どちらか一方を絶対視するのではなく、常設ローカルバックアップには 3.5-inch SATA HDD を使い、遠隔地保管には外付けモバイル 2.5-inch HDD を使うという役割分担が合理的である。
この役割分担を前提にすれば、long test 完走性だけで媒体の価値を判断する必要はなくなる。常設環境では long test が完走することを重視し、遠隔地保管媒体では checksum 照合と複数コピーを重視する。媒体ごとの弱点を理解し、弱点を別の検査や別の媒体で補うことが、バックアップ・リカバリー戦略における物理媒体管理の基本である。
5. S.M.A.R.T. 以外に見るべき管理指標
S.M.A.R.T. は物理媒体の内部状態を見るための重要な手段である。しかし、媒体管理を S.M.A.R.T. だけで完結させることはできない。S.M.A.R.T. が見ているのは、基本的にはデバイスが自分自身について報告できる範囲である。これに対して、実際のバックアップ・リカバリー運用では、OS から見た I/O、接続経路、ファイルシステムの整合性、保存されたファイル内容、バックアップリポジトリ、復元手順まで確認しなければならない。Backblaze のように大規模なドライブ運用を行う事業者は S.M.A.R.T. 属性と故障率の関係を継続的に分析しているが、それでも S.M.A.R.T. は故障傾向を見るための一要素であり、データ復元可能性そのものを保証するものではない[7]。
まず見るべきなのは、OS 側のログである。S.M.A.R.T. が媒体内部からの自己申告であるのに対して、dmesg や journal は、ホスト OS が実際に観測した I/O の結果を示す。外付け HDD では特に重要である。USB reset、timeout、disconnect、UAS の abort、I/O error、Buffer I/O error、ファイルシステムエラーが出ている場合、媒体本体が悪いとは限らない。USB ケーブル、USB ポート、USB ハブ、USB-SATA ブリッジ、バスパワー不足、外付けケースの省電力制御、OS 側のドライバーが原因である可能性もある。したがって、S.M.A.R.T. が正常でも OS ログに異常が出ている場合は、保存媒体としては慎重に扱うべきである。
次に、ファイルシステムの整合性を見る必要がある。媒体が物理的に読めても、ファイルシステムのメタデータが壊れていれば、ディレクトリ構造、ファイル名、権限、ブロック割り当て、ジャーナル、inode、extent などに問題が起きる。電源断、不正な USB 切断、強制アンマウント、カーネル panic、外付けケースの瞬断などは、媒体本体を壊さなくてもファイルシステムを壊すことがある。したがって、S.M.A.R.T. が正常であることと、ファイルシステムが整合していることは分けて考えなければならない。
さらに重要なのが、データ内容の検証である。ファイルが存在していて、ディスクから読めるとしても、その内容が過去に保存した内容と同一であるとは限らない。コピー途中の失敗、誤上書き、同期ミス、サイレント破損、アプリケーション側の破損、バックアップリポジトリのメタデータ破損は、S.M.A.R.T. だけでは検出できない。このため、checksum、バックアップツールの verify、全ファイル読み出し、rsync の checksum 比較などが必要になる。物理媒体が正常に見えることと、保存されたデータが正しいことは別の問題である。
最後に、復元手順を確認する必要がある。S.M.A.R.T. が正常で、ファイルシステムも整合し、checksum も一致していても、リストア手順が成立しなければバックアップとしては不十分である。暗号化媒体のパスフレーズがない、キーファイルがない、LUKS header が壊れている、バックアップツールのバージョンが合わない、復元先の権限が違う、データベースの戻し方が分からない、依存ソフトウェアがない、という状況は起こり得る。したがって、媒体管理は、媒体を読むところで終わらず、実際に必要なデータや環境を復元できるかまで含めて考える必要がある。
| 管理層 | 見る対象 | 検出できる問題 | S.M.A.R.T. との関係 |
|---|---|---|---|
| OS ログ | dmesg、journal、kernel log に出る I/O error、USB reset、timeout、disconnect、UAS abort、Buffer I/O error を見る。 | 媒体本体ではなく、接続経路、USB ブリッジ、ケーブル、電源、OS 側ドライバーの異常を検出できる。 | S.M.A.R.T. が正常でも、OS が実際に I/O 異常を観測している場合は保存運用上の危険が残る。 |
| ファイルシステム検査 | fsck、xfs_repair、ファイルシステムログ、マウント時エラー、メタデータ整合性を見る。 | 電源断、不正切断、強制停止によるディレクトリ構造、inode、extent、ジャーナル、割り当て情報の破損を検出できる。 | 媒体が物理的に正常でも、ファイルシステムが壊れていればデータを正しく取り出せない。 |
| scrub | Btrfs や ZFS などで、データとメタデータを読み出し、checksum や冗長性に基づいて整合性を見る。 | 通常の読み書きでは気づきにくいサイレント破損、メタデータ破損、冗長コピー間の不一致を検出できる。 | S.M.A.R.T. が媒体の自己状態を見るのに対して、scrub はファイルシステムやストレージプールとしての整合性を見る。 |
| checksum | sha256sum などで作成したハッシュ、バックアップツールの check、verify、rsync –checksum による内容比較を見る。 | 保存済みファイルの内容変化、コピー失敗、誤上書き、サイレント破損、バックアップリポジトリの破損を検出できる。 | S.M.A.R.T. が正常でも、ファイル内容が過去の正しい状態と一致するかは checksum でなければ確認できない。 |
| 全ファイル読み出し | 保存されたファイルを実際にすべて読み出せるかを見る。 | 外付け HDD で long test が完走しにくい場合でも、実データが読めるかを現実的に確認できる。 | 媒体自己診断ではなく、実際に保存しているデータをホスト側から読めるかを見る補完手段になる。 |
| バックアップ verify | borg check、restic check、duplicity verify、バックアップツール固有の整合性検査を見る。 | バックアップリポジトリ、チャンク、インデックス、暗号化メタデータ、重複排除データの破損を検出できる。 | S.M.A.R.T. は媒体を見るが、バックアップ verify はバックアップ集合としての整合性を見る。 |
| リストアテスト | 実際にファイル、ディレクトリ、設定、データベース、サービスを復元できるかを見る。 | 鍵喪失、手順不足、権限不整合、依存ソフトウェア不足、復元先環境の不備を検出できる。 | S.M.A.R.T. が正常でも、実際に戻せなければバックアップとしては成立しない。 |
このように見ると、媒体管理には複数の検査層がある。S.M.A.R.T. は媒体内部の状態を見る。OS ログはホストから見た I/O と接続経路を見る。ファイルシステム検査は構造の整合性を見る。checksum はデータ内容の同一性を見る。backup verify はバックアップ集合としての整合性を見る。リストアテストは復元手順の成立性を見る。これらは重複しているように見えるが、実際には別の故障モードを見ている。
たとえば、S.M.A.R.T. が正常でも、USB ケーブル不良でコピーが途中失敗することがある。OS ログに異常がなくても、誤った rsync オプションで削除済み状態を同期してしまうことがある。checksum が一致していても、過去世代が不足していれば、誤削除前の状態へは戻れない。バックアップファイルが存在していても、暗号鍵を失っていれば復元できない。したがって、媒体管理では「どの層の検査で、どの種類の失敗を検出しているのか」を明確にする必要がある。
特に外付けモバイル HDD では、S.M.A.R.T. long test の完走性に限界があることを織り込むべきである。その場合、long test の代わりに checksum や全ファイル読み出しを重視する。常設 3.5-inch SATA HDD では、long test、S.M.A.R.T. 属性、dmesg、scrub を組み合わせる。Btrfs や ZFS のように checksum と scrub を前提にしたファイルシステムでは、媒体単体ではなくストレージ構造全体として整合性を見る。媒体の種類と用途によって、検査の主役は変えるべきである。
結論として、S.M.A.R.T. 以外に見るべき管理指標とは、S.M.A.R.T. の代替ではなく補完である。S.M.A.R.T. は媒体を見ている。OS ログは接続と実 I/O を見ている。ファイルシステム検査は構造を見ている。checksum は内容を見ている。backup verify はバックアップ集合を見ている。リストアテストは復元可能性を見ている。バックアップ・リカバリー戦略における物理媒体管理では、これらを分離して理解し、組み合わせて判断することが重要である。
6. 媒体管理は運用系管理である
物理媒体管理を媒体単体の管理として捉えると、実際の障害を見落とす。HDD や SSD は単独で故障することもあるが、実運用で起きる問題は媒体本体だけから生じるとは限らない。USB ケーブルが不安定でコピーが途中失敗することがある。外付けケースの USB-SATA ブリッジが timeout を起こすことがある。バスパワー不足で一時的に切断されることがある。高温環境で動作が不安定になることもある。つまり、媒体の状態は重要だが、媒体だけを見てもバックアップ運用全体の信頼性は判断できない。
大規模運用の統計では、ドライブモデル、容量、年齢、運用期間によって故障率が異なることが示される。Backblaze の 2025 年ドライブ統計のような大規模データは、ドライブモデルや年齢ごとの故障率を考えるうえで有用である[8]。しかし、個人や小規模運用では、モデル差や年齢だけでなく、筐体、電源、ケーブル、温度、設置場所、持ち運び、操作手順、検査頻度、台帳管理が大きく効く。高信頼な HDD を使っていても、粗悪な USB ケーブル、熱のこもるケース、不安定な電源、不適切な取り外し、未検証のバックアップ手順があれば、復元可能性は簡単に下がる。
ここで重要なのは、媒体を「部品」としてではなく「運用系の一部」として見ることである。媒体本体、接続経路、電源、筐体、ファイルシステム、暗号化、保管場所、検査手順、復元手順は、それぞれ別の故障モードを持つ。どれか一つが弱ければ、バックアップ全体の信頼性はそこに引きずられる。たとえば、HDD が正常でも USB ケースが不安定ならコピーは失敗する。コピーが成功しても checksum を取っていなければ内容の正しさは確認できない。暗号化媒体が正常でも鍵を失えば復元できない。このように、媒体管理は単体管理ではなく、媒体を中心とした運用系管理である。
| 構成要素 | 管理すべき理由 | 見落とした場合に起きること |
|---|---|---|
| 媒体本体 | HDD、SSD、NVMe SSD、USB メモリー、光ディスクなどは、それぞれ故障モード、劣化傾向、検査方法が異なる。 | HDD の代替セクター、SSD の消耗、NVMe の media error などを見落とし、劣化媒体を保存用途に使い続ける。 |
| 接続経路 | SATA、USB、USB ブリッジ、UAS、ハブ、ケーブル、ポートによって安定性と切り分けやすさが変わる。 | USB reset、timeout、disconnect、I/O error を媒体本体の故障と誤認したり、逆に接続不良を見逃したりする。 |
| 電源 | バスパワー不足、AC アダプター不良、瞬断、電圧不安定は、媒体本体の故障に見える症状を引き起こす。 | コピー中の切断、書き込み失敗、ファイルシステム破損、外付け HDD の不安定動作につながる。 |
| 筐体と放熱 | 外付けケース、NAS 筐体、裸ドライブ用ケース、冷却、通気によって温度と物理保護が変わる。 | 高温による劣化、落下や静電気による損傷、端子破損、基板接触が起きやすくなる。 |
| 保管環境 | 温度、湿度、振動、落下、静電気、磁気、盗難、水害、火災がデータ生存性に影響する。 | 媒体が長期保管中に読めなくなったり、同一拠点の災害で複数コピーを同時に失ったりする。 |
| ファイルシステム | ext4、XFS、Btrfs、ZFS、exFAT、NTFS などは、整合性検査、checksum、scrub、障害時回復の性質が異なる。 | 媒体が正常でも、メタデータ破損、ジャーナル不整合、ディレクトリ構造破損によってデータを取り出せなくなる。 |
| 暗号化 | 遠隔地保管や持ち出し媒体では暗号化が有効だが、鍵、パスフレーズ、ヘッダー管理が必要になる。 | 媒体が正常でも、パスフレーズ、キーファイル、LUKS header を失うと復元不能になる。 |
| 操作手順 | 安全な取り外し、マウント確認、コピー後照合、台帳記録、遠隔地ローテーションを手順化する必要がある。 | 不正切断、未照合コピー、古い遠隔地バックアップ、媒体取り違え、上書きミスが発生する。 |
| 検査頻度 | S.M.A.R.T.、dmesg、checksum、scrub、verify、リストアテストをどの頻度で行うかを決める必要がある。 | 壊れたバックアップを長期間放置し、必要になった時点で初めて復元不能に気づく。 |
この表が示しているのは、媒体本体だけを正常に保っても、バックアップ運用は成立しないということである。たとえば、媒体本体に異常がなくても、USB ケーブルが不安定ならコピーは失敗する。コピーが成功しても、ファイルシステムが壊れていればディレクトリ構造を正しく読めない。ファイルシステムが正常でも、checksum を作っていなければ内容が以前と一致するか確認できない。内容が正しくても、遠隔地保管がなければ火災や盗難で同時に失う可能性がある。遠隔地保管があっても、暗号鍵を失えば復元できない。したがって、物理媒体管理は、各構成要素を個別に見るだけでなく、それらが復元可能性へどう接続しているかを見る必要がある。
NIST SP 800-209 はストレージインフラのセキュリティにおいて、データ保護、復元保証、物理セキュリティ、構成管理などを含む包括的な観点を示している[9]。これは大規模なストレージインフラ向けの文脈で語られることが多いが、個人運用でも本質は同じである。媒体を買い、データをコピーし、棚に置くだけでは、復元可能性は保証されない。どの媒体に何を保存し、どの頻度で検査し、どこに保管し、どの手順で復元し、どの条件で退役させるかまで決めて初めて、媒体管理はバックアップ・リカバリー戦略の一部になる。
この意味で、媒体管理は「物を管理する作業」ではなく「運用系を管理する作業」である。物理媒体はデータを保持する基盤だが、その基盤は、接続、電源、筐体、保管、ファイルシステム、暗号化、検査、手順、台帳と結びついて初めて機能する。媒体単体ではなく、媒体を取り巻く運用系を管理しなければ、バックアップは復元可能性を持たない。
7. 3-2-1 ルールと 3-2-1-1-0
バックアップ戦略を考えるとき、最初に押さえるべき基本形が 3-2-1 ルールである。これは、少なくとも 3 つのコピーを持ち、2 種類以上の媒体または保存系に分け、1 つ以上を遠隔地に置くという考え方である。重要なのは、このルールが単なる数合わせではないという点である。3 という数字は単一コピー喪失への対策であり、2 という数字は同一媒体・同一方式への依存を避けるための対策であり、1 つのオフサイトコピーは同一場所での同時喪失を避けるための対策である。つまり、3-2-1 ルールは、媒体故障、方式依存、拠点喪失という異なる失敗モードを分離するための実務的な設計原則である。
NIST SP 800-34 は、情報システムのコンティンジェンシープランにおいて、バックアップ、復旧戦略、代替処理、復旧手順を計画する必要性を示している[10]。これは組織向けの文脈で語られることが多いが、個人や小規模運用でも本質は同じである。バックアップは、媒体を用意するだけでは成立しない。どの障害に備え、どの時点へ戻り、どの媒体から復元し、どの手順で作業を再開するかまで考える必要がある。CISA も重要ファイルを 3 コピー持ち、2 種類のストレージ媒体を使い、1 コピーをオフサイトに置くというバックアップルールを示している[11]。
3-2-1 ルールの第一の意味は、単一媒体への依存を避けることである。作業中のデータが内蔵 SSD にしか存在しない場合、その SSD が突然故障すればデータを失う。外付け HDD に 1 コピーを取っていても、その外付け HDD が壊れていれば復元できない。したがって、作業データ、ローカルバックアップ、遠隔地バックアップのように、役割の違うコピーを複数持つ必要がある。ここでの 3 コピーとは、単に同じ場所に同じ HDD を 3 台並べることではなく、障害時に相互に代替できる実効的なコピーを 3 系統持つという意味である。
第二の意味は、媒体や保存方式を分けることである。同じ型番の HDD を同じ筐体に入れ、同じ電源で、同じ時期に、同じ場所で使っている場合、それらは完全には独立していない。同時期に劣化する可能性があり、同じ電源障害、同じ熱、同じ操作ミス、同じ筐体故障の影響を受ける。内蔵 SSD、3.5-inch SATA HDD、外付けモバイル HDD、NAS、クラウドのように保存方式を分けると、単一方式に固有の失敗を避けやすくなる。もちろん、媒体を分けても、同じ誤削除をすべてに同期してしまえば意味は弱くなるため、方式の分散と世代管理は組み合わせる必要がある。
第三の意味は、場所を分けることである。自宅内に複数 HDD があっても、火災、水害、盗難、落雷、重大な電源障害では同時に失う可能性がある。遠隔地保管は、この同一場所リスクを切り離すための手段である。外付けモバイル 2.5-inch HDD は、3.5-inch SATA HDD より long test の完走性では不利な場合があるが、遠隔地へ持ち出しやすいという点で価値がある。ここで重要なのは、遠隔地コピーに常設 HDD と同じ検査性を求めるのではなく、遠隔地コピーとしての役割、つまり同時喪失を避ける役割を果たせているかを見ることである。
| ルール | 意味 | 防ぐ失敗 | 物理媒体管理上の対応 |
|---|---|---|---|
| 3 コピー | 作業データに加えて、複数の復元可能なコピーを持つ。 | 単一媒体故障、誤操作、コピー失敗、バックアップ媒体の故障による喪失を防ぐ。 | 作業データ、ローカルバックアップ、遠隔地バックアップを分け、各コピーの更新日と検証日を記録する。 |
| 2 種類以上 | 媒体種別、保存方式、筐体、接続方式、サービスを分散する。 | 同一媒体、同一筐体、同一方式、同一サービスに依存することで起きる共通原因故障を防ぐ。 | 内蔵 SSD、3.5-inch SATA HDD、外付け HDD、NAS、クラウドなどを役割別に組み合わせる。 |
| 1 オフサイト | 少なくとも 1 コピーを同一拠点から切り離して保管する。 | 火災、水害、盗難、落雷、重大な電源障害、建物単位の事故による同時喪失を防ぐ。 | 外付けモバイル HDD、別拠点保管、クラウドバックアップを使い、遠隔地コピーの更新日と照合日を管理する。 |
ただし、3-2-1 ルールにも限界がある。3 コピーあっても、すべてが常時接続され、すべてに同じ削除や暗号化済みファイルが同期されるなら、誤削除やランサムウェアには弱い。2 種類の媒体を使っていても、どちらも同じ場所にあり、同じ操作で上書きされるなら独立性は低い。1 つのオフサイトコピーがあっても、何年も更新されていなければ RPO を満たせない。つまり、3-2-1 は出発点として有効だが、それだけで現代的なバックアップ・リカバリー戦略が完成するわけではない。
そこで使われる拡張が 3-2-1-1-0 である。これは、3 コピー、2 種類の媒体または保存系、1 つのオフサイトコピーに加えて、1 つのオフラインまたはイミュータブルコピーを持ち、検証エラー 0 を目指すという考え方である。Veeam は 3-2-1-1-0 の文脈で、イミュータブルコピーと検証エラー 0 の重要性を説明している[12]。この拡張は、現代のバックアップで重要になったランサムウェア、誤同期、改ざん、検証不足への対策を補う。
| 拡張要素 | 意味 | なぜ必要か | 物理媒体管理上の対応 |
|---|---|---|---|
| 追加の 1 | 1 つのコピーをオフラインまたはイミュータブルにする。 | 常時接続されたバックアップは、ランサムウェア、誤削除、誤同期、誤上書きの影響を受ける可能性があるため。 | 普段は外しておく HDD、書き換え不能設定、削除保護、イミュータブルストレージ、クラウドのオブジェクトロックを検討する。 |
| 0 | 検証時のエラーが 0 であることを確認する。 | バックアップが存在しても、壊れている、途中で失敗している、復元できない、鍵がない、という状態では意味がないため。 | checksum、backup verify、scrub、全ファイル読み出し、リストアテストを行い、異常があれば退役や再コピーを判断する。 |
この拡張により、物理媒体管理の役割はさらに明確になる。3-2-1 の「2」は媒体や保存方式を分けることであり、「1」は遠隔地へ分散することである。3-2-1-1-0 の追加の「1」は、常時接続や常時同期から切り離すことであり、「0」は検証によって壊れたバックアップを放置しないことである。つまり、物理媒体管理は、媒体を選ぶことだけではなく、媒体をどこに置き、いつ接続し、どの頻度で更新し、どの方法で検証し、どの時点で切り離すかを決める作業である。
この点で、外付けモバイル HDD は 3-2-1-1-0 の中でも重要な役割を持つ。常設ローカルバックアップには 3.5-inch SATA HDD や NAS が向くが、オフサイトやオフラインコピーには、持ち運びやすく保管しやすい外付けモバイル HDD が現実的である。ただし、遠隔地媒体は接続頻度が低くなりやすいため、更新日、照合日、暗号化状態、パスフレーズ、保管場所を台帳で管理しなければならない。遠隔地に置いた時点で安心するのではなく、持ち帰って読めるか、checksum が合うか、必要な世代が残っているかを確認する必要がある。
結論として、3-2-1 ルールは、バックアップ媒体を増やすための標語ではない。それは、単一媒体、単一方式、単一拠点への依存を避けるための構造である。3-2-1-1-0 は、そこにオフライン性またはイミュータブル性と検証性を加える。バックアップ・リカバリー戦略における物理媒体管理では、コピー数、媒体種別、保管場所、接続状態、検証結果を分けて管理し、壊れる媒体、誤る人間、攻撃される環境を前提に、復元できる構造を維持することが重要である。
8. 想定障害から媒体管理を逆算する
媒体管理は、使用する媒体の種類から考え始めると判断を誤りやすい。3.5-inch SATA HDD を使うべきか、外付けモバイル 2.5-inch HDD を使うべきか、クラウドを併用すべきかという問いは重要だが、それだけでは設計の出発点として不十分である。なぜなら、媒体の良し悪しは単独で決まるものではなく、どの障害に備えるために使うのかによって変わるからである。常設ローカルバックアップに向いた媒体と、遠隔地保管に向いた媒体は同じではない。高速復元に向いた媒体と、ランサムウェア対策に向いた媒体も同じではない。
したがって、媒体管理は「何を保存するか」だけでなく、「何が起きたときに、どの時点へ、どの程度の時間で戻したいか」から逆算する必要がある。HDD 単体故障に備えるなら、同一データの複数コピーが必要である。誤削除に備えるなら、最新状態のミラーではなく、削除前へ戻れる世代管理が必要である。ランサムウェアに備えるなら、常時接続されたバックアップだけでは不十分であり、オフラインコピーまたはイミュータブルコピーが必要になる。火災、水害、盗難に備えるなら、自宅内の複数媒体ではなく、遠隔地保管やクラウドによる拠点分散が必要になる。
このように考えると、バックアップの失敗は「媒体が壊れた」という一種類の問題ではないことが分かる。媒体故障、誤削除、同期ミス、ランサムウェア、サイレント破損、ファイルシステム破損、暗号鍵喪失、災害、盗難、操作手順の欠落は、それぞれ別の障害である。そして、それぞれ必要な対策が違う。複数コピーは媒体故障には有効だが、誤削除が全コピーへ同期される構成では誤削除対策にならない。遠隔地保管は火災対策には有効だが、何年も更新していなければ RPO を満たせない。暗号化は盗難対策には有効だが、鍵を失えば復元不能になる。
セキュリティインシデントからの復旧では、クリーンなバックアップから復元し、復元前に感染や汚染が含まれていないことを確認する考え方が重要になる[13]。これはランサムウェア対策に限らない。誤削除、誤同期、破損、設定ミスでも同じである。バックアップは「存在している」だけでは足りない。障害発生前の正常な時点へ戻れること、復元対象が汚染されていないこと、復元手順が実際に成立することを確認できなければならない。
| 想定障害 | 何が失われるか | 必要な対策 | 媒体管理上の意味 |
|---|---|---|---|
| HDD 単体故障 | 特定の媒体に保存されたデータを読み出せなくなる。 | 複数コピーを持ち、1 台の媒体喪失でデータ全体を失わないようにする。 | 1 台の S.M.A.R.T. 正常性に依存せず、ローカルバックアップ、遠隔地バックアップ、クラウドなどを組み合わせる。 |
| 誤削除 | 人間の操作ミスによって、必要なファイルやディレクトリが消える。 | 世代管理を行い、削除前の時点へ戻れるようにする。 | 最新ミラーだけでは削除後の状態も複製されるため、日次、週次、月次などの過去世代を残す。 |
| 誤同期 | 壊れた状態、消えた状態、古い状態が複数コピーへ反映される。 | 同期とバックアップを分け、dry-run、差分確認、世代保持を行う。 | 常時同期されたコピーをバックアップと見なさず、戻れる時点を持つ保存構造を用意する。 |
| ランサムウェア | 常時接続されたデータやバックアップが暗号化、削除、改ざんされる。 | オフラインコピーまたはイミュータブルコピーを持ち、感染前の正常世代を残す。 | 常時接続された媒体を過信せず、普段は切り離した HDD、削除保護、オブジェクトロックなどを検討する。 |
| 火災・水害・盗難 | 同一拠点にある複数媒体を同時に失う。 | 遠隔地保管を行い、物理的な同時喪失を避ける。 | 外付けモバイル 2.5-inch HDD、別拠点保管、クラウドを使って、自宅内バックアップとは別の場所にコピーを置く。 |
| サイレント破損 | ファイルが存在していても、内容が気づかないうちに変化する。 | checksum、scrub、verify、全ファイル読み出しを行う。 | 保存しているだけでは破損を検出できないため、正しい内容と照合できる基準を作る。 |
| ファイルシステム破損 | 媒体は読めても、ディレクトリ構造、メタデータ、割り当て情報が壊れる。 | fsck、xfs_repair、scrub、正しいアンマウント、安全な取り外しを行う。 | 媒体の健康状態とファイルシステムの整合性を分けて確認する。 |
| 暗号鍵喪失 | 暗号化媒体が正常でも復号できなくなる。 | パスフレーズ、キーファイル、LUKS header、復元手順を管理する。 | 暗号化媒体では、媒体だけでなく鍵とヘッダーと手順書もバックアップ対象になる。 |
| 復元手順の欠落 | バックアップは存在しても、実際に必要な状態へ戻せない。 | リストアテスト、手順書、権限確認、依存ソフトウェア確認を行う。 | 媒体とデータが残っていても、復元手順が成立しなければバックアップとして機能しない。 |
この表で重要なのは、障害ごとに対策の種類が違うという点である。複数コピーは HDD 単体故障に効くが、ランサムウェア対策としては不十分である。世代管理は誤削除に効くが、同一拠点災害には不十分である。遠隔地保管は災害対策として有効だが、コピー後に checksum を確認していなければ、壊れたデータを遠隔地に置いているだけになる。暗号化は盗難時の情報漏えいを防ぐが、鍵管理が弱ければ復元不能性を高める。したがって、単一の対策で全リスクを処理しようとしてはいけない。
媒体の選定も、この障害シナリオから逆算する必要がある。常設ローカルバックアップでは、3.5-inch SATA HDD や NAS のように、安定電源、放熱、S.M.A.R.T. 監視、long test、scrub を行いやすい構成が有利である。遠隔地保管では、外付けモバイル 2.5-inch HDD のように、持ち運びやすく、収納しやすく、必要なときだけ接続できる媒体が合理的である。ランサムウェア対策では、常時接続ではなく、オフライン化またはイミュータブル化できる保存系が必要になる。長期アーカイブでは、媒体寿命だけでなく、将来読み出せる機器、ファイル形式、暗号鍵、台帳が必要になる。
また、障害シナリオごとに検査方法も変わる。HDD 単体故障を疑うなら S.M.A.R.T.、short test、long test、dmesg を見る。サイレント破損を疑うなら checksum、scrub、backup verify を見る。誤削除や誤同期を想定するなら、世代管理と復元可能な時点を確認する。ランサムウェアを想定するなら、オフラインコピーが感染時点から切り離されているか、イミュータブルコピーが改ざんされていないかを見る。復元不能を避けるには、リストアテストによって実際に戻せることを確認する。
したがって、この章の要点は、媒体の種類から運用を決めるのではなく、障害シナリオから媒体の役割を決めることである。3.5-inch SATA HDD が優れている場面もあれば、外付けモバイル 2.5-inch HDD が優れている場面もある。クラウドが有効な場面もあれば、クラウドだけでは危険な場面もある。媒体の価値は、単体性能ではなく、どの障害に対して、どの役割を果たしているかで決まる。
バックアップ・リカバリー戦略における物理媒体管理は、障害シナリオを分解し、それぞれに対してコピー数、媒体種別、保管場所、接続状態、世代管理、検証方法、復元手順を割り当てる作業である。HDD が壊れることだけを想定していては足りない。人間が誤ること、同期が誤ること、攻撃されること、拠点ごと失うこと、暗号鍵を失うこと、復元手順を忘れることまで含めて設計する必要がある。その設計を行って初めて、媒体管理は単なるディスク管理ではなく、復元可能性を守る運用設計になる。
9. 同期、ミラー、バックアップ、アーカイブを混同しない
バックアップ設計でよくある誤りは、同期、ミラー、バックアップ、アーカイブを同じものとして扱うことである。どれも複数の場所にデータを置くという点では似ている。しかし、目的、失敗時の挙動、戻れる時点、必要な管理手順は大きく違う。同期は現在状態を揃える仕組みであり、ミラーは同一内容の代替コピーを持つ仕組みであり、バックアップは過去時点へ戻るための仕組みであり、アーカイブは長期保存するための仕組みである。この違いを曖昧にしたまま媒体を増やしても、実際の障害時には期待した復元ができない。
同期は、複数の場所にあるデータを同じ状態へ近づける仕組みである。PC と NAS、PC とクラウド、複数端末間のファイル同期は、日常的な利便性を高める。ある場所で更新したファイルが別の場所にも反映されるため、複数端末で同じ作業状態を使いやすい。しかし、同期の本質は現在状態の反映であり、過去状態の保存ではない。誤って削除したファイル、壊れたファイル、ランサムウェアで暗号化されたファイル、誤って上書きしたファイルも、設定によってはそのまま同期先へ反映される。つまり、同期は可用性や作業性には有効だが、それだけではバックアップではない。
ミラーは、同一内容の代替コピーを持つ仕組みである。RAID 1、ディスククローン、同一内容を持つ予備ディスクなどは、媒体故障時の即時代替に向いている。ミラーの価値は、現在の状態を別媒体にも保持し、片方が壊れてももう片方から作業を継続しやすい点にある。しかし、ミラーも基本的には現在状態の複製である。現在状態が誤って削除済みなら、ミラーも削除済みになる。現在状態が破損済みなら、ミラーも破損済みになる。世代を持たないミラーは、ハードウェア故障には強いが、論理破損や人為ミスには弱い。
バックアップは、過去時点の状態へ戻れるようにする仕組みである。ここが同期やミラーとの決定的な違いである。バックアップでは、最新状態だけでなく、昨日、先週、先月のような複数の時点を保持する。これにより、誤削除、誤上書き、設定ミス、破損、ランサムウェア感染後の状態から、感染前や破損前の状態へ戻れる可能性が生まれる。ただし、バックアップには世代管理、容量管理、保持期間、検証、リストア手順が必要になる。バックアップは、単にファイルをどこかへコピーすることではなく、戻れる時点を設計することである。
アーカイブは、長期保存を目的とする仕組みである。バックアップが障害から戻るための運用データであるのに対して、アーカイブは将来参照するために保存する長期記録である。古い写真、完成済み原稿、会計資料、研究データ、過去プロジェクト、公開済みコンテンツなどはアーカイブ対象になり得る。アーカイブでは、即時復旧よりも、長期的に読めること、意味が失われないこと、ファイル形式が将来も解釈できること、暗号鍵や読み出し機器を維持できることが重要になる。アーカイブは放置ではなく、長期的な読み出し可能性の管理である。
| 方式 | 目的 | 強い障害 | 弱い障害 | 必要な管理 |
|---|---|---|---|---|
| 同期 | 複数場所の現在状態を揃える。 | 端末故障、作業場所変更、複数端末利用に強い。 | 誤削除、誤上書き、ランサムウェア、破損ファイルの反映に弱い。 | 同期方向、除外設定、削除反映、履歴機能、競合処理を管理する。 |
| ミラー | 同一内容の代替コピーを持つ。 | 単一ディスク故障、即時代替、短時間の可用性維持に強い。 | 世代がなければ、誤削除、論理破損、暗号化済みファイルの複製に弱い。 | ミラー状態、再同期、媒体劣化、同時故障、別媒体へのバックアップを管理する。 |
| バックアップ | 過去時点の状態へ戻れるようにする。 | 誤削除、誤上書き、破損、感染前状態への復元に強い。 | 検証不足、世代不足、容量不足、鍵喪失、復元手順不備に弱い。 | 世代管理、保持期間、checksum、verify、媒体ローテーション、リストアテストを管理する。 |
| アーカイブ | 長期保存し、将来参照できる状態を維持する。 | 完了済みデータ、履歴資料、法定保存、長期記録の保持に強い。 | 媒体寿命、読み出し機器喪失、ファイル形式陳腐化、暗号鍵喪失に弱い。 | 媒体更新、形式維持、定期読み出し、checksum 照合、台帳、鍵管理を行う。 |
この違いを理解すると、外付け HDD に最新状態だけを上書きコピーしている運用の位置づけも明確になる。その運用は、過去世代を持たない限り、厳密にはバックアップというよりミラーに近い。もちろん、最新コピーが別媒体にあること自体には価値がある。内蔵 SSD が突然壊れた場合、外付け HDD に直近のコピーがあれば助かる。しかし、誤削除後にその状態を上書きコピーしてしまえば、削除前の状態へは戻れない。破損したファイルを上書きコピーしてしまえば、正常な過去版は失われる。つまり、最新コピーだけでは、媒体故障には一定の効果があっても、人為ミスや論理破損には弱い。
バックアップとして成立させるには、戻れる時点を持たせる必要がある。日次、週次、月次のように世代を分ける。重要ファイルだけでも、更新前の状態を残す。rsync であれば hard link を使った世代管理、バックアップツールであれば snapshot や archive、ファイルシステムであれば snapshot、クラウドであれば versioning や retention を利用する。ここで重要なのは、最新状態をもう一つ作ることではなく、過去の正常状態を消さずに残すことである。バックアップの価値は、コピー数だけではなく、戻れる時点の幅によって決まる。
一方、アーカイブでは、世代を大量に持つことよりも、長期的に読める状態を維持することが重要になる。たとえば、完了済みの原稿や写真を長期保存する場合、頻繁な世代管理よりも、checksum、媒体台帳、保存形式、暗号鍵、読み出し確認が重要になる。何年後かに読もうとしたとき、媒体が劣化している、ファイル形式を開けない、暗号鍵を失っている、どの媒体に保存したか分からない、という状態ではアーカイブとして失敗である。アーカイブは、古いデータを押し込む場所ではなく、将来の読み出し可能性を維持するための運用である。
同期、ミラー、バックアップ、アーカイブは、互いに排他的なものではない。むしろ、実運用では組み合わせて使う。同期は日常作業の利便性を高める。ミラーは媒体故障時の可用性を上げる。バックアップは過去時点への復元を可能にする。アーカイブは長期保存を支える。問題は、これらを混同することである。同期をバックアップだと思い込むと、誤削除に弱くなる。ミラーをバックアップだと思い込むと、論理破損に弱くなる。アーカイブを単なる古いバックアップだと思い込むと、将来の読み出し可能性を管理しなくなる。
物理媒体管理の観点では、それぞれの方式ごとに媒体の役割を決める必要がある。常設 3.5-inch SATA HDD は、ローカルバックアップやミラーに向く。外付けモバイル 2.5-inch HDD は、遠隔地バックアップやオフライン世代に向く。クラウドは、同期にもバックアップにもアーカイブにも使えるが、設定によって性質が変わる。NAS は便利だが、常時接続である以上、ランサムウェアや誤削除同期には注意が必要である。媒体は同じでも、同期として使うのか、バックアップとして使うのか、アーカイブとして使うのかで、管理方法は変わる。
結論として、物理媒体を増やすこと自体が目的ではない。重要なのは、その媒体が同期、ミラー、バックアップ、アーカイブのどの役割を持っているかを明確にすることである。現在状態を揃えたいのか、即時代替したいのか、過去時点へ戻りたいのか、長期保存したいのかによって、必要な媒体、世代、検証、保管場所、暗号鍵管理、リストアテストは変わる。バックアップ・リカバリー戦略では、媒体の数ではなく、各媒体に割り当てた役割と、それを支える運用手順を管理する必要がある。
10. RPO / RTO で媒体設計を決める
媒体設計は、容量や価格から始めるよりも、RPO と RTO から逆算したほうが明確になる。RPO は Recovery Point Objective の略であり、どの時点まで戻れればよいかを表す。言い換えれば、障害発生時にどれだけのデータ損失を許容できるかである。RTO は Recovery Time Objective の略であり、どれくらいの時間で復旧したいかを表す。言い換えれば、障害発生後にどれだけ停止しても許容できるかである。AWS は災害復旧計画において、アプリケーションごとに RTO と RPO を定義する必要があると説明している[14]。IBM も RPO を許容できるデータ損失量、RTO を復元に必要な許容時間として整理している[15]。
RPO と RTO は似ているが、見ている対象が違う。RPO は時間軸上の「どこまで戻れるか」を問う。たとえば RPO が 24 時間なら、最悪でも 1 日前の状態へ戻れればよいという設計になる。RPO が 1 時間なら、1 時間以内の更新を失う程度に抑える必要がある。これに対して RTO は、障害後に「どれくらいで使える状態へ戻せるか」を問う。RTO が数時間なら、ローカルに高速復元できる媒体や手順が必要になる。RTO が数日でもよいなら、遠隔地媒体を取り寄せて復元する設計も現実的になる。
この違いを理解しないまま媒体を選ぶと、設計がずれる。たとえば、遠隔地に外付け HDD を保管している構成は、災害対策としては有効である。しかし、その媒体を数か月に 1 回しか更新していないなら、RPO は数か月になる。障害発生後に遠隔地から持ち帰る必要があるなら、RTO も長くなる。逆に、NAS や常設 3.5-inch SATA HDD に毎日バックアップしている構成は、RPO と RTO を短くしやすいが、同一拠点に置いているだけなら火災や盗難には弱い。つまり、RPO と RTO は、媒体の種類だけでなく、更新頻度、保管場所、接続状態、復元手順と一体で決まる。
| 指標 | 問うていること | 媒体設計への影響 | 誤解しやすい点 |
|---|---|---|---|
| RPO | 障害発生時に、どの時点のデータまで戻れればよいかを問う。 | バックアップ頻度、snapshot 頻度、世代保持期間、遠隔地コピーの更新頻度を決める。 | 媒体が複数あっても、更新頻度が低ければ RPO は長くなる。 |
| RTO | 障害発生後に、どれくらいの時間で利用可能な状態へ戻せればよいかを問う。 | ローカル復元媒体、復元速度、手順書、代替環境、復元テストの必要性を決める。 | バックアップが存在しても、取り寄せや復元作業に時間がかかれば RTO は長くなる。 |
RPO を短くしたい場合、手動コピーだけに依存する設計は弱くなる。人間が忘れれば、その時点で RPO は伸びる。記事原稿、写真、設定ファイル、業務データ、サーバーデータなど、更新頻度が高く、失いたくないデータほど、自動バックアップ、snapshot、NAS、クラウド同期、バックアップツールによる定期実行を検討する必要がある。ただし、自動化すれば十分というわけではない。自動化された同期は、誤削除や破損も自動で反映する。したがって、RPO を短くしつつ、世代管理も同時に設計する必要がある。
RTO を短くしたい場合、復元元は近く、高速で、手順が明確でなければならない。遠隔地に保管した外付け HDD は、同一拠点喪失への対策として有効だが、すぐに復旧したい場合には遅い。クラウドバックアップも、回線速度、データ量、復元制限、認証、暗号鍵、ツールの準備によって時間がかかる。これに対して、ローカルの 3.5-inch SATA HDD、NAS、予備 SSD、直近 snapshot は、RTO を短くするうえで有利である。ただし、ローカル媒体だけでは災害対策にならないため、RTO の短さとオフサイト性は分けて考える必要がある。
| 要件 | 媒体設計 | 運用上の意味 | 注意点 |
|---|---|---|---|
| RPO が短い | 自動バックアップ、NAS、クラウド、頻繁な snapshot、短い間隔の世代管理を使う。 | 失えるデータ量が少ないため、手動コピーだけでは不足しやすい。 | 自動同期だけでは誤削除や破損も反映されるため、世代管理が必要になる。 |
| RTO が短い | ローカルに高速復元できる 3.5-inch SATA HDD、NAS、予備 SSD、直近 snapshot を置く。 | 遠隔地 HDD やクラウドだけでは、取り寄せやダウンロードに時間がかかる。 | ローカル媒体だけでは火災、水害、盗難による同時喪失に弱い。 |
| 災害対策重視 | 遠隔地保管、外付けモバイル HDD、クラウドバックアップを用意する。 | 自宅内や同一ラック内の複数 HDD だけでは同時喪失に弱い。 | 遠隔地コピーの更新頻度が低いと RPO が長くなり、取り寄せが必要なら RTO も長くなる。 |
| ランサムウェア対策重視 | オフラインコピー、イミュータブルバックアップ、削除保護、感染前世代を使う。 | 常時接続媒体だけでは攻撃面が残る。 | オフライン媒体は更新忘れが起きやすいため、更新日と照合日を台帳で管理する必要がある。 |
| 長期保存重視 | アーカイブ用媒体、複数拠点保管、checksum、定期読み出し、形式維持を行う。 | すぐ復旧するよりも、数年後に読めることが重要になる。 | 媒体寿命、読み出し機器、暗号鍵、ファイル形式、台帳を維持しなければならない。 |
たとえば、個人の写真や公開済みのブログ記事、完成済み原稿であれば、RPO は数日から数週間でも許容できる場合がある。もちろん失いたくないデータであることに変わりはないが、毎分更新される業務データとは性質が違う。この場合は、常設ローカルバックアップに加えて、外付けモバイル HDD に定期コピーし、遠隔地へ保管し、checksum で照合する構成が現実的である。RTO も即時でなくてよいなら、遠隔地媒体を持ち帰って復元する運用でも成立する。
一方、日次更新されるサーバーデータ、データベース、業務用ファイル、設定リポジトリ、作業中の原稿などでは、RPO を短く設計する必要がある。日次バックアップで足りるのか、数時間ごとの snapshot が必要なのか、トランザクションログや binlog が必要なのかを考える必要がある。さらに、復旧が遅れると業務や公開サービスに影響するなら、RTO も短くしなければならない。この場合、遠隔地コピーだけでなく、ローカルで高速復元できる媒体、復元手順書、定期的なリストアテストが必要になる。
RPO と RTO は、常に同時に短くすればよいというものでもない。両方を短くしようとすると、コスト、運用負荷、監視負荷、ストレージ容量、ネットワーク帯域が増える。逆に、両方を長く許容すれば安く簡単になるが、障害時に失うデータ量と停止時間は増える。したがって、データの種類ごとに要件を分ける必要がある。すべてのデータを同じ強度で守ろうとすると、運用が重くなりすぎて継続できない。重要度、更新頻度、再作成可能性、停止時の影響に応じて、RPO と RTO を段階化するべきである。
| データ種別 | RPO の考え方 | RTO の考え方 | 媒体設計の例 |
|---|---|---|---|
| 作業中の原稿や設定ファイル | 更新頻度が高いため、数時間から 1 日程度に抑えたい。 | 作業再開を早くしたい場合は、ローカル復元できる構成が望ましい。 | 内蔵 SSD、ローカル 3.5-inch HDD、Git、クラウド、外付け HDD を組み合わせる。 |
| 写真や完成済み資料 | 更新頻度が低ければ、数日から数週間でも許容できる場合がある。 | 即時復旧よりも、確実に読めることと同時喪失を避けることを重視する。 | ローカル HDD、外付けモバイル HDD、遠隔地保管、checksum 台帳を組み合わせる。 |
| サーバーデータやデータベース | 更新頻度と重要度に応じて、日次、時間単位、ログ単位で設計する。 | サービス停止の許容時間に応じて、ローカル復元、代替環境、手順書を用意する。 | 定期バックアップ、snapshot、binlog や WAL、遠隔地コピー、復元テストを組み合わせる。 |
| 長期アーカイブ | 更新は少ないため、保存時点の完全性と定期照合を重視する。 | 復旧速度よりも、数年後に読めることを重視する。 | 複数媒体、遠隔地保管、checksum、形式維持、暗号鍵管理、媒体更新を組み合わせる。 |
このように、媒体選定は「どの HDD がよいか」「クラウドを使うべきか」という単独の問いでは決まらない。RPO が短いなら、更新頻度と世代管理が重要になる。RTO が短いなら、復元元の近さ、読み出し速度、手順の確実性が重要になる。災害対策を重視するなら、同一拠点から切り離す必要がある。ランサムウェア対策を重視するなら、常時接続から切り離す必要がある。長期保存を重視するなら、媒体寿命、読み出し確認、形式維持、暗号鍵管理が重要になる。
結論として、RPO / RTO はバックアップ設計を実務要件へ接続するための軸である。物理媒体管理は、媒体の容量、価格、型番、S.M.A.R.T. 状態だけで決めるものではない。どのデータを、どの時点まで、どれくらいの時間で、どの障害から戻したいのかを定義し、その要件に合わせて媒体、保管場所、更新頻度、世代管理、検証方法、復元手順を決める必要がある。媒体設計は、RPO と RTO から逆算して初めて、バックアップ・リカバリー戦略の一部になる。
11. 復元可能性を構成する要素
バックアップの信頼性は、媒体単体の故障率だけでは決まらない。もちろん、壊れにくい媒体を選ぶことは重要である。S.M.A.R.T. の状態が悪い HDD より、異常のない HDD のほうが保存先として望ましい。高温で不安定な外付けケースより、安定した電源と放熱を持つ構成のほうがよい。しかし、それだけではバックアップ・リカバリー戦略としては不十分である。なぜなら、実際に必要なのは「媒体が壊れないこと」ではなく、「媒体、接続、ファイルシステム、暗号鍵、操作手順のどこかが壊れても、必要なデータを再構成できること」だからである。
このため、バックアップの信頼性は「ディスクが健康かどうか」ではなく、「復元可能性がどのような要素によって支えられているか」として分解して考える必要がある。復元可能性は、複製数、独立性、世代性、検証性、復元手順性、退役判断の組み合わせで決まる。コピーが多いだけでは足りない。コピー同士が同じ場所にあり、同じ操作ミスを受け、同じ誤削除を同期し、同じ暗号鍵に依存し、どれも検証されていないなら、実効的な復元可能性は低い。逆に、コピー数が過剰でなくても、独立性、世代性、検証性、復元手順性が揃っていれば、実際に戻せる可能性は高くなる。
ここで概念式として書くなら、復元可能性は「複製数 × 独立性 × 世代性 × 検証性 × 復元手順性」によって支えられる。ただし、これは厳密な数式ではない。各要素に数値を割り当てて機械的に計算できるという意味ではなく、見落としを防ぐための分解である。掛け算として表す理由は、どれか一つが極端に弱いと全体の復元可能性が大きく下がるからである。たとえば、複製数が多くても検証性が 0 に近ければ、壊れたコピーを大量に持っているだけになる。世代性がなくても、最新状態のコピーしかなければ、誤削除や破損前の状態へ戻れない。
| 要素 | 意味 | 不足した場合に起きること | 実務上の対応 |
|---|---|---|---|
| 複製数 | 同じデータを、復元に使えるコピーとして何系統持っているかを示す。 | コピーが少ないと、1 台の媒体故障、コピー失敗、誤操作によってデータ全体を失いやすくなる。 | 作業データ、ローカルバックアップ、遠隔地バックアップ、クラウドなどを組み合わせる。 |
| 独立性 | 複数のコピーが、同時に失われにくい配置になっているかを示す。 | 同じ場所、同じ筐体、同じ電源、同じアカウント、同じ同期経路に依存すると、複数コピーを同時に失う可能性がある。 | 別筐体、別拠点、別媒体、別保存方式、別アカウント、オフライン媒体に分ける。 |
| 世代性 | 最新状態だけでなく、過去時点の状態へ戻れるかを示す。 | 世代がないと、誤削除、誤上書き、破損、ランサムウェア感染後の状態だけが残る可能性がある。 | 日次、週次、月次、年次の世代を残し、snapshot、archive、versioning、保持期間を設計する。 |
| 検証性 | 保存されたデータが壊れていないこと、読めること、過去の内容と一致することを確認できるかを示す。 | 検証していないコピーは、必要になった時点で初めて破損、読み取り不能、コピー失敗に気づく可能性がある。 | checksum、scrub、backup verify、全ファイル読み出し、S.M.A.R.T.、dmesg 確認を行う。 |
| 復元手順性 | バックアップから実際に必要なファイル、設定、データベース、環境を戻せるかを示す。 | データが残っていても、暗号鍵、権限、依存ソフトウェア、手順書がなければ実際には復元できない。 | リストアテスト、復元手順書、暗号鍵管理、LUKS header 管理、復元先環境の確認を行う。 |
| 退役判断 | 危険な媒体や不安定な保存経路を、保存系から外せるかを示す。 | 劣化媒体を使い続けると、バックアップが存在するように見えても、実際には復元に使えないコピーが増える。 | S.M.A.R.T. 悪化、I/O error、checksum 不一致、読み取り不能、USB reset 増加を基準に用途を下げるか退役する。 |
複製数は最も分かりやすい要素である。コピーが 1 つしかなければ、その媒体が壊れた時点で終わる。したがって、複数コピーを持つことは基本である。しかし、複製数だけを増やしても安全性は直線的には上がらない。同じ部屋に同じ外付け HDD を 5 台並べ、同じコマンドで同じ最新状態を上書きし、同じ誤削除を反映しているなら、火災、盗難、誤操作、ランサムウェアに対しては弱い。複製数は必要条件だが、十分条件ではない。
独立性は、複数コピーが同時に失われないための条件である。別媒体に保存していても、同じ筐体、同じ電源、同じ場所、同じ OS、同じアカウント、同じ同期設定に依存していれば、共通原因故障を受ける。たとえば、NAS 内の複数ディスクは単一ディスク故障には強いが、NAS 筐体、電源、ファイルシステム、ランサムウェア、誤削除には同時に影響される。外付け HDD を遠隔地へ置くこと、クラウドを併用すること、オフラインコピーを持つことは、この独立性を上げるための手段である。
世代性は、誤削除や論理破損に対する復元可能性を支える。最新状態のコピーだけでは、削除後の状態や壊れた状態も正しく複製されてしまう。バックアップがバックアップとして機能するためには、過去時点へ戻れる必要がある。日次、週次、月次の世代を持つことは、単に古いコピーを残すことではない。どの時点まで戻れるか、どれくらいの期間戻れるか、どの世代をいつ削除するかを設計することである。これは RPO と直接つながる。
検証性は、存在しているバックアップを信用できる状態へ近づける。媒体が棚にあること、ファイルが見えていること、バックアップログが成功していることだけでは十分ではない。実際に読めるか、checksum が一致するか、バックアップリポジトリが壊れていないか、ファイルシステムにエラーがないか、OS ログに I/O error が出ていないかを確認する必要がある。検証していないバックアップは、存在しているように見えるだけで、必要なときに使えるかどうか分からない。
復元手順性は、最後に全体を成立させる要素である。バックアップ媒体があり、内容が正しく、世代も残っていても、復元手順がなければ実用にならない。暗号化媒体のパスフレーズを失っている、LUKS header が壊れている、バックアップツールの使い方を忘れている、復元先の権限が違う、データベースの戻し方が分からない、という状況は十分に起こり得る。したがって、復元可能性は、保存時点ではなく、実際に戻した時点で初めて確認される。
退役判断も復元可能性の一部である。劣化した媒体を保存系に残し続けると、バックアップ構成上はコピーが存在するように見えても、実効的には危険なコピーが混ざる。Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable、Reported_Uncorrect、ATA Error Count、I/O error、checksum 不一致、読み取り不能、USB reset の増加などは、媒体の用途を見直す理由になる。退役とは即廃棄だけではない。主バックアップから補助コピーへ、補助コピーから一時作業用へ、最終的に廃棄へと用途を下げる判断も含む。
このように、復元可能性は単一の要素ではなく、複数の要素が組み合わさって成立する。コピーが 5 個あっても、全部が同じ場所にあり、全部が同期型で、checksum もなく、復元手順も試していないなら、復元可能性は高くない。逆に、コピー数が 3 系統程度でも、別媒体、別拠点、世代管理、checksum、リストアテスト、退役基準が揃っていれば、実効的な安全性は高くなる。ここで重要なのは、数ではなく構造である。
結論として、バックアップの信頼性は「何台あるか」だけではなく、「それぞれがどの役割を持ち、どの障害に対して独立しており、どの時点へ戻れ、どのように検証され、どの手順で復元され、危険になった媒体をどう外すか」で決まる。物理媒体管理は、媒体の故障率を眺める作業ではなく、復元可能性を構成する要素を一つずつ崩れないように管理する作業である。
12. 退役基準を事前に決める
物理媒体管理では、使い始めよりも退役判断のほうが難しい。新しい HDD や SSD を購入してバックアップ先にする判断は比較的簡単である。容量、価格、メーカー、接続方式、用途を見れば、おおよその選定はできる。しかし、すでに運用している媒体をいつ保存用途から外すかは難しい。まだ読める。まだ S.M.A.R.T. は PASSED である。異常値は少数で止まっているように見える。こうした状態では、即廃棄すべきか、補助用途なら使ってよいか、一時作業用へ下げるべきかの判断が曖昧になりやすい。
退役判断が難しい理由は、媒体の異常が必ずしも一瞬で明確な故障として現れるわけではないからである。HDD の Reallocated_Sector_Ct が少数あるだけで、即座に全データが失われるわけではない。代替済みセクターが発生しても、その後 Current_Pending_Sector と Offline_Uncorrectable が 0 のまま安定し、long test が通り、OS ログにも I/O error が出ていないなら、複数コピーの一つとして運用できる場合はある。しかし、Reallocated_Sector_Ct が増加している、Current_Pending_Sector が出ている、Offline_Uncorrectable が出ている、Reported_Uncorrect や ATA Error Count が増えている、long test が失敗する、dmesg に I/O error が出る、checksum が一致しない、という状態なら、保存用途としての信頼性は大きく下がる。
ここで重要なのは、単発の異常値と進行中の劣化を分けることである。過去に 1 回だけ UNC が出て、その後の代替処理や再書き込みによって pending sector が解消し、長期間エラーが増えていない場合と、検査するたびに Reallocated_Sector_Ct や Reported_Uncorrect が増えている場合では意味が違う。前者は「過去に傷がある媒体」であり、後者は「現在も悪化している媒体」である。保存用途で問題になるのは、単に異常値が存在することだけではなく、その異常が増えているか、現在も再現するか、実データの読み出しに影響しているかである。
SSD や NVMe SSD では、HDD の代替セクターと同じ見方をそのまま適用してはいけない。SSD は NAND フラッシュ、コントローラー、予備領域、ウェアレベリング、エラー訂正、ガベージコレクションによって成立している。したがって、available spare、percentage used、media and data integrity errors、critical warning、unsafe shutdown、controller error、temperature、wear leveling に関係する指標を見る必要がある。NVM Express は NVMe の SMART / health log において、available spare や percentage used が寿命・予備領域の把握に使われることを説明している[16]。SSD は機械的な異音や回転不良として劣化が見えにくく、突然認識しなくなることもあるため、健康そうに見えることを過信しないほうがよい。
外付け HDD では、媒体本体と接続系を分けて考える必要がある。USB reset、disconnect、timeout、コピー中停止、マウント解除、I/O error が出た場合、それが HDD 本体の劣化なのか、USB ケーブルなのか、USB-SATA ブリッジなのか、バスパワー不足なのか、USB ハブなのか、OS 側の省電力制御なのかを切り分ける必要がある。同じ媒体を別ケーブル、別ポート、別ケース、別ホストで試したときに再現するなら媒体本体の疑いが強くなる。逆に、特定のケーブルやケースでだけ発生するなら、媒体本体ではなく接続系の退役または交換が必要になる。
| 媒体・構成 | 退役を検討すべき兆候 | 確認すべき観点 | 判断 |
|---|---|---|---|
| HDD | Current_Pending_Sector、Offline_Uncorrectable、Reallocated_Sector_Ct 増加、Reported_Uncorrect 増加、ATA Error Count 増加、long test failure、I/O error が出る。 | 異常値が単発で止まっているか、継続的に増えているか、実データ読み出しや checksum に影響しているかを見る。 | 増加傾向や読み取り不能がある場合は保存用途から外し、補助用途へ下げるか退役する。 |
| SSD / NVMe SSD | Media and Data Integrity Errors、Available Spare 低下、Percentage Used 高止まり、Critical Warning、NVMe timeout、認識不安定が出る。 | HDD の代替セクターではなく、予備領域、消耗度、media error、controller error、unsafe shutdown、温度を確認する。 | 重要データの保存用途から外し、作業用または一時用途へ下げる。認識不安定なら早期交換する。 |
| 外付け HDD | USB reset、disconnect、timeout、コピー中停止、マウント解除、I/O error、long test の不自然な中断が出る。 | 媒体本体、USB ケース、USB ケーブル、USB ポート、バスパワー、USB ハブ、OS 省電力制御を分けて確認する。 | 別ケーブルや別ケースでも再現するなら媒体を疑い、特定の接続系でのみ再現するなら接続部品を退役する。 |
| ファイルシステム | fsck エラー、xfs_repair が必要な状態、Btrfs / ZFS scrub error、マウント失敗、メタデータ破損が出る。 | 媒体本体の故障なのか、不正切断や電源断による論理破損なのか、複数回再発するかを見る。 | 再発する場合は媒体または接続系を疑い、保存用途としての信頼性を下げる。 |
| バックアップデータ | checksum 不一致、backup verify failure、復元失敗、読み取り不能ファイル、リポジトリ破損が出る。 | 媒体の S.M.A.R.T. ではなく、保存された内容とバックアップ集合としての整合性を見る。 | 保存用途としては危険であり、正常コピーから再作成し、原因媒体や接続系を切り分ける。 |
退役判断では、媒体をすぐ捨てるかどうかだけを考える必要はない。重要なのは、その媒体にどの役割を持たせるかを下げることである。主バックアップとして使っていた媒体に疑義が出たなら、まず主バックアップから外す。補助コピーとしてなら使えるかもしれない媒体は、補助用途へ下げる。補助用途としても不安がある媒体は、一時作業用、検証用、消えてよいデータ用へ下げる。それでも読み取り不能や checksum 不一致が出るなら、廃棄または物理破壊を検討する。退役とは、媒体を一気に廃棄することだけではなく、保存用途としての信用度を段階的に下げることである。
| 用途レベル | 使ってよい媒体 | 使ってはいけない媒体 | 判断の考え方 |
|---|---|---|---|
| 主バックアップ | S.M.A.R.T. に重大異常がなく、I/O error がなく、checksum や verify が通り、復元テストにも使える媒体。 | pending sector、uncorrectable error、checksum 不一致、I/O error、増加傾向のある異常値を持つ媒体。 | 必要になったときに最初に頼る媒体なので、疑義がある媒体は置かない。 |
| 補助バックアップ | 過去の軽微な異常があるが増加しておらず、実データ読み出しと checksum が通る媒体。 | 現在も異常値が増える媒体、読み取り不能が出る媒体、復元検証に失敗する媒体。 | 複数コピーの一部としては使えても、唯一の復元元にしてはいけない。 |
| 一時作業用 | 消えてもよい一時データ、検証用データ、再取得可能なデータだけを置く媒体。 | 重要データや唯一コピーを置く用途。 | 保存用途から外した媒体を、失ってもよい用途に限定して使う。 |
| 廃棄 | 保存用途にも一時用途にも使わない媒体。 | 読み取り不能、checksum 不一致、重大な I/O error、認識不安定がある媒体を重要用途へ戻すこと。 | 再利用に伴うリスクが管理価値を上回る場合は退役し、必要に応じて消去または物理破壊する。 |
退役基準は、異常が起きてから感情で決めるべきではない。手元の媒体には愛着が出る。まだ使えるように見える媒体を捨てるのは惜しい。特に大容量 HDD では、少し異常があっても補助用途なら使いたくなる。しかし、バックアップ運用では「まだ読める」ことと「保存用途として信用できる」ことは違う。保存用途の媒体は、必要になったときに読めることが前提である。すでに読み取り不能や checksum 不一致が出ている媒体を、重要データの保存先に残す理由は薄い。
退役基準を事前に決めるには、数値だけでなく増加傾向と実害を見る。Reallocated_Sector_Ct が 0 でないこと自体は注意材料である。しかし、それが長期間固定され、Current_Pending_Sector と Offline_Uncorrectable が 0 で、long test が通り、checksum が一致しているなら、補助コピーとして扱える場合がある。一方、Current_Pending_Sector が 1 でも存在する、Offline_Uncorrectable が出ている、Reported_Uncorrect が増えている、ATA Error Count が増えている、dmesg に I/O error が出る、checksum が一致しない場合は、保存用途から外す判断が妥当になる。
また、退役判断は媒体単体だけでなく、保存構造全体の中で決めるべきである。コピーが複数あり、他に正常な主バックアップと遠隔地バックアップがあるなら、疑義のある媒体を補助用途へ下げる余地はある。逆に、その媒体が唯一のバックアップであるなら、少しの異常でも深刻である。この場合にやるべきことは、異常媒体を延命することではなく、正常媒体へ速やかに再コピーし、バックアップ構成を立て直すことである。
結論として、退役基準はバックアップ・リカバリー戦略の一部である。物理媒体管理では、媒体を導入する基準だけでなく、保存用途から外す基準を持たなければならない。S.M.A.R.T. 悪化、I/O error、checksum 不一致、読み取り不能、復元失敗、接続不安定、暗号鍵管理不能が出た媒体は、役割を下げるか退役する。退役とは敗北ではない。壊れる媒体を前提に、復元可能性を維持するための正常な運用判断である。
13. 媒体台帳を作る
媒体が増えると、記憶だけでは管理できなくなる。外付け HDD が 1 台だけであれば、どこに何を保存したかを覚えていられるかもしれない。しかし、常設 3.5-inch HDD、外付けモバイル 2.5-inch HDD、裸 HDD、NAS、SSD、遠隔地保管媒体、暗号化媒体、古いアーカイブ媒体が混在すると、記憶に頼った管理はすぐに破綻する。どの媒体が主バックアップなのか、どれが遠隔地コピーなのか、どれが古い世代なのか、どれが暗号化されているのか、どれに異常履歴があるのか、どれを退役予定にしていたのかが曖昧になる。
媒体台帳は、単なる所有物リストではない。復旧時に最初に見る運用情報である。障害が起きたとき、人間は落ち着いていない。どの媒体を接続すべきか、どの媒体が最新か、どの媒体は信用してよいか、どの媒体は過去に I/O error が出ていたか、どの媒体のパスフレーズがどこにあるかを、その場で記憶から思い出すのは危険である。媒体台帳は、平常時の整理のためだけでなく、障害時に迷わず復元作業へ入るための入口である。
台帳で最初に決めるべきなのは、媒体 ID である。メーカー型番やシリアル番号は個体識別には有用だが、人間が日常運用で扱う名前としては読みにくい。したがって、HDD-LOCAL-001、HDD-OFFSITE-001、ARCHIVE-2026-001、SSD-TEMP-001 のように、用途が分かる運用名を付ける。媒体本体にも同じ ID をラベルとして貼る。台帳上の ID と物理ラベルが一致していなければ、復旧時に取り違える。媒体台帳は、ファイル上の記録だけでなく、物理媒体に貼るラベルと一体で運用するべきである。
次に必要なのは、媒体の個体情報である。メーカー、モデル、シリアル番号、容量、接続方式、購入日、使用開始日、保証期限を書いておく。これは単なる購買記録ではない。故障時に同一モデルの傾向を調べる、保証交換を検討する、古い媒体の退役時期を判断する、同一ロットや同時期購入媒体への過度な依存を避ける、といった判断に使うためである。特に複数の同型 HDD を同時期に購入している場合、それらは独立コピーに見えても、年齢やロットの面では似た故障傾向を持つ可能性がある。
さらに、用途を明確にする必要がある。媒体にはそれぞれ役割がある。常設ローカルバックアップ、遠隔地バックアップ、オフライン世代、長期アーカイブ、一時作業用、退役予定媒体では、求める信頼性も検査方法も違う。常設媒体なら S.M.A.R.T. 監視や long test を重視する。遠隔地媒体なら最終更新日、最終照合日、暗号化解除確認、保管場所を重視する。アーカイブ媒体なら checksum、保存形式、読み出し確認、媒体更新予定を重視する。用途を書かなければ、その媒体をどの基準で管理すべきかが決まらない。
| 台帳区分 | 記録項目 | 記録内容 | 理由 |
|---|---|---|---|
| 識別情報 | 媒体 ID | HDD-LOCAL-001、HDD-OFFSITE-001、ARCHIVE-2026-001 のような運用名を書く。 | 人間が運用上すぐ識別できる名前を付け、物理ラベルと台帳を対応させるため。 |
| 識別情報 | 型番・シリアル番号 | メーカー、モデル、シリアル番号、容量、接続方式を書く。 | 個体識別、保証確認、同一モデルや同一ロットへの依存確認に使うため。 |
| ライフサイクル | 購入日・使用開始日・保証期限 | 購入した日、バックアップ用途で使い始めた日、保証が切れる日を書く。 | 媒体年齢、交換時期、保証対応、退役予定を判断するため。 |
| 役割 | 用途 | 常設ローカルバックアップ、遠隔地バックアップ、オフライン世代、アーカイブ、一時作業用、退役予定などを書く。 | 用途によって検査方法、更新頻度、保管場所、退役基準が変わるため。 |
| 保存内容 | 保存対象 | 写真、原稿、サーバーバックアップ、設定ファイル、アーカイブ、全体ミラーなど、何を保存しているかを書く。 | 障害時に、どの媒体から何を戻せるかを判断するため。 |
| 保存内容 | 世代情報 | 日次、週次、月次、年次、最新のみ、snapshot あり、archive ありなどを書く。 | 誤削除や破損前の時点へ戻れるかを判断するため。 |
| 更新管理 | 最終更新日 | 最後にバックアップを書き込んだ日、または同期した日を書く。 | RPO と実際のバックアップ鮮度を把握するため。 |
| 検証管理 | 最終照合日 | checksum、backup verify、全ファイル読み出し、scrub、リストアテストを行った日を書く。 | 存在するだけのバックアップを信用せず、読めることと内容の正しさを確認するため。 |
| 媒体状態 | S.M.A.R.T. 要約 | Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable、Reported_Uncorrect、Power_On_Hours、温度、self-test 結果を書く。 | 媒体の劣化傾向、過去の異常、退役判断の材料にするため。 |
| 接続状態 | OS ログ要約 | dmesg や journal に I/O error、USB reset、timeout、disconnect が出たかを書く。 | 媒体本体ではなく、接続経路、ケーブル、電源、USB ケースの問題を見逃さないため。 |
| ファイルシステム | 形式と検査履歴 | ext4、XFS、Btrfs、ZFS、exFAT、NTFS などの形式と、fsck、xfs_repair、scrub の履歴を書く。 | 媒体が正常でもファイルシステム破損で復元できない場合があるため。 |
| 暗号化 | 暗号化方式と鍵管理 | LUKS、BitLocker、FileVault、暗号化なし、パスフレーズ管理方針、キーファイル有無、LUKS header backup 有無を書く。 | 暗号化媒体では、媒体が読めても鍵やヘッダーを失えば復元できないため。 |
| 保管 | 保管場所 | 自宅、別室、実家、職場、貸金庫、クラウド、持ち出し中などを書く。 | 同一拠点喪失を避けられているか、必要時に取り出せるかを判断するため。 |
| 異常履歴 | 事故・異常・交換履歴 | 落下、異音、I/O error、checksum 不一致、USB reset、ケーブル交換、ケース交換などを書く。 | 単発異常と再発傾向を区別し、媒体本体か接続系かを切り分けるため。 |
| ライフサイクル | 次回予定 | 次回更新日、次回照合日、次回持ち帰り日、次回 long test、退役予定日を書く。 | 更新忘れ、照合忘れ、遠隔地媒体の放置、退役判断の先送りを防ぐため。 |
実際の台帳は、最初から複雑にしすぎると続かない。まずは 1 媒体 1 行の一覧表でよい。最低限、媒体 ID、型番、シリアル番号、容量、用途、保存対象、保管場所、最終更新日、最終照合日、暗号化有無、異常履歴、状態を書けばよい。詳細な S.M.A.R.T. 出力や checksum ログまで全部を表に押し込む必要はない。表には要約を書き、詳細ログは別ファイルに保存し、台帳から参照できるようにするのが現実的である。
| 媒体 ID | 用途 | 保存対象 | 保管場所 | 最終更新日 | 最終照合日 | 暗号化 | 状態 |
|---|---|---|---|---|---|---|---|
| HDD-LOCAL-001 | 常設ローカルバックアップ | ホームディレクトリ、サーバーバックアップ、原稿、写真 | 自宅サーバー横 | 2026-05-10 | 2026-05-10 | LUKS | 正常。S.M.A.R.T. 異常なし。月次 long test 対象。 |
| HDD-OFFSITE-001 | 遠隔地バックアップ | 重要データの月次コピー | 実家保管 | 2026-05-01 | 2026-05-01 | LUKS | 正常。コピー後 checksum 照合済み。次回持ち帰り予定は 2026-06-01。 |
| HDD-ARCHIVE-001 | 長期アーカイブ | 過去写真、完成済み原稿、公開済み資料 | 自宅保管箱 | 2026-04-20 | 2026-04-20 | なし | 補助用途。年次読み出し確認対象。 |
| HDD-OLD-001 | 一時作業用 | 消えてもよい一時データ | 作業机 | 2026-03-15 | 2026-03-15 | なし | 退役予定。過去に Reallocated_Sector_Ct あり。重要データ禁止。 |
このような一覧表を作るだけでも、運用はかなり明確になる。どの媒体が主役で、どの媒体が補助で、どの媒体が遠隔地にあり、どの媒体は重要データを置いてはいけないかが一目で分かる。特に重要なのは、状態欄に「正常」だけを書かないことである。正常なら、何を確認して正常と判断したのかを書く。異常があるなら、どの異常があり、重要データ用途に使ってよいのか、補助用途に下げたのか、退役予定なのかを書く。曖昧な「たぶん大丈夫」を台帳に残してはいけない。
媒体ごとの詳細ページを作るなら、さらに具体的に書ける。1 媒体ごとに Markdown ファイルを作り、基本情報、用途、保存対象、暗号化、ファイルシステム、更新履歴、検証履歴、S.M.A.R.T. 要約、異常履歴、退役判断を書く。たとえば、特定の HDD に Reallocated_Sector_Ct が 23 あり、過去に UNC が 5 件あったが、その後 long test が複数回通り、Current_Pending_Sector と Offline_Uncorrectable が 0 で安定しているなら、その経緯を書く。こうすると、後から見たときに「なぜこの媒体を補助用途にしているのか」「なぜ主バックアップから外したのか」が分かる。
| 詳細ページの章 | 書く内容 | 目的 |
|---|---|---|
| 基本情報 | 媒体 ID、メーカー、モデル、シリアル番号、容量、接続方式、購入日、使用開始日を書く。 | 媒体を一意に識別し、物理ラベルと対応させるため。 |
| 用途 | 主バックアップ、遠隔地コピー、アーカイブ、補助用途、一時作業用などを書く。 | この媒体に何を期待してよいかを明確にするため。 |
| 保存対象 | どのディレクトリ、どのバックアップセット、どの世代、どのデータ種別を保存しているかを書く。 | 復旧時に、何をこの媒体から戻せるかを判断するため。 |
| 暗号化と鍵 | 暗号化方式、鍵管理方針、LUKS header backup の有無、復号確認日を書く。 | 媒体が読めても復号できないという失敗を避けるため。 |
| 検査履歴 | short test、long test、checksum、backup verify、scrub、全ファイル読み出し、リストアテストの日付と結果を書く。 | 存在するだけでなく、実際に読める媒体であることを確認するため。 |
| 異常履歴 | S.M.A.R.T. 異常、I/O error、USB reset、落下、異音、checksum 不一致、ケース交換、ケーブル交換を書く。 | 単発異常か再発傾向か、媒体本体か接続系かを判断するため。 |
| 判断 | 現在の評価、用途制限、次回確認日、退役予定を書く。 | 後で見ても、なぜその運用判断をしているか分かるようにするため。 |
台帳には、すべての raw log を貼る必要はない。S.M.A.R.T. の詳細出力、checksum の一覧、バックアップツールのログ、リストアテスト結果は長くなるため、別ファイルに保存したほうがよい。台帳には、そのログへのパス、取得日、要約、判断だけを書く。たとえば、「2026-05-05 smartctl -a 保存済み。Reallocated_Sector_Ct 23、Current_Pending_Sector 0、Offline_Uncorrectable 0、Extended offline completed without error。補助用途として継続」といった書き方でよい。重要なのは、後から判断の根拠を追えることである。
媒体台帳は、バックアップ対象の台帳とも分けて考えるとよい。媒体台帳は「どの媒体があるか」を管理する。バックアップ対象台帳は「何を守るか」を管理する。たとえば、写真、原稿、サーバーバックアップ、設定ファイル、データベース dump、暗号鍵、LUKS header backup、WordPress 原稿、Git リポジトリなどを、どの媒体に、どの頻度で、どの世代で保存するかを別に整理する。媒体台帳だけでは「媒体」は分かるが、「守るべきデータがすべて含まれているか」は分からないためである。
| バックアップ対象 | 保存先媒体 | 更新頻度 | 世代 | 検証方法 | 復元優先度 |
|---|---|---|---|---|---|
| 原稿・ブログ HTML | HDD-LOCAL-001、HDD-OFFSITE-001、クラウド | 日次または作業後 | 日次・週次 | checksum、Git、リストア確認 | 高 |
| 写真 | HDD-LOCAL-001、HDD-OFFSITE-001、HDD-ARCHIVE-001 | 月次 | 月次・年次 | checksum、全ファイル読み出し | 高 |
| サーバーバックアップ | HDD-LOCAL-001、クラウド、HDD-OFFSITE-001 | 日次 | 日次・週次・月次 | backup verify、リストアテスト | 高 |
| 暗号鍵・ヘッダーバックアップ | 暗号化された別媒体、紙または安全な保管先 | 変更時 | 最新版と変更履歴 | 復号確認、保管場所確認 | 最高 |
この 2 種類の台帳を分けると、運用上の抜けを見つけやすい。媒体台帳を見れば、媒体の状態、保管場所、退役予定が分かる。バックアップ対象台帳を見れば、重要データがどの媒体に保存され、どの頻度で更新され、どの方法で検証されているかが分かる。たとえば、媒体は 5 台あるのに、暗号鍵のバックアップ先が 1 つしかない、写真は遠隔地にあるが原稿は遠隔地にない、サーバーバックアップはあるがリストアテストをしていない、といった問題を発見できる。
媒体台帳を作る場所にも注意が必要である。台帳をバックアップ対象媒体の中だけに置くと、その媒体が読めないと台帳も読めない。したがって、台帳は作業端末、印刷または PDF、クラウド、暗号化された別媒体など、複数の場所に置くほうがよい。ただし、保管場所や暗号鍵に関する情報を詳しく書きすぎると、台帳自体がセキュリティリスクになる。媒体の所在や鍵管理方針を書く場合は、台帳自体のアクセス制御や暗号化も考える必要がある。
運用上は、台帳更新をバックアップ作業の一部にするべきである。外付け HDD にコピーしたら、最終更新日を書く。checksum を取ったら、最終照合日を書く。遠隔地へ持っていったら、保管場所と保管開始日を書く。S.M.A.R.T. に異常が出たら、異常履歴を書く。補助用途へ下げたら、用途を変更する。台帳更新を後回しにすると、実際の媒体状態と台帳がずれ、復旧時に使えない情報になる。
結論として、媒体台帳は「どの媒体が信用できるか」を感覚で判断するためのメモではない。媒体 ID、個体情報、用途、保存対象、保管場所、更新日、照合日、暗号化、検査履歴、異常履歴、退役予定を記録し、「どの媒体がどの役割を果たしているか」を管理するための運用基盤である。バックアップ・リカバリー戦略では、媒体を増やすほど台帳の重要性が増す。媒体台帳がなければ、複数媒体は安全性ではなく混乱の原因になる。媒体台帳があれば、媒体の数を復元可能性へ変換できる。
14. 暗号化と鍵管理
遠隔地保管や持ち出し媒体では、暗号化が重要である。外付けモバイル HDD、USB SSD、バックアップ用 SSD、裸 HDD を保管ケースに入れて持ち運ぶ場合、紛失や盗難の可能性を完全には消せない。媒体が第三者の手に渡ったとき、暗号化されていなければ、ファイルシステムをマウントするだけで内容を読まれる可能性がある。したがって、遠隔地保管媒体や持ち出し媒体では、LUKS、BitLocker、FileVault、暗号化バックアップツールなどを使い、媒体を失っても内容を読まれにくくする設計が必要になる。
しかし、暗号化は単純な安全化ではない。暗号化は、盗難や紛失による情報漏えいリスクを下げる一方で、鍵喪失による復元不能リスクを増やす。暗号化していない HDD なら、媒体が読める限り、ファイルシステム修復やデータ救出を試せる余地がある。暗号化媒体では、パスフレーズ、キーファイル、TPM、リカバリーキー、LUKS header、バックアップツールの秘密鍵のいずれかを失うと、媒体本体が完全に正常でもデータを取り出せない。つまり、暗号化した時点で、守るべき対象は媒体だけではなく、鍵、ヘッダー、手順、保管場所へ広がる。
ここでいう鍵は、論理的な鍵だけではない。パスフレーズ、キーファイル、リカバリーキー、秘密鍵、LUKS header backup のような論理的な鍵がある一方で、金庫の鍵、耐火金庫の暗証番号、貸金庫の利用権、保管ケースの鍵、家の鍵、保管場所へ入るための物理的な鍵もある。遠隔地に暗号化 HDD を保管していても、その HDD を入れた金庫を開けられなければ復元できない。逆に、金庫の鍵があっても、暗号化パスフレーズを失っていれば復号できない。復元可能性は、論理鍵と物理鍵の両方が揃って初めて成立する。
したがって、暗号化と鍵管理は、情報セキュリティだけでなく運用設計の問題である。誰が、どの条件で、どの鍵を使い、どの媒体を開き、どの手順で復元できるのかを決めておく必要がある。普段は本人しか開けられないようにするのか、緊急時に家族や管理者がアクセスできるようにするのか、死後や長期入院時に復元可能にするのか、盗難時に絶対に読まれないことを優先するのかで設計は変わる。鍵管理は、単にパスワードを強くすることではなく、アクセス権、保管場所、緊急時手順、漏えい時の影響、喪失時の復元不能性を同時に扱うことである。
LUKS のようなブロックデバイス暗号化では、ヘッダー管理も重要になる。LUKS では、暗号化データ本体だけでなく、ヘッダーと keyslot が復号に必要である。データ領域が無事でも、ヘッダーが破損すれば復号が困難になる。cryptsetup の luksHeaderBackup は、LUKS ヘッダーと keyslot 領域のバイナリバックアップを保存する機能である[17]。ただし、ヘッダーバックアップは強力な復元材料であると同時に、取り扱いを誤れば攻撃面にもなる。したがって、ヘッダーバックアップは、媒体本体とは別に、暗号化された安全な場所、または物理的に保護された場所へ保管する必要がある。
| 管理対象 | 種類 | リスク | 対応 |
|---|---|---|---|
| パスフレーズ | 論理鍵 | 忘れると復元不能になる。短すぎると総当たりや漏えい時のリスクが上がる。 | 十分に強いものを使い、信頼できるパスワード管理方式で保管し、緊急時に参照できる経路を決める。 |
| キーファイル | 論理鍵 | 紛失、破損、保存媒体故障により復号できなくなる。漏えいすれば安全性が下がる。 | 暗号化された別媒体に複製し、保管場所、更新日、照合日を台帳に記録する。 |
| リカバリーキー | 論理鍵 | 印刷物やメモを紛失すると復元不能になり、他人に読まれると復号リスクが生じる。 | 紙、パスワードマネージャー、暗号化ファイル、金庫などに分散して保管し、所在を台帳に記録する。 |
| LUKS header | 論理鍵に近い復号メタデータ | ヘッダー破損でデータ領域が残っていても復号困難になる。ヘッダーバックアップの漏えいは攻撃材料になる。 | luksHeaderBackup を作成し、媒体本体とは別の安全な場所に保管し、復元手順を確認する。 |
| バックアップツールの秘密鍵 | 論理鍵 | borg、restic などの暗号化バックアップで鍵やパスワードを失うと、リポジトリが残っていても復元できない。 | 鍵、設定ファイル、リポジトリ URL、復元コマンド、必要な環境変数を手順書に残す。 |
| 金庫の鍵・暗証番号 | 物理鍵 | 金庫を開けられなければ、媒体、紙のリカバリーキー、ヘッダーバックアップに到達できない。 | 耐火金庫、保管箱、貸金庫などを使う場合は、開錠方法、予備鍵、緊急時アクセス方法を別途管理する。 |
| 保管場所へのアクセス権 | 物理鍵・運用権限 | 実家、職場、貸金庫、別拠点に媒体があっても、必要時に取り出せなければ復旧できない。 | 保管先、連絡先、受け取り方法、本人不在時の扱い、持ち出し記録を台帳に書く。 |
| 復元手順 | 論理鍵と物理鍵をつなぐ運用手順 | 数年後に解除方法、マウント方法、バックアップツールの使い方、鍵の所在を忘れる。 | 復元手順書を残し、定期的に実際に開けるか、読めるか、復元できるかを確認する。 |
鍵管理では、機密性と可用性が衝突する。鍵を 1 箇所にだけ厳重に保管すれば、漏えいリスクは下がる。しかし、その 1 箇所を失えば復元不能になる。鍵を複数箇所に分散すれば、喪失リスクは下がる。しかし、管理が甘い場所に置けば漏えいリスクが上がる。つまり、鍵管理の本質は「絶対に漏らさない」だけでも「絶対に失わない」だけでもない。漏えいしにくく、かつ必要時には確実に取り出せる配置を作ることである。
このため、鍵の置き場所は、媒体の置き場所と同じにしすぎても、完全に切り離しすぎても危険である。暗号化 HDD とパスフレーズを書いた紙を同じポーチに入れて持ち歩けば、紛失時に暗号化の意味が弱くなる。逆に、媒体を遠隔地に置き、鍵の所在を本人しか知らず、本人がアクセス不能になれば、バックアップは残っていても復元できない。実運用では、媒体本体、論理鍵、物理鍵、手順書をどの程度分離し、どの条件で再結合できるようにするかを設計する必要がある。
| 保管設計 | 利点 | 弱点 | 適した用途 |
|---|---|---|---|
| 媒体と鍵を同じ場所に置く | 復元時に迷いにくく、すぐ開けられる。 | 盗難や紛失時に、媒体と鍵を同時に失うため暗号化の効果が弱くなる。 | 低機密データ、一時用途、厳格な機密性より復元速度を優先する用途。 |
| 媒体と鍵を別の場所に置く | 媒体だけ盗まれても復号されにくい。 | 復元時に鍵を探す必要があり、鍵の所在を忘れると復元不能になる。 | 遠隔地保管、持ち出し媒体、個人情報や機密情報を含むバックアップ。 |
| 鍵を複数の安全な場所に分散する | 1 箇所の喪失、火災、紛失、本人不在に強くなる。 | 分散先が増えるほど、漏えい経路や管理ミスも増える。 | 長期アーカイブ、重要データ、家族や組織で復元可能性を確保したい用途。 |
| 金庫や貸金庫に紙のリカバリー情報を置く | 電磁的破損、媒体故障、パスワードマネージャー障害に依存しにくい。 | 物理鍵、暗証番号、利用権、本人確認、緊急時アクセスを管理する必要がある。 | 長期保存、緊急時アクセス、本人以外による復旧可能性を残す用途。 |
物理的な鍵を考えると、金庫や保管箱も媒体管理の一部になる。耐火金庫に外付け HDD、リカバリーキー、LUKS header backup、紙の復元手順書を入れる場合、その金庫自体がバックアップ構成の一部である。耐火性能、耐水性、設置場所、開錠方法、予備鍵、暗証番号、誰が開けられるか、災害時に取り出せるかを考える必要がある。貸金庫を使う場合も同じである。媒体が安全でも、利用者本人しか取り出せず、緊急時にアクセスできなければ、復元可能性は制限される。
また、鍵管理では「誰に復元させるか」という問題も避けられない。完全に個人だけが復元できればよいデータなら、本人だけがパスフレーズを知る設計でもよい。しかし、家族写真、家計資料、サーバー運用情報、事業データ、長期保存資料のように、本人不在時にも必要になる可能性があるデータでは、緊急時アクセスを考える必要がある。これはセキュリティを弱めるという意味ではなく、復元可能性の要件を明確にするという意味である。誰にも開けられない完全な暗号化は、盗難対策としては強いが、継承や緊急復旧には弱い。
暗号化媒体の台帳には、鍵そのものを書いてはいけない場合が多い。しかし、鍵の所在、保管方式、復元に必要な構成要素は書くべきである。たとえば、「HDD-OFFSITE-001 は LUKS で暗号化。パスフレーズはパスワードマネージャー内。紙のリカバリー情報は耐火金庫 A。LUKS header backup は暗号化 USB-KEY-001 とクラウド保管。最終復号確認は 2026-05-10」のように書く。これにより、鍵を台帳へ直接露出させずに、復元時に何を集めればよいかを判断できる。
| 台帳項目 | 書く内容 | 書かないほうがよい内容 | 理由 |
|---|---|---|---|
| 暗号化方式 | LUKS、BitLocker、FileVault、backup tool encryption などを書く。 | 不要な詳細な秘密値。 | どのツールと手順で復号するかを判断するため。 |
| 鍵の所在 | パスワードマネージャー、耐火金庫、貸金庫、暗号化 USB、紙の保管先などを書く。 | 平文のパスフレーズそのもの。 | 台帳漏えい時のリスクを抑えつつ、復元に必要な探索経路を残すため。 |
| ヘッダーバックアップ | LUKS header backup の有無、作成日、保管場所、照合日を書く。 | 保護されていないヘッダーファイルへの不用意な公開パス。 | ヘッダー破損時に復元材料があるかを確認するため。 |
| 物理鍵 | 金庫、保管箱、貸金庫、予備鍵、開錠方法の管理方針を書く。 | 誰でも読める場所への暗証番号の直書き。 | 論理鍵に到達するための物理的な経路を失わないため。 |
| 復元確認 | 最後に実際に復号し、マウントし、ファイルを読めた日を書く。 | 確認していないのに確認済みと書くこと。 | 鍵、媒体、手順が揃って機能することを実証するため。 |
暗号化と鍵管理では、定期的な復号確認も必要である。パスフレーズが正しいか、キーファイルが読めるか、LUKS header backup が存在するか、金庫を開けられるか、紙のリカバリー情報が劣化していないか、バックアップツールが現在の OS で動くかを確認する。鍵管理の失敗は、普段は見えない。媒体が必要になった瞬間に初めて、開かない、鍵がない、手順が分からない、金庫が開かない、という形で発覚する。したがって、暗号化媒体では、保存時だけでなく、定期的に開けることを確認するべきである。
結論として、暗号化媒体では、媒体そのものだけでなく鍵もバックアップ対象になる。さらに、鍵には論理的な鍵と物理的な鍵がある。パスフレーズ、キーファイル、リカバリーキー、LUKS header backup、バックアップツールの秘密鍵だけでなく、金庫の鍵、保管場所へのアクセス権、緊急時の取り出し手順も管理対象である。遠隔地保管媒体は暗号化するべきだが、暗号化した時点で、鍵管理、ヘッダーバックアップ、物理保管、金庫、復元手順、緊急時アクセスまでが物理媒体管理の範囲に入る。
15. 検査頻度と負荷を設計する
検査は多ければよいわけではない。理論上は、すべての媒体に対して毎回 full scan を行い、全ファイルの checksum を照合し、バックアップリポジトリを verify し、リストアテストまで行うのが最も安心に見える。しかし、それを毎回実施すると、時間、騒音、発熱、消費電力、媒体負荷、人間の作業負荷が大きくなり、運用が続かない。逆に、検査をほとんど行わなければ、サイレント破損、読み取り不能、接続不良、古い遠隔地コピー、鍵喪失、復元手順の破綻を見逃す。したがって、検査頻度は理想論ではなく、媒体の役割、更新頻度、データ重要度、実施可能性から設計する必要がある。
検査設計で最初に分けるべきなのは、軽量検査、深掘り検査、履歴監査、実データ照合、復元確認である。軽量検査は、接続直後や日常運用で明白な異常を拾うために行う。深掘り検査は、媒体面や保存領域全体をより広く確認するために行う。履歴監査は、S.M.A.R.T. 属性や error log、self-test log の変化を見るために行う。実データ照合は、媒体が健康かどうかではなく、保存しているファイルが実際に読めて、過去の内容と一致するかを見るために行う。復元確認は、バックアップから本当に戻せるかを確認するために行う。これらを同じ頻度で行う必要はない。
現実的な運用では、検査を階層化するのがよい。接続するたびに行う検査は軽くする。コピー直後には、書いた内容が正しいかを確認する。月次では、主要な S.M.A.R.T. 属性や OS ログを見て、異常の増加傾向を確認する。3 か月から 6 か月に 1 回程度は、常設 HDD で long test、外付け HDD で全ファイル読み出しや checksum 照合を行う。半年から年次では、遠隔地媒体を持ち帰り、照合とリストアテストを行う。つまり、毎回すべてを行うのではなく、検査の重さに応じて頻度を変える。
| 検査種別 | 見るもの | 負荷 | 現実的な使い所 |
|---|---|---|---|
| 軽量検査 | S.M.A.R.T. の主要属性、short test、dmesg、journal、マウント状態を見る。 | 比較的軽い。短時間で終わり、日常運用に組み込みやすい。 | 媒体接続直後、コピー前、月次点検、異常を感じた直後に行う。 |
| 深掘り検査 | long test、full scan、badblocks 相当の読み出し、全領域に近い読み取りを見る。 | 重い。時間がかかり、発熱、騒音、I/O 負荷も大きい。 | 常設 3.5-inch HDD、導入前、疑義発生時、3 か月から 6 か月ごとの定期保守で行う。 |
| 履歴監査 | Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable、Reported_Uncorrect、ATA Error Count、self-test log の変化を見る。 | 軽い。値を取得して前回値と比較するだけなら負荷は小さい。 | 月次または媒体接続時に行い、単発異常と増加傾向を区別する。 |
| 実データ照合 | checksum、backup verify、rsync –checksum、全ファイル読み出し、バックアップツールの check を見る。 | 中から重い。データ量に比例して時間がかかる。 | コピー直後、遠隔地へ持ち出す前、遠隔地から持ち帰った後、外付け HDD の定期確認で行う。 |
| 復元確認 | 実際にファイル、ディレクトリ、設定、データベース、暗号化媒体を復元できるかを見る。 | 人間の作業負荷が大きい。環境準備や手順確認が必要になる。 | 半年から年次、構成変更後、バックアップツール変更後、重要データの保管方式変更後に行う。 |
検査頻度は、媒体の役割ごとに変えるべきである。常設 3.5-inch SATA HDD は、電源、放熱、接続経路が比較的安定しており、S.M.A.R.T. の long test も完走しやすい。そのため、smartd による監視、月次の属性確認、定期的な short test、3 か月から 6 か月ごとの long test、必要に応じた scrub や backup verify を組み合わせる運用が向いている。常設媒体は、いつでも検査できることが強みなので、軽量な監視を継続しつつ、重い検査を低頻度で入れるのが合理的である。
外付けモバイル 2.5-inch HDD は、常設媒体とは考え方を変える必要がある。外付け HDD は、接続されている時間が短く、USB ブリッジ、バスパワー、省電力制御、ケーブル、ホスト側 I/O の影響を受けやすい。long test が Aborted by host になる環境もある。したがって、外付け媒体では long test 完走性だけに依存せず、接続直後の S.M.A.R.T. 要約、dmesg 確認、コピー後の checksum 照合、全ファイル読み出し、バックアップツールの verify を中心にするほうが現実的である。外付け媒体では、媒体自己診断よりも実データが読めることを重視する。
遠隔地保管媒体では、さらに別の制約がある。遠隔地媒体は、頻繁に接続できない。毎月持ち帰れる場合もあれば、半年に 1 回しか確認できない場合もある。そのため、遠隔地媒体では、更新日と照合日を台帳に記録し、持ち出す前に checksum 照合を行い、持ち帰ったときに読み出し確認を行うことが重要になる。理想的には、遠隔地へ持ち出す前に内容照合を済ませ、保管後の次回ローテーション時に再度読めることを確認する。遠隔地媒体は、頻繁な検査ではなく、ローテーションと照合を確実に行うことが中心になる。
| 媒体の役割 | 重視する検査 | 頻度の目安 | 現実的な運用 |
|---|---|---|---|
| 常設 3.5-inch SATA HDD | S.M.A.R.T. 監視、short test、long test、dmesg、scrub、backup verify を重視する。 | 属性確認は月次、short test は月次または隔週、long test は 3 か月から 6 か月ごとを目安にする。 | smartd や cron で軽量監視を自動化し、重い検査は夜間や低利用時間帯に行う。 |
| 外付けモバイル 2.5-inch HDD | 接続直後の S.M.A.R.T. 要約、dmesg、コピー後 checksum、全ファイル読み出しを重視する。 | 接続ごとに軽量確認、コピーごとに照合、3 か月から 6 か月ごとに実データ読み出しを目安にする。 | long test が中断されやすい場合は、実データ照合と OS ログ確認を中心にする。 |
| 遠隔地保管 HDD | 更新前後の checksum、持ち帰り時の読み出し確認、暗号化解除確認、台帳更新を重視する。 | ローテーションごと、または半年から年次の持ち帰り時に確認する。 | 遠隔地へ置く前に照合し、次回持ち帰り時に読めることを確認する。 |
| 長期アーカイブ媒体 | checksum、年次読み出し、ファイル形式確認、暗号鍵確認、媒体更新計画を重視する。 | 年次確認、数年ごとの媒体更新を目安にする。 | 普段は触らず、定期的に読めることと意味が失われていないことを確認する。 |
| 一時作業用媒体 | 最低限の読み書き確認と dmesg 確認を行う。 | 必要時のみ確認する。 | 消えてもよいデータに限定し、重要データの唯一コピーを置かない。 |
検査計画では、実施できることを優先するべきである。たとえば、毎週すべての外付け HDD を接続し、全ファイル checksum を照合し、リストアテストを行う計画は、理屈としては強い。しかし、時間がかかりすぎて続かなければ意味がない。続かない検査計画は、存在しない検査計画と同じである。現実的には、接続直後の軽量確認とコピー直後の照合を必ず行い、重い検査は月次、四半期、半年、年次に分けるほうが継続しやすい。
検査の負荷は、媒体にも人間にもかかる。HDD の long test や全ファイル読み出しは、ディスクを長時間動かし、発熱と I/O 負荷を生む。SSD や NVMe SSD では、読み出し中心の検査は書き込み消耗ほどではないが、発熱やコントローラー負荷はある。ネットワーク越しの verify は帯域を使う。クラウドの復元テストは時間と場合によっては費用がかかる。人間の側にも、接続、マウント、照合、記録、取り外し、遠隔地ローテーションという作業が発生する。検査頻度は、検出精度だけでなく、運用コストとの釣り合いで決める必要がある。
現実的な運用では、自動化できる部分と手動で確認する部分を分ける。S.M.A.R.T. 属性の取得、dmesg の異常確認、バックアップログの保存、checksum 作成、backup verify の実行は、ある程度スクリプト化できる。一方で、遠隔地媒体の持ち出し、金庫からの取り出し、物理ラベル確認、ケーブル交換、異音の確認、実際のリストア判断は、人間の作業が残る。すべてを手動にすると忘れる。すべてを自動化しようとすると、物理媒体や遠隔地保管の現実に合わない。自動化と手動確認を分けて設計することが重要である。
| タイミング | 検査内容 | 目的 | 運用上の注意 |
|---|---|---|---|
| 接続直後 | S.M.A.R.T. 主要属性、short test、dmesg、journal、マウント状態を確認する。 | コピー前に明白な媒体異常、接続不良、USB reset、timeout、I/O error を見つける。 | 時間をかけすぎると運用が重くなるため、毎回見る項目は絞る。 |
| コピー直後 | checksum 照合、rsync dry-run、バックアップツールの verify、コピー件数と容量の確認を行う。 | 書き込んだ内容が期待どおりであり、途中失敗や除外ミスがないことを確認する。 | コピー成功ログだけで満足せず、内容照合またはツール固有の検証を行う。 |
| 月次 | 主要 S.M.A.R.T. 属性、dmesg、journal、バックアップログ、ファイルサンプル読み出しを確認する。 | 異常値の増加傾向、接続不良、定期バックアップの失敗を早めに拾う。 | 台帳に前回値と今回値を記録し、単発異常と進行中の劣化を分ける。 |
| 3 か月から 6 か月 | 常設 HDD では long test、scrub、backup verify、外付け HDD では全ファイル読み出しや checksum 照合を行う。 | 媒体全体または実データ全体が読める状態にあるかを確認する。 | 時間がかかるため、夜間や休日など、失敗しても対応できるタイミングで行う。 |
| 半年から年次 | 遠隔地媒体の持ち帰り照合、暗号化解除確認、リストアテスト、媒体台帳とバックアップ対象台帳の棚卸しを行う。 | 実際に戻せる状態で保管されているか、鍵や手順が失われていないかを確認する。 | 遠隔地媒体は放置されやすいため、カレンダーや台帳で次回確認日を管理する。 |
検査頻度を決めるときは、データ重要度も考慮する必要がある。すべてのデータを同じ頻度で検査する必要はない。作業中の原稿、サーバーバックアップ、暗号鍵、設定ファイルのように失う影響が大きいものは、更新頻度も検証頻度も高める。過去写真や完成済み資料のように更新頻度が低いものは、頻繁な更新よりも、保存時の checksum、年次読み出し、遠隔地保管を重視する。再取得可能なデータや一時データは、強い検査対象から外してよい。検査負荷を重要データへ集中させることが、現実的な運用では重要である。
また、検査結果は必ず台帳へ反映するべきである。検査を実行しても、結果を記録しなければ履歴にならない。Reallocated_Sector_Ct が 23 で固定されているのか、23 から 24 へ増えたのかは、前回値がなければ分からない。long test が通った日、checksum が一致した日、dmesg に USB reset が出た日、ケーブルを交換した日、遠隔地へ持ち出した日を記録することで、単発の異常と再発傾向を分けられる。検査は、実行するだけではなく、履歴として残して初めて判断材料になる。
結論として、検査頻度と負荷の設計では、理想的にすべてを検査することより、継続できる検査体系を作ることが重要である。常設 3.5-inch HDD では S.M.A.R.T. 監視、short test、long test、scrub を中心にする。外付けモバイル 2.5-inch HDD では、long test に固執せず、checksum、実ファイル読み出し、dmesg 確認を中心にする。遠隔地媒体では、ローテーションごとの照合と台帳更新を重視する。軽い検査を頻繁に、重い検査を低頻度に、復元テストを定期的に行う。この配分によって、検査精度と運用継続性のバランスを取ることができる。
16. リストアテストこそ最終検査である
バックアップは、取得できた時点では完成していない。バックアップファイルが存在すること、コピー処理が正常終了したこと、checksum が一致すること、バックアップツールの verify が通ることは、いずれも重要である。しかし、それらは復元可能性を構成する途中段階であって、最終確認ではない。バックアップの目的は、保存済みデータを眺めることではなく、障害時に必要な状態へ戻すことである。したがって、バックアップ運用の最終検査は、媒体検査でも、checksum 照合でも、backup verify でもなく、リストアテストである。
checksum や verify は、リストアテストの前提として重要である。GNU coreutils の sha256sum は SHA256 checksum の出力と照合を行えるため、ファイル内容の同一性確認に使える[18]。BorgBackup の check はリポジトリとアーカイブの整合性を検証する[19]。restic は暗号化と多様な保存先に対応するバックアッププログラムとして、バックアップ運用と検証に使える[20]。これらの検査によって、ファイル内容、バックアップリポジトリ、チャンク、メタデータ、暗号化された保存構造の整合性を確認できる。しかし、整合性が確認できることと、実際のサービスや作業環境が復元できることは同じではない。
たとえば、バックアップツールの check が通っていても、復元先に必要なソフトウェアが入っていなければ復元作業は止まる。ファイルを取り出せても、所有者、権限、SELinux context、ファイルパス、シンボリックリンク、改行コード、文字コード、タイムスタンプが想定どおりでなければ、アプリケーションが動かないことがある。データベースの dump が残っていても、復元順序、文字コード、ストレージエンジン、ユーザー権限、binlog や WAL との整合性を誤れば、正常に起動しないことがある。つまり、リストアテストは、保存されたデータを「使える状態」へ戻せるかを確認する検査である。
リストアテストを一度に完全な災害復旧訓練として行う必要はない。むしろ、現実的には段階を分けるべきである。最初は 1 ファイルを別ディレクトリへ復元するだけでよい。次に、ディレクトリ単位で復元し、階層や権限を確認する。さらに、アプリケーション設定、データベース、サービス全体へ進む。リストアテストを段階化すれば、日常運用に組み込みやすくなり、いきなり大規模復旧訓練を行わなくても、復元経路の弱点を発見できる。
| リストアテストのレベル | 内容 | 確認できること | 現実的な実施場面 |
|---|---|---|---|
| レベル 1 | 任意の 1 ファイルを別ディレクトリへ復元する。 | バックアップ媒体を読めること、暗号化を解除できること、バックアップツールでファイルを取り出せることを確認できる。 | 月次点検、バックアップ方式変更後、媒体交換後に行う。 |
| レベル 2 | ディレクトリ単位で復元する。 | ディレクトリ階層、ファイル名、文字コード、タイムスタンプ、所有者、権限、シンボリックリンクの問題を確認できる。 | 四半期または半年ごとの確認、重要ディレクトリのバックアップ設計変更後に行う。 |
| レベル 3 | アプリケーション設定を復元する。 | 設定ファイル、依存パス、権限、環境変数、サービスユーザー、設定ファイルの配置が成立するか確認できる。 | サーバー構成変更後、OS 更新後、重要アプリケーション更新後に行う。 |
| レベル 4 | データベースを復元する。 | dump、binlog、WAL、文字コード、ユーザー権限、整合性、起動確認、アプリケーションからの接続確認まで確認できる。 | 半年から年次、データベースバージョン更新前後、バックアップ手順変更後に行う。 |
| レベル 5 | 別環境でサービス全体を復旧する。 | RTO、復旧手順、依存サービス、DNS、証明書、ネットワーク設定、ジョブ、監視、運用再開まで確認できる。 | 年次、重要構成変更後、サーバー移行前、災害復旧計画の見直し時に行う。 |
この段階化で重要なのは、レベル 1 やレベル 2 を軽視しないことである。1 ファイルの復元に失敗する環境で、サービス全体の復旧が成功することはない。暗号化媒体を開けない、バックアップリポジトリの場所が分からない、復元コマンドを忘れている、復元先ディレクトリを間違える、権限が崩れる、といった問題は、小さなリストアテストでも発見できる。小さい復元を定期的に行うことは、大きな復旧失敗を防ぐための現実的な手段である。
一方で、ファイル単位の復元だけでは不十分である。特にサーバーデータ、データベース、WordPress、Git リポジトリ、設定ファイル、証明書、cron、systemd unit、ログローテーション、アプリケーション設定を含む環境では、ファイルが戻るだけでは運用は再開しない。データベースが起動するか、アプリケーションが接続できるか、証明書が有効か、権限が正しいか、サービスが自動起動するか、バックアップ取得後の差分をどう扱うかまで確認する必要がある。リストアテストは、ファイルの取り出しから運用再開まで、必要な範囲を段階的に広げるべきである。
リストアテストでは、復元先を本番環境と分けることも重要である。本番ディレクトリへ直接戻すと、誤操作で現在のデータを壊す危険がある。まずは一時ディレクトリ、検証用 VM、別ホスト、コンテナー、検証用データベースへ復元する。そこで内容を確認し、必要なら差分を見て、本番へ戻す手順を考える。バックアップの検査で本番データを壊しては本末転倒である。復元テストには、必ず安全な復元先を用意する。
| 確認項目 | 見る内容 | 失敗例 | 対策 |
|---|---|---|---|
| 復元元 | どの媒体、どのリポジトリ、どの世代、どの snapshot から戻すかを見る。 | 最新コピーしかなく、誤削除前の世代が残っていない。 | 復元対象ごとに、戻せる世代と保持期間を台帳に記録する。 |
| 鍵と認証 | 暗号化パスフレーズ、キーファイル、リカバリーキー、クラウド認証情報を確認する。 | 媒体は読めるが、暗号鍵がなく復号できない。 | 鍵の所在、保管方式、最終復号確認日を台帳に記録する。 |
| 復元コマンド | バックアップツールの復元手順、オプション、対象パスを確認する。 | 取得コマンドは分かるが、復元コマンドや除外条件が分からない。 | バックアップ手順だけでなく、復元手順を手順書として残す。 |
| 権限と所有者 | 所有者、グループ、パーミッション、ACL、SELinux context を確認する。 | ファイルは戻ったが、サービスユーザーが読めずアプリケーションが起動しない。 | 復元後の権限確認コマンドと修復手順を手順書に含める。 |
| アプリケーション整合性 | 設定ファイル、データファイル、データベース、依存サービスの整合性を確認する。 | ファイル単体は戻ったが、データベースやアプリケーションが整合せず起動しない。 | アプリケーション単位の復元手順と起動確認手順を用意する。 |
| 復旧時間 | 実際に復元に何分または何時間かかるかを見る。 | バックアップはあるが、容量が大きく、復元に想定以上の時間がかかる。 | リストアテストで実測し、RTO を現実の値に更新する。 |
リストアテストは、RTO と RPO の現実値を明らかにする。設計上は RTO 4 時間のつもりでも、実際にクラウドから数百 GB をダウンロードすると 1 日以上かかるかもしれない。遠隔地 HDD を取りに行く必要があるなら、その移動時間も RTO に含まれる。RPO についても、台帳上は日次バックアップのつもりでも、最後の成功ログが 2 週間前なら実効 RPO は 2 週間である。リストアテストは、設計上の安心と実際の復旧能力の差を露出させる。
リストアテストの結果は、必ず記録する必要がある。いつ、どの媒体から、どの世代を、どこへ復元し、何を確認し、どこで詰まり、どの手順を修正したかを残す。成功した場合も、所要時間、使用したコマンド、必要だった鍵、復元先、確認したファイル、確認したサービスを書く。失敗した場合は、失敗理由を記録し、バックアップ方式、媒体配置、手順書、鍵管理、検査頻度のどこを修正するかを決める。リストアテストは、一度実施して終わりではなく、運用改善の材料である。
現実的な運用では、すべてのバックアップ対象に対して毎回レベル 5 の復旧訓練を行う必要はない。重要度に応じて頻度を変える。個人の原稿や写真であれば、定期的に数ファイルを復元し、年次でディレクトリ単位の読み出しを確認するだけでも効果がある。サーバーデータやデータベースであれば、半年から年次で検証環境へ復元し、起動確認まで行う価値がある。暗号化媒体では、少なくとも定期的に復号とマウントができることを確認する。リストアテストも、検査頻度と同じく、重要度と実施可能性のバランスで設計するべきである。
結論として、リストアテストは面倒だが、バックアップ運用の最終検査である。S.M.A.R.T. は媒体を見る。checksum は内容を見る。backup verify はバックアップ集合を見る。しかし、リストアテストは、媒体、鍵、ツール、手順、権限、依存ソフトウェア、復元先環境が揃って実際に戻せるかを見る。バックアップ成功ログがあっても、暗号鍵がない、手順がない、ソフトウェアが古い、権限が違う、データベースが起動しない、DNS や設定が戻らないということは起こり得る。物理媒体管理は、媒体の読み出し確認で終わらず、必要な状態へ戻せるかを確認するところまで含めるべきである。
17. 実用的な構成例
実用的なバックアップ構成を考えるときは、最初に個人利用、小規模運用、本番業務を分ける必要がある。個人の写真や原稿を守る構成と、業務データや公開サービスを守る構成では、求められる RPO、RTO、検証頻度、責任範囲が違う。個人利用では、数日から数週間の RPO や、数時間から数日の RTO を許容できる場合がある。一方、本番業務では、日次バックアップだけでは不足する場合があり、データベースのトランザクションログ、継続的な snapshot、別環境への復旧手順、監視、権限管理、責任者、障害時連絡経路まで必要になる。したがって、実用構成は「どの媒体を買うか」ではなく、「どの業務またはデータを、どの障害から、どの時間内に戻すか」から設計するべきである。
個人または小規模運用で現実的な基本構成は、常用データ、ローカルバックアップ、遠隔地バックアップ、追加保険を分けることである。すべてを 1 種類の媒体で満たそうとすると、必ず弱点が残る。内蔵 SSD は日常作業と高速アクセスに強いが、PC ごと故障したり、盗難や火災に遭ったりすれば同時に失う。3.5-inch SATA HDD は容量、常設検査、long test、scrub、ローカル復元速度に強いが、可搬性や遠隔地保管には弱い。外付けモバイル 2.5-inch HDD は持ち運びと遠隔地保管に強いが、USB 接続や long test の完走性では不利な場合がある。クラウドは地理分散に強いが、アカウント停止、課金、帯域、認証、暗号化、削除同期、サービス依存を考慮する必要がある。
この基本構成では、各層に役割を割り当てる。常用データは日々の作業を担当する。ローカルバックアップは高速復元と日常的な世代管理を担当する。遠隔地バックアップは災害、盗難、同一拠点喪失への対策を担当する。追加保険としてのクラウドや別媒体は、物理媒体を同時に失った場合、遠隔地媒体の更新が遅れた場合、あるいは特定データだけを早く取り戻したい場合の補助になる。重要なのは、これらを重複ではなく分担として設計することである。
| 層 | 媒体例 | 役割 | 検査方法 | 注意点 |
|---|---|---|---|---|
| 常用データ | 内蔵 SSD、作業端末、サーバー上の本番データ領域。 | 日常作業、高速アクセス、現在状態の保持を担当する。 | ファイルシステム整合性、作業データのバックアップ対象漏れ、同期状態、アプリケーションログを見る。 | 常用データ自体はバックアップではない。作業しやすさと復元可能性を混同しない。 |
| ローカルバックアップ | 3.5-inch SATA HDD、NAS、ローカルバックアップサーバー、予備 SSD。 | 容量、復元速度、短い RTO、日常的な世代管理、定期検査を担当する。 | S.M.A.R.T.、short test、long test、scrub、checksum、backup verify、dmesg、journal を見る。 | 同一拠点にあるため、火災、水害、盗難、ランサムウェアには別対策が必要になる。 |
| 遠隔地バックアップ | 外付けモバイル 2.5-inch HDD、別拠点保管媒体、貸金庫保管媒体、オフサイト NAS。 | 災害、盗難、同一拠点での同時喪失への対策を担当する。 | コピー後 checksum、全ファイル読み出し、short test、S.M.A.R.T. 要約、暗号化解除確認、台帳更新を行う。 | 更新頻度が低いと RPO が長くなり、取り寄せが必要なら RTO も長くなる。 |
| 追加保険 | クラウドバックアップ、オブジェクトストレージ、別アカウント、別媒体、イミュータブルストレージ。 | 物理媒体喪失、遠隔地媒体の更新遅延、特定ファイルの早期復元、ランサムウェア対策の補助を担当する。 | バックアップログ、復元テスト、暗号化設定、削除保持期間、アクセス権、課金状態を確認する。 | クラウドは万能ではない。アカウント、認証、課金、削除同期、サービス仕様変更に依存する。 |
個人利用では、この 4 層構成を軽量に実装すればよい。たとえば、作業端末の内蔵 SSD を常用データとし、常設 3.5-inch SATA HDD に日次または週次で世代付きバックアップを取り、外付けモバイル 2.5-inch HDD に月次で重要データをコピーして遠隔地へ置き、さらに重要な原稿や設定ファイルだけを暗号化してクラウドにも置く。この構成なら、内蔵 SSD の故障にはローカルバックアップで対応できる。自宅の火災や盗難には遠隔地 HDD またはクラウドで対応できる。誤削除には世代管理で対応できる。クラウドアカウントの問題には物理媒体で対応できる。
ただし、個人利用でも、暗号化と台帳は省略しすぎないほうがよい。遠隔地へ外付け HDD を置くなら暗号化が必要である。暗号化するならパスフレーズ、LUKS header backup、復元手順、金庫や保管場所へのアクセスも管理対象になる。媒体が 3 台以上になるなら、媒体 ID、保存対象、最終更新日、最終照合日、異常履歴、退役予定を台帳に書く必要がある。軽量運用であっても、復元時に何を接続すればよいか分からない構成は危険である。
小規模業務では、個人利用よりも責任範囲が広がる。ファイルサーバー、業務 PC、会計データ、顧客資料、ソースコード、設定ファイル、メール、データベース、Web サイトなど、複数のデータ種別が存在する。ここでは、すべてを同じ頻度で守るのではなく、重要度と更新頻度で分ける必要がある。日次でよいデータ、時間単位で取りたいデータ、月次アーカイブで足りるデータ、法定保存が必要なデータ、暗号化が必要なデータを分類する。媒体構成は、データ分類に従って決めるべきである。
| 運用規模 | 構成例 | 主な狙い | 不足しやすい点 |
|---|---|---|---|
| 個人利用 | 内蔵 SSD、常設 3.5-inch HDD、外付け 2.5-inch HDD、暗号化クラウドを組み合わせる。 | 作業データ、写真、原稿、設定ファイルを媒体故障、誤削除、災害から守る。 | 台帳更新、遠隔地媒体の照合、暗号鍵管理、リストアテストが後回しになりやすい。 |
| 小規模業務 | NAS またはバックアップサーバー、外付け遠隔地媒体、クラウドバックアップ、世代管理を組み合わせる。 | 業務継続、誤削除対策、端末故障対策、拠点喪失対策を両立する。 | 担当者依存、手順書不足、復元テスト不足、権限管理不足が起きやすい。 |
| 本番業務 | 本番ストレージ、ローカル snapshot、バックアップサーバー、オフサイトコピー、イミュータブルコピー、監視、復旧環境を組み合わせる。 | 短い RPO / RTO、ランサムウェア対策、監査可能性、サービス復旧を実現する。 | バックアップ取得だけで満足し、復元手順、依存サービス、DNS、証明書、データベース整合性の検証が不足しやすい。 |
本番業務を想定する場合、物理媒体管理は単なるバックアップ媒体の管理ではなく、サービス継続設計の一部になる。Web サーバー、データベース、アプリケーション、証明書、DNS、ジョブ、監視、ログ、設定管理、秘密情報、デプロイ手順が相互に依存しているため、ファイルだけ戻ってもサービスは復旧しない。データベースなら dump だけでなく、binlog や WAL、トランザクション整合性、復元順序、文字コード、ユーザー権限、アプリケーション接続確認が必要になる。Web サービスなら、DocumentRoot、設定ファイル、TLS 証明書、cron、systemd unit、環境変数、リバースプロキシ設定、DNS 切り替えまで含めて復旧手順を持つ必要がある。
本番業務では、RPO と RTO をデータ種別ごとに分ける。静的ファイルや公開済みコンテンツは日次バックアップでよいかもしれない。データベースは更新頻度によって、数時間単位、数十分単位、あるいはログ単位の復元が必要になるかもしれない。設定ファイルやインフラコードは Git で管理し、変更履歴を追えるようにする。証明書や秘密情報は、バックアップされていないと復旧時に詰まるが、平文で広く複製すると漏えいリスクが増える。したがって、本番業務では、媒体だけでなく、データ種別ごとの復元要件を明示する必要がある。
| 本番業務の対象 | バックアップ対象 | 検証内容 | 復旧時の注意点 |
|---|---|---|---|
| Web コンテンツ | 公開ファイル、アップロードファイル、テーマ、プラグイン、設定ファイル、リダイレクト設定を保存する。 | ファイル復元、権限、所有者、Web サーバーからの読み出し、URL 単位の表示確認を行う。 | ファイルだけでなく、Web サーバー設定、TLS 証明書、PHP やアプリケーション実行環境も必要になる。 |
| データベース | dump、物理バックアップ、binlog、WAL、ユーザー権限、スキーマ情報を保存する。 | 検証環境への復元、整合性確認、アプリケーション接続、文字コード、時点復元を確認する。 | dump があっても、復元順序、バージョン差、権限、ログ適用手順を誤ると正常復旧できない。 |
| 設定・インフラ | Apache、Nginx、systemd、cron、logrotate、firewall、DNS 設定、デプロイ手順を保存する。 | 別環境でサービス起動、設定構文チェック、依存パッケージ、ポート、権限を確認する。 | データが戻っても設定が戻らなければサービスは起動しない。 |
| 秘密情報 | API key、DB password、TLS key、バックアップ暗号鍵、クラウド認証情報を安全に保存する。 | 復元時に参照できるか、漏えいしない保管になっているか、緊急時アクセスがあるかを確認する。 | 秘密情報を失えば復旧不能になり、広く複製しすぎれば漏えいリスクが上がる。 |
| 監視・ジョブ | 監視設定、通知先、バッチ、cron、バックアップジョブ、ログ収集設定を保存する。 | 復旧後に監視が戻るか、定期ジョブが動くか、バックアップが再開するかを確認する。 | サービスが一見復旧しても、監視やバックアップが戻っていないと次の障害を見逃す。 |
本番業務での実用構成では、常設ローカルバックアップとオフサイトコピーに加えて、イミュータブル性またはオフライン性を持つコピーを入れる価値が高い。常時接続されたバックアップは便利だが、ランサムウェア、誤削除、誤同期、管理者権限の侵害に巻き込まれる可能性がある。そのため、オブジェクトロック、WORM 的な保持、削除保護、世代ロック、オフライン媒体、別権限アカウントを組み合わせる。業務用途では、バックアップデータを「保存できること」だけでなく、「攻撃者や誤操作によって同時に消されにくいこと」まで考える必要がある。
また、本番業務では復旧順序を決めておく必要がある。障害時には、すべてを同時に戻すことはできない。まず認証情報とインフラ設定を復旧し、次にデータベースを復元し、その後アプリケーションと Web サーバーを起動し、最後に監視、ジョブ、DNS、証明書、バックアップ再開を確認する、といった順序が必要になる。復旧順序がないと、ファイルは戻ったがアプリケーションが動かない、データベースは戻ったが権限がない、サービスは動いたがバックアップが再開していない、という状態になりやすい。
| 構成要素 | 個人・小規模での役割 | 本番業務での役割 | 検証すべきこと |
|---|---|---|---|
| 常設ローカルバックアップ | 短い RTO を実現し、日常的な復元元になる。 | 一次復旧元、短時間復旧、直近世代の保持を担当する。 | 定期 backup verify、復元テスト、S.M.A.R.T.、scrub、権限確認を行う。 |
| 遠隔地バックアップ | 火災、盗難、水害などの同一拠点喪失に備える。 | 拠点障害、重大インシデント、ローカルバックアップ喪失時の復旧元になる。 | 更新頻度、暗号化解除、取り出し手順、復旧にかかる時間を確認する。 |
| イミュータブルまたはオフラインコピー | 誤削除、誤同期、ランサムウェアへの追加保険になる。 | 侵害時に消されない最後の復元元になる。 | 保持期間、削除保護、復元手順、管理者権限の分離を確認する。 |
| クラウドバックアップ | 物理媒体喪失や遠隔地更新遅延への補助になる。 | 地理分散、迅速な一部復元、別リージョン保管、監査ログの確保に使える。 | 課金、帯域、復元速度、暗号化、アカウント復旧、削除保持を確認する。 |
| 手順書と台帳 | 媒体の所在、更新日、鍵、復元手順を忘れないために使う。 | 担当者不在時でも復旧できるようにする運用資産になる。 | 最新版か、第三者が読んで実行できるか、秘密情報を書きすぎていないかを確認する。 |
実用的な構成では、3.5-inch SATA HDD と外付けモバイル 2.5-inch HDD は競合しない。3.5-inch SATA HDD は、検査しながら守る媒体として使う。常設し、S.M.A.R.T.、long test、scrub、backup verify を行い、ローカルで素早く復元するための媒体にする。外付けモバイル 2.5-inch HDD は、分散して守る媒体として使う。暗号化し、checksum 照合後に遠隔地へ置き、同一拠点喪失への対策にする。クラウドやイミュータブルストレージは、さらに別の故障モードを補う追加層として使う。このように役割を分ければ、単一媒体の弱点を運用系全体で補える。
ただし、構成を複雑にしすぎると運用が破綻する。媒体が多すぎる、バックアップ方式が多すぎる、台帳が更新されない、鍵が分散しすぎる、復元手順が長すぎる、検査頻度が高すぎる構成は、理論上は強く見えても現実には続かない。個人利用では、まず常用データ、ローカルバックアップ、遠隔地バックアップ、追加保険の 4 層を最小構成として作る。小規模業務では、担当者、台帳、復元手順、定期検証を加える。本番業務では、RPO / RTO、監視、イミュータブルコピー、復旧順序、権限分離、定期的なリストアテストまで含める。このように段階的に強化するほうが現実的である。
結論として、実用的な構成とは、最も高価な媒体を選ぶことではなく、媒体ごとの役割を明確にし、障害シナリオごとに弱点を補うことである。内蔵 SSD は作業性、3.5-inch SATA HDD は検査可能性と高速復元、外付けモバイル 2.5-inch HDD は遠隔地分散、クラウドは地理分散と追加保険、イミュータブルコピーは侵害対策、台帳と手順書は復元可能性を支える。個人利用でも本番業務でも、媒体を並べるだけでは足りない。各媒体に役割を割り当て、検査し、記録し、実際に復元できることを確認して初めて、バックアップ・リカバリー戦略として機能する。
18. 情報を物理媒体に固定するということ
ここから少し抽象度を上げる。ここまでの議論は、HDD、SSD、S.M.A.R.T.、checksum、リストアテスト、遠隔地保管、暗号鍵、媒体台帳といった実務の話だった。しかし、その背後には、情報とは何か、記録とは何か、保存とは何か、復元とは何かという、より根本的な問題がある。バックアップ・リカバリー戦略は、単にデータを別の場所へコピーする技術ではない。情報を物理世界の中に固定し、その固定された状態を将来もう一度読み取り、意味ある構造として再構成するための運用である。
情報は抽象的なものに見える。ファイル名、文章、写真、設定、データベース、暗号鍵、ソースコードは、画面上では記号や意味として現れる。しかし、実際には情報は単独では存在しない。HDD 上の磁化状態、SSD 上の電荷状態、光ディスク上のピット、クラウド事業者の分散ストレージ、紙に印字された文字列、金庫に保管されたリカバリーキー、ファイルシステム上の inode、暗号化ヘッダー、バックアップリポジトリのチャンク、読み取り装置、復号ソフトウェア、解釈するアプリケーションに依存している。情報は抽象的に扱えるが、保存されるときには必ず物理的な実装を持つ。
この点を見落とすと、「データはあるはずなのに読めない」という事態が起きる。媒体が物理的に壊れていれば読めない。ファイルシステムが壊れていればファイルとして取り出せない。暗号鍵を失えば復号できない。バックアップツールがなくなればリポジトリを解釈できない。文字コードやファイル形式が分からなければ意味として読めない。つまり、情報は単に物理状態として残っていれば十分なのではない。物理状態、符号化、構造、鍵、手順、解釈系が連結して初めて、情報として再び現れる。
保存とは、情報を何らかの物理状態として固定することである。文章を HTML ファイルとして保存することは、文字列を符号化し、ファイルシステム上のブロックへ配置し、媒体上の物理状態へ落とし込むことである。写真を保存することは、光の分布をセンサーで数値化し、画像形式として符号化し、ファイルとして記録することである。データベースをバックアップすることは、ある時点の関係構造、行、列、インデックス、トランザクションの整合状態を、dump や物理バックアップやログとして固定することである。ここで固定されているのは、単なるビット列だけではなく、将来再構成されるべき構造である。
既稿では、意味は世界に最初から人間向けに埋め込まれているのではなく、差異を読み取り、構造化し、履歴として扱うことから成立すると整理した[21]。この観点から見ると、バックアップとは、意味ある差異を未来へ渡すための物理的な履歴化である。ファイルの内容、ディレクトリ構造、タイムスタンプ、権限、データベースの整合状態、設定ファイル、暗号鍵、復元手順は、どれも差異の集合である。それらが保存され、照合され、再び読み取られることで、単なる物理状態は「復元可能な情報」になる。
| 抽象的な観点 | 実務上の対応 | 意味すること |
|---|---|---|
| 情報は物理媒体に依存する。 | HDD、SSD、クラウド、光ディスク、紙、ファイルシステム、暗号鍵、読み取り装置を管理する。 | 情報は抽象的に扱えるが、保存されるときには必ず物理的な実装を持つ。 |
| 記録は劣化する。 | 定期的に読み出し、checksum、scrub、backup verify、全ファイル読み出しで照合する。 | 物理状態は時間とともに劣化し、保存しただけでは将来の読み出しを保証しない。 |
| 単一実装は失われる。 | 複数媒体、複数拠点、複数世代、オフラインコピー、イミュータブルコピーへ分散する。 | 情報を一つの媒体、一つの場所、一つの時点に閉じ込めると、その実装の喪失とともに情報も失われる。 |
| 復元には解釈系が必要である。 | ファイル形式、バックアップツール、暗号化方式、OS、アプリケーション、手順書を維持する。 | ビット列が残っていても、それを意味ある構造として解釈できなければ復元にならない。 |
| 履歴は現在から再構成される。 | 世代管理、snapshot、ログ、台帳、更新履歴、リストアテストを行う。 | 過去時点そのものが残るのではなく、現在に残された記録から過去の状態を再構成する。 |
| 意味は手順によって再び立ち上がる。 | リストアテスト、鍵管理、復元手順、権限確認、サービス起動確認を行う。 | 保存されたデータは、復元手順を通じて初めて実用上の意味を取り戻す。 |
この表が示しているのは、バックアップが単なる複製ではないということである。コピー先にファイルがあるだけでは足りない。そのファイルが読めること、内容が壊れていないこと、正しい時点の世代であること、復号できること、ファイル形式を解釈できること、アプリケーションが利用できること、必要な権限で配置できること、サービスを再起動できることまで含めて初めて、保存された情報は復元可能な情報になる。情報は物理状態として固定されるが、その物理状態を意味へ戻すには、読み取りと解釈の連鎖が必要である。
バックアップにおける物理媒体管理は、この読み取りと解釈の連鎖を切らさないための管理である。HDD の S.M.A.R.T. を見るのは、磁気媒体としての固定状態が崩れつつないかを見るためである。checksum を取るのは、ビット列の差異が保存時と一致しているかを見るためである。scrub を行うのは、ファイルシステムやストレージプールが保持する整合性を確認するためである。暗号鍵を管理するのは、物理的に残されたビット列を可読な情報へ戻すためである。リストアテストを行うのは、保存された構造が実際の運用状態として再構成できるかを確認するためである。
哲学的に言えば、バックアップとは、情報を時間の中で持続させるための実践である。現在のデータは、そのまま未来へ移動するわけではない。媒体は劣化し、環境は変わり、ソフトウェアは更新され、暗号鍵は失われ、ファイル形式は古くなり、運用者の記憶も薄れる。そのため、未来の時点で同じ情報を再び利用するには、現在の情報を複数の物理媒体へ固定し、検証し、台帳化し、手順化し、必要に応じて新しい媒体や形式へ移し替えなければならない。情報の保存とは、静的な保管ではなく、時間をまたいで読み取り可能性を維持する運用である。
この視点から見ると、遠隔地バックアップも、単なる災害対策ではない。それは、情報を一つの場所、一つの媒体、一つの物理条件から切り離し、複数の実装へ分散させることである。同じデータが内蔵 SSD、常設 HDD、外付け HDD、クラウド、紙の鍵、台帳、手順書に分かれて存在することで、単一の物理的失敗によって意味ある情報全体が失われる可能性を下げる。分散は、単なる冗長化ではなく、情報を未来へ渡すための構造化である。
ただし、分散すれば自動的に安全になるわけではない。分散した情報を再び結合できなければ、復元は成立しない。暗号化 HDD、パスフレーズ、LUKS header backup、金庫の鍵、復元手順書、バックアップツール、復元先環境がばらばらに存在していても、それらの関係が台帳化されていなければ、障害時に再構成できない。したがって、分散と再結合は対である。バックアップは情報を複数の場所へ分散させるが、リストアはそれらを正しい順序で再結合する。
結論として、情報を物理媒体に固定するとは、抽象的な意味を物理状態へ落とし込み、将来もう一度読み取れるようにすることである。バックアップとは、情報を単一の物理媒体から解放し、複数の物理的実装へ分散させ、未来のある時点で再構成できるようにする運用である。これは単なるコピーではない。コピー先が読めること、内容が正しいこと、意味ある構造として解釈できること、必要な時点へ戻れること、鍵と手順が揃っていること、復元後に実際の作業やサービスが再開できることまで含めて初めて、バックアップはバックアップとして成立する。
19. 媒体を信用するのではなく、復元可能な構造を信用する
媒体管理の本質は、特定の HDD や SSD を信用することではない。信頼性の高い媒体を選ぶことは重要である。異常値の少ない HDD、十分な予備領域を持つ SSD、安定した電源、放熱のよい筐体、品質のよいケーブルを選ぶことには意味がある。しかし、どれほど良い媒体を選んでも、媒体は壊れる。接続は切れる。ファイルシステムは破損する。人間は誤削除する。暗号鍵は失われる。バックアップジョブは失敗する。遠隔地媒体は更新されずに古くなる。したがって、信用すべき対象は、個別媒体そのものではなく、個別媒体が壊れても復元できるように設計された構造である。
ここで、前章の「情報を物理媒体に固定する」という話は、運用設計へ直接つながる。情報は抽象的に見えるが、実際には HDD、SSD、ファイルシステム、暗号鍵、台帳、復元手順、読み取り装置、ソフトウェアに依存して存在している。したがって、情報を未来へ渡すには、単に 1 台の媒体へ保存するだけでは不十分である。複数の媒体へ固定し、複数の場所へ分散し、複数の世代として保持し、checksum で照合し、鍵と手順を保管し、リストアテストで再構成できることを確認する必要がある。これは哲学的な抽象論ではなく、そのままバックアップ・リカバリーの運用要件である。
時間を「履歴が増える構造」として見るなら、バックアップはある時点の状態を履歴として固定し、未来の障害時にそこへ戻るための技術である[22]。この視点では、バックアップの価値は、最新コピーがあることではなく、必要な履歴へ戻れることにある。最新ミラーだけでは、誤削除後の状態や破損後の状態も正しく複製してしまう。世代管理、snapshot、archive、バックアップログ、台帳は、時間の中で戻れる地点を残すための構造である。したがって、媒体管理は、媒体を保存する作業であると同時に、復元可能な履歴を維持する作業でもある。
また、単一の物体ではなく、関係、配置、更新、保持、再構成の全体を構造として見るなら、バックアップ・リカバリーは、データを複数の媒体と手順へ分散する構造設計として理解できる[23]。ここでいう構造とは、抽象的な比喩ではない。内蔵 SSD、常設 3.5-inch HDD、外付け 2.5-inch HDD、クラウド、金庫、暗号鍵、LUKS header backup、媒体台帳、復元手順書、リストアテスト結果が、それぞれ役割を持って接続された全体である。この全体が成立していれば、1 台の媒体が壊れても、1 つのコピーが古くても、1 つの接続経路が不安定でも、別の経路から復元できる可能性が残る。
運用設計として重要なのは、信用の対象を「状態」ではなく「構造」に置くことである。S.M.A.R.T. が PASSED であるという状態は参考になる。しかし、それは媒体の自己申告であり、ファイル内容、世代、鍵、復元手順までは保証しない。バックアップ成功ログも参考になる。しかし、それは取得処理が成功したことを示すだけで、実際にアプリケーションが動く状態へ戻せることまでは保証しない。暗号化済み媒体が存在することも参考になる。しかし、鍵、ヘッダー、金庫の鍵、復元手順が揃っていなければ復元できない。したがって、運用で信用すべきなのは、単独の正常表示ではなく、複数の確認手段が組み合わされた復元可能な構造である。
| 信用してはいけないもの | なぜ不十分か | 信用すべき構造 | 運用上の確認方法 |
|---|---|---|---|
| 単一 HDD の健康状態 | HDD が現在正常でも、将来の故障、落下、電源障害、ファイルシステム破損、誤削除には対応できない。 | 複数コピー、複数媒体、遠隔地保管、世代管理を持つ構造を信用する。 | 媒体台帳でコピー数、保管場所、最終更新日、最終照合日を確認する。 |
| S.M.A.R.T. PASSED | 媒体の自己診断としては有用だが、ファイル内容の正しさ、バックアップ世代、復元手順は見ない。 | S.M.A.R.T.、OS ログ、checksum、scrub、backup verify、restore test を組み合わせる構造を信用する。 | 主要属性、dmesg、checksum 照合、バックアップ検証、リストアテストの履歴を確認する。 |
| 最新ミラー | 現在状態の複製には強いが、誤削除、誤上書き、破損、ランサムウェア感染後の状態も複製してしまう。 | 過去時点へ戻れる世代管理、snapshot、archive、保持期間を持つ構造を信用する。 | 削除前、破損前、感染前へ戻れる世代が残っているかを確認する。 |
| 遠隔地媒体の存在 | 遠隔地に媒体があっても、更新されていない、読めない、暗号鍵がない、内容が壊れている場合は復元できない。 | 更新日、照合日、暗号化解除確認、持ち帰り手順、リストアテストまで含む遠隔地保管構造を信用する。 | 遠隔地媒体のローテーション記録、checksum 結果、復号確認日、保管場所を台帳で確認する。 |
| 暗号化済み媒体の存在 | 媒体が残っていても、パスフレーズ、キーファイル、LUKS header、金庫の鍵、復元手順がなければ復元できない。 | 論理鍵、物理鍵、ヘッダーバックアップ、手順書、解除テストまで含む構造を信用する。 | 鍵の所在、ヘッダーバックアップの有無、金庫の開錠方法、最終復号確認日を確認する。 |
| バックアップ成功ログ | バックアップ取得処理の成功は示すが、復元先でアプリケーションやサービスが動くことまでは示さない。 | リストアテスト、権限確認、アプリケーション起動確認、データベース復元確認を含む構造を信用する。 | どの世代をどこへ復元し、どのファイルやサービスを確認したかを記録する。 |
この表を運用設計へ落とすと、媒体管理の基準が明確になる。媒体を買ったかどうかではなく、どの役割を持つ媒体が何系統あるかを見る。コピーがあるかどうかではなく、どの障害に対して独立しているかを見る。バックアップが成功したかどうかではなく、どの時点へ戻れるかを見る。暗号化しているかどうかではなく、鍵とヘッダーと物理保管を含めて開けられるかを見る。検査したかどうかではなく、検査結果を台帳に記録し、増加傾向や退役判断につなげているかを見る。構造を信用するとは、こうした確認点を運用に組み込むことである。
本番業務では、この考え方はさらに重要になる。本番環境では、媒体単体の信頼ではサービス継続を保証できない。データベースの dump があっても、binlog や WAL がなければ目標時点へ戻れない場合がある。ファイルがあっても、証明書、秘密鍵、環境変数、systemd unit、cron、DNS、監視設定がなければサービスは復旧しない。ローカルバックアップがあっても、ランサムウェアで同時に暗号化されるなら最後の復元元にはならない。したがって、本番業務で信用すべきなのは、バックアップファイルではなく、RPO、RTO、世代管理、オフサイト性、イミュータブル性、復旧手順、権限分離、リストアテストが組み合わさった構造である。
個人運用でも本質は同じである。写真、原稿、設定ファイル、ブログ HTML、サーバーバックアップを守る場合、特定の外付け HDD が正常かどうかだけを見ても足りない。常設ローカルバックアップがあるか、遠隔地コピーがあるか、最新ミラーだけでなく過去世代があるか、checksum があるか、暗号化媒体を開けるか、金庫や保管場所へアクセスできるか、台帳に最終更新日と照合日が書かれているか、実際にファイルを戻したことがあるかを見る必要がある。個人運用ではこの構造を軽量に作り、本番業務ではより厳格に作るという違いがあるだけである。
| 運用要素 | 媒体信仰の見方 | 構造としての見方 | 設計上の結論 |
|---|---|---|---|
| 媒体選定 | 壊れにくい HDD や SSD を選べば安全だと考える。 | 媒体は壊れる前提で、複数媒体、複数拠点、複数世代に分ける。 | 高品質な媒体を選びつつ、単一媒体に依存しない構成にする。 |
| 検査 | S.M.A.R.T. が PASSED なら安心だと考える。 | S.M.A.R.T. は入口であり、checksum、OS ログ、verify、restore test と組み合わせる。 | 媒体検査、内容検査、復元検査を分けて定期実行する。 |
| バックアップ方式 | 最新コピーが別媒体にあれば十分だと考える。 | 最新コピー、過去世代、オフラインコピー、遠隔地コピーを役割分担させる。 | 同期、ミラー、バックアップ、アーカイブを分ける。 |
| 暗号化 | 暗号化すれば安全だと考える。 | 暗号化は漏えい対策であり、鍵喪失対策、物理鍵管理、解除テストが必要になる。 | 論理鍵、物理鍵、ヘッダー、手順書、緊急時アクセスを管理する。 |
| 本番復旧 | バックアップファイルがあれば復旧できると考える。 | データ、設定、証明書、秘密情報、依存サービス、DNS、監視、復旧順序が必要になる。 | サービス単位のリストアテストと復旧手順書を持つ。 |
この見方は、退役判断にもつながる。媒体を信用する発想では、少し異常が出ても「まだ読めるから大丈夫」と判断しがちである。しかし、構造を信用する発想では、その媒体がどの役割を担っているかを見て判断する。主バックアップに異常が出たなら、正常媒体へ役割を移す。過去に異常があるが増加していない媒体は、補助コピーへ下げる。checksum 不一致や読み取り不能が出た媒体は、保存用途から外す。媒体そのものに執着するのではなく、復元可能な構造を維持するために役割を入れ替える。
この見方は、検査頻度の設計にもつながる。媒体を信用する発想では、定期的に S.M.A.R.T. を見るだけで安心しやすい。しかし、構造を信用する発想では、検査を役割ごとに分ける。常設 HDD では long test と scrub を行う。外付け HDD では checksum と実ファイル読み出しを重視する。遠隔地媒体では持ち帰り照合と暗号化解除確認を行う。クラウドでは復元テスト、削除保持、アカウント復旧を確認する。検査は媒体ごとの健康診断ではなく、復元構造が機能しているかを確認する作業になる。
さらに、この見方は台帳管理にもつながる。媒体を信用する発想では、台帳は単なるディスク一覧になりがちである。しかし、構造を信用する発想では、台帳は復元可能性の地図になる。どの媒体がどの役割を持ち、どのデータを含み、どの世代を保持し、どこに保管され、いつ更新され、いつ照合され、どの異常履歴があり、どの鍵と手順で開けるのかを記録する。障害時には、この台帳が復元構造を再結合するための入口になる。
哲学との接続は、ここで実務に戻る。情報は物理媒体に固定されるが、単一の固定状態として永続するわけではない。媒体は壊れ、時間は進み、履歴は増え、運用環境は変化する。そのため、情報を保存するとは、単一物体を信用することではなく、変化する時間の中で、再構成可能な履歴構造を維持することである。これは抽象的な思想ではなく、3-2-1、3-2-1-1-0、RPO / RTO、checksum、台帳、鍵管理、リストアテストとして具体化される。
結論として、物理媒体管理は「よいディスクを買う」ことでは終わらない。よいディスクを選ぶことは重要だが、それは復元可能な構造の一要素にすぎない。重要なのは、壊れる媒体、切れる接続、壊れるファイルシステム、失われる鍵、誤る人間、攻撃される環境、変化するソフトウェアを前提に、それでも復元できる構造を設計することである。信用すべきなのは、単一の HDD でも、S.M.A.R.T. PASSED でも、最新ミラーでも、暗号化済み媒体の存在でも、バックアップ成功ログでもない。信用すべきなのは、複数媒体、複数拠点、複数世代、検証、鍵管理、台帳、リストアテストが結びついた、復元可能な構造である。
20. 結論
バックアップ・リカバリー戦略における物理媒体管理とは、HDD や SSD を壊れないものとして扱うことではない。むしろ出発点は逆である。媒体は壊れる。接続は切れる。USB ブリッジやケーブルや電源は不安定になる。ファイルシステムは破損する。暗号鍵は失われる。バックアップジョブは失敗する。人間は誤削除し、誤同期し、台帳更新を忘れ、復元手順を忘れる。さらに、本番業務では、媒体だけでなく、データベース、証明書、秘密情報、DNS、監視、ジョブ、設定ファイル、依存ソフトウェアまで含めて復旧できなければならない。この前提に立つと、物理媒体管理は単なるディスク管理ではなく、データを将来もう一度意味ある形で再構成するための運用設計である[24]。
| 壊れるもの | 起こり得る問題 | 必要な設計 |
|---|---|---|
| 媒体 | HDD 故障、SSD 突然死、代替セクター増加、読み取り不能が起こる。 | 複数媒体、退役基準、S.M.A.R.T. 監視、checksum、リストアテストを用意する。 |
| 接続経路 | USB reset、timeout、ケーブル不良、電源不良、ケース不良が起こる。 | dmesg、journal、別ケーブル、別ポート、別ケースで切り分ける。 |
| 論理構造 | ファイルシステム破損、誤削除、誤同期、破損済みファイルの複製が起こる。 | 世代管理、snapshot、fsck、scrub、backup verify を行う。 |
| 鍵と手順 | 暗号鍵喪失、金庫を開けられない、復元コマンドを忘れる、手順書が古くなる。 | 鍵管理、物理鍵管理、ヘッダーバックアップ、手順書、復号確認を行う。 |
| 本番環境 | ファイルは戻っても、データベース、証明書、DNS、監視、ジョブが戻らない。 | サービス単位の復旧手順、RPO / RTO、別環境リストアテストを用意する。 |
このため、媒体管理の目的は「正常な媒体を持つこと」ではなく、「媒体が壊れても復元できる構造を維持すること」である。S.M.A.R.T. が PASSED であること、short test が通ること、long test が完走すること、エラーログが空であることは重要である。しかし、それだけではバックアップとして十分ではない。S.M.A.R.T. は媒体の内部状態を示すが、ファイル内容の同一性、世代管理、暗号鍵の有無、復元手順、アプリケーション起動確認までは見ない。したがって、S.M.A.R.T. は入口であり、最終判定ではない。媒体検査、OS ログ確認、checksum、scrub、backup verify、リストアテストを組み合わせて初めて、復元可能性を評価できる。
short test、long test、error log、self-test log も、それぞれ役割が違う。short test は軽量なスクリーニングであり、接続直後や日常点検に向く。long test は媒体全体に近い範囲を確認する深い検査であり、常設 3.5-inch SATA HDD では有効である。一方、外付けモバイル 2.5-inch HDD では、USB ブリッジ、省電力、バスパワー、ホスト I/O の影響で long test が中断されることがある。その場合、long test の完走性だけで媒体価値を判断するのではなく、実データ読み出し、checksum 照合、dmesg や journal の確認を重視するべきである。検査方法は媒体の役割に合わせて選ぶ必要がある。
3.5-inch SATA HDD と外付けモバイル 2.5-inch HDD は、どちらが絶対的に信頼できるかで比較するものではない。3.5-inch SATA HDD は、安定電源、放熱、SATA 直結、long test、scrub、常時監視に向いている。したがって、ローカルバックアップや短い RTO を支える媒体として有用である。外付けモバイル 2.5-inch HDD は、小型、軽量、筐体保護、可搬性、遠隔地保管に向いている。したがって、同一拠点喪失への対策として有用である。前者は検査しながら守る媒体であり、後者は分散して守る媒体である。両者は競合せず、役割分担によって補完し合う。
| 要素 | 本文での位置づけ | 最終的な役割 |
|---|---|---|
| S.M.A.R.T.、short test、long test、error log | 媒体の状態や異常履歴を見るための入口である。 | 媒体を信用するためではなく、用途変更や退役判断の材料にする。 |
| 3.5-inch SATA HDD | 常設検査、安定電源、放熱、短い RTO に向く媒体である。 | 検査しながら守るローカルバックアップとして使う。 |
| 外付けモバイル 2.5-inch HDD | 可搬性、筐体保護、遠隔地保管に向く媒体である。 | 分散して守るオフサイトバックアップとして使う。 |
| checksum、scrub、backup verify | 媒体ではなく、保存内容やバックアップ集合の整合性を見る。 | サイレント破損や不完全なコピーを検出する。 |
| リストアテスト | 媒体、鍵、手順、権限、環境が揃っているかを見る。 | バックアップ運用全体の最終検査として機能する。 |
バックアップ設計では、同期、ミラー、バックアップ、アーカイブを混同してはいけない。同期は現在状態を複数場所へ反映する仕組みであり、誤削除や破損も同期する。ミラーは同一内容の代替コピーを持つ仕組みであり、媒体故障には強いが、世代がなければ過去へ戻れない。バックアップは過去時点へ戻るための仕組みであり、世代管理、検証、復元手順が必要になる。アーカイブは長期保存の仕組みであり、媒体寿命、ファイル形式、読み出し装置、暗号鍵、台帳が重要になる。物理媒体を増やすだけでは不十分であり、それぞれの媒体にどの役割を持たせるかを明確にしなければならない。
RPO と RTO は、媒体設計を実務要件へ接続するための軸である。RPO はどの時点まで戻れればよいかを示し、RTO はどれくらいの時間で復旧したいかを示す。RPO を短くしたいなら、自動バックアップ、snapshot、ログ、世代管理が必要になる。RTO を短くしたいなら、ローカルに高速復元できる媒体、復元手順、検証済み環境が必要になる。災害対策を重視するなら遠隔地保管が必要であり、ランサムウェア対策を重視するならオフラインまたはイミュータブルなコピーが必要になる。媒体選定は、容量や価格だけでなく、RPO / RTO と想定障害から逆算するべきである。
復元可能性は、複製数、独立性、世代性、検証性、復元手順性、退役判断によって構成される。コピーが多くても、すべて同じ場所にあり、すべて同期型で、checksum がなく、暗号鍵も不明で、リストアテストもしていないなら、復元可能性は高くない。逆に、コピー数が過剰でなくても、別媒体、別拠点、過去世代、checksum、verify、鍵管理、復元手順、退役基準が揃っていれば、実効的な安全性は高くなる。ここで重要なのは、媒体の数ではなく、復元可能な構造である。
退役基準も、事前に決めておく必要がある。HDD の Reallocated_Sector_Ct が少数あるだけで即廃棄とは限らないが、Current_Pending_Sector、Offline_Uncorrectable、Reported_Uncorrect、ATA Error Count、I/O error、checksum 不一致、long test failure が出る場合は、保存用途としての信頼性を下げるべきである。SSD や NVMe SSD では、available spare、percentage used、media and data integrity errors、critical warning などを見る必要がある。退役とは即廃棄だけではなく、主バックアップから補助用途へ、補助用途から一時作業用へ、一時作業用から廃棄へと役割を下げる判断も含む。危険な媒体を保存系から外すことは、復元可能性を守るための正常な運用である。
媒体台帳は、復旧時の入口である。媒体 ID、型番、シリアル番号、容量、用途、保存対象、保管場所、最終更新日、最終照合日、暗号化方式、鍵の所在、S.M.A.R.T. 要約、OS ログ、異常履歴、退役予定を記録することで、どの媒体がどの役割を持っているかを管理できる。媒体が増えるほど、記憶による管理は破綻する。特に遠隔地媒体、暗号化媒体、古いアーカイブ媒体、退役予定媒体が混在する場合、台帳なしでは復旧時に何を接続し、どの鍵を使い、どの世代を戻せばよいか分からなくなる。台帳は単なるメモではなく、分散した復元構造を再結合するための地図である。
暗号化と鍵管理も、物理媒体管理の一部である。遠隔地保管媒体や持ち出し媒体は暗号化するべきだが、暗号化した時点で、パスフレーズ、キーファイル、リカバリーキー、LUKS header backup、バックアップツールの秘密鍵、復元手順が管理対象になる。さらに、鍵には論理的な鍵だけでなく、物理的な鍵もある。金庫の鍵、貸金庫の利用権、保管場所へのアクセス権、予備鍵、暗証番号、緊急時の取り出し手順も、復元可能性を構成する。媒体があっても鍵がなければ読めない。鍵があっても金庫を開けられなければ到達できない。暗号化は漏えいリスクを下げるが、鍵喪失リスクを増やすため、機密性と可用性の両方を設計しなければならない。
検査頻度と負荷は、現実的に継続できる形で設計する必要がある。毎回すべての媒体に full scan、checksum、verify、リストアテストを行う計画は、理想的に見えても続かなければ意味がない。軽量検査は頻繁に行い、重い検査は月次、四半期、半年、年次に分ける。常設 HDD では S.M.A.R.T. 監視、short test、long test、scrub を中心にする。外付け HDD では、checksum、実ファイル読み出し、dmesg 確認を中心にする。遠隔地媒体では、ローテーションごとの照合、暗号化解除確認、台帳更新を重視する。検査は、精密さだけでなく、運用継続性との釣り合いで設計する必要がある。
リストアテストは、バックアップ運用の最終検査である。S.M.A.R.T. は媒体を見る。checksum は内容を見る。backup verify はバックアップ集合を見る。しかし、リストアテストは、媒体、鍵、ツール、手順、権限、依存ソフトウェア、復元先環境が揃って、実際に必要な状態へ戻せるかを見る。ファイル単体の復元、ディレクトリ単位の復元、アプリケーション設定の復元、データベース復元、別環境でのサービス復旧を段階的に行うことで、バックアップが単なる保存ではなく復旧能力を持っているかを確認できる。バックアップ成功ログがあっても、復元できなければバックアップとしては未完成である。
本番業務では、物理媒体管理はサービス継続設計の一部になる。Web コンテンツ、データベース、設定ファイル、証明書、秘密情報、DNS、cron、systemd unit、監視、ジョブ、ログ、復旧順序まで含めて考える必要がある。ファイルだけ戻っても、データベースが起動しない、証明書がない、秘密情報がない、DNS が切り替わらない、監視が戻らない、バックアップジョブが再開しないなら、業務復旧とは言えない。本番業務では、RPO / RTO、イミュータブルコピー、オフサイトコピー、権限分離、監視、手順書、リストアテストを含めて設計する必要がある。
| 運用領域 | 守るべき対象 | 必要な管理 |
|---|---|---|
| 媒体管理 | HDD、SSD、外付け媒体、NAS、クラウド保存領域を守る。 | S.M.A.R.T.、ログ、温度、接続状態、退役基準を管理する。 |
| 内容管理 | 保存されたファイル、バックアップリポジトリ、データベース dump を守る。 | checksum、scrub、backup verify、世代管理を行う。 |
| 鍵管理 | パスフレーズ、キーファイル、LUKS header、金庫の鍵、保管場所へのアクセスを守る。 | 論理鍵、物理鍵、ヘッダーバックアップ、復号確認を管理する。 |
| 復旧管理 | 必要な状態へ戻すための手順、権限、設定、依存サービスを守る。 | 手順書、台帳、リストアテスト、復旧順序、RPO / RTO を管理する。 |
| 本番業務管理 | サービス継続、業務再開、監視再開、バックアップ再開を守る。 | 別環境復旧、監視、DNS、証明書、秘密情報、ジョブ、権限分離を管理する。 |
より抽象的に言えば、情報は抽象物として存在しているのではなく、常に物理媒体、符号化方式、ファイルシステム、暗号鍵、読み取り装置、ソフトウェア、手順に依存して存在している。保存とは、情報を何らかの物理状態として固定することである。そしてバックアップとは、その物理的実装を単一媒体に閉じ込めず、複数媒体、複数拠点、複数世代、複数手順へ分散し、未来のある時点で再び意味ある構造として再構成できるようにすることである。情報は保存されるだけでは足りない。読めなければならず、照合できなければならず、復号できなければならず、解釈できなければならず、運用状態へ戻せなければならない。
したがって、最終的に信用すべきものは、単一の HDD でも、S.M.A.R.T. PASSED でも、最新ミラーでも、暗号化済み媒体の存在でも、バックアップ成功ログでもない。信用すべきものは、複数コピー、複数媒体、遠隔地保管、世代管理、checksum 照合、S.M.A.R.T. 監視、OS ログ確認、退役基準、暗号鍵管理、物理鍵管理、媒体台帳、リストアテストが結びついた復元可能な構造である。この構造があるからこそ、媒体が壊れても、接続が切れても、拠点を失っても、誤削除しても、攻撃されても、必要なデータを再構成できる可能性が残る。
結論として、バックアップ・リカバリー戦略における物理媒体管理とは、壊れない媒体を探すことではない。壊れる媒体、切れる接続、破損するファイルシステム、失われる鍵、誤る人間、攻撃される環境、変化するソフトウェアを前提に、それでも戻せる構造を維持することである。守るべきものはディスクそのものではない。守るべきものは、データが未来において再び意味ある形で読み出され、復号され、検証され、必要な状態として復元される可能性である。物理媒体管理は媒体の健康管理ではなく、データの生存管理であり、バックアップ・リカバリー戦略は、壊れないものに賭ける設計ではなく、壊れても戻せる構造を作り続ける設計である[25]。
参考文献
- id774, 意味は差異の読み取りから生まれる（2026-05-09）. https://blog.id774.net/entry/2026/05/09/4740/
- smartmontools, smartmontools official site. https://www.smartmontools.org/
- Debian manpages, smartd(8) — smartmontools. https://manpages.debian.org/testing/smartmontools/smartd.8.en.html
- Seagate, SeaTools for Windows User Guide. https://www.seagate.com/support/seatools/seatools_for_windows.pdf
- Western Digital Support, Download, Install, Test Drive and Erase Using Western Digital Kitfox. https://support-en.wd.com/app/answers/detailweb/a_id/51537/~/download%2C-install%2C-test-drive-and-erase-using-western-digital-kitfox
- Seagate, SeaTools 5 User Guide. https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/support-content/downloads/seatools/_shared/downloads/100869623_B.pdf
- Backblaze, Hard Drive SMART Stats and Failure Rates. https://www.backblaze.com/docs/cloud-storage-hard-drive-smart-stats-and-failure-rates
- Backblaze, Backblaze Drive Stats for 2025. https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/
- NIST, SP 800-209, Security Guidelines for Storage Infrastructure. https://csrc.nist.gov/pubs/sp/800/209/final
- NIST, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- CISA, Back Up Government Data. https://www.cisa.gov/audiences/state-local-tribal-and-territorial-government/secure-us-sltt/back-government-data
- Veeam, 3-2-1 Backup Rule Explained. https://www.veeam.com/blog/321-backup-rule.html
- AWS, Security Incident Response Guide — Recovery. https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-security-incident-response-guide/recovery.html
- AWS, Recovery objectives. https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/recovery-objectives.html
- IBM, Backup Requirement Analysis. https://www.ibm.com/docs/en/wam/wm-api-control-plane/11.1.0?topic=management-backup-requirement-analysis
- NVM Express, Features for Error Reporting, SMART, Log Pages, Failures and Management Capabilities in NVMe Architectures. https://nvmexpress.org/resource/features-for-error-reporting-smart-log-pages-failures-and-management-capabilities-in-nvme-architectures/
- man7.org, cryptsetup-luksHeaderBackup(8). https://man7.org/linux/man-pages/man8/cryptsetup-luksHeaderBackup.8.html
- man7.org, sha256sum(1) — compute and check SHA256 message digest. https://man7.org/linux/man-pages/man1/sha256sum.1.html
- BorgBackup documentation, borg check. https://borgbackup.readthedocs.io/en/stable/usage/check.html
- restic documentation, Introduction. https://restic.readthedocs.io/en/stable/010_introduction.html
- id774, 世界がなぜ意味を持つのか（2026-01-02）. https://blog.id774.net/entry/2026/01/02/3191/
- id774, 時間はなぜ一方向に進むのか（2026-04-26）. https://blog.id774.net/entry/2026/04/26/4613/
- id774, 宇宙を構造として再定義する（2026-03-27）. https://blog.id774.net/entry/2026/03/27/4171/
- id774, タイタニック号事故から読み解く巨大システム運用の本質（2026-05-02）. https://blog.id774.net/entry/2026/05/02/4656/
- id774, バックアップとは復元可能性を設計することである（2026-05-07）. https://blog.id774.net/entry/2026/05/07/4728/