LUKS + ext4 は、Linux 上で暗号化バックアップ媒体を扱うには自然な形式である。既稿では、LUKS の作成、解除、ファイルシステム作成、マウント、ヘッダーバックアップ、鍵管理を一体の運用として整理した[1][2]。また、暗号化ディスクは作った時点で終わるのではなく、長期にわたり開ける状態、読める状態、移行できる状態、退役できる状態を維持する必要があると確認した[3]。さらに、具体的な運用手順として、通常運用、点検、復旧、退役までを一つのライフサイクルとして扱うべきだと整理した[4]。
本稿の主題は、その方針を崩さずに、macOS から外付け LUKS + ext4 媒体をどう読み取るかである。結論を先に述べると、媒体形式は変更しない。VeraCrypt や exFAT に寄せるのではなく、macOS 上に Debian 仮想マシンを用意し、その Debian に LUKS と ext4 を扱わせる。Mac は仮想化ホスト、確認端末、必要に応じた取得先として使い、暗号化層とファイルシステム層は Linux に処理させる。
本稿は、LUKS + ext4 媒体を macOS 向け形式へ変換するものではない。既存の LUKS + ext4 形式を維持したまま、Mac 上の Debian VM を使って読み取り専用で開くための汎用手順を整理するものである。用途は特定の障害時に限らず、内容確認、設定ファイルの参照、ディレクトリ構成の確認、一部ファイルの取得、バックアップ内容の検証、現在のファイルとの比較などを含む。ただし、書き込み同期、修復、整理、削除、権限変更は扱わない。
この方式は、Finder で自然に開くための方法ではない。外付け HDD を Mac に接続し、VirtualBox 上の Debian VM へ渡し、読み取り専用で LUKS を開き、ext4 を読み取り専用でマウントし、必要な範囲を確認または取得するための手順である。主張は、Mac を正本運用環境にすることではない。LUKS + ext4 の正本性を保ちながら、macOS 側にも読み取り経路を持つことである。
1. Mac では LUKS + ext4 をそのまま読めない
外付け HDD を Mac に接続したとき、通常の APFS、Mac OS 拡張、FAT、exFAT のような媒体であれば、ディスクユーティリティや Finder から扱える。Apple のディスクユーティリティ文書でも、macOS が扱うファイルシステム形式として APFS、Mac OS 拡張、MS-DOS FAT、ExFAT が説明されている[5]。ここに LUKS や ext4 は登場しない。つまり、Mac に挿しただけで LUKS + ext4 媒体を普通の外付けディスクとして読めるわけではない。
この問題は、一つの原因ではなく、二つの層が重なっている。第一に、LUKS は Linux の暗号化ブロックデバイス形式であり、cryptsetup と dm-crypt によって開くことを前提にしている。第二に、ext4 は Linux で広く使われるファイルシステムであり、macOS の標準ファイルシステムではない。したがって、暗号化層とファイルシステム層の両方が macOS 標準の対象外になる。
| 層 | 役割 | macOS 標準での扱い |
|---|---|---|
| 物理ディスク | USB や Thunderbolt、または SATA 変換を通じて接続される外付け HDD である。 | デバイスとしては認識される場合がある。 |
| LUKS | ディスク上のブロックデバイスを暗号化する層である。 | 標準機能だけでは自然に開けない。 |
| ext4 | LUKS を開いた後に現れる Linux のファイルシステムである。 | 標準機能だけでは Finder で自然に読めない。 |
| ファイル | 実際に取り出したい文書、写真、設定、バックアップデータである。 | 上位の二層を通過できなければ到達できない。 |
ここで重要なのは、Mac から読めないことを、ただちに媒体設計の失敗とみなさないことである。LUKS + ext4 は、Mac 用の外付けディスク形式ではない。Linux で正本運用するための形式である。したがって、問題は「Mac で読めないから形式を変えるべきか」ではなく、「正本媒体の形式を維持したまま、Mac 側に読み取り経路を追加できるか」である。
2. 形式を変えるのではなく、読み取り環境を追加する
Mac で LUKS + ext4 の外付け媒体をそのまま読めないとき、最初に考えたくなるのは、媒体形式そのものを変えることである。たとえば、暗号化層を VeraCrypt にすれば macOS や Windows から開ける可能性は上がる。ファイルシステムを exFAT にすれば、Mac でも Windows でも日常的に読み書きしやすくなる。商用の ext4 ドライバを導入すれば、Mac の Finder に近い操作感で ext4 を扱える可能性もある。しかし、この発想は、問題を少し早く単純化している。読めないという現象だけを見ると媒体形式の変更が解決策に見えるが、バックアップ媒体の役割まで含めて見ると、変更してよい層と、変更しないほうがよい層を分けて考える必要がある。
バックアップ媒体では、媒体そのものが健康であることだけでなく、必要な時点で復元できることが重要である。既稿では、物理媒体管理を、HDD の良し悪しだけではなく、鍵、手順、検証履歴、復元可能性を含む運用設計として整理した[6]。この観点に立つと、Mac で直接読めないという理由だけで媒体形式を変えるのは早い。なぜなら、媒体形式を変えることは、単に Mac から見えるようにするだけの変更ではなく、バックアップが何をどこまで忠実に保存するかを変える操作でもあるからである。
ここで分けるべきなのは、暗号化層、ファイルシステム層、読み取り環境の三つである。LUKS は暗号化層であり、媒体が流出したときに内容を読みにくくする。ext4 はファイルシステム層であり、所有者、グループ、パーミッション、シンボリックリンクなどの Unix 的な情報を保持する。Mac や Debian VM は読み取り環境であり、その媒体をどの OS とどの手順で開くかを決める。Mac で読めないという問題は、必ずしも暗号化層やファイルシステム層を変えなければ解けない問題ではない。読み取り環境を追加することで解ける場合がある。
| 層 | 役割 | 変更した場合の影響 |
|---|---|---|
| 暗号化層 | LUKS、VeraCrypt などにより、媒体単体から内容を読みにくくする層である。 | 形式を変えると、開くためのソフトウェア、鍵管理、復旧手順、既存運用との互換性が変わる。 |
| ファイルシステム層 | ext4、exFAT、APFS などにより、ファイル名、ディレクトリ、属性、空き領域を管理する層である。 | 形式を変えると、権限、所有者、シンボリックリンク、rsync の意味が変わる。 |
| 読み取り環境 | Linux 実機、macOS、Debian VM など、媒体を開く OS と手順の組み合わせである。 | 環境を追加しても、媒体そのものの保存形式は変わらない。 |
本稿で重視するのは、媒体形式を Mac に寄せることではない。目的は、Linux 用の正本バックアップ媒体を LUKS + ext4 のまま維持し、macOS から読み取り用途で扱える補助経路を確保することである。つまり、Mac を日常的なバックアップ運用環境にするのではなく、内容確認、参照、比較、一部取得、検証などに使える読み取り環境として位置づける。この違いを曖昧にすると、Mac から便利に使えることを優先して、正本媒体として保持すべき情報を削ってしまう。
| 方式 | 利点 | 問題点 | 本稿での扱い |
|---|---|---|---|
| LUKS + ext4 | Linux での暗号化、マウント、権限保持、rsync 運用に自然に接続できる。 | macOS からは標準機能だけで自然に読めない。 | 維持する正本形式である。 |
| VeraCrypt + ext4 | 暗号化層の可搬性は上がる。 | 中身が ext4 である限り、Mac が標準で扱えない問題は残る。 | 検討対象ではあるが、本稿では採用しない。 |
| VeraCrypt + exFAT | 異なる OS 間での日常的な読み書きはしやすい。 | Unix 権限、所有者、シンボリックリンクの保持を弱める。 | 正本バックアップ媒体の目的には合わない。 |
| 商用 ext4 ドライバ | Mac から Finder に近い操作感で ext4 を扱える可能性がある。 | 追加費用と低レベルドライバ導入を伴い、保全媒体への書き込みリスクも別途評価が必要になる。 | 本稿では採用しない。 |
| Debian VM | 媒体形式を変更せず、Linux の標準的な処理系で LUKS と ext4 を扱える。 | 手順は重く、Finder で自然に扱える方法ではない。 | 読み取り用の補助経路として本稿で採用する方式である。 |
この表で重要なのは、Debian VM 方式が最も便利だから採用するのではないという点である。便利さだけを見れば、Mac から直接扱える形式に寄せたほうがよい。しかし、正本バックアップ媒体では、便利さよりも、保存すべき情報を失わないこと、既存の Linux 運用と矛盾しないこと、復元時に同じ意味で読み戻せることが重要である。Debian VM 方式は、Mac での操作感を犠牲にする代わりに、媒体形式を変更しない。ここに採用理由がある。
自由ソフトウェアだけで暗号化媒体を扱う範囲については、既稿で、Debian パッケージとして導入できる cryptsetup と Linux カーネルの device-mapper 系機能により、LUKS や dm-crypt などを実用的に扱えることを整理した[7]。また、TrueCrypt 旧資産についても、主系として再採用するのではなく、既存資産の読み取り経路として位置づけるべきだと確認した[8]。本稿はこの流れを受け、暗号化形式を増やすのではなく、既存の LUKS + ext4 を読む環境を Mac 側に追加する。
したがって、本稿の判断は「Mac で読めないなら形式を変える」ではない。判断は、「正本媒体は LUKS + ext4 のまま維持し、Mac 側には Linux 読み取り環境を追加する」である。この切り分けにより、Linux 上でのバックアップ運用、権限保持、暗号化媒体管理を崩さずに、macOS から確認、参照、比較、一部取得、検証を行う経路を増やせる。媒体形式を変えるのではなく、読み取る側の環境を足す。これが本稿の基本方針である。
3. 本稿で扱う読み取りユースケースを明確にする
ここで、本稿が扱う用途を明確にしておく。Mac 上に Debian VM を用意して LUKS + ext4 媒体を読む、という説明だけでは、用途が曖昧になりやすい。単に障害時の取得だけを想定しているのか、日常的な Finder 的操作まで想定しているのか、同期や修復まで含めるのかが見えにくい。本稿で扱うのは、macOS から LUKS + ext4 媒体を読み取り専用で扱うための汎用手順である。
汎用手順というのは、何でも行うという意味ではない。むしろ逆である。用途は複数に広げるが、操作は読み取りに限定する。たとえば、バックアップ内に必要なファイルがあるか確認する、過去の設定ファイルを読む、現在のファイルとバックアップ内のファイルを比較する、必要なディレクトリだけを Mac 側へコピーする、といった用途は本稿の対象である。一方、Mac 側から LUKS + ext4 媒体へ書き戻す、同期する、削除する、移動する、権限を変更する、fsck で修復する、といった用途は対象外である。
この線引きが必要なのは、raw disk access が物理ディスクを VM に直接見せる操作だからである。読み取りだけであっても、対象ディスクの取り違え、ホストとゲストの同時アクセス、VM の停止、USB 切断、Mac のスリープなどには注意が必要になる。まして書き込み運用まで含めると、事故要因は大きく増える。したがって、本稿では、読み取り用途には広く対応し、書き込みを伴う運用は明確に外す。
| 用途 | 内容 | 本稿での扱い |
|---|---|---|
| 内容確認 | 媒体内に必要なディレクトリやファイルが存在するかを確認する。 | 対象に含める。 |
| 設定ファイル参照 | 過去の設定、構成、ログ、文書などを読む。 | 対象に含める。 |
| 一部ファイル取得 | 必要なファイルやディレクトリだけを Mac 側へコピーする。 | 対象に含める。 |
| バックアップ内容の検証 | 代表的なファイルが読めるか、サイズやチェックサムを確認する。 | 読み取り範囲で対象に含める。 |
| 比較 | 現在のファイルとバックアップ内のファイルを比較する。 | 読み取り範囲で対象に含める。 |
| 障害時の取得 | Linux 実機が使えない場面で必要なファイルを取得する。 | 対象に含めるが、唯一の用途ではない。 |
| 同期 | Mac 側から媒体へ書き戻す。 | 対象外とする。 |
| 修復 | fsck や journal replay によって媒体状態を変更する。 | 対象外とする。 |
| 整理 | 削除、移動、リネーム、権限変更を行う。 | 対象外とする。 |
この章を置く理由は、後続の手順を誤解しないためである。読み取り専用で LUKS を開き、ext4 を ro,noload でマウントするのは、特定の障害時だけを想定しているからではない。Mac 上の VM から物理媒体を扱う以上、読み取り用途であっても元媒体を不用意に変更しないことを優先するからである。したがって、本稿の主張は、「緊急時にだけ使う手段」ではなく、「読み取り用途に広く使えるが、書き込み運用には使わない手順」である。
4. LUKS + ext4 を維持する理由
LUKS + ext4 を維持する理由は、暗号化方式の好みではない。Linux のバックアップ媒体として、データ本体だけでなく、所有者、グループ、パーミッション、シンボリックリンク、ディレクトリ構造を自然に保存できるからである。バックアップは、単にファイル名とファイル内容を別の場所へ置く作業ではない。復元したときに、実行権限、所有者、設定ファイルの配置、リンク構造まで含めて意味のある状態に戻せなければならない。
たとえば、実行ファイルから実行権限が落ちていれば、ファイルの内容が残っていてもそのままでは動かない。設定ファイルの所有者が変わっていれば、サービスが起動しないことがある。シンボリックリンクが通常ファイルとしてコピーされていれば、参照関係が壊れる。ディレクトリ構造が残っていても、権限や所有者の意味が失われれば、復元後のシステムは元の状態と同じではない。したがって、Linux のバックアップでは、ファイルの中身だけでなく、そのファイルが Linux 上でどのような意味を持っていたかを保存する必要がある。
この点で、ext4 は Linux 正本媒体として扱いやすい。ext4 は Linux で広く使われるファイルシステムであり、所有者、グループ、パーミッション、シンボリックリンク、デバイスファイルなどの Unix 的な情報を自然に扱える。rsync のアーカイブモードを使う場合も、こうしたメタデータを保持する前提と相性がよい。つまり、ext4 は単にファイルを置く箱ではなく、Linux 上でファイルが持っていた意味を保つための形式でもある。
一方、exFAT のような異 OS 可搬性を重視したファイルシステムでは、Mac や Windows からの日常的な読み書きはしやすくなる。しかし、その便利さは、Linux の所有者、パーミッション、シンボリックリンクを同じ意味で保持できることを保証しない。Mac で扱いやすくするためにファイルシステムを変えると、バックアップ媒体として保存したい意味が削られる可能性がある。ここで問題になるのは、読めるかどうかだけではない。読めたとしても、復元したときに Linux 上で同じ意味に戻るかどうかである。
| 対象 | 保存したい意味 | 失われた場合の問題 |
|---|---|---|
| 所有者 | どのユーザーがそのファイルを所有しているかを示す。 | 復元後にサービスやユーザーが必要なファイルを扱えなくなる可能性がある。 |
| グループ | 複数ユーザーやサービス間でのアクセス範囲を示す。 | 共有前提のファイルが読めなくなったり、逆に意図しない範囲へ開いたりする可能性がある。 |
| パーミッション | 読み取り、書き込み、実行の可否を示す。 | 実行すべきファイルが実行できなくなり、保護すべきファイルが不用意に読める状態になる可能性がある。 |
| シンボリックリンク | ファイルやディレクトリの参照関係を示す。 | リンク構造が壊れると、設定、ライブラリ、データ参照の位置関係が復元できなくなる可能性がある。 |
| ディレクトリ構造 | ファイル群がどの位置関係で意味を持つかを示す。 | ファイル単体は残っていても、アプリケーションや運用手順から見た意味が失われる可能性がある。 |
暗号化層についても同じことが言える。LUKS は Linux 側で cryptsetup と dm-crypt に自然に接続できる。暗号化されたブロックデバイスを開き、その上に ext4 をマウントし、必要に応じて点検し、アンマウントし、閉じる。この流れが Linux の通常運用として成立している。つまり、LUKS + ext4 は、暗号化とファイルシステムを別々の層として扱いながら、Linux 上では一貫した手順で運用できる。
この一貫性は、長期運用では重要である。バックアップ媒体は、一度作って終わりではない。定期的に同期し、読み取れることを確認し、ディスクの状態を点検し、容量が不足すれば移行し、古くなれば退役させる必要がある。その過程では、暗号化ヘッダー、パスフレーズ、マウント手順、fsck、rsync、権限正規化、媒体台帳が互いに接続する。LUKS + ext4 を維持するという判断は、単に形式を固定するという話ではなく、この運用全体を Linux 側で一貫させるという判断である。
この問題は、データサーバー運用の前提とも接続する。既稿では、暗号化された複数の HDD を直接扱う Linux データサーバーでは、SATA 直結、HDD ベイ、S.M.A.R.T.、ケーブル追跡性、ディスク交換の作業空間が効いてくると整理した[9]。これは、暗号化媒体の運用がソフトウェアだけで完結しないことを示している。どのディスクをどのポートにつなぎ、どの媒体をどの手順で開き、異常時にどのディスクを外して検査するかという物理的な扱いまで含めて、バックアップの復元可能性は決まる。
本稿で扱う Mac + Debian VM 方式は、その Linux 実機運用を置き換えるものではない。Linux 実機は、通常の同期、点検、修復、移行、退役を担う正本運用環境である。Mac + Debian VM は、macOS から読み取り用途で LUKS + ext4 媒体へアクセスする補助経路である。この二つを混同すると、Mac 側から日常的に書き込みたくなる。しかし、それは本稿の目的ではない。
| 観点 | LUKS + ext4 を維持する意味 | Mac 側で補う範囲 |
|---|---|---|
| 暗号化 | LUKS、cryptsetup、dm-crypt の標準的な Linux 運用に接続できる。 | Debian VM 内で cryptsetup を使い、既存の LUKS 媒体を読み取り専用で開く。 |
| ファイルシステム | ext4 により、Linux の所有者、権限、リンク構造を自然に保持できる。 | Mac が ext4 を直接扱うのではなく、Debian VM 内の Linux カーネルに扱わせる。 |
| 復元可能性 | 通常運用、点検、fsck、移行、退役を Linux 側で一貫して扱える。 | Mac 側では修復や正本同期を行わず、必要なファイルの読み取りに限定する。 |
| 操作性 | Linux 実機では、lsblk、cryptsetup、mount、rsync などの標準的な道具で扱える。 | Mac 側では Finder 的な自然さを求めず、VirtualBox と Debian VM による手順化で補う。 |
| 媒体管理 | SATA 直結、S.M.A.R.T.、ディスク交換、ケーブル追跡性などの物理運用と接続できる。 | Mac 側では読み取り用途に限定し、恒常的な媒体管理は Linux 実機に残す。 |
したがって、LUKS + ext4 を維持するという判断は、Mac を無視する判断ではない。むしろ逆である。正本媒体を Linux に最適化したまま維持し、Mac にはその媒体を直接変形させずに読むための補助環境を用意する。媒体形式を Mac に寄せるのではなく、Mac 上に Linux 読み取り環境を置く。これにより、保存すべき情報の意味を削らずに、読み取りアクセス経路だけを増やせる。
この章で確認したことは、本稿全体の前提になる。LUKS + ext4 は、Mac から直接扱いやすい形式ではない。しかし、Linux の正本バックアップ媒体としては、暗号化、権限保持、復元可能性、物理媒体管理に接続しやすい形式である。だから本稿では、媒体形式を変更しない。変更するのは媒体ではなく、Mac 側の読み取り環境である。
5. Mac 上に Debian VM を用意する
本稿で採用する構成は、Mac に LUKS や ext4 を直接理解させるものではない。Mac 上に Debian VM を作り、その Debian に Linux として LUKS と ext4 を扱わせる。つまり、macOS の機能を増やして Linux のファイルシステムを読ませるのではなく、macOS の中に Linux 環境を用意し、その Linux 環境に既存媒体を読ませる。この違いは重要である。前者は Mac 側へファイルシステム対応を追加する発想であり、後者は媒体形式を変えず、読み取り環境だけを追加する発想である。
VirtualBox は、macOS、Linux、Windows などのホスト OS 上で仮想マシンを動かすためのソフトウェアであり、Oracle のダウンロードページでは macOS 用のパッケージも提供されている[10]。VirtualBox の導入自体は、Oracle のインストール文書に従う[11]。ここで VirtualBox を使う目的は、Debian を日常利用することではない。LUKS + ext4 の外付け媒体を、必要なときだけ Linux の標準的な道具で読み取るためである。
Debian は、LUKS と ext4 を扱うための小さな作業環境として使う。Debian VM は、通常の Linux サーバー運用を置き換えるものではない。通常の同期、点検、修復、移行、退役は Linux 実機で行う。Mac 上の Debian VM は、外付け LUKS + ext4 媒体を macOS から読み取り用途で扱うための Linux 作業環境である。この位置づけを曖昧にすると、Mac 側から書き込み同期や修復を行いたくなる。しかし、本稿で扱う Debian VM は、書き込み・同期・修復を担う環境ではなく、読み取り専用の補助環境である。
この構成では、Mac、VirtualBox、Debian VM、外付け HDD の役割を分ける必要がある。Mac は物理マシンであり、外付け HDD を接続し、VirtualBox を起動し、読み取り結果の確認端末になり、必要に応じて取得先になる。VirtualBox は、Debian VM を動かし、外付け HDD をゲスト OS へ見せる仲介層である。Debian VM は、cryptsetup で LUKS を開き、Linux カーネルで ext4 を読み、必要な内容を確認または取得する作業環境である。外付け HDD は、既存の LUKS + ext4 バックアップ媒体として扱い、形式変更しない。
| 環境 | 役割 | 本稿での扱い |
|---|---|---|
| macOS | VirtualBox を動かし、外付け HDD を接続し、読み取り結果の確認端末になり、必要に応じて取得先になる。 | LUKS や ext4 を直接扱う主体ではなく、仮想化ホストとコピー先として扱う。 |
| VirtualBox | Debian VM を起動し、外付け HDD をゲスト OS に見せる。 | 物理ディスクを Debian に渡すための仲介層として扱う。 |
| Debian VM | cryptsetup で LUKS を開き、ext4 をマウントし、必要な内容を確認または取得する。 | Linux の標準的な処理系で LUKS + ext4 を読む作業環境として扱う。 |
| 外付け HDD | LUKS + ext4 の既存バックアップ媒体として扱う。 | 形式変更せず、原則として読み取り専用で扱う。 |
この役割分担が必要になるのは、LUKS と ext4 がどちらも Linux 側で自然に扱われる層だからである。LUKS は暗号化されたブロックデバイスを開く層であり、ext4 はその上にあるファイルシステム層である。Mac がこれらを標準機能だけで自然に扱えないからといって、媒体を Mac 向け形式へ変える必要はない。Linux に読ませればよい。Debian VM は、そのために Mac 上へ一時的に用意する Linux である。
Debian のインストールイメージは公式ページから取得できる。Debian のダウンロードページでは、Debian 13 trixie の netinst イメージが案内されている[12]。netinst は、基本システムを入れるための小さなインストール媒体であり、残りのパッケージをネットワークから取得する方式である[13]。Intel Mac では amd64、Apple Silicon Mac では arm64 を選ぶ。Debian は amd64 用と arm64 用のインストールガイドをそれぞれ提供している[14][15]。
ここで CPU アーキテクチャを意識する理由は、Mac の種類によって動かすべき Debian が変わるからである。Intel iMac では amd64 の Debian を選ぶのが自然である。一方、M 系の MacBook では Apple Silicon に対応する arm64 の Debian を選ぶ。仮想マシンは、ホストの CPU アーキテクチャと無関係に何でも自由に動かせる箱ではない。特に本稿の目的は、性能検証ではなく、外付け媒体を確実に読み取るための安定した作業環境を作ることである。したがって、使用している Mac に合った Debian を選ぶことを前提にする。
5.1 VirtualBox をインストールする
まず、Oracle の VirtualBox ダウンロードページから、使用している Mac に合うパッケージを入手する。Intel iMac であれば macOS / Intel hosts、Apple Silicon MacBook であれば macOS / Apple Silicon hosts を選ぶ。インストール後、VirtualBox を起動できることを確認する。この段階では、まだ外付け LUKS + ext4 HDD を接続して作業する必要はない。先に仮想化環境だけを安定させる。
VirtualBox の導入時には、macOS 側のセキュリティ許可や再起動が必要になる場合がある。ここで重要なのは、VirtualBox が正常に起動し、新しい仮想マシンを作成できる状態にすることである。外付け HDD の接続や raw disk access の設定は、VirtualBox と Debian VM が安定して動くことを確認してから行う。低レベルなディスク操作を行う前に、仮想化環境そのものを切り分けて確認しておくと、後のトラブル原因を減らせる。
5.2 Debian VM を作成する
VirtualBox で新しい仮想マシンを作成し、OS 種別は Linux、ディストリビューションは Debian にする。読み取り専用の作業環境として使うだけなら、大きな仮想ディスクは不要である。20 GB 程度の仮想ディスクを Debian 用に用意し、メモリは 2 GB 以上を割り当てると操作しやすい。GUI が不要であれば、最小構成の Debian でもよい。本稿の用途では、端末から cryptsetup、mount、rsync、ssh を使えれば十分である。
ここで作る仮想ディスクは、Debian 自体を入れるための領域である。外付け LUKS + ext4 HDD の中身をコピーして入れる場所ではない。対象の外付け HDD は、後の手順で raw disk として Debian VM に接続する。つまり、Debian 用の仮想ディスクと、読み取り対象の外付け HDD は別物である。この区別を曖昧にすると、VirtualBox のストレージ画面で何を追加しているのかがわかりにくくなる。
| ディスク | 用途 | 注意点 |
|---|---|---|
| Debian 用仮想ディスク | Debian OS、作業用パッケージ、設定ファイルを保存する。 | VirtualBox が管理する通常の仮想ディスクであり、外付けバックアップ媒体そのものではない。 |
| 外付け LUKS + ext4 HDD | 既存の暗号化バックアップ媒体として、必要な内容を読み取る対象になる。 | 後の手順で raw disk として Debian VM に渡すため、macOS 側で同時にマウントしない。 |
Debian のインストールでは、デスクトップ環境を入れるかどうかを選べる。初心者向けには GUI があるほうが安心に見えるが、本稿の作業は最終的に端末で行う。外付け HDD の識別、LUKS の解除、ext4 のマウント、rsync による取得や内容確認はいずれもコマンドで確認したほうが誤操作を減らしやすい。したがって、画面操作に慣れていない場合でも、本稿では端末で確認する前提にする。
5.3 Debian に必要なパッケージを入れる
Debian を起動したら、必要なパッケージを入れる。cryptsetup は LUKS を開くために使う。Debian のパッケージ一覧でも cryptsetup は暗号化ボリュームを扱うためのパッケージとして提供されている[16]。e2fsprogs は ext4 の確認に使う。rsync は Mac 側へファイルを取得するために使う。openssh-server は Mac から SSH 経由で接続するために使う。これらは、LUKS + ext4 媒体を読み取り、必要なファイルを別の場所へ移すための最小限の道具である。
1 2 | sudo apt update sudo apt install cryptsetup e2fsprogs rsync openssh-server |
この時点で、Debian VM は LUKS + ext4 読み取り用の Linux 環境になる。まだ外付け HDD は接続しない。まずは Debian が起動し、端末からコマンドを実行できることを確認しておく。ここで cryptsetup や rsync のインストールが失敗していると、後で外付け HDD を渡した段階で原因の切り分けが難しくなる。ディスクを扱う前に、作業環境を完成させるのが安全である。
確認として、Debian VM 内で次のコマンドを実行し、必要な道具が見えることを確認する。
1 2 3 4 5 | command -v cryptsetup command -v rsync command -v sshd command -v lsblk command -v mount |
ここでは、外付け HDD をまだ扱わないことにも意味がある。LUKS + ext4 媒体を読む作業では、VirtualBox、Debian、raw disk access、cryptsetup、ext4、rsync の複数の層が関係する。最初からすべてを同時に行うと、問題が起きたときにどの層で失敗しているのかわからなくなる。まず VirtualBox が起動すること、次に Debian が起動すること、次に必要なパッケージが入ることを順番に確認する。外付け HDD を接続するのは、その後でよい。
この章で準備したものは、Mac 上の Linux 読み取り環境である。まだバックアップ媒体には触れていない。ここまでを分離しておくことで、次章の raw disk access では、外付け HDD を Debian VM に渡すことだけに集中できる。媒体を扱う前に環境を作り、環境ができてから媒体を渡す。この順序が、低レベルなディスク操作で事故を減らす基本になる。
6. VirtualBox で外付け HDD を Debian VM に渡す
外付け LUKS + ext4 HDD を Debian VM で読むには、Mac のファイル共有機能では足りない。ファイル共有で見えるのは、Mac がすでに読めるファイルである。しかし、本稿で読みたいのは、Mac が標準では解釈できない LUKS + ext4 の媒体そのものである。つまり、Mac 上のディレクトリを Debian VM に共有するのではなく、外付け HDD というブロックデバイスを Debian VM に渡す必要がある。
ここでいうブロックデバイスとは、ファイル単位ではなく、ディスクやパーティションのように一定の単位で読み書きされる記憶装置を指す。LUKS はそのブロックデバイス上に暗号化層を作り、その中に ext4 ファイルシステムが置かれる。したがって、Mac が LUKS を開けず、ext4 も読めない場合、Mac から見えるファイルを共有しても意味がない。まだファイルとして見えていないものを読むために、ディスクそのものを Linux に見せる必要がある。
この目的で使うのが VirtualBox の raw hard disk access である。raw hard disk access では、VirtualBox が物理ディスク全体または特定パーティションを仮想ディスクとして VM に提示する。Oracle の文書は、VirtualBox が物理ディスクまたは選択したパーティションを仮想マシンに提示できると説明している。また、この機能は VMDK 形式の一部として実装され、実データを VMDK ファイル内にコピーするのではなく、物理ディスク上のデータを参照する特殊な VMDK ファイルを作る[17]。
この仕組みは、通常の仮想ディスクとは意味が違う。通常の仮想ディスクでは、VMDK ファイルそのものが仮想ディスクの実体になる。一方、raw disk access で作る VMDK は、物理ディスクへの参照を持つ入口である。つまり、VMDK を作ったからといって外付け HDD の内容が安全なファイルへ複製されるわけではない。Debian VM からその VMDK 経由で読み書きすれば、実際には外付け HDD へアクセスする。
| 方式 | 見えている対象 | 本稿での意味 |
|---|---|---|
| 共有フォルダー | macOS がすでに読めるフォルダーを VM に見せる。 | LUKS + ext4 媒体を開く前の段階では使えない。 |
| 通常の仮想ディスク | VMDK などのファイルを仮想ディスクとして VM に見せる。 | Debian OS を入れる用途には使えるが、外付け HDD そのものではない。 |
| raw hard disk access | 物理ディスクまたはパーティションを VM に見せる。 | 外付け LUKS + ext4 HDD を Debian VM から読むために使う。 |
この操作は便利だが危険でもある。Oracle の文書は、raw hard disk access は熟練者向けであり、誤った使用や古い設定は物理ディスク上のデータ全損につながり得ると警告している[17]。危険の中心は、対象を間違えることと、同じディスクをホストとゲストが同時に触ることである。たとえば、外付け HDD のつもりで内蔵ディスクを指定すれば、Debian VM から内蔵ディスクへアクセスできてしまう。また、macOS 側でマウントされたまま Debian VM に渡せば、同じ媒体を二つの OS が同時に管理しようとする。
したがって、本稿の手順では、対象ディスク確認、macOS 側でのアンマウント、Debian 側での読み取り専用マウントを必須にする。raw disk access は、便利な共有機能ではなく、物理媒体をゲスト OS に渡す低レベル操作である。この章では、対象の特定、ホスト側の切り離し、raw VMDK の作成、VM への接続までを順に確認する。
6.1 macOS 側で対象ディスクを確認する
外付け HDD を Mac に接続したら、まず対象ディスクを確認する。macOS では diskutil を使う。diskutil は、ディスクやボリュームの情報表示、アンマウント、取り外しなどを扱う管理コマンドである[18]。
1 | diskutil list |
ここで、外付け HDD が仮に /dev/disk4 として見えているものとする。この /dev/disk4 は例であり、実際の環境では必ず異なる可能性がある。macOS では、接続順や他の外付け媒体の有無によってデバイス名が変わることがある。したがって、過去に /dev/disk4 だったから今回も /dev/disk4 だと考えてはいけない。
確認では、容量、メーカー名、接続種別、パーティション構成を見る。LUKS パーティションは macOS からファイルシステムとして読めないため、わかりやすい名前で表示されるとは限らない。しかし、ディスク全体の容量、外付けであること、パーティション数などは確認できる。ここで対象が外付け HDD であることを二重に確認する。内蔵ディスクを指定してはいけない。
| 確認項目 | 確認する理由 | 誤った場合の問題 |
|---|---|---|
| 容量 | 対象の外付け HDD と一致するかを確認するためである。 | 容量だけで判断すると、同容量の別ディスクを誤指定する可能性がある。 |
| 接続種別 | 内蔵ディスクではなく、外付けディスクであることを確認するためである。 | 内蔵ディスクを raw disk として VM に渡すと、ホスト環境そのものを壊す可能性がある。 |
| パーティション構成 | LUKS パーティションがどこにあるかを推定するためである。 | ディスク全体を渡すべきか、特定パーティションを渡すべきかの判断を誤る可能性がある。 |
| デバイス名 | 後続の unmountDisk と raw VMDK 作成で使うためである。 | 誤った /dev/diskN を指定すると、別の物理ディスクを Debian VM に渡してしまう。 |
この段階では、まだ何も変更しない。diskutil list は確認のための操作である。重要なのは、対象ディスク名を一度だけ見るのではなく、容量や接続種別と合わせて確認することである。raw disk access では、後続のコマンドが物理ディスクに直接つながるため、対象確認そのものが安全手順になる。
6.2 macOS 側で外付け HDD をアンマウントする
raw disk access を使う前に、macOS 側で対象ディスクをアンマウントする。ここでいうアンマウントは、物理的に取り外すことではない。macOS がそのディスク上のボリュームをファイルシステムとして利用しない状態にすることである。外付け HDD 自体は接続したままにする。
1 | diskutil unmountDisk /dev/disk4 |
ここでも /dev/disk4 は例である。diskutil list で確認した対象ディスク名に読み替える。アンマウントに失敗する場合は、Finder、ターミナル、バックアップソフト、検索インデックスなどが対象ディスクを使っていないか確認する。何かがディスクを使っている状態で強引に次へ進むと、ホスト macOS とゲスト Debian の両方が同じ媒体へ関与する可能性が残る。
ホスト macOS とゲスト Debian が同じディスクを同時に触ると、ファイルシステム破損につながる。Oracle の raw disk access 文書でも、Mac OS X ホストでは対象ディスクにマウントされたボリュームがない場合に全ディスクへアクセスできると説明されている。この条件は単なる形式的な制約ではない。ディスクの整合性を、どの OS が責任を持って管理するのかを一つに絞るための条件である。
本稿の手順では、外付け HDD の管理主体を一時的に Debian VM 側へ移す。その前提として、macOS 側ではそのディスクを使わない状態にする。Mac に挿しているから macOS が管理するのではなく、VirtualBox 経由で Debian VM に渡した時点で、LUKS と ext4 の解釈は Debian 側に任せる。この切り替えを曖昧にしないために、アンマウントを必須にする。
6.3 raw disk 用の VMDK を作成する
次に、物理ディスクを参照する特殊な VMDK ファイルを作る。VMDK は実データを保持する通常の仮想ディスクとしても使われるが、ここでは物理ディスクへの参照を保持する入口として使う。実データは VMDK にコピーされない。読み書きは物理ディスクに向かう。
1 2 | mkdir -p ~/VMs/rawdisks sudo VBoxManage internalcommands createrawvmdk -filename ~/VMs/rawdisks/luks-ext4-disk4.vmdk -rawdisk /dev/disk4 |
このコマンドは、外付け HDD が /dev/disk4 である場合の例である。ディスクを差し替えた場合、macOS のデバイス名は変わることがある。したがって、古い VMDK を漫然と使い回すのではなく、接続のたびに diskutil list で確認し、対象ディスクと VMDK の対応を明確にする方が安全である。
VMDK のファイル名にも、対象がわかる名前を付ける。上の例では luks-ext4-disk4.vmdk としているが、これは手順説明用の名前である。実運用では、媒体名、容量、作成日などを含めてもよい。ただし、ファイル名に disk4 と入れても、次回接続時に同じ外付け HDD が /dev/disk4 になるとは限らない。ファイル名は補助情報にすぎず、最終確認は diskutil list で行う。
この VMDK は、外付け HDD のバックアップではない。VMDK を別の場所へコピーしても、外付け HDD の中身をコピーしたことにはならない。逆に、Debian VM からこの VMDK を経由して書き込めば、物理ディスク上のデータが変更される。この性質が、raw disk access を危険にも有用にもしている。
| 誤解 | 実際の意味 | 注意点 |
|---|---|---|
| VMDK がディスクのコピーである | raw disk 用 VMDK は物理ディスクへの参照である。 | VMDK を保存しても、外付け HDD のバックアップにはならない。 |
| VMDK に書き込まれる | raw disk 用 VMDK 経由のアクセスは物理ディスクへ向かう。 | Debian VM からの書き込みは外付け HDD の内容を変更する可能性がある。 |
| 一度作れば常に安全に使える | macOS のデバイス名は接続状況によって変わることがある。 | 使用前に必ず対象ディスクを再確認する必要がある。 |
6.4 Debian VM に VMDK を接続する
VirtualBox Manager で Debian VM を停止した状態にし、設定のストレージ画面から、作成した luks-ext4-disk4.vmdk を既存ディスクとして追加する。VM 起動中に追加や削除を行わない。接続後、Debian VM を起動する。
ここで重要なのは、macOS 側の /dev/disk4 と Debian 側のデバイス名は一致しないことである。macOS で /dev/disk4 だった物理ディスクは、Debian 側では /dev/sdb や /dev/sdc のように見える。ホスト OS とゲスト OS は別々のデバイス名空間を持つ。したがって、次章では Debian 側であらためて lsblk を使い、どのデバイスが外付け HDD に対応しているかを確認する。
この段階で完了するのは、外付け HDD を Debian VM から見える位置へ置くことだけである。まだ LUKS は開いていない。まだ ext4 もマウントしていない。raw disk access は、物理ディスクを Debian VM に見せる入口を作るだけであり、暗号化解除やファイルシステムの解釈までは行わない。次章で、Debian 側から対象ディスクを確認し、LUKS を読み取り専用で開き、その中の ext4 を読み取り専用でマウントする。
ここまでの手順は、媒体へアクセスする前の準備である。対象を確認し、macOS 側から切り離し、raw VMDK を作り、Debian VM に接続する。この順序を守ることで、Mac が読めない LUKS + ext4 媒体を、媒体形式を変えずに Debian へ渡せる。重要なのは、便利さではなく、管理主体を明確にすることである。macOS ではなく Debian VM が読む。そのために、外付け HDD をファイルとしてではなくブロックデバイスとして渡す。
7. Debian VM で LUKS を開き ext4 を読み取り専用でマウントする
Debian VM が起動したら、最初に行うことは、接続されたディスクを確認することである。前章で macOS 側の /dev/disk4 を Debian VM に渡したとしても、Debian 側で同じ名前になるわけではない。macOS と Debian は別々の OS であり、デバイス名の付け方も別である。したがって、Debian 側ではあらためて、どのブロックデバイスが外付け HDD なのかを確認する必要がある。
確認には lsblk を使う。lsblk はブロックデバイスを一覧表示するコマンドであり、ファイルシステム、ラベル、UUID などの確認にも使える[19]。ここでいうブロックデバイスとは、ディスクやパーティションのように、ファイル単位ではなくブロック単位で読み書きされる対象である。LUKS はこのブロックデバイスの上に暗号化層を作り、その内側に ext4 が置かれる。したがって、最初に確認すべきなのは、ファイル名ではなく、ディスクとパーティションの対応関係である。
1 | lsblk -f |
以下では、外付け HDD が Debian 側で /dev/sdb として見え、LUKS パーティションが /dev/sdb1 として見えているものとする。ただし、これは説明用の例である。実際には lsblk -f の出力、容量、パーティション構成、ファイルシステム種別を見て判断する。macOS 側で /dev/disk4 だったものが Debian 側では /dev/sdb になることもあれば、別の名前になることもある。過去のデバイス名を信用せず、その場で確認することが必要である。
| 確認対象 | 確認する理由 | 誤った場合の問題 |
|---|---|---|
| ディスク名 | Debian 側で外付け HDD が /dev/sdb や /dev/sdc のどれとして見えているかを確認するためである。 | 別のディスクを LUKS として開こうとしたり、誤った対象を操作したりする可能性がある。 |
| パーティション名 | LUKS パーティションが /dev/sdb1 なのか、別の番号なのかを確認するためである。 | ディスク全体とパーティションを取り違え、cryptsetup の対象を誤る可能性がある。 |
| 容量 | 対象の外付け HDD と一致するかを確認するためである。 | 同じような構成の別ディスクを誤認する可能性がある。 |
| ファイルシステム表示 | LUKS、crypto_LUKS、ext4 などの表示から、どの層が見えているかを判断するためである。 | 暗号化層を開く前の対象と、開いた後の mapper デバイスを混同する可能性がある。 |
この確認段階では、まだ LUKS を開かない。まず、Debian 側で外付け HDD がどう見えているかを把握する。ディスク操作では、正しいコマンドを知っていることよりも、正しい対象を選んでいることのほうが重要である。特に本稿の方式では、VirtualBox の raw disk access により物理ディスクを VM に渡しているため、Debian 側の操作は実媒体へ到達し得る。確認を省略してはいけない。
7.1 LUKS パーティションを読み取り専用で開く
対象の LUKS パーティションが /dev/sdb1 であると確認できたら、cryptsetup で LUKS を開く。cryptsetup は、LUKS、plain dm-crypt、その他の暗号化ブロックデバイス形式を扱う管理ツールである[20]。カーネル側では dm-crypt が device-mapper のターゲットとして暗号化ブロックデバイスを提供する[21]。つまり、cryptsetup はユーザーが暗号化デバイスを開閉するための操作入口であり、実際のブロックデバイス変換は Linux カーネル側の仕組みで行われる。
ここで行うのは、暗号化された LUKS パーティションを、復号後のブロックデバイスとして /dev/mapper の下に見えるようにする操作である。まだファイルシステムをマウントするわけではない。暗号化層を開くことと、ext4 をマウントすることは別段階である。この二つを分けて理解しておくと、どこで失敗しているのかを切り分けやすい。
1 | sudo cryptsetup open --type luks --readonly /dev/sdb1 luks_ext |
このコマンドでは、/dev/sdb1 を LUKS として開き、復号後の mapper 名を luks_ext にしている。–readonly を付ける理由は、Mac 上の Debian VM を読み取り用の補助環境として扱うためである。ここで読み取り専用にしておくと、LUKS の mapper デバイス自体が読み取り専用になる。後続の ext4 マウントでも読み取り専用を指定するが、暗号化層とファイルシステム層は別であるため、両方で読み取り専用を意識する。
成功すると、/dev/mapper/luks_ext が作成される。この時点では、LUKS の暗号化層を開いただけであり、まだ ext4 ファイルシステムをマウントしていない。つまり、暗号化された外側の扉を開け、内側のブロックデバイスが見えるようになった段階である。ファイルやディレクトリとして読むには、次にその中の ext4 を Linux のディレクトリツリーへ接続する必要がある。
1 2 | ls -l /dev/mapper/luks_ext lsblk -f |
ここでも lsblk -f を再度確認すると、/dev/mapper/luks_ext の内側に ext4 が見える場合がある。確認の目的は、/dev/sdb1 が LUKS の外側であり、/dev/mapper/luks_ext が復号後の内側であることを区別することである。ext4 をマウントする対象は /dev/sdb1 ではなく、/dev/mapper/luks_ext である。
| 対象 | 意味 | この段階での扱い |
|---|---|---|
| /dev/sdb1 | 外付け HDD 上の LUKS パーティションである。 | cryptsetup で開く対象であり、ext4 として直接マウントしない。 |
| /dev/mapper/luks_ext | LUKS を開いた後に見える復号後のブロックデバイスである。 | ext4 としてマウントする対象である。 |
| /mnt/luks_ext | ext4 を Linux のディレクトリツリーへ接続するためのマウントポイントである。 | 次の手順で作成し、読み取り専用マウント先として使う。 |
7.2 ext4 を ro,noload でマウントする
次に、マウントポイントを作成し、復号後のブロックデバイスを ext4 として読み取り専用でマウントする。mount は、デバイス上のファイルシステムを Linux のディレクトリツリーへ接続するコマンドである[22]。LUKS を開いただけでは、まだファイルやディレクトリは見えない。/dev/mapper/luks_ext の中にある ext4 を /mnt/luks_ext に接続することで、ファイルとして参照できるようになる。
1 2 | sudo mkdir -p /mnt/luks_ext sudo mount -t ext4 -o ro,noload /dev/mapper/luks_ext /mnt/luks_ext |
ここで ro だけでなく noload を付ける。ro は、ファイルシステムを読み取り専用でマウントする指定である。しかし ext4 では、読み取り専用マウントであっても、dirty なファイルシステムに対して journal replay が走ると、ディスクへ書き込みが発生する場合がある。noload は journal を読み込まない指定であり、元媒体を変更しないことを優先する読み取り用途では重要である。この点は後の章で詳しく扱う。
ただし、ro,noload は万能の安全装置ではない。これは、媒体へ書き込まないことを優先する指定であり、dirty な ext4 を整合した状態へ修復する指定ではない。異常終了後の媒体や、不整合が疑われる媒体を ro,noload で読んだ場合、見えている内容が journal replay 後の整合状態とは異なる可能性がある。したがって、Mac 上の Debian VM では、修復ではなく読み取りを目的にする。整合回復や fsck は、Linux 実機または取得済みイメージのコピー上で行う。
| 指定 | 意味 | 本稿での意図 |
|---|---|---|
| –readonly | cryptsetup で開く mapper デバイスを読み取り専用にする。 | LUKS の暗号化層から書き込みを避けるために使う。 |
| ro | ext4 ファイルシステムを読み取り専用でマウントする。 | 通常のファイル書き込み、削除、権限変更を行わないために使う。 |
| noload | ext4 の journal を読み込まず、journal replay を行わない。 | 読み取り用途で元媒体への回復書き込みを避けるために使う。 |
この三つは同じ意味ではない。–readonly は暗号化層の指定であり、ro と noload はファイルシステム層の指定である。読み取り専用で扱うという方針を実現するには、どの層に対してどの指定をしているのかを理解する必要がある。特に ext4 の journal replay は、通常のファイル書き込みとは別の経路で媒体へ書き込み得るため、ro だけでは本稿の目的には足りない。
7.3 内容を確認する
マウントできたら、内容を確認する。ここで行うのは、対象媒体から必要なファイルを読み取れるかどうかの確認である。正本媒体の整理、削除、移動、権限変更を行う段階ではない。
1 2 | ls -la /mnt/luks_ext findmnt /mnt/luks_ext |
findmnt では、/mnt/luks_ext がどのデバイスから、どのオプションでマウントされているかを確認できる。ここで、ro や noload が意図通りに反映されているかを確認する。確認せずに作業を始めると、読み取り専用で開いたつもりでも、実際には異なるオプションでマウントしている可能性を見落とす。
内容確認では、必要なディレクトリが見えるか、想定した base や extended などの領域があるか、取得対象のファイルが存在するかを見る。見えるからといって、その場で整理を始めない。Mac 上の Debian VM は、正本媒体を管理する環境ではなく、読み取り用途で使うための環境である。この段階では、閲覧、検索、比較、必要に応じた取得だけを行う。
| 操作 | 本稿での扱い | 理由 |
|---|---|---|
| 閲覧 | 行ってよい。 | 必要なファイルや情報を確認するためである。 |
| 部分取得 | 行ってよい。 | Mac 側や別媒体へ必要なファイルをコピーすることも読み取り用途に含まれるためである。 |
| 削除 | 行わない。 | 正本媒体の整理作業ではなく、読み取り環境だからである。 |
| 移動 | 行わない。 | ディレクトリ構造を変更する作業は Linux 実機側の通常運用で行うべきだからである。 |
| 権限変更 | 行わない。 | 所有者やパーミッションの正規化は、読み取り専用の目的から外れるためである。 |
| fsck | 元媒体には行わない。 | 修復は書き込みを伴う可能性があり、Mac 上の VM で直接行うべきではないためである。 |
7.4 終了時は必ずアンマウントしてから閉じる
作業後は、Debian VM 側で ext4 をアンマウントし、LUKS mapper を閉じる。順序を逆にしてはいけない。ext4 は /dev/mapper/luks_ext の上にマウントされているため、先に cryptsetup close を実行すると、まだ使われている下層デバイスを閉じようとすることになる。層構造に合わせて、上から順に外す必要がある。
1 2 3 | sudo umount /mnt/luks_ext sudo cryptsetup close luks_ext sudo poweroff |
この順序には理由がある。まず、/mnt/luks_ext から ext4 を切り離す。次に、/dev/mapper/luks_ext を閉じて LUKS の復号マッピングを消す。最後に Debian VM を停止する。これにより、Debian 側が外付け HDD に関与していない状態に戻る。
| 順序 | 操作 | 意味 |
|---|---|---|
| 1 | umount /mnt/luks_ext | ext4 ファイルシステムを Debian のディレクトリツリーから切り離す。 |
| 2 | cryptsetup close luks_ext | LUKS の復号後 mapper デバイスを閉じる。 |
| 3 | poweroff | Debian VM を停止し、外付け HDD への関与を終える。 |
| 4 | diskutil eject /dev/disk4 | macOS 側で外付け HDD を取り外し可能な状態にする。 |
Debian VM が停止したことを確認してから、macOS 側で外付け HDD を取り外す。
1 | diskutil eject /dev/disk4 |
ここでも /dev/disk4 は例である。最初に diskutil list で確認した対象ディスク名に読み替える。Debian VM が起動したまま、または LUKS mapper を閉じないまま、外付け HDD を抜いてはいけない。読み取りであっても、終了手順は通常のディスク運用と同じく重要である。
この章で行ったことは、外付け LUKS + ext4 媒体を Debian VM で読み取り専用として開き、内容を確認し、最後に安全に閉じることである。ここまでで、Mac が LUKS や ext4 を直接扱えなくても、Mac 上の Debian VM を経由して既存形式のまま読み取れることがわかる。ただし、この手順の安全性は、対象確認、読み取り専用、ro,noload、終了順序に依存している。便利なショートカットとして扱うのではなく、層ごとの責任を確認しながら実行する手順として扱う必要がある。
8. ext4 journal replay は何をするのか
この章は、本稿の技術的な核心である。読み取り専用で開くと聞くと、ディスクには一切書かれないように思える。しかし ext4 では、通常のファイル書き込みと、ファイルシステムを整合状態へ戻すための journal replay を分けて考える必要がある。mount の man page は、dirty な ext3 や ext4 では read-only mount でも journal replay によってデバイスへ書くことがあると説明している[22]。Linux カーネル文書も、ext4 を read-only でマウントしても journal replay が行われ、結果としてパーティションへ書き込みが発生すると説明している[23]。
ここでいう dirty とは、ファイルシステムが正常に閉じられていない可能性がある状態である。たとえば、電源断、USB ケーブル抜け、VM の強制終了、カーネル停止、外付け HDD の瞬断などが起きると、ファイルシステム上の更新が途中で止まることがある。このとき、ファイル本体、ディレクトリエントリ、inode、空き領域管理情報などの更新状態が、完全にはそろっていない可能性がある。ext4 の journal は、このような中途半端な状態を回復するために使われる。
ext4 の journal は、ファイルシステムのメタデータ更新を安全に扱うための仕組みである。たとえば、ファイルを作るときには、ファイル名をディレクトリへ追加し、inode を更新し、空き領域管理情報も更新する。これらの途中で電源が落ちると、ある場所では更新済み、別の場所では未更新という中途半端な状態になり得る。journal は、このような更新をいったん記録し、異常終了後の次回マウント時に、完了済みの更新を再適用して整合状態へ戻す。
つまり、journal replay は余計な書き込みではない。ファイルシステムを壊すための動作でもない。むしろ通常の Linux 運用では、異常終了後の ext4 を整合状態へ戻すために必要な回復処理である。問題は、その回復処理が元媒体への書き込みを伴う点にある。本稿のように、外付けバックアップ媒体を Mac 上の Debian VM から読み取り用途で使う場合、元媒体を変更しないことを優先したい場面がある。その場合、journal replay が善意の回復処理であっても、保全の観点では望ましくない書き込みになり得る。
| 状態 | 起こること | 運用上の意味 |
|---|---|---|
| clean | ファイルシステムが正常にアンマウントされている。 | journal replay は基本的に不要であり、ro,noload で読みやすい。 |
| dirty | 電源断、USB 抜け、VM 強制終了などにより、未反映の journal が残っている可能性がある。 | journal replay を行えば整合状態に戻る可能性があるが、その処理は書き込みを伴う。 |
| ro | 通常のファイル書き込みは抑止される。 | dirty な ext4 では journal replay による書き込みが起きる場合がある。 |
| ro,noload | journal を読み込まず、journal replay も行わない。 | 媒体を変更しないことを優先できるが、dirty な状態を整合回復するわけではない。 |
この表で重要なのは、ro と ro,noload が同じ意味ではないことである。ro は、マウント後の通常の書き込み操作を禁止する指定である。ファイルを作る、削除する、名前を変える、権限を変える、といった操作はできない。しかし、マウント時の journal replay は、通常のファイル操作ではなく、ファイルシステムを整合状態へ戻すための回復処理である。そのため、ro だけでは、元媒体へ一切書かないことを保証する指定としては不十分になる。
この書き込みを避けるために使うのが noload である。ext4 の man page では、noload または norecovery は journal をマウント時に読み込まない指定であり、クリーンにアンマウントされていないファイルシステムで journal replay を飛ばすと、不整合を含む可能性があると説明されている[24]。したがって、ro,noload は安全な修復手段ではない。正確には、元媒体を変更しないことを優先し、journal による回復処理も行わずに読む指定である。
ここに、保全と整合性の緊張関係がある。journal replay を許すと、ファイルシステムは整合状態に戻りやすい。しかし、そのためには元媒体へ書き込む。journal replay を止めると、元媒体を変更しにくい。しかし、dirty な状態をそのまま読む可能性がある。つまり、「媒体を一切変更しないこと」と「整合状態へ戻すこと」は、常に同時には満たせない。
| 方針 | 得られるもの | 失うもの |
|---|---|---|
| journal replay を許す | dirty な ext4 を整合状態へ戻せる可能性が高くなる。 | 元媒体へ書き込みが発生する可能性がある。 |
| journal replay を止める | 元媒体を変更しないことを優先できる。 | dirty な ext4 を回復せず、不整合を含む状態で読む可能性がある。 |
| 元媒体ではなくイメージコピーで回復する | 元媒体を保全しながら、コピー上で整合回復を試せる。 | 追加の保存先、時間、復旧手順が必要になる。 |
本稿の標準手順は、読み取り用途では cryptsetup open –readonly と mount -o ro,noload を組み合わせることである。これは、元媒体に書かないことを優先する手順である。すでに clean にアンマウントされている媒体であれば、この手順で問題なく読める可能性が高い。一方、dirty な可能性がある媒体では、ro,noload によって見える内容が journal replay 後の整合状態とは異なる可能性がある。この違いを理解せずに、「読み取り専用だから常に安全で正しい」と考えてはいけない。
もしファイルシステムが dirty であり、整合回復が必要な場合は、Mac 上の VM で元媒体を直接修復しない。Linux 実機、または取得済みディスクイメージのコピー上で journal replay や e2fsck を行うべきである。e2fsck は ext2、ext3、ext4 ファイルシステムを検査するためのツールだが、マウント中のファイルシステムに実行することは一般に安全ではないと説明されている[25]。したがって、Mac 上の Debian VM で読み取り中の媒体に対して、ついでに fsck をかけるという運用は避ける。
より保全寄りにする場合は、Debian VM 側で blockdev によりブロックデバイスを読み取り専用にする方法もある。blockdev はブロックデバイスの属性を操作するためのコマンドである[26]。ただし、これは物理的に書き込み信号を遮断する write blocker ではない。対象デバイスを間違えれば別の危険が生じるため、通常手順では cryptsetup の –readonly と mount の ro,noload を標準にし、blockdev は保全モードの追加手段として位置づけるのがよい。
1 2 3 4 | sudo blockdev --setro /dev/sdb sudo blockdev --setro /dev/sdb1 sudo cryptsetup open --type luks --readonly /dev/sdb1 luks_ext sudo mount -t ext4 -o ro,noload /dev/mapper/luks_ext /mnt/luks_ext |
この追加手順を使う場合も、対象確認が最優先である。/dev/sdb や /dev/sdb1 は説明用の例であり、実際の環境では lsblk -f で対象を確認してから読み替える。blockdev による読み取り専用化は、誤操作を防ぐ魔法ではない。どの層に対して何を指定しているのかを理解して初めて意味を持つ。
この章の結論は単純である。ext4 では、読み取り専用マウントでも journal replay によって書き込みが発生することがある。書かせないことを優先するなら ro,noload を使う。ただし、ro,noload は修復ではない。dirty なファイルシステムを整合状態へ戻したいなら、元媒体に対してその場で作業するのではなく、Linux 実機またはイメージコピー上で慎重に行う。本稿が Mac 上の Debian VM を読み取り用の補助経路として位置づけ、書き込みや修復を扱わない理由は、ここにもある。
9. Mac 側から内容を確認し、必要に応じて取得する
Debian VM で ext4 を読み取り専用でマウントできたら、次に考えるべきことは、Mac 側からその内容をどのように読むかである。ここで行うことは、必ずしもファイルのコピーではない。必要なファイル名を確認するだけの場合もある。ディレクトリ構成を確認する場合もある。一部の設定ファイルを読む場合もある。必要なファイルだけを Mac 側へコピーする場合もある。したがって、本章では「取得」に限定せず、「読み取り」の経路として整理する。
この構成では、ext4 を読んでいる主体は Debian VM である。Mac は ext4 を直接読んでいるわけではない。Mac 側からは、Debian VM が読み取った内容に SSH、rsync、sftp、または共有フォルダーなどを通じてアクセスする。つまり、ファイルシステムの解釈は Debian 側に任せ、Mac 側は確認端末または取得先として使う。この役割分担を崩さないことが重要である。
| 用途 | 内容 | 向いている方法 |
|---|---|---|
| 一覧確認 | どのディレクトリやファイルが存在するかを確認する。 | Debian VM 上で ls や find を使う。 |
| 内容確認 | 設定ファイルやテキストファイルの中身を確認する。 | Debian VM 上で less、cat、grep などを使う。 |
| 部分取得 | 必要なファイルやディレクトリだけを Mac 側へコピーする。 | Mac 側から rsync、scp、sftp などを使う。 |
| 構成確認 | base や extended などのバックアップ領域の構成を確認する。 | Debian VM 上で find、du、lsblk、findmnt などを使う。 |
| 検証用読み取り | 必要なファイルが読めるか、チェックサムやサイズを確認する。 | Debian VM 上で sha256sum、stat、du などを使う。 |
Mac 側から Debian VM に入って読む場合、使いやすいのは SSH である。OpenSSH は、暗号化されたネットワーク接続を提供する実装であり、リモートログインやファイル転送の基盤として広く使われている[27]。VirtualBox の NAT では、ゲスト OS から外部ネットワークへ出るだけでなく、ポートフォワードによりホスト側のポートをゲスト側へ転送できる[28]。
Debian VM に openssh-server を入れ、VirtualBox のネットワークを NAT にし、ホスト側 127.0.0.1 の 2222 番をゲスト側 22 番へ転送する。こうすると、Mac 側から 127.0.0.1:2222 へ SSH 接続することで、Debian VM に入れる。この接続は、外部ネットワークへ公開するためのものではない。Mac 上のホスト OS から、同じ Mac 上で動いている Debian VM へ入るための経路である。
| 設定 | 値 | 意味 |
|---|---|---|
| Host IP | 127.0.0.1 | Mac 自身からだけ接続できるようにする。 |
| Host Port | 2222 | Mac 側で待ち受けるポートである。 |
| Guest IP | 空欄または Debian VM の IP | 通常は空欄でもよい。 |
| Guest Port | 22 | Debian VM 側の SSH ポートである。 |
SSH 接続ができると、Mac 側から Debian VM の端末へ入って、マウント済みの ext4 を確認できる。たとえば、次のように接続する。
1 | ssh -p 2222 user@127.0.0.1 |
Debian VM に入った後は、/mnt/luks_ext 以下を確認する。この確認は、Debian VM 側で ext4 を読んでいるだけであり、Mac が ext4 を直接理解しているわけではない。
1 2 3 | ls -la /mnt/luks_ext find /mnt/luks_ext -maxdepth 2 -type d findmnt /mnt/luks_ext |
ファイルの中身を読むだけであれば、Debian VM 側で less や grep を使えばよい。Mac 側へコピーする必要がない場合、無理にファイルを移す必要はない。読み取り専用でマウントした媒体を確認し、必要な情報だけを画面で読むという使い方も、本稿の想定に含まれる。
1 2 | less /mnt/luks_ext/path/to/file grep -R "keyword" /mnt/luks_ext/path/to/directory |
必要なファイルを Mac 側へ取得する場合は、rsync を使うと扱いやすい。rsync は、ファイルやディレクトリを同期・コピーするためのツールである[29]。ただし、この場面での rsync は、正本媒体を同期運用するためではなく、Debian VM が読み取れるファイルを Mac 側へ取得するために使う。読み取り元は /mnt/luks_ext であり、これは読み取り専用でマウントされた ext4 である。
1 2 3 | rsync -a --info=progress2 -e "ssh -p 2222" \ user@127.0.0.1:/mnt/luks_ext/base/ \ ./restore/base/ |
この例では、Mac 側から Debian VM に SSH 接続し、/mnt/luks_ext/base/ 以下を ./restore/base/ へコピーしている。これは取得の一例であり、常に base 全体をコピーする必要はない。必要な単一ファイルだけを指定してもよいし、特定のディレクトリだけを指定してもよい。重要なのは、Debian VM 側の LUKS + ext4 媒体を読み取り元とし、Mac 側を取得先として扱うことである。
| 方法 | 用途 | 注意点 |
|---|---|---|
| SSH ログイン | Debian VM に入って、ファイル一覧や内容を確認する。 | コピーせずに確認できるが、端末操作が前提になる。 |
| rsync | 必要なファイルやディレクトリを Mac 側へ取得する。 | 取得先を誤ると Mac 側の既存ファイルを上書きする可能性がある。 |
| scp | 少数のファイルを単純にコピーする。 | 大量ファイルや差分取得では rsync のほうが扱いやすい。 |
| sftp | 対話的にファイルを取得する。 | 操作はわかりやすいが、再現性のある手順としては rsync より弱い。 |
| 共有フォルダー | Mac と Debian VM の間でディレクトリを共有する。 | Guest Additions、権限、シンボリックリンク、所有者の扱いを別途確認する必要がある。 |
VirtualBox には共有フォルダー機能もある[30]。しかし、共有フォルダーは、Mac と Debian VM の間でファイルを受け渡すための機能であり、LUKS + ext4 媒体を開く機能ではない。また、Guest Additions、権限、シンボリックリンク、所有者の扱いが絡む。本稿の主眼は、外付け LUKS + ext4 媒体を Debian VM で読み取り専用で開くことにあるため、Mac 側からの確認や取得には、まず SSH と rsync を基本にする。
この章で確認したいことは、Mac 側へ必ず部分取得することではない。Debian VM で ext4 を読み、必要に応じて Mac 側から参照し、必要であれば取得することである。読むだけで足りる場合は読むだけでよい。一部を取得する必要がある場合だけ、rsync や scp を使う。この切り分けにより、Mac 上の Debian VM を、正本媒体の操作環境ではなく、読み取り用の補助環境として保てる。
10. raw disk access と VM 運用で気をつけること
Debian VM 方式は、媒体形式を変えずに Mac 側の読み取り経路を追加できる。しかし、この方式は、外付け HDD を Mac の通常の外付けディスクとして扱う方法ではない。VirtualBox の raw disk access により、物理ディスクを VM に直接見せる方法である。ここでいう raw disk access とは、Mac が読めるファイルやフォルダーを共有する機能ではなく、ディスクそのもの、またはその中のパーティションを、ゲスト OS である Debian に仮想ディスクとして見せる機能である。したがって、安全な GUI 操作の延長ではなく、対象を誤ると実媒体へ直接影響する低レベル操作として扱う必要がある。
まず、ホストとゲストという言葉を分けておく。ホストは、VirtualBox を動かしている側の OS であり、本稿では macOS である。ゲストは、VirtualBox の中で動いている OS であり、本稿では Debian VM である。通常のファイル共有では、ホストが読めるフォルダーをゲストに見せる。しかし raw disk access では、ホストが直接読めない LUKS + ext4 の外付け HDD を、ゲスト側にブロックデバイスとして見せる。ブロックデバイスとは、ファイル単位ではなく、ディスクやパーティションのように一定のブロック単位で読み書きされる対象である。
この構成で最も避けるべきことは、同じ物理ディスクを二つの OS が同時に管理することである。macOS が外付け HDD をマウントしたまま Debian VM に渡すと、ホストとゲストが同じ媒体に対して別々の前提でアクセスする可能性がある。ファイルシステムは、どの OS がどの状態を管理しているかを前提に整合性を保つ。管理主体が二つになると、片方の OS が把握していない更新や状態変更が起こり、破損につながる。
もう一つ重要なのは、I/O という言葉である。I/O は input/output の略で、ディスクに対する読み書き処理を指す。ファイルを読む、コピーする、マウント時にファイルシステム情報を確認する、journal replay が走る、といった処理はいずれも I/O である。VM 稼働中に外付け HDD を抜いたり、Mac がスリープしたりすると、この I/O が途中で止まる可能性がある。読み取りだけのつもりでも、処理途中でデバイスが消えると、コピー失敗、マウント状態の異常、ファイルシステムの dirty 化につながることがある。
| 用語 | 本稿での意味 | 誤解しやすい点 |
|---|---|---|
| ホスト | VirtualBox を動かしている macOS である。 | 外付け HDD を接続しているからといって、LUKS + ext4 の解釈を担当するわけではない。 |
| ゲスト | VirtualBox の中で動く Debian VM である。 | 外付け HDD を渡した後は、LUKS と ext4 の解釈を担う作業環境になる。 |
| raw disk access | 物理ディスクまたはパーティションを VM に仮想ディスクとして見せる仕組みである。 | ディスク内容を VMDK へコピーする機能ではなく、実媒体への参照を作る機能である。 |
| ブロックデバイス | ディスクやパーティションのように、ブロック単位で読み書きされる対象である。 | Mac が読めるファイルやフォルダーとは別の層にある対象である。 |
| I/O | ディスクへの読み書き処理である。 | ファイルコピーだけでなく、マウント、journal replay、デバイス確認も I/O を伴うことがある。 |
| dirty | ファイルシステムが正常に閉じられておらず、整合回復が必要な可能性がある状態である。 | すぐに読めないという意味ではなく、journal replay や fsck の判断が必要になり得る状態である。 |
危険の中心は、対象ディスクの取り違え、ホストとゲストの同時アクセス、VM 稼働中の切断、Mac のスリープである。これらはすべて、ディスクの管理主体が曖昧になったり、I/O が途中で途切れたりすることで起こる。raw disk access は、外付け HDD を Debian VM に渡せる強力な方法である一方、対象を間違えると別のディスクをゲスト OS に見せてしまう。特に内蔵ディスクを誤って指定すると、ホスト環境そのものに影響する可能性がある。
| 危険 | 何が起こるか | 避ける方法 |
|---|---|---|
| ディスク指定ミス | 内蔵ディスクや別の外付けディスクを VM に渡すおそれがある。 | diskutil list、容量、接続種別、パーティション構成を必ず確認し、対象ディスク名を毎回確認する。 |
| 同時アクセス | macOS と Debian VM が同じディスクを同時に触り、ファイルシステム破損につながる可能性がある。 | macOS 側で diskutil unmountDisk を実行してから VM に渡し、管理主体を Debian VM 側へ一時的に寄せる。 |
| 書き込みマウント | VM の異常終了、USB 瞬断、Mac のスリープにより、ext4 が dirty になる可能性がある。 | cryptsetup open –readonly と mount -o ro,noload を標準にし、Mac 上の VM では書き込み運用をしない。 |
| VM 中の取り外し | 読み取り中に I/O が途切れ、確認作業やコピー処理が失敗し、マウント状態も不安定になる可能性がある。 | umount、cryptsetup close、VM 停止、diskutil eject の順序を守る。 |
| Mac のスリープ | 長時間の読み取りやコピー中に I/O が停止し、SSH 接続、rsync、デバイス認識が途切れる可能性がある。 | 作業中はスリープを避け、必要な確認や取得を区切って行う。 |
| 古い VMDK の使い回し | 以前の /dev/diskN と現在の /dev/diskN が別の物理ディスクを指している可能性がある。 | 接続のたびに diskutil list で確認し、VMDK と対象ディスクの対応を固定的に思い込まない。 |
この方式の弱点は、Finder で自然に扱えないことだけではない。macOS、VirtualBox、Debian、LUKS、ext4、SSH、rsync という複数の層が加わるため、障害時の切り分け対象が増える。Linux 実機なら、lsblk、cryptsetup、mount、dmesg で比較的直接確認できることも、Mac + VM では、まず VirtualBox が物理ディスクを Debian VM に正しく渡しているかを確認しなければならない。次に Debian がそのディスクをブロックデバイスとして認識しているかを確認し、その後に LUKS、ext4、SSH、rsync の順に切り分ける必要がある。
| 層 | 確認すること | 失敗時に疑うこと |
|---|---|---|
| macOS | 外付け HDD が接続され、diskutil list で対象として見えているかを確認する。 | USB 接続、電源、ケーブル、ディスク認識、誤った /dev/diskN を疑う。 |
| VirtualBox | raw disk 用 VMDK が Debian VM に接続されているかを確認する。 | VMDK の参照先、VM のストレージ設定、VM 起動状態を疑う。 |
| Debian | lsblk -f で外付け HDD が /dev/sdb などとして見えているかを確認する。 | raw disk access の接続、権限、デバイス名の取り違えを疑う。 |
| LUKS | cryptsetup open –readonly で /dev/mapper/luks_ext が作成されるかを確認する。 | 対象パーティション、パスフレーズ、LUKS ヘッダー、読み取りエラーを疑う。 |
| ext4 | mount -o ro,noload で /mnt/luks_ext にマウントできるかを確認する。 | dirty 状態、ファイルシステム破損、マウント対象の取り違えを疑う。 |
| SSH / rsync | Mac 側から Debian VM に接続し、必要に応じてファイルを読めるか確認する。 | NAT ポートフォワード、SSH サーバー、ユーザー名、取得先パスを疑う。 |
ここで大切なのは、トラブル時にいきなり修復へ進まないことである。読めない原因が、VirtualBox の設定なのか、Debian 側のデバイス認識なのか、LUKS の問題なのか、ext4 の問題なのかを分けて確認する。原因が raw disk access の設定にあるのに fsck を実行しても意味がない。逆に、ext4 が dirty である可能性があるのに、単なる SSH 接続の問題だと思い込むのも危険である。層が増える方式では、層ごとに確認する態度が必要になる。
したがって、この方式は日常運用の快適化ではない。通常の同期、修復、fsck、権限整理、退役判断は Linux 実機で行う。Mac 上の Debian VM は、必要なファイルや情報を読み取るための補助経路として管理する。読み取りだけで足りる場合は読むだけでよい。必要なファイルを取得する場合だけ rsync や scp を使う。正本媒体の整理や修復まで Mac 上の VM に担わせないことが、この方式を安全側に保つ条件である。
11. 読み取り用途には広く使えるが、書き込み運用には使わない
本稿の結論は、LUKS + ext4 の正本媒体を Linux で扱う形式として維持しつつ、macOS 側には読み取り用の補助経路を追加する、というものである。macOS が LUKS + ext4 を直接読めないことは不便である。しかし、その不便を理由に、媒体形式を Mac 向けへ変える必要はない。Mac 上に Debian VM を用意し、外付け HDD を読み取り専用で Debian に渡せば、形式変更なしで必要な内容を読める。
ここで重要なのは、この方式を特定の場面に限定しすぎないことである。Linux 実機が使えない場合の取得にも使えるが、それだけではない。Mac 作業中に外付け LUKS + ext4 媒体の中から数個のファイルを取り出したい場合、バックアップ内の特定ディレクトリ構成を確認したい場合、保存済みの設定ファイルを参照したい場合、移行前に中身を確認したい場合にも使える。つまり、この方式は、macOS から LUKS + ext4 媒体を読み取り用途で扱うための補助経路である。
ただし、補助経路であることと、日常的な書き込み運用に使えることは違う。Mac 上の Debian VM で LUKS + ext4 を読めるからといって、Finder で外付け HDD を整理する感覚で使うべきではない。raw disk access は物理ディスクを VM に見せる低レベル操作であり、ext4 journal replay は read-only の意味を複雑にする。したがって、本稿の方式は「読む」「確認する」「必要に応じて取得する」ための方法として位置づけ、正本媒体の同期、修復、整理、退役判断までは担わせない。
| 用途 | 適否 | 理由 |
|---|---|---|
| 一部ファイルの取得 | 向いている。 | 読み取り専用で LUKS を開き、必要なファイルやディレクトリだけを Mac 側へコピーできる。 |
| ファイル内容の確認 | 向いている。 | Debian VM 側で ext4 を読み、設定ファイルやテキストファイルの内容を確認できる。 |
| ディレクトリ構成の確認 | 向いている。 | base、extended、保存済みプロジェクトなどの構成を、媒体形式を変えずに確認できる。 |
| バックアップ内容の簡易確認 | 限定的に向いている。 | 必要なファイルが存在するか、読めるかを確認できるが、完全な検証や修復は Linux 実機で行うべきである。 |
| バックアップ同期 | 向いていない。 | 書き込み運用になり、VM、USB、スリープ、journal の事故要因が増える。 |
| fsck や修復 | 向いていない。 | 元媒体を直接変更する作業は、Linux 実機またはイメージコピー上で行うべきである。 |
| Finder 的な整理 | 向いていない。 | Mac から自然に扱える形式ではなく、操作層が多く、誤操作時の影響も大きい。 |
この表で確認すべきことは、用途の境界である。本稿の方式は、LUKS + ext4 媒体を Mac からまったく読めない状態にしないための方法である。数個のファイルを取得する、保存内容を確認する、必要な設定を読む、といった用途には十分に意味がある。一方で、Mac から正本媒体を書き換える、同期する、修復する、整理する用途には向かない。読み取り経路としては有効だが、運用主体を Mac に移す方法ではない。
正本媒体は、正本媒体として最も自然な形式を選ぶべきである。他の環境からのアクセスは、その正本形式を崩してまで実現するものではなく、補助経路として設計すればよい。LUKS + ext4 は Linux で扱うための形式である。Mac から読む必要があるなら、媒体形式を Mac 向けに変えるのではなく、Mac 上に Debian VM という Linux 読み取り環境を用意する。本稿の方式は、そのための現実的な折衷案である。
したがって、本稿の結論は「Mac では障害時だけ読むべきである」ではない。より正確には、「Mac では読み取り用途に広く使えるが、正本媒体の書き込み運用は Linux 実機に残すべきである」である。読み取りには、確認、参照、比較、検証、必要ファイルの取得が含まれる。書き込みには、同期、削除、移動、修復、権限変更が含まれる。この境界を明確にすれば、LUKS + ext4 の正本性を保ちながら、macOS からの実用的な読み取り経路を持てる。
参考文献
- id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
- id774, A Practical Lifecycle Guide to Operating LUKS Encrypted Disks（2026-06-07）. https://blog.id774.net/entry/2026/06/07/4864/
- id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
- id774, 暗号化ディスク運用手順を整理する（2026-05-31）. https://blog.id774.net/entry/2026/05/31/4829/
- Apple, File system formats available in Disk Utility on Mac. https://support.apple.com/guide/disk-utility/file-system-formats-dsku19ed921c/mac
- id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
- id774, 自由ソフトウェアだけで暗号化媒体をどこまで扱えるか（2026-06-03）. https://blog.id774.net/entry/2026/06/03/4849/
- id774, TrueCrypt 資産を GNU/Linux で保全する（2026-05-16）. https://blog.id774.net/entry/2026/05/16/4773/
- id774, SATA ポートが足りない時代のデータサーバー運用（2026-06-14）. https://blog.id774.net/entry/2026/06/14/4889/
- Oracle, Oracle VM VirtualBox – Downloads. https://www.oracle.com/virtualization/technologies/vm/downloads/virtualbox-downloads.html
- Oracle, Installing VirtualBox. https://www.virtualbox.org/manual/topics/installation.html
- Debian, Downloading Debian. https://www.debian.org/download
- Debian, Network install from a minimal USB, CD. https://www.debian.org/CD/netinst/
- Debian, Debian GNU/Linux Installation Guide for amd64. https://www.debian.org/releases/trixie/amd64/
- Debian, Debian GNU/Linux Installation Guide for arm64. https://www.debian.org/releases/trixie/arm64/
- Debian, Details of package cryptsetup in trixie. https://packages.debian.org/trixie/cryptsetup
- Oracle, Using a Raw Host Hard Disk From a Guest. https://docs.oracle.com/en/virtualization/virtualbox/6.0/admin/adv-storage-config.html
- diskutil(8) macOS man page. https://www.manpagez.com/man/8/diskutil/osx-10.12.6.php
- Michael Kerrisk, lsblk(8) – Linux manual page. https://man7.org/linux/man-pages/man8/lsblk.8.html
- Michael Kerrisk, cryptsetup(8) – Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup.8.html
- Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
- Michael Kerrisk, mount(8) – Linux manual page. https://man7.org/linux/man-pages/man8/mount.8.html
- Linux Kernel Documentation, ext4 General Information. https://docs.kernel.org/admin-guide/ext4.html
- Michael Kerrisk, ext4(5) – Linux manual page. https://man7.org/linux/man-pages/man5/ext4.5.html
- Michael Kerrisk, e2fsck(8) – Linux manual page. https://man7.org/linux/man-pages/man8/e2fsck.8.html
- Michael Kerrisk, blockdev(8) – Linux manual page. https://man7.org/linux/man-pages/man8/blockdev.8.html
- OpenSSH, OpenSSH. https://www.openssh.com/
- Oracle, Network Address Translation (NAT). https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/network_nat.html
- Michael Kerrisk, rsync(1) – Linux manual page. https://man7.org/linux/man-pages/man1/rsync.1.html
- Oracle, Shared Folders. https://docs.oracle.com/en/virtualization/virtualbox/6.0/user/sharedfolders.html