目次 — 知りたいところから読む
写真、ファイル、パスワード。個人データの中でも失うと取り返しがつかない領域を、外部クラウド事業者ではなく自前の基盤で管理する。ここでは、その3つを担う自己ホスト型ソフトウェアの構成と、実際のデータ移行で使った手法を記す。
Immich
Nextcloud
Vaultwarden画像: Immich / Nextcloud / Vaultwarden ロゴ、Wikimedia Commons
図: Duskcoil作成。データの保管、提供、復元検証の境界を示す。
写真管理: Immich
Immichはセルフホスト型の写真・動画管理ソフトウェアで、スマートフォンアプリからの自動バックアップ、顔認識、位置情報でのタイムライン表示など、商用クラウド写真サービスと同等の機能を持つ。バックエンドはPostgreSQL(pgvector拡張で類似検索に対応)、機械学習推論(顔認識・被写体検出)は別プロセスに分離されている。本体・機械学習推論・DB・キャッシュの4プロセスそれぞれに個別のメモリ上限を設定しており、機械学習推論プロセスには瞬間的な負荷スパイクを見込んで他より大きめの上限を割り当てている。
移行にあたっては、iCloud(17,784件)とOneDrive分を合わせて計19,868件の写真・動画を統合した。単純にファイルをコピーするだけでは「本当に全件揃っているか」を検証できないため、移行元の総件数を事前に把握した上でエクスポートし、Immich側の取り込み件数と突き合わせる手順を踏んだ。加えて、Immichのデータベースをダンプして移行前後の状態を保存し、後から差分を確認できるようにしている。
ファイル・連絡先・カレンダー: Nextcloud
Nextcloudはファイル同期・共有に加えて、CalDAV/CardDAVによる連絡先・カレンダーの同期機能を持つ。スマートフォン標準の連絡先/カレンダーアプリから、追加の専用アプリなしで同期できるのが実用上の利点である。
ファイル共有: Samba
Nextcloudとは別に、LAN内の端末から直接アクセスするための旧来型のファイル共有(Samba)も並行して運用している。読み書き可能な共有と、iCloud由来の写真を読み取り専用で公開する共有の2つを分けて公開しており、後者を読み取り専用にしているのはImmichの外部ライブラリと同じ理由(元データの誤変更・誤削除を防ぐ)による。
パスワード管理: Vaultwarden
VaultwardenはBitwardenのAPI互換なセルフホスト実装で、Bitwarden製の公式クライアント(ブラウザ拡張・スマートフォンアプリ)がそのまま使える。TOTP方式の2段階認証はサーバー側の追加設定(SMTP等)なしで動作するため、認証アプリを使った2FAを有効化している。
Immichへの複数の写真ソースの統合
Immichへは、単一のバックアップ元だけでなく、複数の外部ソースを読み取り専用の外部ライブラリとしてマウントしている。iCloud由来の写真、OneDriveの共有バックアップ、個人用OneDriveのバックアップという3つの異なる由来のディレクトリをそれぞれ独立したマウントポイントとしてコンテナに渡し、Immich側でそれぞれを別の外部ライブラリとして認識させている。読み取り専用でマウントしているのは、Immichのライブラリスキャン処理が誤って元データを変更・削除することを防ぐためで、写真という失うと取り返しのつかないデータに対する安全側の設計である。
EXIF情報に撮影日時が残っていないOneDrive由来のファイル(スクリーンショット等)は、そのままだとタイムライン上に無秩序に散らばってしまう。これに対しては、該当ファイルの日時情報を一律で最も古い日付に設定し、タイムラインの最下部(最古)にまとめて表示されるよう調整した。iCloudの「お気に入り」アルバム相当の情報も、専用アルバムを作成した上でお気に入りフラグを個別に設定し直し、933件相当のうち389件について移行済みにしている。
iCloud移行で直面したレート制限との戦い
iCloudからの写真移行(17,784件)は、単純な一括ダウンロードでは完了しなかった。使用しているダウンロードツールは1回の実行(1パス)ごとに正常終了する仕様だが、Apple側のレート制限により1パスでダウンロードできる件数に上限があり、超過すると新しい写真が取得できないままそのパスが終了する。この制限の発生条件は不規則で、実行結果を観測した限り明確な規則性を見出せなかった(300回近い実行のうち7割強はダウンロード0件で終わっていたが、時間帯や間隔との相関は確認できなかった)。対応として、フルダウンロードが完了するまでは常に再起動するモードで走らせ続け、地道にパスを重ねて完了させた。完了後は無限リトライ運用から、1日1回の定時実行に切り替え、無駄なAPI呼び出しを減らしている。
もう一つ直面したのが、公式に近いダウンロードツール以外からのAPIアクセスが一貫してブロックされる問題である。同じセッションCookieを使っていても、別のスクリプト経由でのアクセスは認証エラーで拒否された。クライアントの通信の特徴(TLS/HTTPフィンガープリント)で判定されていると推測している。この制約により、写真の一括削除のような、ダウンロードツール本体が持たない操作をスクリプトで自動化する道は事実上閉ざされている。iCloud Drive側は対象件数が少なく手作業で対応できたが、写真17,784件を手作業で扱うのは非現実的なため、削除自体は見送っている。回避策として、ダウンロードツール自身が持つアルバム単位の取得機能を使えば、特定アルバム(お気に入り等)の中身一覧だけは取得できることを見つけ、これを使ってお気に入り情報の移行を実現した。
バックアップの復元検証
バックアップを取得しているだけでは「本当に復元できるか」は分からない。最新のImmichデータベースダンプを、テスト用に立てた別のPostgreSQLコンテナへ実際に復元し、復元後の資産件数が本番環境の件数と完全に一致することを確認する検証を実施済みである。取得したバックアップを一度も検証せずに放置するのは、バックアップを取っていないのとリスクの面でさほど変わらないという考え方に基づく。
バージョン固定という運用判断
Nextcloud・VaultwardenはWatchtowerの自動更新対象から明示的に除外し、コンテナイメージのタグをバージョン番号で固定している。Nextcloudは連絡先・カレンダーの実データを扱うアプリケーションであり、メジャーバージョンをまたぐ更新には内部コマンド(occ)を使ったアップグレードパスの互換性確認が必要になるため、リリースノートを確認した上で手動でタグを上げる運用にしている。Vaultwardenはパスワード管理という性質上、意図しない自動更新自体がリスクになるため、変更履歴を確認してから手動でタグを上げる方針を徹底している。
別ファイル管理ゆえの見落とし
Immichは定義ファイルが他の主要サービス群とは別に独立して管理されている。この構成上の理由から、サーバー全体の待受設定を横断的に点検した際、一度目の点検ではImmichだけが対象から漏れ、全インターフェースに公開されたままになっていたことが後日判明した。19,868件という写真・動画の総量を考えると、見落としとしては重大なものであり、発覚後は速やかにループバック限定へ修正している。単一の定義ファイルにまとまっていないサービスほど、横断点検の対象から抜け落ちやすいという教訓につながった。
移行における不可逆な判断
写真・ファイル・パスワードいずれも、移行後は元のクラウドサービス側のデータを削除し、自前基盤側を正本として運用する方針を採っている。バックアップとして両者を並行運用する選択肢もあったが、二重の正本は更新の反映漏れによってどちらが最新か不明になるリスクを生むため、明確に一本化した。
バックアップの完了ログだけで復元できると判断してよい？
実際の復元試験が必要である。ファイルに加えてデータベース、設定、バージョンの対応も確認する。
コメント
コメントの投稿にはログインが必要です
まだコメントはありません。