最初のボリューム選択が更新、障害、移行、将来の拡張で何が残るかを決めるため、アプリをインストールする前にストレージを計画してください。
セルフホスト型アプリは、ユーザーに見えるファイルだけを保存することはほとんどありません。データベース、設定、シークレット、インデックス、サムネイル、ログ、一時ファイル、バックアップなども作成し、それぞれ異なるパフォーマンスと復旧要件があります。インストール前にこれらの役割をマッピングすることで、ブートディスク、アプリ状態、交換不可能な家庭内データが誰も安全に再構築できない一つのフォルダになるのを防ぎます。
ドライブやフォルダを選ぶ前にデータ役割をリストアップする
サービスの成果から始め、それを生み出すために必要なすべてのデータ役割を特定します。写真ライブラリには、オリジナル画像、アップロード中のファイル、データベース、サムネイル、機械生成インデックス、エクスポートファイルがあるかもしれません。メディアサービスには、ソースファイル、アートワーク、視聴状態、トランスコードキャッシュ、設定があるかもしれません。パスワードサービスは容量は小さいかもしれませんが、バックアップの整合性とアクセス制御に非常に敏感です。
ホームラボ計画ガイドでは、コンテナを展開する前に目的、ストレージ、バックアップ、ネットワーク、セキュリティ、ドキュメントを定義することを推奨しています。目的を先にしてストレージを後にする順序により、ストレージマップが後で変わるかもしれないアプリ名ではなく、実際のワークフローに結びつきます。
各役割について、所有者、交換可能かどうか、成長速度、変更頻度、低遅延が必要かどうか、許容できる復旧ポイントを記録します。これらの回答が、カタログ内のアプリカードの数ではなく、ストレージ設計を決定します。
システム、アプリ状態、ユーザーデータ、キャッシュ、バックアップのレイヤーを分ける
オペレーティングシステムとアプリケーションコードは交換可能であるべきです。永続的なアプリケーション状態には、データベース、設定、アカウント記録、インデックス、再インストール後にサービスを認識可能にするためのシークレットが含まれます。ユーザーデータには、写真、ドキュメント、メディア、メモ、その他実際に価値のあるファイルが含まれます。キャッシュや一時データは通常再構築可能であるべきです。バックアップコピーは、ライブサーバーが故障した場合でも回復可能でなければなりません。
クリーンなアプリストレージガイドでは、コンテナ化されたサービスがホスト管理のデータセットやパスに接続されるため、インストール前にアプリケーションストレージを配置することを推奨しています。アプリケーションの展開と接続されたストレージの分離により、アプリの更新や再インストールがユーザーデータの移行になるのを防ぎます。
| ストレージ層 | 典型的な内容 | 推奨される扱い |
|---|---|---|
| システム | Linux、ダッシュボード、コンテナエンジン | 内部SSD;文書化された手順から再インストール可能 |
| アプリケーション状態 | データベース、設定、シークレット、インデックス | 永続的なパス;頻繁で一貫したバックアップ |
| ユーザーデータ | 写真、ドキュメント、メディア、プロジェクト | バージョニングと独立したバックアップが可能な容量プール |
| キャッシュ | サムネイル、トランスコード、一時ダウンロード | 制限付きの高速ストレージ;通常はバックアップ対象外 |
| バックアップ | 回復用コピーとエクスポートされた設定 | 障害ドメインを分離し、復元テストを行う |
アクセスパターンに合わせてストレージメディアを選ぶ
容量と速度は異なる要件です。データベースやインデックスは多数の小さな読み書きを行うため、低遅延のSSDストレージが有利です。大規模なメディアライブラリ、アーカイブ、ロールバックアップは手頃なHDD容量が必要かもしれません。一時的なトランスコードや生成プレビューは十分な速度と明確な容量制限が必要ですが、オリジナルと同じ保護は不要です。
Better Stackのボリュームガイドは、永続的なコンテナデータはコンテナ自体の置き換えよりも長く存続すべきだと説明しています。その独立したデータライフサイクルモデルは、階層化されたホームサーバーレイアウトを支持しています。遅延に敏感な状態はSSDに、ユーザーデータの大容量は保護された容量プールに、使い捨てキャッシュは復旧に影響しないパスに置きます。
アプリケーションのデータベースを、サイズが小さいからといって遅いスリープ状態のディスクに置かないでください。再構築可能なサムネイルのバックアップに高価なSSD容量を無駄に使わないでください。ストレージメディアは各パスのワークロードに合わせるべきです。
最初のインストール前に安定したパスとマウントを作成する
アプリケーションは、ソフトウェアの変更を経ても意味が変わらないパスを参照すべきです。例えば、 /data/photos, /appdata/photo-service、および /cache/photo-service アプリが置き換えられた後も理解可能であること。単に一時的なコンテナIDや自動生成されたボリューム名だけのパスは、監査や移行が難しくなります。
個人用ホームサーバー設計の記事では、大容量の追記専用メディア、高頻度更新のデータベース、再現可能なアプリケーション定義を分けています。なぜなら、それぞれが異なるバックアップおよび復元方法を必要とするからです。データタイプ別の回復モデルは、マウントパスがアプリケーション内にすべてを隠すのではなく、データの役割を明示すべき理由を示しています。
アプリ起動前にすべてのディスクやプールが起動時にマウントされることを確認します。使い捨てデータで2回の再起動と1回の一時的なストレージ切断をテストします。マウントがない場合はサービスを停止するか、目に見えるエラーを出すべきであり、アプリケーションが起動ディスクの空のディレクトリに新しいファイルを書き込むことを許してはいけません。
フォルダツリーと並行して権限とサービスの所有権を計画する
明確なフォルダ構造だけでは不十分です。すべてのコンテナが広範な管理者権限で動作している場合は特にそうです。各サービスはその機能に必要なパスのみを読み書きすべきです。家庭のユーザーは自分のフォルダと承認された共有データにアクセスできる必要がありますが、バックアップ先やプライベートなアプリケーション状態は一般共有として公開されるべきではありません。
Linux Handbookは、ファイルアクセスはユーザー、グループ、その他の権限によって決まると説明しています。その所有権とグループの権限モデルは、インストール前にサービスのIDをストレージパスにマッピングする実用的な基盤を提供します。
計画したすべてのパスの横に、想定される所有者とアクセスモードを書き込みます。そして拒否される操作をテストします。メディアサービスはバックアップリポジトリを変更してはいけませんし、一時的なダウンローダーはプライベートドキュメントを閲覧してはいけません。一般的な家庭用アカウントはアプリのデータベースやシステムファイルを変更してはいけません。
成長、バージョン、リカバリーコピーのための容量を見積もる
今日見えているファイルだけのサイズで容量を決めないでください。予想される年間成長、アプリケーションの状態、サムネイルやインデックス、スナップショット、ファイルのバージョン、作業用の一時領域、データベースのダンプ、更新や修復に必要な空き容量も加えましょう。ミラーリングやパリティ後の使用可能容量が重要な数字であり、ドライブラベルに記載された合計容量ではありません。
セルフホスティングのバックアップガイドでは、データベース、ユーザーファイル、設定を分けて管理します。これら3つすべてが動作するサービスを再構築するために必要だからです。その3部構成のリカバリーインベントリは、メディアフォルダの2つ目のコピーが完全なアプリケーションバックアップであると仮定するのではなく、容量計算に含めるべきです。
成長するデータベース、失敗したクリーンアップジョブ、またはキャッシュの急増がシステムディスクを満たさないように運用予備を確保してください。実用的な開始モデルは、現在のデータに予想される成長、選択した冗長性オーバーヘッド、バージョン履歴オーバーヘッド、1つのバックアップまたはスナップショット作業領域、および通常の運用のために少なくとも15~20%の空き容量を含みます。
アプリを追加する前に再構築と拡張を証明してください。
ストレージプランは、あるサービスを削除して再構築しても、その状態がどこにあるか推測する必要がないときに準備完了です。アプリケーション定義をエクスポートし、そのデータベースや設定を一貫してバックアップし、ユーザーデータパスを保持し、テスト用の場所にサービスを復元します。その後、ドライブの追加、データセットの移動、またはブートディスクの交換が他のすべてのアプリの再編成を必要としないことを確認してください。
セルフホストのバックアップに関する記事では、通常のファイルとライブデータベースを区別し、コピーされたボリュームが常に復元可能であると仮定するのではなく、アプリケーション整合性のあるデータベースエクスポートを推奨しています。そのゼロからの復元要件は、ストレージ設計がダッシュボードの外に存在するかどうかの最終テストです。
最初の3つの接続されたホームサーバーサービスの選び方に関するZimaSpaceのガイドは、初期のストレージ役割を制限するのに役立ちます。ZimaBoard 2 ミニホームサーバーは、最初のスタックが小さく、ストレージを意図的に接続できる場合にアプリ優先のレイアウトに適しています。ZimaCube 2 AI NASは、マルチドライブ容量、共有ファミリーデータ、スナップショット、およびストレージ優先の拡張が最初から必要な場合により明確なベースとなります。
すべての永続パスに所有者、バックアップルール、成長予測、および交換可能なシステム層の外部にテスト済みの保存先が設定されてから、最初のアプリをインストールしてください。
NAS&サーバー設定
もっと読む

研究論文、ノート、プライベートドキュメント向けのローカルRAG環境
元のドキュメントを正本として扱い、インデックス作成を再現可能にし、引用を必須とし、交換可能なモデルを非公開のソースデータから分離する。

開発者はなぜプライベートDNS、VPN、テストアプリにゲートウェイノードを使うのか?
ゲートウェイノードにより、プライベートアプリには管理された1つの名前とアクセス経路を提供し、コンピュートノードは外部に公開せず、交換可能な状態に保てます。

Composeファイル、シークレット、永続データを分離して再現性のあるアプリケーションスタックを構築する方法
Compose定義の移植性を保ち、シークレットを保護し、アプリデータを個別にバックアップして、クリーンなホスト上でスタックを再構築できるようにします。

