HBS3アップデート後、RTRRデーモンがCPU使用率17%超え

この問題に加えて、7台あるNASのうち2台(ポート8899でRTRRを使用)がバックアップの際に頻繁に接続不能になります。HBS3を再起動すると、一時的に接続問題は解消します。

ご利用のNASの機種、現在のファームウェアバージョン、そしてインストールされているHBS3(Hybrid Backup Sync 3)のバージョンを教えてもらえると、役立つ情報になります。

モデル:TVS-473XT。

QTS 529.3499。

その状態で24時間以上動いていました。アプリを停止して再起動したら直りました。

また出ました。7台あるNASのうち、これが出ているのは1台だけです。他にも同じ症状の方いますか?

ご指摘いただいた接続問題についてですが、次回発生した際にはHBSのデバッグログをご提供いただけますでしょうか(クラウドドライブにアップロードし、プライベートメッセージでリンクをお送りください)。こちらでチームが確認いたします。

CPU使用率についてですが、当社のシステムは現在の状況に応じてCPU使用率を調整しています。現在の18%のCPU使用率は何か実際に問題を引き起こしていますか?もしくは、何か異常を感じられましたか?アップデート前の通常のCPU使用率もお教えいただけると助かります。ありがとうございます!

HBS3からデバッグログおよび分析に必要な情報を収集する方法 | QNAP

昨夜も再び切断が発生しました。接続できない2台のNAS(毎回同じ2台)からのログもお送りしますね。そして、接続できない4台のNASについてもお送りします。問題のある2台のNASは、離れた場所にあり、それぞれ別々の静的IPの裏にありますが、同じ場所にある他のNASは全く問題ありません。

また、そのNASは何年もCPU使用率が6〜9%で安定していたのですが、HBSをアップデートしてからはCPU使用率が26〜29%になりました。HBSを一度停止して再起動するとCPU使用率がまた6〜9%まで戻りますが、次の日になると再び26〜29%に上がります。そのNASのログも合わせて送ります。

TS-251、TS-264、TS-464のいずれでも同じ問題が発生しています――いずれも最新のQTSバージョンと最新のHBS3バージョンを使用しています。この問題は、6月初めのHBS3の最新アップデート以降に発生しました。デバッグログでは私には明確な原因が分かりません。ログには、ポート8899経由で接続できないとだけ記載されています。RTRR_DAEMONプロセスを手動で停止し、RTRRサービスを再起動(NASの再起動では改善しません)すると、バックアップジョブが1回だけ実行されますが、次のジョブはまた止まったままになります。

やはりHBS3のアップデートを元に戻すのが一番良さそうです。

私は何週間もこの問題と戦いました。7台中6台のNASのポートを別々に変更することで、「1回バックアップが成功した後、接続できなくなる」問題が解決しました。9988、8898、8989、8999、9898、9888です。1台は8899のままにしましたが、CPU使用率が約27%で、以前は7%ほどでした。再起動しても、HBS(Hybrid Backup Sync)を再度実行するまでしか直りませんでした。@NA9Dさんが別のスレッドで「ゾンビプロセス」について提案していた方法を参考に、HBSを停止し、NASの電源を完全に切って再起動しました。それから、そのNAS上のHBSを再び動かすために、ストレージスペースを持つ他のNASに行き、「サービス」をクリックして「適用」をクリックしました。すると「すべての接続がリセットされます」というメッセージが出ますが、まさにそれを実行したいのです。CPU使用率は通常に戻り、私の160個のHBSジョブが全て動作しています。

これはほぼ間違いなくバグです。最初の週はISPの問題で多くのパケットがドロップしていましたが、彼らがそれを修正したので、HBSの問題だと確信しました。

同じ問題が、最新のファームウェア5.2.9.3499でも発生しています。
TS-230とTS-251Aの端末をいくつか使っていて、RTRR(リアルタイムリモートレプリケーション)を一部で動かしています。以前のファームウェアバージョンではすべてのジョブが正常に動作していましたが、今はサービスに接続できなくなっています。RTRRを再起動すれば接続問題は解消しますが、次のレプリケーションでまた失敗してしまいます。

早まってしまいました。2日後、またRTRRデーモン(RTRR Daemon)がCPUの18%を使用しています。新しいポートは引き続き動作しています。

今日のアップデートで解決しました。

また早まった発言をしてしまいました。2日後、RTRRが再びCPUの17〜18%を使用していました。このNASではRTRRサーバーがオフになっていました。RTRRサーバーをオンにしたところ、2日後にはCPU全体の使用率が約7%になりました。QVR-472XT。QTS 529..3499 HBSの最新バージョンです。

確かに、アップデートでは改善は見られませんでした――2日後にはまた「元通り」になってしまいました…これはTS-251+、TS-264、TS-464のいずれでも最新のQTS(キュー・ティー・エス)で同様です。

かなりフラストレーションが溜まりますね…デバッグログにも私の見る限り、エラーの手がかりになるような情報は特にありませんでした。

また17%に戻りました。他の6台のNASではこんな動作はしていません。

TS-873AeU と TS-264 の両方でまったく同じ問題が発生しています。どちらも最新のファームウェアと HBS 3 の最新バージョンを使用しています。

ポート8899には引き続き到達可能で、ネットワークや設定の変更も行っていないにもかかわらず、RTRR接続が突然機能しなくなります。ほとんどの場合、RTRRの設定を再適用したりパスワードを再入力したりするとすぐに接続が復旧しますが、稀にNAS本体を再起動しないと直らないこともあります。

両方のNASシステムで発生しているため、ネットワークやファイアウォールの問題というよりも、HBS 3/RTRRサービス側の問題のように思えます。

昨日チケットを出しました。

チケットの結果:
私のチームがこの問題をソフトウェアのバグとして報告したようです。これはHBS3 26.4.2で修正される予定ですが、そのリリース時期についてはまだ分かりません。

アップデートについて、アプリを随時ご確認ください。

他にご質問があればお知らせください。

新しいバージョンがあります

  • HBS 3 Hybrid Backup Sync 26.4.2.617

    2026/07/15

    [修正された問題]

    • SSHベースのRsyncジョブが一部のNASファームウェアバージョンで「unknown option」エラーで失敗する問題を修正しました。
    • RTRRサーバー(rr2ゲートウェイ)がポートスキャン後に応答しなくなる問題を修正しました。
    • Azureクラウドバックアップで、マルチパートサイズが小さくファイルが大きい場合にメタデータのアップロードに失敗する問題を修正しました。
    • ネットワーク障害が長時間続いた後、Box同期ジョブが期限切れの変更ストリームにより失敗した場合のエラーメッセージを改善しました。
    • Active Syncジョブが暗号化/復号化後に宛先フォルダーを検出できずに失敗する問題を修正しました。
    • 過剰なActive Syncジョブが一時的なマウントファイルを残し、ストレージ容量を消費する問題を修正しました。
    • SSHログインバナーが原因で、転送が成功しても同期ジョブが失敗として報告される問題を修正しました。
    • 旧バージョンのHBS先にバックアップする際、保持されるバージョン数が設定と一致しない問題を修正しました。
    • OneDrive Personalの双方向同期で、サイズ除外フィルター使用時に成長中のファイルがアップロードに失敗する問題を修正しました。
    • USBドライブ名が「USBDisk」+数字の場合、MRスキャン後にリアルタイム同期ジョブが失敗する問題を修正しました。

リリースノート HBS 3 Hybrid Backup Sync