Zimaからのメッセージ
プライバシー、試行錯誤、そして実際に手を動かして学ぶことを、利便性と同じくらい大切にしたとき、初めてのNASがどのようなものになるのかを共有してくださったKing_Ardaさん、ありがとうございます。あなたのZimaBladeは、Immich、Jellyfin、Duplicati、暗号化バックアップ、そしてネットワークですでに信頼していたWireGuardによるリモートアクセスの拠点になりました。
うまくいった部分だけでなく、Dockerの設定やストレージパスの混乱、バックアップの挙動、2台目のドライブに向けた電源計画まで、試行錯誤した点も率直に記録してくださったことに、特に感謝しています。こうした詳細によって、他のホームラボ構築者も、小さなDIY NASを時間をかけて成長させていく実際の過程を、より具体的に理解できます。
— Zima
King_Ardaさんについて
King_Ardaさんは、Redditでホームラボを構築しているユーザーです。元の投稿では、サイバーセキュリティを学んでおり、Cisco CCNAで得たネットワーク知識があると自己紹介していました。単にファイルを保存できる箱を探していたわけではありません。セルフホストサービス、ネットワーク、バックアップ、ストレージを実践的に試せるNASを求めていました。
ZimaBladeを購入する前に、一般的なNASの選択肢と古いPCの再利用を比較しました。最終的には、価格、柔軟性、外観、そして試行錯誤できる余地の組み合わせが、初めてのホームラボNASに求めていたものと合致したため、より小型のx86システムを選びました。
このユーザーストーリーの背景にあるクリエイタープロフィールを見るには、RedditでKing_Ardaさんをフォローできます。
開示：元のReddit投稿で、King_Ardaさんは、希望していたストレージ構成に既存の電源装置では不十分だと気づいた後、Zimaのサポートに連絡したと述べています。サポートから投稿の作成を条件に送料を無料にしてもらった一方で、自分の意見を自由に共有できたとも明らかにしています。このユーザーストーリーでは、その開示内容と、セットアップ体験に関する批判的な意見の両方をそのまま紹介しています。
NASの調査からZimaBladeへ
King_Ardaさんは、ZimaBladeを選ぶ前に、Synology NASを購入するか、古いPCを再利用するかという、よくある2つの選択肢を検討しました。調査を進めるうちに、ストレージと汎用ホームサーバーの両方として使える、より小型のDIYプラットフォームに惹かれていきました。
選択の決め手は、主にコストパフォーマンスと柔軟性でした。また、オープンソースソフトウェアという考え方や、マシン上で動作するサービスをより細かく管理できる点も気に入っていました。NASは最初から、単一用途のアプライアンスにとどまる予定ではなかったためです。
現在のZimaBladeのドキュメントでは、このプラットフォームを、SATA 3.0接続を2基、ギガビットイーサネット、PCIe拡張を備えたx86シングルボードサーバーとして説明しています。King_Ardaさんの投稿では、基板が3760モデルか7700モデルかは特定されていないため、このストーリーでもどちらか一方とは断定しません。
なぜZimaOSを中心に使い続けたのか
King_Ardaさんは、Windows、Proxmox、その他のサーバーOSにすぐ置き換えるのではなく、システム上でZimaOSを使い続けました。ブラウザベースのファイル操作環境とApp Storeを気に入っており、あらゆる実験をコマンドライン作業にせず、Dockerアプリを簡単に見つけてデプロイできたためです。
セットアップの中心となったアプリは、写真用のImmich、メディア用のJellyfin、バックアップワークフロー用のDuplicatiの3つでした。途中では他のアプリも試しており、その頃からマシンは単純なNASというより、実際のホームラボノードらしい動作を見せるようになりました。
オフサイトバックアップを維持しながらプライバシーを確保
写真は、King_Ardaさんがセルフホストを選んだ明確な理由の1つでした。特に、クラウド上の写真がAIとの関連でどのように利用される可能性があるかを懸念し、写真ライブラリを完全にGoogleに預けることに不安を感じていたと述べています。
しかし、クラウドストレージを完全に手放したわけではありません。Immichによって、自分で管理するハードウェア上に写真サービスを構築し、Duplicatiで暗号化バックアップをGoogle Driveに送信しました。また、DriveからZimaBladeへファイルを戻すことも説明しており、どちらか一方が唯一のコピーにならないようにしていました。
これにより、プロジェクトはすべてをローカルにするか、すべてをクラウドにするかという二者択一ではなくなりました。日常的な管理にはローカルサービスを使い、別のバックアップ層として暗号化したオフサイトストレージも維持する、ハイブリッドな構成です。
別のリモートアクセス層を追加せずWireGuardを使う
リモートアクセスについては、King_ArdaさんはTailscaleも検討しましたが、ルーターがすでに対応していたためWireGuardを選びました。NAS専用に別のリモートアクセスサービスを追加するのではなく、自分が理解しているネットワーク経路を使えたためです。
現在のZimaOSのバージョンでは、ZimaClientによるリモートアクセスも案内されています。一方、King_Ardaさんの構成は、別のセルフホストのパターンを示しています。すでに自分のネットワークを管理しているユーザーであれば、既存のインフラに合ったアクセス層を選べるということです。
現在のZimaOSリモートアクセスガイドではZimaClientの方法を説明しています。元のReddit投稿では、King_Ardaさんが別の選択肢としてWireGuardを採用したことが記録されています。
簡単な道が簡単ではなくなった場面
App Storeは便利でしたが、King_Ardaさんは、すべてのインストールが完全に手放しで済んだとは説明していません。アプリを意図したとおりに動作させるため、Dockerファイルの一部を変更しなければならないことがあったと述べています。
さらに、より気になるストレージパスの問題も報告しています。HDDを選択したつもりでも、一部のデータがZimaBladeの内部ストレージに書き込まれているように見えたのです。自動的に実行されるはずだと考えていたバックアップジョブも、常に期待どおりには動作しませんでした。
こうした問題によってシステムを手放すことはありませんでしたが、どのようなユーザーに勧めるかは変わりました。設定を確認し、トラブルシューティングを行う意思のある人にとっては、基盤となるコンテナやストレージの仕組みを意識せずに使えるアプライアンスを期待する人よりも、はるかに好ましい体験だったのです。
現在のZimaOSガイダンスではアプリデータのパスがより明確に
現在のZimaOSドキュメントでは、アプリのストレージについて独立したガイダンスが提供されています。アプリストレージパスガイドでは、大容量の永続データセットをシステムドライブに残すのではなく、メインストレージ領域にアプリデータを配置することを推奨しています。特にImmichのような写真ライブラリは、小容量のシステムディスクをすぐに埋めてしまう可能性があるワークロードとして挙げられています。
これは、King_Ardaさんが遭遇した問題が、彼のマシン上で解決されたことを証明するものではありません。ただし、ZimaOSとDockerの永続化の関係を学ぶ中で彼が直面したものと同じ種類の問題について、現在はより明確な指針が示されています。
誰にでもではなく、試行錯誤する人に勧められるNAS
King_Ardaさんの全体的な評価は、意図的に条件付きのものでした。デバイスを気に入り、望んでいたことを実現できたと感じていましたが、設定や調査なしですべてのサービスが動作することを期待する完全な初心者に、同じ体験をそのまま勧めることはありませんでした。
設定を編集し、データの保存場所を理解し、必要に応じてコンテナのトラブルシューティングができる人にとっては、結論ははるかに前向きでした。その意味で、ZimaBladeはストレージとしてだけでなく、学習プラットフォームとしても機能しました。
まずは1台、次は2台目
元の投稿時点では、NASは1台のHDDで動作していました。King_Ardaさんは2台目のドライブを追加してRAIDを使う予定でしたが、想定しているRAIDレベルは公開していません。
2台のディスクを使う場合、現在のZimaOSドキュメントではミラーリング構成としてRAID 1が案内されています。一方、RAID 5には少なくとも3台のドライブが必要です。これは読者にとって有用な背景情報ですが、King_Ardaさん自身がRAID 1を選んだという主張に変えてはいけません。公開されている更新内容は、もう1台のディスクを追加する計画にとどまっています。
より広範な選択肢については、現在のZimaOS RAIDリファレンスで説明されています。
電源計画がストレージ計画の一部に
2台目のディスクに移行しようとしたことで、別の現実的な制約も明らかになりました。King_Ardaさんの構成で使っていた電源装置では、実行したい内容に対して十分な電力を供給できなかったのです。これがサポートに連絡するきっかけとなり、Reddit投稿で開示された送料無料の対応につながりました。
現在のZimaBlade NASセットアップガイダンスでも、HDDを長期的に使用する場合は外部電源を検討するよう案内しています。元の投稿には、ドライブのモデル、スピンアップ時の電流、アダプターの仕様、ZimaBladeのモデルが記載されていないため、このストーリーでは構成の正確な電気的限界を診断しようとはしません。
小さなNASが実践的なホームラボに
King_Ardaさんがこのプロジェクトについて書いた時点で、ZimaBladeは単にファイルを保存する以上の役割を担っていました。プライベートな写真サーバー、Jellyfinのメディアサーバー、バックアップノードとなり、さらに、すでに学んでいたネットワークとサイバーセキュリティの知識を実践する場所にもなっていました。
このストーリーで役立つのは、成功だけでなく、試行錯誤からも学びが得られた点です。コンテナデータをどこに保存するか、どのリモートアクセス層が適切か、暗号化したオフサイトコピーをどう維持するか、そしてストレージを拡張して電力要件が増えたときに何が変わるかを判断する必要がありました。
ストーリーは今も続いている
King_ArdaさんとZimaのストーリーは、今も続いています。2026年1月31日のReddit投稿には、すでに役立ちながらも拡張途中にあるシステムの姿が記録されています。1台のHDDで実際のワークロードを処理し、2台目のディスクとRAIDが計画され、ImmichとJellyfinが日常的なサービスとなり、Duplicatiがバックアップを担い、WireGuardがリモートアクセスを提供していました。
このページで確認できた資料には、2台目のドライブへのアップグレード、最終的なRAID構成、アプリデータとバックアップの問題が後に解決されたかどうかを確認できる公開フォローアップはありません。King_Ardaさん自身が次の段階を記録するまで、これらの点は未確定のままとすべきです。
このストーリーの出典を追うには、RedditでZimaBlade NASの元の投稿を読むか、King_ArdaさんのRedditプロフィールを見ることができます。
