ソース、データベース、アーティファクト、キャッシュ、バックアップでは耐久性やパフォーマンスの要件が異なるため、セルフホスト開発には独立したストレージ計画が必要です。
実験段階では大きなディレクトリを1つ使う方法でも問題ないかもしれませんが、容量アラート、スナップショット、権限、移行、復元の範囲が曖昧になります。ホストを再構築しても保持すべき状態と、コードから再作成できるデータを特定できるようにしましょう。
データを再構築可能性で分類する
ソースリポジトリ、データベースの状態、アップロードされたテストデータ、コンテナレジストリのレイヤー、パッケージキャッシュ、ビルド成果物、ログ、シークレット、バックアップのエクスポートを分けてください。それぞれに所有者と損失時の影響を割り当てます。
役割ベースのホームラボ用ストレージ設計も同じ原則に従います。ブート、アプリケーションの状態、大容量データ、バックアップは、同じハードウェアを共有しているというだけで、同じポリシーを継承すべきではありません。
ソースコードがリモートGitオリジンにすでにある場合もありますが、未プッシュのブランチはそうとは限りません。レジストリのレイヤーは再構築できても、プライベートなベースイメージはできない場合があります。ディスクを選ぶ前に、こうした違いを書き出してください。
アクティブなデータと大容量アーティファクトの配置を計画する
| データの役割 | 推奨配置 | 理由 |
|---|---|---|
| データベース | 低レイテンシの保護されたボリューム | 変更可能で、一貫性が重要 |
| Gitリポジトリ | 保護されたボリュームとリモートミラー | 小容量で価値の高い履歴 |
| レジストリ | 保持期間を設定した容量重視のストレージ階層 | 大容量で、一部は再構築可能 |
| ビルドキャッシュ | 容量を制限した高速スクラッチ領域 | 変更頻度が高く、破棄可能 |
| バックアップ | 独立した保存先 | プライマリの障害時にも維持する必要あり |
データベースファイルと、頻繁に更新される大容量のビルドキャッシュに、同じ無制限の容量ルールを適用しないでください。データベースボリュームがいっぱいになったとき、キャッシュのクリーンアップを緊急対応にしてはいけません。
すべての役割が1つの物理プール上にある場合でも、クォータを設定するか、データセットを分けてください。論理的に分離すると、スナップショット、権限、復元順序が明確になります。
開発者アクセスとサービスIDを分離する
開発者にはリポジトリ、プレビュー、データベースへのアクセスが必要です。ビルドランナーにはより限定された書き込み権限が、バックアップジョブには読み取り権限と保護された保存先が1つ必要です。これらの役割でホスト管理者アカウントを共有しないでください。
ノートパソコンからのマウントでは、コンテナエンジンのデータルート全体ではなく、プロジェクトデータを公開してください。クライアントとIDモデルに応じてSMBまたはNFSを選びましょう。次の判断には、こちらのSMBとNFSの比較ガイドが役立ちます。
シークレットはソースリポジトリや、再構築可能なキャッシュの外に保存してください。開発サーバーがなくてもアクセスできる場所に、暗号化された復旧用データを保管しましょう。
アプリケーションの整合性を考慮してバックアップを設計する
Gitリポジトリ、データベース固有のダンプ、デプロイ定義、シークレットへの参照、再生成できないアップロードファイルをバックアップしてください。公開イメージや再生成可能なビルド成果物に、同じ保存期間の予算を割くのは避けましょう。
コンテナの復元ワークフローからもわかるように、Composeファイル、ボリューム、シークレットはそれぞれ異なる復旧対象です。ホスト全体を無差別にスナップショットするのではなく、それぞれを意図的に取得しましょう。
リポジトリを1つ、データベースを1つ、隔離されたテスト環境に復元してください。バックアップが成功したと判断する前に、ユーザー、拡張機能、権限、アプリケーションの起動を検証しましょう。
フォルダーのサイズではなく、役割ごとに拡張する
データベースやビルドのレイテンシーがボトルネックになったら、高速ストレージを追加してください。レジストリやデータセットが増えたら、容量重視のストレージを追加しましょう。実験的なワークロードが安定したサービス基盤を脅かすようになったら、ホストをもう1台追加してください。
空き容量、スナップショットの増加、データベースのレイテンシー、キャッシュの入れ替わり、バックアップ所要時間をそれぞれ個別に監視してください。プールの使用率を示す単一の割合では、どの役割に変更が必要か判断できません。
1回のクリーンアップ、アップデート、または権限エラーによって、稼働中のデータとその復旧用コピーの両方が失われる状態になったら、統合をやめましょう。空のホストで、定義と保護された状態からサービスを再作成できることが、ストレージ計画の成功です。
最終セットアップのルール
すべてのサービスに明確な役割があり、状態が保護され、アクセス経路が制御され、復元がテスト済みで、トポロジーを分割または拡張するための測定可能な条件があれば、このセットアップは合格です。
NASとサーバーのセットアップ
続きを読む

寮のサーバーは、睡眠や勉強、ビデオ通話の妨げにならないほど静かに動作しますか?
はい。低消費電力のハードウェアを使い、ストレージの振動を抑え、負荷の高い処理をスケジュールし、部屋で騒音を確認すれば、寮のサーバーは目立たずに運用できます。

寮の部屋から初めてのアパートへ持ち運べる学生向けホームラボ
サービスを部屋ごとのネットワークから切り離し、ハードウェアを最小限に抑え、状態をバックアップし、スムーズな移設をリハーサルして、学生のホームラボを持ち運びやすく保ちましょう。

アカウントや個人ファイルを共有せずに、ルームメイトと1台のホームサーバーを共有する方法
ルームメイト一人ひとりに名前付きのIDとプライベートストレージを用意し、共有権限は必要なものだけ付与しましょう。管理、バックアップ、利用終了時の対応はそれぞれ分けて管理します。



