スマホの写真を自宅へ：Immich 初期設定・アプリ連携編

前回の記事で、ついに中古ミニPC上で Immich が産声を上げました！
（まだの方はコチラ→Docker で Immich を立ち上げる：自宅サーバー本番稼働編）

ブラウザに「Welcome」の画面が出たあの瞬間、管理人は「よっしゃ！！」と小躍りしました。・・・が、本当の戦い（というか楽しみ）はここからです。

管理者アカウントの作成と初期設定
スマホアプリ（iOS/Android）との連携
「安全に使い続けるため」のバックアップ・復元・セキュリティ設計

結論：

この構成は「家庭内LANでの利用」が前提です。自前サーバーは自由ですが、その裏には「自己責任」という境界線があります。この記事でその境界線の引き方をマスターして、Googleフォトからの完全自立を果たしましょう！！

はじめに：この記事の構成と「ローカル運用」の前提
管理者アカウントを作成しよう（ブラウザ操作）
スマホアプリをインストールして連携する
写真を流し込む：バックアップ設定の神髄
【重要】自前サーバー運用の「覚悟」と「境界線」
データを守る「バックアップ」と「復元」
セキュリティとトラブルシューティングの思考
まとめ：Google フォトからの「完全自立」

はじめに：この記事の構成と「ローカル運用」の前提

まず、大切なお話を。このシリーズで解説している構成は、基本的に「自宅のWi-Fi（LAN）内での利用」を前提としています。

「えっ、外出先から見られないの？」と思うかもしれませんが、今のままの設定（HTTP通信）でポートを世界中に開放するのは、玄関の鍵をかけずに外出するのと同じくらい危険です。外部公開したい場合は「HTTPS化」が必須になりますが、まずは安全なローカル環境を完璧に整えるところから始めましょう！！

でも、安心してください。「外出先から安全にアクセスする方法」については、また別の記事でじっくり解説する予定です。まずは一歩ずつ、確実に足元を固めていきましょう！！

管理者アカウントを作成しよう（ブラウザ操作）

ブラウザで http://ミニPCのIPアドレス:2283 にアクセスし、「Getting Started」をクリックして管理者アカウントを作成します。

このアカウントは、いわば、あなたの写真庫の「マスターキー」です。

外部公開した場合、ここを突破されるとすべての写真が丸見えになります。パスワードは以下の条件を満たす「マジで強いやつ」を設定してください。

12文字以上
英数字・記号を混ぜたランダムな文字列
パスワードマネージャーでの管理を強く推奨

「123456」なんていうヨコシマな横着は厳禁です！！

管理人は、パスワードマネージャ（Bitwarden）を愛用しています。

自分でも覚えられない超長い文字のランダム文字列を設定しています（笑）

スマホアプリをインストールして連携する

管理人の本命、スマホアプリとの連携です。Immich は、スマホで撮った写真を自動でサーバーへ送り込んでこそ真価を発揮します。

1. App Store または Google Play で「Immich」を検索してインストールします。
2. アプリを開くと「Server Endpoint URL」を聞かれます。ここに

http://ミニPCのIPアドレス:2283

と入力します。

【接続できない時のヒント】
もし「サーバーに接続できない」と怒られたら、URLの末尾に /api を付けてみてください。（例：http://192.168.x.x:2283/api）

環境によってはこのサフィックスが必要な場合があります。ちなみに管理人は付けなくても動いていますが、おまじないとして覚えておくと便利ですよ！！

写真を流し込む：バックアップ設定の神髄

バックアップ設定では、管理人の場合は「カメラロール（DCIM）」を丸ごと指定しています。

設定のコツは、「バックアップの自動化」です。
・「Background Backup」をONにする
・「Only when charging（充電中のみ）」をONにする

これで寝ている間に勝手にサーバーへ写真が吸い込まれていきます。

ここで大事なスタンスの話をひとつ。
Immich公式も「Immichをデータの最終保存先（唯一の場所）にしないでください」と公言しています。あくまで「大事な写真のバックアップを取り、かつ快適に見返せる」ことを支援するツールだというわけです。この「データの多重化」の精神こそが、デジタル時代の家内安全の秘訣なんですよね。

【重要】自前サーバー運用の「覚悟」と「境界線」

さて、ここまでの記事で紹介してきた、ミニPCによるサーバー構成には明確な「限界」があります。これを理解せずに使うのは、地図を持たずに砂漠へ行くようなものです。

1. 適用範囲の限界
この構成（ミニPC1台）は、あくまで「個人・小規模利用」前提です。数万枚程度なら快適ですが、100人のユーザーで同時に使うような本番用途には、今の設計では耐えられません。

2. 耐久性の限界
ミニPC1台の構成は、専門用語で言うと「単一障害点（SPOF）」です。PCが物理的に壊れたらすべて止まります。「自作したからには、自分で守る」。この覚悟がセルフホストの神髄です。

なぜクラウドではなく「自己ホスト」か
月額料金をケチる（ドケチな管理人の動機）のも一つですが、最大のメリットは「データの所有権」です。クラウドサービスは、規約一つでアカウントが凍結されたり、サービスが終了したりする可能性がありますが、自己ホストは自分次第です。

自己ホストとは、手間がかかる代わりに、誰にも邪魔されない「聖域」を手に入れる行為なのです。

データを守る「バックアップ」と「復元」

皆さん、お疲れさまでした。
ここまでついてきていただいた皆さまは、きっと素晴らしいマイサーバーが隣で頼もしく鎮座してくれていることでしょう。

ようこそ、セルフホストの世界へ。

・・・といいたいところですが、ここで一つ、セルフホストするにあたって
最も大事なことを、最後にお伝えします。

セルフホストはすべて自己責任です。

「明日PCが燃えても大丈夫か？」を常に考えてください。
Immichなら、画像データとデータベース（PostgreSQL）の両方を守る必要があります。

管理人の場合は、TrueNAS Scale というOSでサーバーを運用しており、そこから定期的に別の外付けHDDへ rsync コマンドでバックアップを取っています。本体とバックアップ先、物理的に2台のドライブに分けることが鉄則です！！

そしてこれまた超重要なのが、「具体的な復元方法」を把握しておくことです。バックアップを取っていても、戻し方が分からなければただのゴミです。「戻せて初めてバックアップ」と言えるわけですね。

ここでは、今回紹介した構成であるUbuntu Server + Docker + 外付けHDDという構成での具体的なコマンドを紹介します。

バックアップの取り方

準備：外付けHDDをマウントする

まず、Ubuntu Serverに外付けHDDを認識させ、読み書きできる状態にします。基本の流れは以下の通りです。

1. HDDのデバイス名（/dev/sdb1など）を確認

lsblk

2. マウントポイント（置き場所）の作成

sudo mkdir -p /mnt/backup

3. マウント実行

sudo mount /dev/sdb1 /mnt/backup

※デバイス名は環境によって変わるので、lsblk　の結果（サイズなどで判断）をよく見てください。

再起動しても自動で繋がるようにする

手動マウントだと再起動のたびにコマンドを打つ必要があり、バックアップを自動化（cron等）したときに失敗してしまいます。以下の手順で自動マウントを設定しましょう。

1. HDDの情報を調べる（UUIDとTYPEを確認）

sudo blkid /dev/sdb1

出力例: /dev/sdb1: UUID=”xxxx…” TYPE=”ext4” … と表示されます
このUUIDと、TYPEは後で使用するので、どこかにメモしておいてください。

2. fstabを開く

sudo nano /etc/fstab

3. 末尾に以下の内容を追記して保存

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/backup ext4 defaults 0 0

ここで、先ほどメモしたUUIDとTYPEに書き換えてください。

4. 設定が正しいかテスト（エラーが出なければ成功）

sudo mount -a

これで、再起動しても勝手に外付けHDDが

/mnt/backup

に繋がるようになります。準備万端ですね！！

バックアップを取ってみよう

1.画像データを外付けHDDへ同期します。

rsync -av --delete /path/to/immich/library/ /mnt/backup/immich/library/

※ /path/to/immich/library は .env ファイルの UPLOAD_LOCATION で指定したパスに置き換えてください。

2.データベース（PostgreSQL）のダンプを取得します。

docker exec immich_postgres pg_dumpall -c -U postgres > /mnt/backup/immich/db_dump.sql

バックアップが取れているか確認する

1.ファイルの存在とサイズを確認します（サイズが0だと失敗しています）。

ls -lh /mnt/backup/immich/

2.db_dump.sql の末尾がSQLになっているか目視確認します。

tail -5 /mnt/backup/immich/db_dump.sql

末尾にエラーメッセージではなく GRANT などのSQL文が並んでいれば成功です。

もしもの時の復元方法

さて、いよいよここからが本番です。マジでこれが一番大事です。
一回はこの手順を踏んでおくことを強くお勧めします。
一回復旧できた。この経験が、セルフホストの不安を大きく払拭してくれます。

1.まずImmichを停止します。

cd ~/Applications/immich
docker compose down

2.バックアップした画像データを元のディレクトリへ戻します。

rsync -av /mnt/backup/immich/library/ /path/to/immich/library/

3.Immichを再起動します（DBコンテナを先に立ち上げます）。

docker compose up -d immich_postgres
sleep 10

4.DBのダンプを流し込みます。

cat /mnt/backup/immich/db_dump.sql | docker exec -i immich_postgres psql -U postgres

5.残りのコンテナも起動して、復旧を完了させます。

docker compose up -d

※コンテナ名（immich_postgres）は docker compose ps で確認できます。

これは、まだ動いていないコンテナ（Immich本体や機械学習エンジンなど）をすべてバックグラウンドで立ち上げるコマンドです。実行後、

docker compose ps

を打ってすべてのコンテナが「Up」になっていれば、あなたの Immich は無事に過去から現代に蘇ったことになります！！

Tips　なんでDBだけ先に立ち上げるの？

アプリ（Immich本体）を一斉にに立ち上げると、中身が空っぽのDBを見に行ってエラーを吐いたり、変な初期データを書き込んじゃったりする可能性があります。
だから、まず「箱（DB）」を立ち上げ、「中身（データ）」を戻し、準備が整ってから
「主役（アプリ）」を呼ぶ。という順序が、最も安全で確実な復元方法なんです。

一度、テスト環境で復元を試しておくことを強くおすすめします。「いざとなればなんとかなる」ではなく、「いざとなっても確実に戻せる」状態を目指しましょう！！