NAS、Docker、リモートアクセス向けのホームサーバーOSの選び方

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Choose a Home Server OS for NAS, Docker, and Remote Access - Zima Store Online

簡単な答え

ホームサーバーOSは、NASストレージ、Dockerアプリ、リモートアクセス、仮想化、軽量制御のどの役割が最も重要かを決めて選びましょう。

ほとんどの初心者にとって：

ファイルストレージ、多ドライブ保護、スナップショット、バックアップが最も重要なら、NAS優先のシステムを選びましょう。
主にDockerアプリ、メディアツール、スマートホームサービスを使いたいなら、アプリ優先のシステムを選びましょう。
複数の隔離されたシステムを動かしたいなら、仮想化優先のプラットフォームを選びましょう。
古いハードウェアで手動制御を望むなら、軽量なLinuxベースのセットアップを選びましょう。
リモートアクセスは、ストレージ、ユーザー、権限、アプリの公開が明確になってから計画しましょう。

良いホームサーバーOSは、単にインターフェースがきれいなものではありません。主なワークロード、ハードウェア、データリスク、初期設定後のシステム維持能力に合ったものです。

ホームサーバーOSは最初にどの問題を解決すべきか？

ホームサーバーOSは、最も重要なサーバーの問題を最初に解決すべきです。家族のファイルを安全に保つことが最大の関心事なら、ストレージが決定の中心になります。いくつかのセルフホストアプリを動かすことが目的なら、Dockerやアプリ管理が重要になるでしょう。多くのシステムを隔離して動かしたいなら、仮想化が主な要件になります。

これは重要です。なぜなら、NAS、Docker、リモートアクセスは異なる役割だからです。システムは複数をサポートできますが、どこか一つの分野で最も強力であることが多いです。

CasaOS、TrueNAS、Unraid、OpenMediaVault、Proxmox、または単なるLinuxサーバーの名前を比較する前に、次のことを考えてください：

このサーバーはどんなデータを保持しますか？
どんなアプリを動かしますか？
誰がアクセスする必要がありますか？
アクセスはローカルのままですか、それともリモートになりますか？
どれだけのハードウェアを持っていますか？
何かが壊れたときにこのシステムを維持できますか？

最良の選択は人気ではなく、ワークロードの優先順位から始まります。

ホームサーバーOSがバランスを取るべき3つの役割

ほとんどのホームサーバーOSの選択は、ストレージ、アプリ、アクセスの3つの役割に集約されます。難しいのは、どれがアーキテクチャを支配すべきかを決めることです。

NASとファイルストレージ

NASとファイルストレージは、データの保存場所、ドライブの配置、ファイルの共有方法、障害発生時の復旧方法に関わります。

ストレージ優先のセットアップでは、アプリのインストール前にドライブのレイアウトを考慮すべきです。ZFS、RAIDのようなレイアウト、プール、スナップショット、バックアップ先はすべて最終的なシステム設計に影響を与えます。

TrueNAS ZFSストレージプールのホワイトペーパーでは、プールのレイアウトが読み取りIOPS、書き込みIOPS、ストリーミング速度、使用可能容量、耐障害性に影響を与えることが説明されています。また、最適なレイアウトはワークロードのバランスによって異なるため、すべての指標を最大化する単一のプール構成は存在しないと警告しています。

だからストレージ重視のホームサーバーはダッシュボードのデザインだけで選ぶべきではありません。ドライブ構成やリカバリープランニングがアプリの利便性より重要になることがあります。

Dockerアプリとセルフホストサービス

Dockerアプリはメディアサーバー、ダッシュボード、自動化ツール、データベース、同期ツール、その他のセルフホストアプリの実行に関するものです。

アプリ優先OSはサービスのインストールと管理を容易にしますが、Dockerではアプリデータの保存場所、公開ポート、コンテナがローカルネットワーク内か外部からアクセス可能かを理解する必要があります。

Dockerのポート公開ドキュメントは未公開のコンテナポートはデフォルトでホスト外からアクセスできず、公開ポートはホストのIPアドレスにマッピングされると説明しています。また、ポート公開は制限しないとホスト外からアクセス可能になるリスクがあると警告しています。

これはアプリホスティングが単なる「アプリをインストールして終わり」ではないことを意味します。ポートマッピング、データパス、ネットワーク、権限もOS選択の一部です。

リモートアクセスとネットワークセキュリティ

リモートアクセスとは、家を離れたときにホームサーバーに接続する方法のことです。VPN、プライベートメッシュネットワーク、トンネル、リバースプロキシ、証明書、権限、公開サービスなどが関わる場合があります。

初心者はホームサーバーOSを先に選び、リモートアクセスを後回しにする誤りを犯しがちです。認証やネットワーク境界が理解される前にダッシュボードやアプリ、ファイル共有が公開されるとリスクが生じます。

TailscaleのDockerドキュメントはリモートでサービスにアクセスするには公開インターネットにさらす必要があることが多く、これがセキュリティリスクを生む一方、コンテナをプライベートなtailnetに接続すれば公開せずにアクセス可能になると説明しています。

ホームサーバーでは、リモートアクセスはローカルセットアップの回避策ではなく、制御されたアクセス経路として計画すべきです。

ホームサーバーOSの選択方法の比較

システムを選ぶ前にNAS-Docker-アクセス優先マトリックスを使ってください。目標はどの責任範囲がセットアップを主導すべきかを決めることです。

フレームワークモジュール	重要な質問	決定を助けるもの	最適な方向性
主要なワークロード	サーバーはまず何をすべきか：ファイルの保存、アプリの実行、または複数システムのホスティング？	NAS優先OS、アプリ優先OS、仮想化プラットフォーム、または軽量Linuxセットアップが必要かどうか	NAS優先 / アプリ優先 / 仮想化優先 / 軽量
ストレージの責任範囲	ドライブ構成、バックアップ、ファイル共有、リカバリーの重要度はどのくらいですか？	ストレージ保護がアプリより先にOS選択の指針となるかどうか	NAS優先 / ストレージ重視
アプリホスティングモデル	シンプルなDockerアプリ、アプリストア、手動コンテナ、または分離されたサービスのどれが欲しいですか？	初心者向けアプリ、手動Docker、またはVM/LXC分離が必要かどうか	アプリ優先 / 仮想化優先
リモートアクセスの境界	サーバーはローカルのみ、VPNベース、または選択されたサービスを通じて公開されますか？	OSとスキルレベルが安全なアクセスと権限をサポートできるか	リモートアクセス / セキュリティ優先
ハードウェア適合性	古いハードウェア、混在ドライブ、専用NAS構築、またはより強力な仮想化ホストを使用していますか？	システムがCPU、RAM、起動方法、ドライブレイアウト、拡張に合っているか	軽量 / NAS優先 / 仮想化優先
メンテナンスの道筋	最初のセットアップ後にこのシステムを維持できますか？	シンプルに始めるか、構造化されたNAS OSを選ぶか、成長の道筋を計画するか	初心者 / 成長 / 長期

このマトリックスは、記事が単なるソフトウェア名のリストになるのを防ぎます。また、インストールは簡単でも信頼しにくいシステムや、理論上は強力でも維持が複雑すぎるシステムを選ぶのを避けるのに役立ちます。

ストレージ優先システム

ストレージ優先システムは、サーバーの主な役割がファイルの整理、共有、復元可能性の維持である場合に最適です。複数ドライブ、重要なデータ、家族のファイル、バックアップ、長期的なNAS計画がある場合に最も理にかなっています。

ストレージ優先システムは以下を支援すべきです：

ドライブレイアウト。
ストレージプールや類似の構造。
SMBまたはNFSファイル共有。
ユーザーおよびフォルダの権限。
スナップショットやロールバックオプション。
バックアップと復元の計画。
ヘルスモニタリングと回復ワークフロー。

トレードオフは複雑さです。ストレージ優先システムは、最初の有用なアプリが動作する前にユーザーにより多くを求めることがあります。

アプリ優先システム

アプリ優先システムは、Dockerアプリ、メディアツール、ホームオートメーション、ダッシュボード、小規模なセルフホストサービスへのクリーンな道筋を望む場合に適しています。

通常、複数ドライブのNAS設計よりもサービスの運用を重視するユーザーに適しています。ミニPC、シングルボードサーバー、古いマシンでセルフホスティングを学ぶ初心者にとって良い出発点となることがあります。

アプリ優先システムは以下を支援すべきです：

アプリのインストール。
Dockerまたはコンテナ管理。
基本的なファイルアクセス。
メディアおよび自動化サービス。
シンプルなダッシュボード。
セットアップの摩擦が少ない。

制限として、アプリの利便性が自動的にストレージの安全性、バックアップ設計、リモートアクセスのセキュリティを解決するわけではありません。

仮想化優先システム

仮想化優先プラットフォームは、1台の物理マシンで複数の分離されたシステムを実行したい場合に適しています。

NASの役割に1つのVM、Dockerアプリ用の別の環境、テスト用の別の環境、ネットワークサービス用の別の環境が欲しい場合に役立ちます。利点は柔軟性と分離です。欠点はセットアップが多く、維持するものも増えることです。

仮想化優先の選択肢は、なぜ分離が必要かをすでに理解しているユーザーにとって通常はより良いです。ファイル共有といくつかのアプリだけが必要な場合は、必要以上に複雑かもしれません。

軽量Linuxベースのシステム

軽量なLinuxベースのセットアップは、古いハードウェア、手動制御、基礎システムを学びたいユーザーにとって良い選択肢です。

この方法は柔軟ですが、多くの場合より多くの手動の判断が必要です。Dockerのインストール、ファイル共有の設定、ユーザー管理、リモートアクセスの設定、更新の管理を自分で行う必要があります。

コントロールと学習を望むなら適しています。最初からガイド付きNASダッシュボードやシンプルなアプリストア体験を望むならあまり理想的ではありません。

どのホームサーバーOSがあなたの使用ケースに合っていますか？

適切なシステムは最初の実際の使用ケースによって異なります。バックアップ用のホームサーバーは、メディアアプリ、リモートダッシュボード、仮想化実験用のホームサーバーとは異なるニーズがあります。

複数ドライブのストレージとバックアップのためのNAS優先OSを選ぶ

サーバーの主な役割が重要なファイルの保存である場合はNAS優先のOSを選んでください。特に複数ドライブの構成、家族のアーカイブ、バックアップ先、共有フォルダ、回復可能なストレージが必要な場合に当てはまります。

NAS優先の選択が通常より適しているのは次の場合です：

複数のドライブがある場合。
ドライブ故障の計画を重視する場合。
構造化されたSMBまたはNFS共有が欲しい場合。
ユーザー権限が必要な場合。
スナップショットやロールバックオプションが欲しい場合。
より明確なバックアップとリカバリのワークフローが必要な場合。

これはNAS優先システムがバックアップに代わるという意味ではありません。冗長性は一部のドライブ故障シナリオに役立ちますが、別のバックアップコピーや復元テストに代わるものではありません。

シンプルなDockerとメディアサービスのためのアプリ優先OSを選ぶ

サービスの実行が主な目的なら、アプリ優先のOSを選んでください。これにはPlex、Jellyfin、Home Assistant、Pi-hole、ダッシュボード、同期ツール、小規模データベース、その他のセルフホストアプリが含まれます。

この方向は初心者にとってしばしば簡単です。なぜなら、より速いフィードバックが得られるからです。サービスをインストールし、ローカルでテストし、より複雑なストレージシステムを構築する前に実際に必要なものを学べます。

アプリ優先のシステムが通常より適しているのは次の場合です：

ドライブが1台か2台しかない場合。
データリスクが低いか、他の場所でバックアップされている場合。
ダッシュボード駆動の体験を望む場合。
Dockerを段階的に学びたい場合。
複雑なストレージプールが必要ない場合。
低消費電力のハードウェアを使用している場合。

主なリスクは、ストレージとバックアップの計画がないままアプリサーバーを完全なNASのように扱うことです。

複数の分離されたシステムのための仮想化プラットフォームを選ぶ

サーバーで複数の種類のシステムをホストしたい場合は、仮想化プラットフォームを選んでください。例えば、NAS VM、複数のLinuxコンテナ、テスト環境、別々のネットワークサービスなどです。

この方法は強力ですが、責任も伴います。ハードウェアのパススルー、ストレージの配置、VMのバックアップ、ネットワークブリッジ、リソース制限、ホストが故障した場合の対応を考慮する必要があります。

なぜ分離が必要なのか理由がわかっている場合にこの方法を使ってください。単に高度に聞こえるからといって選ばないでください。

古いハードウェアや手動制御向けの軽量サーバーOSを選ぶ

柔軟性を求め、ハードウェアが限られている場合は軽量のLinuxベースセットアップを選んでください。古いミニPC、低消費電力システム、学習用ホームラボに適しています。

利点は制御性です。コストは自分で多くの部分を設定する必要があるかもしれないことです。

この方向性は通常以下の場合に適しています：

Linuxの基本を学ぶことに抵抗がない。
必要なサービスだけを追加したい。
重いNASプラットフォームを望まない。
ハードウェアのRAMやストレージが限られている。
ガイド付きダッシュボードより手動設定を好む。

これは後でより専門的なOSに移行する前に重要なことを学ぶ良い方法でもあります。

ホームサーバーOSをインストールする前に確認すべきこと

ホームサーバーOSをインストールする前に、システムがハードウェア、ドライブ、ワークロードに適合しているか確認してください。インストールの成功は長期的な適合を保証しません。

ハードウェア互換性と起動要件

ハードウェアから始めます。CPUアーキテクチャ、RAM、起動デバイスの要件、ドライブ接続、ネットワークアダプターのサポート、必要なインストールメディアから起動可能かを確認してください。

古いハードウェアの場合は、冷却、電源の安定性、長時間稼働可能かも確認してください。デスクトップとして動作する機械が常時稼働サーバーとして信頼できるとは限りません。

最低限、以下を確認してください：

CPUアーキテクチャとOSのサポート。
最低限のRAMと起動デバイスの要件。
USBまたはイメージベースのインストール経路。
ドライブとコントローラーの互換性。
ネットワークアダプターのサポート。
BIOSまたはUEFIの設定。
ウェブダッシュボードが故障した場合の復旧アクセス。

ドライブレイアウトとバックアップ計画

重要なファイルをインポートする前にドライブのレイアウトを計画すべきです。これは特にNAS優先システムや複数ドライブ構成で重要です。

良いストレージ計画は3つの質問を分けます：

質問	なぜ重要なのか
アクティブなファイルはどこにありますか？	日常のファイル共有とアプリアクセスを決定します
アプリのデータはどこにありますか？	Dockerアプリが誤った場所にデータを保存するのを防ぎます
バックアップはどこに保存されますか？	削除、破損、更新失敗、ドライブ損失から保護します
復元はどのようにテストされますか？	バックアップが存在するだけでなく、使用可能であることを確認します
OSが故障した場合はどうなりますか？	設定とデータが回復可能かどうかを決定します

RAID、ZFS、スナップショット、ミラーリングドライブを完全なバックアップ計画と考えないでください。これらはストレージ戦略の一部であり、完全な復旧戦略ではありません。

Docker、アプリストア、またはコンテナのサポート

Dockerアプリが重要な場合は、インストール前にOSがコンテナをどのように扱うかを確認してください。

一部のシステムはアプリストアやテンプレートに重点を置いています。その他は手動でのDocker、Docker Compose、VM内のコンテナ、またはLXC環境内のサービスを想定しています。最適な選択は、シンプルさ、制御、または分離のどれを重視するかによります。

これらの詳細を早めに確認してください：

システムはDockerを直接サポートしていますか？
アプリストア、テンプレート、Compose、手動コンテナのどれを使っていますか？
アプリのボリュームや永続データはどこにありますか？
ポートはどのように公開されていますか？
アプリはバックアップや移動が可能ですか？
アプリとストレージ間の権限はどう管理されていますか？

アプリのインストールが簡単なホームサーバーOSでも、データパスやポートが不明確だと問題が起こります。

リモートアクセス方法と権限モデル

リモートアクセスはローカルアクセスが機能してから計画してください。まず家庭内ネットワークでサーバーに接続できることを確認し、その後リモートユーザーの接続方法を決めます。

より安全な決定プロセスは：

何にリモートアクセスが必要か決めてください。
誰がアクセスすべきか決めてください。
可能な限りプライベートアクセスやVPNスタイルのアクセスを使ってください。
リスクを理解しない限り、ダッシュボードを直接公開しないでください。
権限は必要最小限に制限してください。
家庭内ネットワーク外からテストしてください。
リモートアクセスが失敗した場合に備え、ローカルでの復旧方法を用意してください。

リモートアクセスは単なる便利機能ではありません。サーバー全体のセキュリティ境界を変えます。

ホームサーバーOS選択時のよくある間違い

多くのミスは、ユーザーがサーバーの主な役割を定義する前にOSを選ぶことで起こります。その結果、インストールは成功しても後で使いにくくなるシステムができあがります。

メインワークロードではなくインターフェースで選ぶこと

シンプルなインターフェースは役立ちますが、決定を支配すべきではありません。美しいアプリダッシュボードが重要なマルチドライブストレージの基盤に適しているとは限りません。数個のアプリだけなら強力なNASインターフェースは不要かもしれません。

まずメインのワークロードを使う：

ストレージとバックアップ → NAS優先。
アプリとメディア → アプリ優先。
複数の分離システム → 仮想化優先。
古いハードウェアと手動制御 → 軽量Linuxベース。

インターフェースはワークロードをサポートすべきであり、不一致を隠すべきではありません。

RAIDやZFSを完全なバックアップとみなすこと

RAID、ZFS、ミラーvdev、RAIDZ、スナップショット、プールレイアウトは設定次第で耐障害性を高めますが、バックアップの代わりにはなりません。

バックアップはドライブ故障以上のリスクに備える必要があります。誤削除、ランサムウェア、アプリの破損、更新失敗、盗難、火災、ユーザーエラーも考慮すべきです。

ホームサーバーに重要なファイルを保存する場合、OSを信用する前にバックアップと復元の計画を立ててください。

Dockerのデータパスとポート競合を無視すること

Dockerアプリはインストールは簡単でも、データパスが不明確だと修正が難しいです。アプリが誤った場所にデータを保存すると、再インストールやストレージ変更でデータが消えたように見えることがあります。

ポートの競合もよくある問題です。2つのサービスは同じホストポートを同時に同じ方法で使用できません。ポートを公開すると、そのアプリにアクセスできるユーザーも変わることがあります。

多くのアプリを追加する前に、次を書き留めてください：

ホストパス。
コンテナパス。
アプリデータディレクトリ。
公開ポート。
ローカルのみまたはリモートアクセスの状態。
バックアップ場所。

この小さな習慣が、多くのアプリ移行や復旧の問題を後で防ぎます。

サーバーを保護する前にリモートアクセスを開くこと

リモートアクセスは最初に設定すべきではありません。ファイル共有、アプリのダッシュボード、管理パネルがユーザーや権限が明確になる前に公開されると、サーバーの保護が難しくなります。

初心者には、プライベートアクセス方法の方が直接の公開より安全なことが多いです。サービスを公開する必要がある場合は、認証、更新、ログ記録、ロールバック計画を含む別のセキュリティプロジェクトとして扱うべきです。

役立つルールは「誰がなぜサービスにアクセスできるか説明できなければ、まだ公開しないこと」です。

長期的に維持できないシステムの選択

セットアップ時はワクワクしても、メンテナンス時は疲れることがあります。アップデート、バックアップ、ディスク交換、権限変更、アプリ移行、リモートアクセスの障害、復旧などが実際の所有コストになります。

何か問題が起きたときに維持できるシステムを選んでください。小さな変更ごとに理解できない指示が必要なら、そのシステムは現在の利用ケースには複雑すぎるかもしれません。

見た目は強力でも脆弱になるシステムを構築するより、安全に運用できるシステムから始める方が良いです。

NAS、Docker、リモートアクセスの優先順位の決め方

実用的な判断として、OSを選ぶ前にNAS、Docker、リモートアクセスの優先順位をつけます。

この順序を使います：

データのリスクを特定します。
主要なアプリを特定します。
アクセスが必要な人を特定します。
OSのカテゴリを主なワークロードに合わせます。
ハードウェアとインストール要件を確認します。
バックアップと復元を計画します。
ローカルサービスが動作した後にリモートアクセスを追加します。
ワークロードが増えたら選択を再確認してください。

シンプルな優先マップはこちらです：

あなたの優先事項	最適な出発点	避けるべきこと
重要なファイルと複数ドライブのストレージ	NAS優先OS	アプリの利便性をストレージの安全性とみなすこと
シンプルなDockerアプリとメディア	アプリ優先OS	維持しないシステムで過剰構築すること
多数の分離されたシステム	仮想化優先プラットフォーム	すべてを1台の管理されていないホストで実行
古いハードウェアと学習	軽量なLinuxベースのセットアップ	マシンに負担をかける重いOSのインストール
プライベートサービスのリモートアクセス	OSとプライベートアクセス方法	セキュリティ確保前にダッシュボードを直接開くこと
将来の成長	今はシンプルに、後で計画的に移行	最初のセットアップは永続的であると仮定します

最適なホームサーバーOSは、最もリスクの高いタスクを管理しやすくするものです。

OSの選択から実際のセットアップ手順への移行方法

OSのカテゴリを選択した後、比較からセットアップへ進みます。すべての実際のシステムには独自のイメージ、起動方法、ストレージのワークフロー、アプリモデル、最初のログインプロセスがあります。

セットアップの手順は以下を確認すべきです：

ハードウェアは互換性があります。
インストールメディアは正しいものです。
起動設定は理解されています。
最初のログイン方法は明確です。
データをインポートする前にストレージが見えています。
アプリのデータパスは把握されています。
リモートアクセスは安全に計画されています。

例えば、ZimaOSインストールガイドでは、軽量なNAS指向システムがイメージのダウンロード、USB書き込み、UEFIとセキュアブートの要件、インストール、最初のウェブアクセス、ファイル共有、メディアアプリ、Dockerアプリ、バックアップの次のステップをどのように扱うかを示しています。

ストレージ重視のプライベートクラウド、メディア、ファイル共有、バックアップ、リモートファイルアクセスのワークフローを望むユーザーには、ZimaCube 2パーソナルクラウドNASがNAS優先の計画がより重要になるデバイスカテゴリの一例です。それでも、ワークロード、ストレージ責任、アプリモデル、リモートアクセスの境界、ハードウェア適合性、メンテナンス経路という同じマトリックスで評価する必要があります。

「どのOSが最適か？」からすぐにインストールに飛びつかないでください。まず役割を決め、次にシステムを選び、そのシステムの公式セットアップ手順に従いましょう。

よくある質問

一つのホームサーバーOSでNAS、Docker、リモートアクセスをすべて扱えますか？

はい、多くのホームサーバーシステムはこれら三つすべてをサポートできますが、同じ簡単さや深さで扱えるわけではありません。ストレージに強いもの、Dockerアプリに使いやすいもの、仮想化やネットワーク分離に強いものがあります。問題が起きたときに最も重要なタスクに基づいて選んでください。

ホームサーバーにTrueNASやUnraidは本当に必要ですか？

必ずしもそうではありません。少数のアプリ、基本的なファイル共有、シンプルな学習セットアップだけが必要なら、軽量なアプリ優先またはLinuxベースのシステムで十分な場合があります。マルチドライブストレージ、構造化されたファイル共有、スナップショット、長期バックアップターゲットが主な目的なら、NASに特化したシステムの方が適しています。

ProxmoxはNASオペレーティングシステムより優れていますか？

主な目的が仮想化と複数の独立したシステムの運用であれば、Proxmoxの方が適しています。主な目的がストレージ管理とファイル共有であれば、NASオペレーティングシステムの方が通常は優れています。多くのユーザーは両者を比較しますが、どちらもホームラボで使われることがありながら、解決する主要な問題は異なります。

Dockerアプリとファイル共有だけを使いたい場合は何を選べばいいですか？

ストレージのニーズがシンプルで、データが他の場所にバックアップされている場合は、アプリ優先または軽量のLinuxベースのセットアップから始めましょう。多くのアプリを追加する前に、Dockerのデータパス、ポート公開、権限を理解していることを確認してください。後でファイル共有が最も重要な役割になる場合は、NAS優先のシステムに移行できます。

今はシンプルに始めるべきですか、それとも将来の成長のためにより高度なOSを選ぶべきですか？

まだ学習中でデータのリスクが低い場合は、シンプルに始めましょう。すでにマルチドライブストレージ、強力なリカバリ計画、仮想化、または複数ユーザーが必要だと分かっている場合は、より高度なシステムを早めに選択してください。バックアップと移行計画が明確でない限り、初心者向けのセットアップを永久的なものと見なすのは避けるのが最も安全な方法です。