NAS新調。TS-216G選定理由。

デジタルデータの保管庫として、自室で稼働し続けてきたNAS。気づけば導入から10年という月日が流れていました。

なぜ今、リプレースが必要だったのか。そして数ある選択肢からなぜ冒頭の機種を選んだのか。その経緯のメモです。

限界を超えたHDD。

きっかけは、現在のNAS(ASUSTOR AS-202T)のディスクチェックを確認したことでした。そこに並んでいた数値は、まさに「驚愕」の一言です。

  • 稼働時間:
    • 約45,000時間(設計寿命の目安30,000時間を大幅超過)
  • ヘッド退避回数:
    • 約340万回(公称耐用回数60万回の5倍以上)

NAS本体は2015年の導入。2021年にディスクの状況が怪しくなって2TB→4TBに交換。

そこから大きなトラブルもなく動いてくれたのは奇跡に近いと言えるでしょう。そして、筆者が利用していただけというのも相まって、奇跡的に長持ちをしました。

決断の理由

実は2022年頃から「そろそろ機器も限界だろう」とは感じていました。しかし、日々の忙しさやコスト(何より2022年はコロナに罹患、そこからVPSの運用やらクラウドストレージの失敗と出費)を前に、騙し騙し運用を続けてきたのが本音です。

今回、重い腰を上げた決定的な要因は「ストレージ市場の激変」です。2025ね12月よりSSDの価格暴騰が続き、その波がHDDに波及するのも時間の問題という状況。

「今この瞬間が、最も安く、安全に逃げ切れる最後のチャンスだ」という直感が、4年越しの迷いを断ち切らせました。

そして注文して届いたのがこちらです。

なぜ「QNAP TS-216G」を選んだのか

選定にあたっては、同一メーカーであるASUSTORは候補に挙がっていましたが、エントリーモデルは市場で手に入れづらく、ミドルモデルは逆に高い。そこで、選択肢として上がったのが

  • QNAP
  • UGREEN

の2択。特に、圧倒的なスペックの新興勢力であるUGREENなども検討対象に挙がりました。しかし、最終的に老舗のQNAPを選んだ理由は、単なるスペック比較では測れない「データの重み」にありました。

  • ソフトウェアの信頼性:
    • 単なるファイル置き場ではなく、PCまるごとのバックアップや復旧(ベアメタル復旧)まで備えた信頼性の高く守備の広いソフトウェア群
  • 静音・排熱設計:
    • ホームNASにも一日の長があるメーカーです。リビングに置くことを前提とした、10年先を見据えたハードウェアの造り込み。
  • アップデートの継続性:
    • 長期間、最新のセキュリティパッチを供給し続けるエンタープライズ向けメーカーという信頼。
  • セキュリティと地政学的リスク:
    • これが一番の問題かもしれません。「かの国の法律は仕込もうと思えばバックドアを仕掛けられる」という懸念がありました。

特に、「自分だけの記録」という、失えば二度と手に入らない単一障害点を守るため、新興勢力への不安を捨て、実績あるQNAPを選びました。

HDDとしてこれを選んだ理由

NASの筐体が決まったら、次に決めるべきは最も重要な心臓部、HDDの選定です。今回、私は迷わずWestern Digitalの「WD Red Plus (8TB)」を2台選択しました。

これまで使用していたWD Blueも、10年・45,000時間という驚異的な耐久性を見せてくれましたが、「NAS専用品」を載せるべき明確な根拠がありました。

24時間365日の「常時稼働」を前提とした設計

現行のWD Blueが「PCを使っている間だけ動く」ことを想定しているのに対し、WD Red Plusは「1年365日、1秒も休まず動き続ける」ことを前提に設計されています。

今後、PCパーツの値上がりが予想されているので、逆にケチらない方が安上がりという判断。

「CMR方式」へのこだわり

近年のHDDには、安価ですが書き込み速度にムラが出やすい「SMR方式」が増えています。しかし、NASのRAID構成において書き込み遅延は致命的なエラーに繋がりかねません。
WD Red Plusは、安定した記録が可能な「CMR(従来型磁気記録)方式」を堅持しています。データの整合性を最優先するNASにおいて、この信頼性は譲れない一線でした。

NAS特有の「振動」への対策

2台、3台とドライブを並べて動かすNASでは、お互いの回転振動がエラーの原因になります。WD Red Plusには、この振動を検知し補正する仕様。
静音性に優れたQNAPの筐体と、振動に強いWD Redを選んだわけです。

今後の流れ

  1. セットアップ
  2. 基礎設計
  3. 運用方針決め
  4. データ移行の計画
  5. 移行と同時に実運用

先は長いのですが、HDDの寿命待ったなし。そこはFestina Lenteの精神で行きます。

バーガーの休日。

連休最終日に開拓したお店が自分好みでした。

和牛100%、夕方までお腹いっぱいというボリューミーなハンバーガー。

非常に丁寧に造られたパティに、みずみずしいサラダ(タマネギ、トマト、レタス)が合いました。

そして、これだけの素材を挟みながらも型崩れしないバンズ。程よい堅さはハンバーグとしっかり調和。かみ切れるからこそ、途中で潰れたりソースでふやけるということもありません。

チップスも一級品。カリカリの表面にサクッとした芋の風味。

こう、新たな見せを発掘するというのもまた休日の収穫です。

『ライザのアトリエ2(及び2DX)』アークナイトの採取。

スタルチウム調合に必要な素材、アークナイト。レシピ調合で必要なのに属性値が1と序盤の難所となっています。

斧での採取

シルム湿原

ヴィントミューレ渓谷にファストトラベルして湿原に戻った先、

乳白色の水晶で採れます。
序盤はここで採取することになるでしょう。

霊獣での採取

遺跡「戦乙女の地下墓所」マップ2:鐘鳴り路

確率は低めですが、属性値2のアークナイトを霊獣で掘り当てることができます。

  1. マップ入り口から右側に沿って霊獣で移動する。
  2. 掘り当てる場所が3箇所ぐらい固まっていますので掘ります。
  3. 2DXであれば、『手向けの花々』にファストトラベルできるので更に便利です。

※効果「掘り当てる:大」以上は必要です。

上記2箇所で採取。それ以降は種やショップ開発でより高品質なアークナイトを入手します。

種での採取

石の種で良質なものが採れます。(効果を解放すれば)

ショップ開発

「エーテルコア」売却で解放されます。周回プレイを見据えるのであれば売却しておきましょう。

ケーブル兼ストラップ。

いざというときに仕えるし、実用性もあるという品を入手です。

この、充電ケーブルそのものがストラップになっているという仕様。

スマートフォンケースにアタッチメントを取り付けるだけ。

これで、ショルダーストラップ完成。

保護カバーを取り外せば充電もできます。しっかりと落ちないようにストラップつきでした。

Nextcloudで大容量ファイルを安定して扱うためのApacheチューニング:RequestReadTimeoutの調整

スマートフォンからの画像を自分のPCに転用する形で用いているNextcloud。

アップロードが途中で失敗したり、特定の条件下で接続が切れたりすることがあります。Apacheビルトインのmod_reqtimeout設定を最適化し、サーバーの安定性と利便性を両立させるためのチューニングを行いました。

環境

  • Nextcloud 32
  • Apache 2.4
  • PHP-FPM8.3
  • Ubuntu 24.04

そもそもmod_reqtimeoutとは?

Slowloris(スローロリス)攻撃への対策

このモジュールがビルトインされたのは、Slowlorisという、非常に低コストで強力な攻撃手法への対抗があります。

通常のDoS攻撃は大量の通信を送りますが、Slowlorisは逆に「極めてゆっくり」通信します。

  1. サーバーに接続を開始する。
  2. リクエスト(ヘッダーやボディ)を、タイムアウトにならないギリギリの遅さで、1バイトずつ小出しに送る。
  3. サーバー側は「まだデータが来るはずだ」と判断し、その接続(スレッドやプロセス)を維持し続ける。

結果 サーバーの同時接続数の上限が攻撃者の「待ち」状態で埋まってしまい、正規のユーザーがアクセスできなくなります。

mod_reqtimeout は、この「嫌がらせ」を許さないための防衛線です。

サーバーリソースの適正管理

Apacheサーバーが1つの接続を維持するには、メモリやCPUリソースを消費します。
もしタイムアウト設定がない、あるいは極端に長い場合、以下のような問題が発生します。

  • ゾンビ接続の蓄積: ネットワークが切れたのにクローズ処理が終わっていない接続が残り続ける。
  • リソースの浪費: 応答の遅いクライアント(意図的か否かに関わらず)のために、サーバーの貴重な作業枠をいつまでも空けておくことになります。

なぜこれがNextcloudで徒になるのか

Nextcloudのデータの性質と通信の仕組みにあります。

巨大なファイルを細切れにする

Nextcloudは、数MBから数GBあるような大きなファイルを送る際、一気に送らずにファイルを分割して、「チャンク(塊)」に分割して送信します。

  • 動作の流れ:
    • チャンクAを送信 → サーバーが処理 → チャンクBを送信……
  • 問題点:
    • チャンクとチャンクの間に、クライアント側でのファイル読み込みやハッシュ計算などで一瞬「無通信」の時間が流れます。
  • 結果:
    • Apacheのmod_reqtimeoutは、この無通信を先のSlowlorisと誤認して、接続をバッサリ切ってしまいます。

モバイル回線の不安定さ

Nextcloudは外出先のスマートフォンから使うことを想定しています。

  • 電波の瞬断:
    • 移動中にWi-Fiから4G/5G回線に切り替わったりする。
  • 上り速度の制限:
    • モバイル回線は「下り」は速くても「上り」が極端に遅いことが多い。

これも、先のSlowloris攻撃と見做されてしまいます。

チューニングの必要性

だからといって、このmod_reqtimeoutを無効にすると、それらの攻撃への備えがなくなります。

Nextcloudの利便性を高めつつ不審な攻撃を守るというのは

「任務」は遂行する「部下」も守る
お前ごときに「両方」やるというのはそう難しいことじゃあないな

ぐらいの精神でやっていきましょう。

さっくりとした手順

  • mod_reatimeoutの設定ファイルのバックアップを取る。
  • mod_reatimeoutの設定ファイルを修正する。
  • サービス再起動を行う。

mod_reatimeoutの設定ファイルのバックアップ

  • 念のためのモジュール確認
sudo apache2ctl -M |grep req

reqtimeout_module (shared)を確認します。(apacheをapt等で入れていれば、まず入っています)

  • ファイルバックアップ
sudo cp -pi /etc/apache2/mods-available/reqtimeout.conf /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d)

/path/to/backup/directoryは自分の環境に合わせます。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 

エラーがないことを確認します。

mod_reatimeoutの設定ファイルを修正

/etc/apache2/mods-available/reqtimeout.confを管理者権限で修正します。

筆者は以下のように行いました。

-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500

具体的には、リクエストボディ(データの送信本体)の読み取り開始を待機する時間を10秒から20秒へ延長しています。

  • body=20:
  • リクエストボディの最初の1バイトを待つ時間を20秒に設定。
  • minrate=500:
  • データが送り始められた後、最低でも秒間500バイトの転送速度を要求する。これより遅い状態が続くとタイムアウトします。
  • ファイルの差分確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 

以下のような差分を確認します。

-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500

設定反映

  • 構文チェック
sudo apache2ctl configtest

Syntax OKとなることを必ず確認してください。でないと、apacheサービスが停止したままとなってしまい、サービス断が発生します。

  • Apache サービス再起動
sudo systemctl reload apache2.service
  • Apacheサービス再起動確認
systemctl status apache2.service

active(running)を確認します。

まとめ

Nextcloudサーバーにおいて、RequestReadTimeout のbody待ち時間を延長することは、「モバイル環境や大容量ファイル送信時の安定性」を向上させるために非常に有効な手段です。

もし、ログ(Apacheのerror_log)に The timeout specified has expiredrequest body read timeout といった記録が残っている場合は、この値を調整してみることをお勧めします。

  • 参考コマンド
sudo grep "request body read timeout" /var/log/apache2/error.log

2026年3月の外食記録-2-

昨日の続き、メインディッシュと言える食事群です。

鰯塩焼き

本当に鰯なのかと言うぐらいの大きさ。骨離れも良好。ワタもみっちり詰まって濃厚。身の脂ののりも言うまでもないです。

鱈の唐揚げ

フィッシュアンドチップスの定番、鱈がこうなるという例。白身がふわふわで、英国時代のものとは次元が違いました。

ポテトコロッケ

自家製という気合いの入れよう。ジャガイモを皮ごと潰した野趣あふれる風味が最高でした。

食事:手巻き

ブリの漬けを手巻きにするという技巧。のりがふやけないうちにすぐに食べる必要があったものの、これもおいしかったです。

いずれも、いい食事で心が満たされました。

2026年3月の外食記録-1-

週末、お世話になっているお店でのおいしい食事をいただきました。

刺身から始まり。この切付の時点で鮮度と腕がうかがえます。

蒸したジャガバターの上にウニをのせるという背徳的な食べ方をしたり

旬のホタルイカの酢味噌和え、

店の自作という牡蠣のオイル漬け。

この時点でも感動は極上でしたが、まだ続きがあります。

2026年3月の差しボードゲーム記録。

友人と卓を囲みました。

ロストシティ タイルズ

色を絞れたこともあり、40点差をつけての勝利。(上のタイルは計算のため順番を変えています)

真打

納涼落語会での『牡丹灯籠』に年末落語会の『芝浜』をかけることができました。

宝石の煌めき デュエル

一色10点で勝利。発展カードの偏りを読み取れたのが功を奏しました。

天下鳴動

計略カードと援軍が勝敗を形づけるゲーム。運と戦略が絡むゲームではありましたが敗北。

いい気分転換でした。

Nextcloud Ver 32にアップデート後、高性能バックエンドのDockerをアップデート。

警告: 実行中のバージョン: 2.0.4~docker; サーバーはこのTalkバージョンの全ての機能をサポートしていません。欠落している機能: chat-relay

と出たので、それに対応していきます。

環境

  • Nextcloud 33.0
  • Dockerを利用して高性能バックエンドサーバ(Signaling Server)を構築。構築手順
  • それ以外はLAMP環境。
    • Apache 2.4
    • MySQL
    • PHP-FPM
    • その上でNextcloud

アップデートは、こちらの手順で、コマンドラインから行いました。

その後、管理画面で上記のエラーが出たという次第です。

やっぱり必要なフェイズ・ゼロ

このNextcloudを個人的に運用しているのならばそのまま行って構いません。しかし、これを組織で運用しているとなると話はまるで違います。

  • NextcloudのアップデートによりDockerコンテナもアップデートが必要。
  • ついてはこの計画でサーバ設定を行う
  • そのため、追加で作業時間をいただきたい
  • 作業時間は○時頃、○分程度で終わる。その間、Nextcloudは使えなくなる
    など、利用者への周知という名の政治交渉が必要になります。この運用者の政治的な立ち位置(担当者/担当部門が強権を振るえるか否か)でも言い方や手段が決まってきます。そこは状況に応じていきましょう。

※ 検証環境を用意できる程度には時間と予算と環境に余裕がある方は、その環境にいることを感謝しつつ、検証を重ねていきましょう。

さっくりとした手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Dockerの設定ファイルを修正します。
  3. Dockerコンテナを最多値揚げします。
  4. Nextcloudのメンテナンスモードを無効化します。
  5. エラーの解消を確認します。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

設定ファイル (server.conf) の構成

  • ファイルのバックアップ
sudo cp -pi /hoge/docker/files/nextcloud-signaling/server.conf /path/to/backup/directory/server.conf.$(date +%Y%m%d)

自分の環境に合わせます。

  • ファイルのバックアップ確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

差分がないことを確認します。

  • server.confファイル修正

chat-relay 機能を有効にするため、以下のように項目を付け加えます。

  • [chat] セクション(新規追記)
[chat]
enabled = true

追記したら保存を行います。

  • ファイル修正確認
diff -u /path/to/backup/directory/server.conf.$(date +%Y%m%d) /hoge/docker/files/nextcloud-signaling/server.conf

以下の差分を確認します。

+ [chat]
+ enabled = true

Docker アップデート・再起動

これが地味にハマりました。古い docker-compose (v1.29.x等) を使用している環境だと、イメージのメタデータ構造の違いによるエラー(KeyError: 'ContainerConfig')が発生。

それを避けるための手順です。

  • 最新イメージの直接取得

docker-compose を介さず、Docker本体で最新イメージをプルする。

sudo docker pull strukturag/nextcloud-spreed-signaling:latest
sudo docker pull nats:2.9
  • 不完全なコンテナの掃除

作成失敗などで残った残骸を削除し、競合を防ぐ。

sudo docker container prune -f
  • コンテナの起動
sudo docker-compose up -d

Nextcloudのメンテナンスモードの無効化

  • メンテナンスモード無効化
sudo -u www-data php occ maintenance:mode --off
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、管理画面に入ります。

Nextcloud管理画面での反映

Nextcloudの「設定」>「Talk」にある高性能バックエンド設定で、URL横の「チェックマーク(保存)」を押し、chat-relayAvailable features に含まれたことを確認して対処完了です。

改めて思ったこと

Dockerは確かに便利な代物ですが、管理が複雑になっていくというのが難点。それ故、Dockerは最小限にして登録していきたいものです。

緊急対応:Ubuntu搭載PCが不調となったとき(initramfsエラー)の対処。

宅内でのサーバとして立てているUbuntu20.04という完全にEOLを迎えている機体。それがエラーを起こしたときのメモです。

1. 発生した事象

Ubuntu 20.04を入れているミニPCの起動時、画面に以下のメッセージが表示され、デスクトップが立ち上がらずに (initramfs) というプロンプトで停止しました。

  • sgx: disabled by BIOS
  • (initramfs) _ (入力待ち状態)

2. 原因切り分け

以下、Geminiからのアドバイス。

  • SGXのメッセージ: これは単なる「通知」であり、起動不可の直接的な原因ではないことが多い。
  • initramfsでの停止: 真の原因は、ファイルシステムの整合性エラー。強制終了や停電などで、Ubuntuがインストールされているディスク領域(パーティション)が正常に読み込めなくなったために発生します。

3. 対処手順(修復方法)

これに従って対処を行いました。

エラーを起こしたパーティションの特定

(initramfs) プロンプトで exit を入力

エラーの詳細(どのパーティションが壊れているか)を確認するために、まず exit と打ちます。

エラーメッセージからデバイス名を特定

The root filesystem on /dev/sdb2 requires a manual fsck

というメッセージが表示されました(筆者環境)これをメモします。

パーティション修復

特定したデバイス名に対して修復コマンドを実行します。

fsck /dev/sdb2 -y

-y オプションを付けることで、すべての修復箇所を自動で「Yes」として処理します。

修復完了後の再起動

FILE SYSTEM WAS MODIFIED と表示されたら、以下のコマンドで再起動(またはブート続行)を試みます。

reboot

または

exit

結局原因は?

機器が古すぎたためのディスクエラー につきます。

これが仕事でしたら「さっさと取り替えろ」「いや、取り替えないように準備する」なのですが、自分の環境なのでそうはいかず。

なんとか予算と時間を見つけてリプレースをする必要に迫られました。

Page 1 of 286

Powered by WordPress & Theme by Anders Norén