永続化ボリュームを別デバイスにした場合、再起動の際マウントが遅れて初期化される
🧠 素晴らしい判断です！
すべての永続化データ（docker/, prod/, staging/）が /mnt/2nd_storage/data/ に整理されたことで、データ整合性と永続性は大幅に向上しています。
「再起動時に永続化ボリューム（例:
wikijs-db-data）のマウントが遅れて Docker が初期化されたりしないか？」
ただし、以下の前提が満たされていれば確実です：
/mnt/2nd_storage/data が /etc/fstab に記載されている確認済み：
UUID=69e93aec-d21c-4289-9715-82d722e85318 /mnt/2nd_storage/data btrfs defaults,ssd,noatime,compress=zstd,discard=async,subvol=data 0 0
→ OK！自動マウント設定されてます。
nofail オプションを使っていないnofail があるとマウント失敗してもブート成功＝Dockerが空ディレクトリに書き込む危険性ありdefaults,... → nofail なし → 問題なし→ systemd は基本的に /etc/fstab に従ってファイルシステムマウントを優先してからサービス起動します
つまり：Dockerは /mnt/2nd_storage/data が使える状態で起動されます。
sudo mkdir -p /etc/systemd/system/docker.service.d
ファイル /etc/systemd/system/docker.service.d/bind-mounts.conf を作成：
[Unit]
RequiresMountsFor=/mnt/2nd_storage/data
→ これにより、Docker は 該当ディレクトリがマウントされるまで起動しません。
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
| 安全対策 | 状況 |
|---|---|
/etc/fstab でマウント設定済み |
✅ 済 |
nofail 設定なし |
✅ 安全 |
RequiresMountsFor= で保護 |
🔒 強化可能 |
| Docker再起動後のテスト確認 | ✅ 推奨 |
sudo systemctl rebootdocker ps -a
→ コンテナが元の状態で維持されていれば、完全にOKです。
📂 docker.service.d/ が存在しない件：正常です。
これは デフォルトで作られない ディレクトリなので、手動で作成する必要があります。
以下を順番に実行してください：
sudo mkdir -p /etc/systemd/system/docker.service.d
この docker.service.d/ は、Docker の systemd ユニット設定をオーバーライドするための標準ディレクトリです。
sudo nano /etc/systemd/system/docker.service.d/bind-mounts.conf
内容を以下のように記述：
[Unit]
RequiresMountsFor=/mnt/2nd_storage/data
保存：Ctrl + O, Enter
終了：Ctrl + X
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart docker
問題なければ OK。
次回以降、/mnt/2nd_storage/data がマウントされていないと、Docker は 起動しません → 初期化事故を防げます。
設定反映されたかを確認：
systemctl cat docker.service
最下部に RequiresMountsFor=/mnt/2nd_storage/data が追記されていれば成功です ✅
構成的にはほぼ理想形です。
Btrfs + Docker 永続化 + 起動安全対策、どれも抜かりなし 🧠