Bebe Lab

  • 自宅ラボのBIND 9をCVE対応でアップデート|Docker移行で発生した権限問題とDNS監視

    はじめに

    自宅ラボでは、AdGuard HomeとBIND 9を組み合わせて内部DNSを運用しています。

    先日、Xで「BIND 9を使っている」という内容をポストしたところ、それを見てくださった方からBIND 9の脆弱性についての記事を教えていただきました。

    紹介いただいた情報では、BIND 9に以下の2件の脆弱性が報告されていました。

    • CVE-2026-19666
    • CVE-2026-19667

    調べたところどちらもリゾルバのDoSに関する脆弱性で、CVE-2026-19666はDNS64有効時、CVE-2026-19667はデフォルトで影響するとされています。CVSSはどちらも7.5(High)です。

    自宅ラボのBINDも対象となる可能性があるため、実際の構成を確認したうえでアップデートすることにしました。

    今回は、その対応内容をまとめます。

    1. 更新前のDNS構成

    今回の環境では、DNSの役割をAdGuard HomeとBINDで分けています。

    イメージとしては以下の構成です。

    クライアント
         |
         v
    AdGuard Home
         |
         | 内部ドメイン
         v
       BIND 9
         |
         +-- 内部正引き
         +-- 内部逆引き
         +-- Tailscale用DNS
         |
         v
      PBS Secondary

    AdGuard Homeをクライアントから見えるDNSサーバとして使用し、内部ドメインの問い合わせだけBINDへ渡しています。

    外部ドメインについてはAdGuard Home側で処理する構成です。

    なお、記事では実環境のIPアドレスやドメイン名などは掲載せず、構成が分かる範囲でサンプル値に置き換えています。


    2. BINDの役割を確認

    今回の脆弱性情報をきっかけに、まず現在のBINDの役割を確認しました。

    この環境のBINDは、インターネット向けの再帰DNSとして使用しているのではなく、内部ゾーンを提供するauthoritative DNSとして利用しています。

    そのため、

    recursion no;

    として、BIND自身では再帰問い合わせを行わない構成にしています。

    また、問い合わせ元についても、以前の設定に存在していた

    any;

    を削除しました。

    内部ネットワークからの問い合わせだけを許可する構成に変更しています。


    3. DNS64の利用状況を確認

    今回の脆弱性のうち、CVE-2026-19666はDNS64有効時に影響するとされています。

    そこで、AdGuard Home側の設定を確認しました。

    この環境ではDNS64を使用しておらず、

    use_dns64: false

    となっていることを確認しました。

    一方、CVE-2026-19667についてはデフォルトで影響するとされているため、DNS64を使用していないことだけで対応を終えるのではなく、BIND自体を更新することにしました。


    4. BINDイメージを変更

    更新前はUbuntuベースのBINDイメージを使用していました。

    BINDのバージョンを確認したところ、今回の脆弱性対応として必要な修正版へ確実に更新するため、ISC公式のBINDイメージを利用することにしました。

    変更前:

    ubuntu/bind9:latest

    変更後:

    internetsystemsconsortium/bind9:9.20

    最終的に、

    BIND 9.20.29

    で起動していることを確認しました。


    5. Dockerイメージ変更で発生した権限問題

    今回、一番苦労したのがDockerイメージ変更後の権限問題です。

    ISC公式イメージへ変更したところ、最初はBINDコンテナが起動と停止を繰り返す状態になりました。

    ログを見ると、

    directory '/var/cache/bind' is not writable

    というエラーが出ていました。

    ISC公式イメージのbindユーザーを確認すると、

    uid=53(bind) gid=53(bind)

    でした。

    一方、ホスト側のcacheディレクトリは別のUID/GIDで所有されていました。

    つまり、同じ「bind」という名前のユーザーを使用していても、Dockerイメージが変わればUID/GIDが同じとは限りません。

    そこで、ホスト側のcacheディレクトリをISC公式イメージのbindユーザーに合わせました。

    chown 53:53 /srv/ubn-name-sv/cache

    その後、BIND 9.20.29が正常に起動しました。


    6. 設定とゾーンを確認

    コンテナ起動後、

    named-checkconf -z /etc/bind/named.conf

    を実行しました。

    結果として、以下の3ゾーンが正常にロードされました。

    • 内部正引きゾーン
    • 内部逆引きゾーン
    • Tailscale用DNSゾーン

    設定ファイルの構文だけではなく、実際にゾーンがロードされているところまで確認しました。


    7. DNSの名前解決を順番に確認

    BINDが起動しただけでは、DNS環境が正常に復旧したとは言えません。

    そこで、DNSの経路ごとに確認しました。

    BINDへ直接問い合わせ

    まずBIND自身に問い合わせます。

    dig @127.0.0.1 -p 5353 dns01.home.example A +noall +answer

    期待するIPアドレスが返ることを確認しました。

    AdGuard HomeからBINDへ問い合わせ

    次に、AdGuard HomeからBINDへの名前解決を確認しました。

    docker exec adguardhome nslookup dns01.home.example 172.18.0.2

    こちらも正常に名前解決できました。

    ホストからAdGuard Home経由で問い合わせ

    最後に、普段クライアントが利用する経路を確認しました。

    dig @127.0.0.1 dns01.home.example A +noall +answer

    この結果も正常でした。

    DNSサーバを更新するときは、単純に「サービスが起動した」だけではなく、

    クライアント
      ↓
    AdGuard Home
      ↓
    BIND

    という実際の通信経路を確認することが重要です。


    8. PBSのセカンダリDNSも確認

    BINDでは、別サーバにセカンダリDNSを用意しています。

    今回の対応では、PBS側のセカンダリDNSについても確認しました。

    SOAレコードを取得して、

    dig @192.168.10.20 -p 5353 home.example SOA +noall +answer

    マスターとセカンダリのserialが一致することを確認しました。

    さらにBINDのログから、マスターからセカンダリへNOTIFYが送信されていることも確認しました。

    DNSの冗長化を構成している場合は、マスターだけ正常でも不十分です。

    セカンダリ側まで確認する必要があります。


    9. DNS確認用スクリプトを作成

    今回の確認を毎回手作業で行うのは面倒なので、最後にdns-pipeline.shを作成しました。

    スクリプトでは、

    1. BINDコンテナが起動しているか
    2. BINDのバージョン
    3. BIND設定とゾーン
    4. BINDへの直接問い合わせ
    5. BINDへの逆引き問い合わせ
    6. AdGuard Home経由の名前解決
    7. PBSセカンダリのSOA
    8. マスターとセカンダリのserial一致

    を確認します。

    すべて成功した場合、

    DNS PIPELINE: OK

    として終了コード0を返します。

    どれか1つでも失敗すると、

    DNS PIPELINE: NG

    として終了コード1を返します。

    実際に今回の環境で実行し、すべてのチェックがPASSして正常終了することを確認しました。


    10. 今回の対応で得られたこと

    今回の対応では、単純にBINDをアップデートしただけではありませんでした。

    脆弱性情報をきっかけに、

    脆弱性情報を確認
        ↓
    現在のDNS構成を確認
        ↓
    BINDの役割を確認
        ↓
    DNS64の利用状況を確認
        ↓
    BINDイメージを変更
        ↓
    UID/GID問題を切り分け
        ↓
    BINDをアップデート
        ↓
    ゾーン確認
        ↓
    DNS疎通確認
        ↓
    セカンダリDNS確認
        ↓
    ヘルスチェックを自動化

    という一連の対応を行いました。

    特に、Dockerイメージを変更するときには、アプリケーションの設定だけでなく、コンテナ内ユーザーのUID/GIDやホスト側のボリューム権限まで確認する必要があることを改めて実感しました。

    また、DNSについては「サービスが起動している」だけではなく、実際の問い合わせ経路を確認することが重要だと感じました。


    まとめ

    今回、XでBIND 9を使用していることをポストしたことをきっかけに、BIND 9の脆弱性情報を教えていただきました。

    そこから自宅ラボのDNS構成を確認し、BINDをISC公式イメージへ移行して9.20.29へ更新しました。

    その過程でDockerのUID/GIDによる権限問題も発生しましたが、原因を切り分けて解決し、最終的には、

    • BIND 9.20.29への更新
    • authoritative-onlyとしての運用確認
    • DNS64を使用していないことの確認
    • 内部ネットワークからの問い合わせに限定
    • 3ゾーンの正常ロード
    • AdGuard HomeからBINDへの名前解決
    • PBSセカンダリとの同期
    • DNSパイプラインによる自動チェック

    まで確認できました。

    自宅ラボであっても、脆弱性情報をきっかけに実際の構成を確認し、アップデート、障害対応、疎通確認、監視まで一通り実施してみると、普段の運用では気づきにくい問題を発見できます。

    今回教えていただいたことをきっかけに、DNSまわりの構成を見直す良い機会になりました。

  • 4畳半に作った自宅ラボ環境を紹介|Proxmox・10GbE・NASで構築

    自宅ラボ用に19インチラックをDIYし、サーバーやネットワーク機器の電源を守るためにUPSも導入しました。

    今回は、それらの機器を含めて、現在運用している自宅ラボ環境を紹介したいと思います。

    自作PCが好きで、最初はLinuxを触るところから始まりました。

    その後、Proxmoxを使った仮想化環境を作り、サーバーが増え、ネットワークを10GbE化し、NASやバックアップサーバーも導入。

    気が付けば、4畳半の部屋に自宅ラボができていました。

    そして最終的には、機器を整理するために19インチラックまで自作することになりました。

    この記事では、現在の自宅ラボのハードウェア、ネットワーク、サーバー構成、そして実際に動かしているサービスをまとめて紹介します。


    自宅ラボの全体像

    現在の自宅ラボは、大きく分けると以下のような構成になっています。

    • Proxmox VE 3ノード
    • NAS兼GPUサーバー
    • TrueNAS
    • Proxmox Backup Server
    • 10GbEネットワーク
    • iSCSIを利用したストレージ環境
    • ZFSによる冗長化
    • Dockerを利用した各種サービス

    以前は機器を床や一般的な棚に置いていましたが、サーバーやネットワーク機器が増えるにつれて管理が難しくなってきました。

    そこで、現在はDIYした木製の19インチラックを中心に機器をまとめています。

    ラックについては、以前の記事で製作過程を紹介しています。

    自宅ラボは「最初から大規模な環境を作ろう」と思って始めたものではありませんでした。

    自作PCから始まり、Linux、Proxmox、ネットワーク、ストレージと興味が広がっていった結果、少しずつ現在の環境になりました。


    自宅ラボの主なハードウェア

    現在使用している主な機器はこちらです。

    ネットワーク機器

    • YAMAHA RTX1200
    • Allied Telesis AT-x510L-28GT
    • XikeStor SKS8310-8X
    • XikeStor SKS1200-4GPY2XF-P
    • Buffalo WSR-1166DHPL2

    メインのネットワークにはAllied Telesisのスイッチを使用し、SAN用には別の10GbEネットワークを構築しています。

    家庭用のネットワークと、自宅ラボのネットワークを分けているのも現在の環境の特徴です。


    サーバーはProxmox VEを中心に構築

    自宅ラボの中心になっているのは、Proxmox VEです。

    現在は3台の自作PCでProxmoxクラスターを構成しています。

    Proxmoxノード(2U)

    • pve01
    • pve02
    • pve03

    それぞれAMD Ryzen 3 4100を搭載した自作PCで、10GbE NICを追加しています。

    仮想マシンやコンテナを複数のノードで動かすことで、さまざまなサービスを試せる環境になっています。

    Proxmoxを使い始めたことで、「1台のPCにLinuxをインストールして使う」だけだった環境から、仮想化を利用した本格的な自宅サーバー環境へ発展しました。


    NAS兼GPUサーバー(3U)

    自宅ラボには、NASとGPU処理を担当するサーバーもあります。

    このサーバーには、

    • AMD Ryzen 5 3400G
    • メモリ64GB
    • AMD Radeon RX 9060 XT 16GB
    • 10GbE NIC

    を搭載しています。

    GPUを搭載しているため、通常のNAS用途だけではなく、AI関連の処理にも使用しています。

    現在はProxmox上でAI用の環境も構築しており、OllamaやStyle-Bert-VITS2などをDockerで動かしています。

    自作PCとして使っていた機器を、その後どう活用するか。

    自分の場合は、その答えのひとつが「自宅ラボのサーバーにする」でした。


    TrueNASとストレージ環境

    ストレージ用には、PRIMERGY TX1320 M3を使用してTrueNAS SCALEを動かしています。

    自宅ラボでは、ZFSを利用してストレージを冗長化しています。

    また、SAN用に分離したネットワークを用意し、iSCSIを利用してProxmoxノードへストレージを提供しています。

    ※夏場は室温上昇によるSASディスクの騒音問題が発生し、NAS機能をGPUサーバに移しています。

    現在のネットワークは、大きく以下のように分けています。

    家族用ネットワーク

    192.168.11.0/24

    自宅ラボ用ネットワーク

    192.168.2.0/24

    Proxmoxクラスタ用ネットワーク

    10.1.1.0/24

    SAN用ネットワーク

    10.2.2.0/24

    用途ごとにネットワークを分けることで、管理しやすい環境を目指しています。

    特にProxmoxクラスタやストレージ関連の通信を、普段使っているネットワークと分けているのが特徴です。


    10GbEネットワークを導入

    自宅ラボでは10GbEネットワークも構築しています。

    最初から10GbEが必要だったわけではありません。

    しかし、仮想マシンを複数運用するようになり、ストレージをネットワーク経由で利用するようになると、高速なネットワークにも興味が出てきました。

    現在は10GbEネットワークを利用して、

    • Proxmoxノード間の通信
    • SANへの接続
    • ストレージへのアクセス

    などを行っています。

    自宅で10GbE環境を構築するのは少し大げさにも見えますが、「自宅で試せる環境がある」ということ自体が自宅ラボの面白さだと思っています。

    仕事で触る技術でも、実際に自分で構築してみると理解が深まります。


    バックアップ専用サーバーも用意

    仮想化環境を作ると、次に気になってくるのがバックアップです。

    現在はProxmox Backup Server専用の自作PCを用意しています。

    バックアップサーバーには、

    • Intel Core i3-8100T
    • メモリ16GB ECC
    • NVMe SSD
    • HDD 1TB×2
    • HDD 500GB×1

    を搭載しています。

    Proxmoxの仮想マシンやコンテナを運用するだけではなく、「障害が発生したときにどう復旧するか」まで考えるのも自宅ラボの楽しさのひとつです。

    新しいサービスを作るたびに、バックアップ対象も増えていきます。

    その結果、専用のバックアップサーバーを用意することになりました。

    ディスクはシングル構成でVMデータと、Immich、Sambaなどのデータでディスクを分けています。


    自宅ラボで実際に動かしているサービス

    自宅ラボでは、単純にサーバーを並べているだけではありません。

    Proxmox上で仮想マシンやコンテナを作成し、さまざまなサービスを運用しています。

    DNS・ネットワーク関連

    LAN内の名前解決用として、

    • Bind9
    • AdGuard Home
    • Tailscale

    などを利用しています。Bind9はLPICの資格試験勉強のために構築したものです。


    監視環境

    モニタリング用のサーバーでは、

    • Grafana
    • PostgreSQL
    • Python

    などを使用しています。

    SwitchBotの温湿度計やスマートプラグも利用しており、サーバー室の温度や電力を監視しています。

    異常があった場合には、Discordへ通知が届くようにしています。

    サーバーが増えると、「ちゃんと動いているか」を確認する仕組みも必要になります。

    自宅ラボではありますが、監視の仕組みを作ることで、運用する楽しさも増えました。


    Nextcloud

    Nextcloudも自宅ラボで運用しています。

    Docker上で、

    • Nextcloud
    • MariaDB
    • Nginx
    • Redis
    • Tailscale

    などを組み合わせています。

    スマートフォンからもアクセスできるため、自分の環境やナレッジを保存する用途などに利用しています。


    AIサーバー

    GPUを搭載したサーバーを活用し、AI関連のサービスも動かしています。

    現在は、

    • Ollama
    • Style-Bert-VITS2

    などをDockerで運用しています。

    自宅にGPUサーバーがあることで、クラウドサービスを利用するだけでは分からない部分も実際に試せるようになりました。


    家計簿Webアプリ

    自宅ラボでは、自分で作成した家計簿Webアプリも運用しています。

    FlaskやMariaDBなどを使用し、AIサーバーとも連携しています。

    レシートを読み取り、購入履歴や支出を管理する仕組みを作っています。

    自宅ラボがあると、「こんなものを作ってみたい」と思ったときに、すぐサーバーを用意して試せるのが便利です。


    Immich

    家族の写真や動画の保存にはImmichを使用しています。

    Docker上で、

    • Immich
    • PostgreSQL
    • Redis
    • Nginx
    • Tailscale

    などを運用しています。

    スマートフォンで撮影した写真や動画を保存し、タブレットやテレビから家族で閲覧できる環境を作っています。

    自宅ラボは技術を試す場所というイメージがありますが、実際には家族が使えるサービスを作ることも増えてきました。


    UPSも導入

    サーバーやネットワーク機器が増えてくると、気になるのが停電や瞬断です。

    そこで、サーバー用とネットワーク機器用にUPSを導入しています。

    現在使用しているのは、

    • APC UPS 500:サーバー用
    • APC UPS 400S:ネットワーク用

    です。

    サーバー用のUPSには、

    • Proxmoxノード
    • NAS兼GPUサーバー
    • SAN用スイッチ

    などを接続しています。

    UPSを導入した理由については、別の記事でも詳しく紹介しています。


    自宅ラボを始めて変わったこと

    最初は、自作PCにLinuxをインストールして遊んでいただけでした。

    しかし、Proxmoxを知ったことで仮想化に興味を持ちました。

    仮想マシンを作る。

    ↓

    サービスを増やす。

    ↓

    サーバーが増える。

    ↓

    ネットワークを高速化・冗長化したくなる。

    ↓

    ストレージが必要になる。

    ↓

    バックアップも必要になる。

    ↓

    そして、最終的にはラックまで必要になる。

    こうして振り返ると、自宅ラボは少しずつ大きくなっていったことが分かります。

    最初から現在のような環境を作る予定はありませんでした。

    その時々で「これを試してみたい」と思ったものを追加していった結果です。


    自宅ラボは完成しない

    現在の環境でも、まだまだ改善したい部分があります。

    新しい技術を試したくなれば、新しい仮想マシンやコンテナを作ることもあります。

    機器が増えれば、ラックの使い方も変わります。

    ネットワーク構成を変更したくなることもあります。

    自宅ラボは、一度完成したら終わりではありません。

    むしろ、

    「完成しないこと」そのものが自宅ラボの面白さなのかもしれません。

    既製品や既存の構成で満足できなければ、自分で考えて変更してみる。

    うまくいかなければ、また改善する。

    19インチラックをDIYしたのも、その延長線上にあります。

    自作PCから始まり、LinuxやProxmoxを使うようになり、気が付けば自宅ラボになって、最終的にはラックまで自作していました。

    これからも、自宅ラボで新しい技術を試したり、環境を改善したりしながら、記事として記録していきたいと思います。


    まとめ

    現在の自宅ラボでは、

    • Proxmox VE 3ノード
    • NAS兼GPUサーバー
    • TrueNAS
    • Proxmox Backup Server
    • 10GbEネットワーク
    • ZFS・iSCSIによるストレージ環境
    • UPS
    • Dockerを利用した複数のサービス

    を運用しています。

    ひとつひとつの機器やサービスは、また別の記事で詳しく紹介していく予定です。

    この記事が、自宅ラボをこれから作ってみたい人や、「自宅でサーバーを動かすとどんな環境になるの?」と思っている人の参考になれば嬉しいです。

    そして、これからも自宅ラボは少しずつ変化していくと思います。

    その変化も含めて、楽しんでいきたいと思います。

  • 自宅ラボにUPSを導入した理由|停電とブレーカー落ちでサーバーを守る

    自宅ラボでサーバーを24時間運用していると、気になるのが「突然の電源断」です。

    サーバーやネットワーク機器が増えてくると、「UPS(無停電電源装置)は本当に必要なのだろうか?」と考える人もいると思います。

    実際、YouTubeなどでUPSについて調べてみると、導入したものの「自分の環境では必要なかった」「結局使うのをやめた」という意見も見かけます。

    そのため、すべての自宅ラボにUPSが必須だとは思いません。

    しかし、必要な環境なら使う価値があるというのが、実際に自宅ラボを運用している私の結論です。

    私の場合は、仕事での経験もあり、壁のコンセントから供給される電力が一瞬途切れる「瞬電」によって機器が停止するリスクを意識していました。

    瞬電や停電のたびにサーバーが突然落ちる環境は避けたい。

    そんな理由から、自宅ラボにもUPSを導入しています。

    今回は、私が自宅ラボにAPCのUPSを導入した理由と、実際にどの機器をUPSで保護しているのかを紹介します。


    そもそも自宅ラボにUPSは必要なのか?

    結論から言うと、環境によっては必要だと思っています。

    もちろん、UPSがなくても自宅サーバーを運用することはできます。

    普段から停電がほとんどなく、サーバーが突然停止しても特に問題がないのであれば、UPSを導入する優先度はそれほど高くないかもしれません。

    一方で私の場合は、電源が突然落ちることを実際に経験してきました。

    仕事でも、電源の瞬断や停電によって機器が停止することを想定した環境を扱うことがあります。

    家庭用のコンセントだからといって、必ずしも電源が安定して供給され続けるとは限りません。

    停電はもちろん、雷やその他の原因によって一瞬だけ電力供給が途切れる可能性もあります。

    自宅ラボでは、

    • Proxmoxクラスタ
    • NAS
    • 仮想マシン
    • ネットワーク機器

    など、複数の機器が連携して動いています。私の環境でも、複数のProxmoxノードを中心にサーバーやネットワーク機器を運用しています。

    そのため、単純に「PCの電源が落ちた」だけでは済まない場合もあります。

    特に仮想マシンやストレージを運用している場合、できることなら正常な手順で停止したいところです。

    もちろんUPSは永久に電力を供給してくれる装置ではありません。

    しかし、突然の電源断を回避し、安全に停止するまでの時間を確保するという目的であれば、私の環境では十分に価値があると考えています。


    停電を経験した

    UPSを導入する理由の一つは、実際に停電を経験していることです。

    私が住んでいる地域では、豪雨や台風、雷などの自然災害によって停電した経験があります。

    「自宅だから大丈夫だろう」と思っていても、自然災害による停電はいつ発生するか分かりません。

    実際に停電すると、当然ながらコンセントから電力を供給されている機器はすべて停止します。

    一般的なPCであれば、作業中のデータが消える程度で済むこともあるでしょう。

    しかし、自宅ラボでは複数のサーバーが常時稼働しています。

    Proxmox上では複数のVMやLXCを動かしており、DNS、監視、Nextcloud、Immich、AI関連サービスなど、さまざまなサービスを運用しています。

    これらが停電によって一斉に突然停止するのは、できるだけ避けたいと考えていました。

    UPSがあれば、停電が発生した瞬間にすべてが停止するわけではありません。

    短時間ではありますがバッテリーから電力を供給できるため、その間に状況を確認したり、安全に停止したりするための時間を確保できます。

    私にとってUPSは、「停電してもそのまま運用を続けるための装置」というよりも、突然電源が落ちることを防ぐための保険に近い存在です。


    意外な敵は家族の家電同時使用

    自然災害による停電も心配ですが、自宅ラボを運用していて意外だったのが、もっと身近な問題でした。

    それが、家庭内での家電の同時使用です。

    朝や夕方など、家族がそれぞれ家電を使う時間帯があります。

    例えば、

    • 電子レンジ
    • オーブントースター
    • 電子ケトル
    • ドライヤー

    といった消費電力の大きい家電です。

    これらが同時に使用されることで、これまで何度かブレーカーが落ちた経験があります。

    ブレーカーが落ちれば、自宅ラボも当然突然停止します。

    自宅ラボのために家族へ「家電を同時に使わないで」とお願いするのも現実的ではありません。

    電子レンジやドライヤーを使うことは、普通の生活の一部です。

    サーバーを守るために家族の生活に制限をかけるのは避けたい。

    だからこそ、サーバー側で電源断に備えることにしました。

    ブレーカーが落ちた場合でも、UPSが動作すればサーバーはすぐには停止しません。

    その間に電源が復旧すればそのまま運用を継続できますし、復旧しない場合でも安全に停止するための時間を確保できます。

    自宅ラボを運用する上では、自然災害だけでなく、こうした日常生活の中で発生する電源トラブルも考える必要があると感じています。


    APC UPS 500を中古で購入

    そこで導入したのが、APCのUPS 500です。

    購入したのは2025年2月。

    ヤフオクで中古品を購入しました。

    購入価格は16,500円でした。(たぶんもっと安いのもあります。)

    新品のUPSは比較的高価ですが、中古であれば導入コストを抑えることができます。

    ただし、中古UPSには注意点もあります。

    それが、バッテリーの状態です。

    UPS本体は問題なく動作していても、内部のバッテリーは消耗品です。

    実際、私が購入したUPSも使用を開始してから1年経たずに純正バッテリーがダメになりました。

    中古UPSを購入する場合、本体価格だけでなく、

    「バッテリーを交換することになる可能性がある」

    という点も考えておいたほうがよさそうです。


    互換バッテリーに交換した

    純正バッテリーが使えなくなったため、互換バッテリーを購入することにしました。

    購入したのは楽天で販売されていた互換バッテリーです。

    ・LONG WP1236W 2個セット(産業用鉛蓄電池)【サイクルバッテリー】

    純正品よりも価格が安く、同じAPC製UPSで問題なく使用できたというレビューも参考にしました。

    購入時の価格は7380円でした。(参考までに)

    UPSのバッテリーは、単純に「安ければ何でもいい」というものではないため、実際に同じ機種や同じメーカーのUPSで使用した人のレビューは参考になります。

    そして、2026年1月4日にバッテリーを交換しました。

    (互換バッテリーへの交換は保証等はありませんので、自己責任になります。)

    古いバッテリーについても、購入した販売店で有料回収に対応していました。

    回収費用は1個550円。

    バッテリーは一般的なゴミとして簡単に処分できるものではないため、回収サービスがあるのは助かりました。

    今回は2個セットを購入したのですが、最初はなぜか1個しか届かないというトラブルもありました。

    販売店へ連絡したところ、その後もう1個も送ってもらうことができました。

    結果的には無事に2個そろい、UPSのバッテリーを交換できました。

    中古UPSを使う場合は、

    • 本体価格
    • バッテリーの状態
    • 交換用バッテリーの価格
    • 古いバッテリーの処分方法

    まで考えておくと安心だと思います。

    本体を安く購入できても、すぐにバッテリー交換が必要になる可能性があるためです。


    UPS 500で実際にどこまで守っているのか

    現在、UPS 500にはすべての機器を接続しているわけではありません。

    UPSの容量には限りがあるため、「何を優先して保護するのか」を考えて接続しています。

    現在、主に接続しているのは以下の機器です。

    Proxmox node ×3台

    自宅ラボの中心となっているProxmoxノードです。

    3台の自作PCでProxmoxクラスタを構成しています。

    このノード上で複数の仮想マシンやコンテナを運用しているため、私の環境では優先的にUPSへ接続したい機器です。

    NAS兼GPUサーバー

    NASやGPUを使用する用途を持つサーバーもUPSへ接続しています。

    Ryzen 5 3400G、64GBのメモリ、GPUなどを搭載した自作PCで、Proxmox VEを運用しています。

    このサーバーも自宅ラボの重要な機器の一つです。

    Proxmoxノードを接続するSAN用10GbEスイッチ

    サーバーだけではなく、Proxmoxノード間で使用しているSAN用の10GbEスイッチもUPSへ接続しています。

    停電時にサーバー本体だけが動いていても、必要なネットワークが先に停止してしまうと困るためです。

    私の環境では、通常のラボ用ネットワークとは別に、SAN用のネットワークを構成しています。

    停電が発生した際にも、仮想マシンやストレージ関連の処理に必要なネットワークを可能な限り維持することを目的として接続しています。


    まだUPSにつないでいない機器

    一方で、すべての機器をUPSへ接続できているわけではありません。

    今後UPSで保護したいと考えている機器もあります。

    • YAMAHA RTX1200
    • メインL3スイッチ(Allied Telesis AT-x510)
    • Proxmox Backup Server
    • 管理PC(NEC Mate)

    現在の自宅ラボには、メインのL3スイッチやバックアップサーバー、作業用PCなどもあります。

    では、なぜこれらをUPS 500につないでいないのか。

    理由は、UPSの使用率です。

    現在の使用率は約40%。

    数字だけを見ると、まだ余裕があるようにも見えます。

    しかし、UPSでは単純に「容量に余裕があるから、接続できるだけ機器をつなぐ」という考え方にはしたくありません。

    停電が発生した際には、UPSの負荷が少ないほど長く電力を供給できます。

    私の場合、停電から復旧するまで待つ時間、または安全にサーバーを停止するための時間を確保したいと考えています。

    そのため、あえてUPS 500には重要な機器を優先して接続し、ある程度の余裕を残しています。


    ネットワーク機器用にもう1台UPSを購入

    サーバー用のUPSとは別に、ネットワーク機器用として別のUPSも購入しています。

    2025年11月には、APC UPS RS400Sを中古で購入しました。

    こちらは、ネットワーク機器をUPSで保護することを目的として購入しました。

    ただし、記事執筆時点ではまだ本格的な運用には使用していません。(バッテリー交換待ち…)

    今後は、

    • RTX1200
    • メインL3スイッチ
    • その他のネットワーク機器

    などを別系統のUPSへ接続することを検討しています。

    サーバーとネットワーク機器を1台のUPSにすべて接続するのではなく、用途ごとにUPSを分けることで、容量やバックアップ時間を考えやすくなるのではないかと考えています。


    UPSを使ってみてどうだったか

    実際にUPSを導入して感じた一番のメリットは、やはり安心感です。

    停電が発生した瞬間、何の対策もしていなければサーバーは突然停止します。

    しかしUPSがあれば、少なくとも「その瞬間にすべてが落ちる」という状況は避けられます。

    突然電源が落ちない安心感

    自宅ラボを24時間動かしていると、常に停電を心配しているわけではありません。

    しかし、雷や自然災害、家庭内のブレーカー落ちなどは、自分では完全に防げない問題です。

    UPSがあることで、

    「もし電源が落ちても、すぐにはサーバーが停止しない」

    という安心感があります。

    復旧または安全な停止までの時間を確保できる

    UPSの役割は、長時間サーバーを動かし続けることだけではありません。

    短時間でも、

    • 電源が復旧するか待つ
    • サーバーの状態を確認する
    • 必要に応じて安全に停止する

    という時間を確保できます。

    私にとっては、この時間を確保できることがUPSを導入した大きな理由です。

    24時間運用するなら精神的な安心感が大きい

    自宅ラボは趣味として始めた環境ですが、現在では複数のサービスを常時動かしています。

    そのため、「突然落ちても仕方ない」と割り切るよりも、できる範囲で対策しておきたいと考えています。

    UPSは必ずしもすべての人に必要な機器ではないと思います。

    しかし、

    • 停電を経験したことがある
    • 雷が多い地域に住んでいる
    • ブレーカーが落ちることがある
    • 24時間サーバーを運用している
    • 突然の電源断をできるだけ避けたい

    という環境であれば、導入を検討する価値はあると感じています。


    まとめ|自宅ラボにUPSは必要なのか?

    私の結論は、必要な環境なら導入する価値があるです。

    私の場合は、自然災害による停電を経験したことに加えて、家族が家電を同時に使用したことでブレーカーが落ちることもありました。

    自宅ラボを守るために家族の生活を制限することはできません。

    だからこそ、サーバー側で電源トラブルに備えることにしました。

    現在は、APC UPS 500を中心に重要なProxmoxノードやNAS兼GPUサーバー、SAN用ネットワーク機器を保護しています。

    すべての機器を接続するのではなく、使用率を約40%に抑えながら、停電時に復旧または安全に停止するための時間を確保するという運用です。

    また、中古UPSを購入したことで、バッテリー交換という経験もしました。

    中古UPSは導入費用を抑えられる一方で、バッテリーの状態や交換費用も考える必要があります。

    それでも、停電やブレーカー落ちが発生した際に「突然すべてのサーバーが落ちる」という状況を避けられる安心感は大きいと感じています。

    自宅ラボの規模が大きくなるにつれて、サーバー本体だけでなく、ネットワークや電源についても考えることが増えてきました。

    次はネットワーク機器用として購入したUPSの運用も進めながら、自宅ラボ全体の電源構成も少しずつ改善していきたいと思います。

  • 自宅ラボ用の木製19インチラックをDIYしてみた|1×4材でサーバーラックを自作

    先日、Xに自宅ラボの様子を投稿したところ、たくさんの反応をいただきました。

    特に反応が多かったのが、1×4材を使ってDIYした木製ラックです。

    「これどうやって作ったの?」
    「設計図を見てみたい」
    といった反応をいただいたので、今回は実際に使った材料や設計、製作過程、そして作ってみて分かった失敗点までまとめてみます。

    DIY初心者が、できるだけ自分の環境に合わせて作ったラックです。

    完成した状態だけを見るとそれなりに見えますが、実際には寸法を間違えたり、後から補強が必要になったりと、いくつか失敗もありました。

    これから自宅ラボ用のラックを作ってみたい方の参考になればと思います。


    1. 木製ラックを作った理由

    これまでは、無印良品の竹製3段ラックに自宅ラボの機器を置いていました。

    当初は特に問題を感じていなかったのですが、Proxmoxのノードを3段に積んで使っていると、下の段のサーバーを開けるときに問題がありました。

    下段のサーバーをメンテナンスするためには、ケーブル類を外し、その上に載せているサーバーを一度どかす必要があります。

    また、竹ラックは1段あたりの高さにも制限があります。

    そのため、これまでは上段にサーバー、下段にネットワーク機器というように、機器の種類によって置き場所を分けていました。

    そこで、19インチラックを使って機器をまとめ、必要な機器へアクセスしやすい環境にしたいと考えました。

    もう一つの理由がUPSです。

    UPSを置く場所がなく、これまではデスクの足元に置いていました。そこで、今回作るラックの中にUPSも収められるようにすることにしました。

    自宅ラボの機器が増えてきたこともあり、「そろそろラックが欲しい」と思ったのが今回のDIYのきっかけです。


    2. 完成した木製ラック

    今回製作したのは、1×4材を組み合わせた木製のラックです。

    中央にサンワサプライの12Uラックを固定し、周囲を木材で支える構造にしました。

    外形は、おおよそ幅533mm、高さ910mm、奥行400mmです。

    19インチラックのマウント幅は495mmなので、ラックを木製フレームの中に収める構成にしています。

    (SNSにアップした画像↓)

    (設計図的なもの↓)

    ラック部分にはネットワーク機器やサーバーなどをラッキングし、その下のスペースにはUPSなどを置けるようにしました。

    木製なので一般的な金属製ラックとは少し雰囲気が違いますが、自宅の環境に合わせてサイズや構造を決められるのがDIYの面白いところです。


    3. 使用した材料・工具

    今回使用したものは以下の通りです。

    種類使用したもの
    木材1×4材(厚19×幅89×長1820mm)4本
    ラックサンワサプライ 卓上19インチマウントラック 12U ブラック CP-TB12UBK
    固定木ねじ(3.3×35mm)
    レール固定ワッシャー(M4用10mm)
    レール固定タッピングねじ(4×10mm)
    工具きり
    接着ボンド

    ※材料や商品の詳細、購入先などは必要に応じて追記します。

    サンワサプライのラックなど、今回使用した機材については、実際に使用したものを中心に紹介しています。

    ・サンワサプライ(Sanwa Supply) 卓上19インチマウントラック[12U] ブラック

    リンク:https://amzn.to/46f9sHf

    ・角利(KAKURI) ドリル錐 ストレート刃 & テーパー刃 最大穴径3.0mm 収納式 ハイス鋼ドリル刃 収納 永切れ きり キリ 貫通穴 下穴 DIY 日曜大工 道具 工具 41883

    リンク:https://amzn.to/4zBF5Zi

    ※この記事にはアフィリエイトリンクが含まれています。


    4. 設計で考えたこと

    今回のラックを設計するときに、特に意識したのが「横幅」「奥行き」「通気性」の3点です。

    横幅は600mm以内

    まず、設置場所の都合から、ラック全体の横幅を600mm以内に収めたいと考えました。

    19インチラックなので、機器を取り付ける部分は19インチ規格に合わせる必要があります。

    ただし、木材の厚みやラックを固定する部分もあるため、単純に19インチの幅だけを考えればよいわけではありません。

    実際、この部分は製作時に失敗することになります。

    奥行きは400mm程度

    次に奥行きです。

    ネットワークラックを選ぶ場合、奥行きが大きくなると設置場所との兼ね合いが出てきます。

    一方で、業務用のサーバーラックまで大きくすると、自宅に置くにはサイズ感が大きくなります。

    そこで、今回使用する機器の奥行きを考え、ラック自体の奥行きを400mm程度にしました。

    ただし、後述するように、奥行400mmのラックマウントケースを前側だけで固定すると、後方が下がってくるという問題が発生しました。

    通気性を確保する

    もう一つ意識したのが通気性です。

    木材で周囲を完全に板で囲ってしまうのではなく、1×4材を組み合わせてフレーム状にしました。

    これなら空気の通り道を確保できます。

    また、板を全面に貼るよりも材料を少なくできるため、コスト面でもメリットがあります。

    「必要な強度を確保しながら、できるだけシンプルにする」という考えで設計しました。


    5. 製作1日目|木材の加工と仮組み

    今回の製作で最初に困ったのが、電動工具を持っていなかったことです。

    もちろん手動工具も十分に揃っているわけではありません。

    そこで、木材のカットはホームセンターにお願いすることにしました。

    必要な長さにカットしてもらった1×4材を家に持ち帰り、まずはラック全体の組み方を確認します。

    次に、ねじを打つ位置を決めていきます。

    今回は、きりを使って下穴を開けました。

    いきなり本締めしてしまうのではなく、まずボンドを使って木材を仮止め。

    全体の位置や形を確認してから、次の工程へ進むことにしました。

    DIY初心者なので、最初から完璧に組み上げようとせず、「一度仮組みして確認する」ことを意識しました。

    1日目はここまで。

    ボンドが固まるまで、1日置いて乾燥させました。


    6. 製作2日目|ねじ止め・レール取り付け・ラッキング

    2日目は、仮止めした木材をねじで固定していきます。

    木製フレームが形になったところで、19インチラックのマウント部分を取り付けます。

    今回使用したラックの固定には、木ねじやワッシャー、タッピングねじを使いました。

    ラックマウントレールの位置を確認しながら固定し、実際に機器を取り付けていきます。

    ここまで来ると、ただの木材だったものが少しずつ「サーバーラック」らしくなっていきました。

    最後にProxmoxノードやネットワーク機器などをラッキング。

    実際に機器を収めてみると、想像していたよりもラックらしく仕上がりました。


    7. 作って分かった4つの失敗

    今回のDIYでは、実際に作ってみないと分からなかったことがいくつもありました。

    ここでは、これから同じようなラックを作る方の参考になるよう、失敗したところをまとめます。

    失敗1|木材の横幅を間違えた

    一番最初にやってしまったのが、木材の長さの間違いです。

    19インチラックのマウント幅を基準に寸法を考えていたのですが、実際に木材を組み込んでみると、想定していた内寸になりませんでした。

    「19インチだから、この長さにしておけば大丈夫」と考えていたのですが、木材の組み方や木材そのものの厚みを含めて考える必要がありました。

    結果として、用意していた木材では長さが足りず、追加で木材を購入することになりました。

    DIYでは、図面上の寸法だけでなく、「どの部材を内側に入れるのか」「木材の厚みがどこに影響するのか」まで考えておく必要があると実感しました。

    これから作る場合は、木材を切る前に実際の組み方をイメージしながら、内寸と外寸の両方を確認することをおすすめします。


    失敗2|12U目が使えなくなった

    次の失敗は、ラックマウントレールの取り付け位置です。

    今回は木製フレームにレールをできるだけピッタリ合わせて固定しました。

    ところが、実際に機器をラッキングしてみると、一番上の12U目が使えなくなってしまいました。

    レールを木台に近づけすぎたことが原因です。

    数ミリ程度の余裕を持たせておけばよかったと思います。

    現在はワッシャーをかませて固定しているため、数ミリ程度であればレールを移動できる余地があります。

    次回のメンテナンス時に、レールの位置を調整する予定です。

    「取り付けられる位置」だけを見るのではなく、「一番上・一番下まで実際に機器を取り付けられるか」を確認してから固定するべきでした。


    失敗3|奥行400mmのラックマウントケースが傾いた

    今回の設計で特に反省しているのが、奥行方向の支えです。

    奥行400mmのラックマウントケースを前側だけで固定したところ、最初は問題ありませんでした。

    しかし、時間が経つにつれて、ケースの後方が少しずつ下がってきました。

    ラックマウント機器は前側の耳の部分だけで固定できるように見えますが、木製ラックでは荷重のかかり方にも注意が必要でした。

    そこで、後からラックの奥側に支えとなる木材を追加しました。

    これで後方を支えられるようになり、現在は問題なく使用できています。

    奥行きのある機器をラッキングする場合は、最初から後方の支えを設計に入れておくべきでした。


    失敗4|木材を加工せず、そのまま使った

    最後は、木材そのものについてです。

    今回は1×4材をカットしたあと、やすり掛けや塗装をせず、そのまま使用しました。

    製作当初は特に問題ありませんでしたが、時間が経つと湿気の影響で木材が少し歪んできました。

    現時点では機器をラッキングして使用するうえで大きな問題はありません。

    ただ、見た目や耐久性まで考えるのであれば、木材をやすり掛けして表面を整えたり、塗装などの処理をしておいたほうがよかったと思います。

    今回は「まず作ってみる」ことを優先しましたが、次に木製ラックを作る機会があれば、このあたりも改善したいところです。


    8. 完成後に使ってみて

    実際に完成したラックを使ってみると、思っていたよりもうまくできました。

    これまで使っていた竹製ラックでは、下段のサーバーへアクセスするために上の機器を移動させる必要がありました。

    今回のラックでは、それぞれの機器をラックにまとめられたため、以前よりもメンテナンスしやすくなりました。

    UPSもラック内に収められたので、デスクの足元に置いていた機器を整理できたのもよかったところです。

    一方で、実際に使ってみたことで分かった課題もあります。

    特にラックマウントレールの位置や、奥行方向の支えについては、最初の設計段階でもう少し考えておけばよかったと思います。

    今回の経験は、次にラックを製作するときに生かしたいと思います。

    また、レールの長さを変えれば、ラック部分をさらに拡張することもできそうです。

    現在ラックの上に置いているネットワーク機器についても、将来的にはラッキングしてみたいと考えています。


    9. まとめ|DIYだからこそ自分の環境に合わせられる

    今回、1×4材を使って自宅ラボ用の木製19インチラックをDIYしてみました。

    実際に作ってみると、寸法を間違えたり、レールの位置を失敗したり、後から補強が必要になったりと、いくつか問題もありました。

    特に、ラックマウントケースの形状や奥行きによっては、今回と同じ方法でうまく固定できない可能性があります。

    そのため、この設計をそのまま使えばどんな機器でも取り付けられる、というものではありません。

    私が使用しているラックマウントケースでは問題なく使用できていますので、これから自宅ラボ用のラックをDIYしてみたい方は、一例として参考にしてもらえればと思います。

    DIYの良さは、自分の環境に合わせてサイズや構造を決められること。

    市販のラックでは「少し大きい」「この場所には入らない」「ここにUPSを置きたい」といった問題があっても、自作なら自分の環境に合わせて調整できます。

    今回のラックも、まだ完成形ではありません。

    これから自宅ラボの機器が増えていけば、さらに改良していきたいと思います。

    この記事が、自宅ラボのラックをDIYしてみたい方の参考になれば嬉しいです。