Zusätzlich zu diesem Problem werden 2 meiner 7 NAS, die Port 8899 für RTRR verwenden, immer wieder für Backups unerreichbar. Ein Neustart von HBS3 behebt das Verbindungsproblem vorübergehend.
Es wäre wahrscheinlich hilfreich zu wissen, welches NAS-Modell du hast, welche Firmware-Version du verwendest und welche Version von HBS3 bei dir installiert ist.
Modell: TVS-473XT.
QTS 529.3499.
Es lief auf diese Weise über 24 Stunden. Habe die App gestoppt und neu gestartet, und das hat das Problem behoben.
Bezüglich der von dir genannten Verbindungsprobleme: Bitte schicke uns beim nächsten Auftreten die HBS-Debug-Logs (du kannst sie auf einen Cloud-Speicher hochladen und uns den Link per privater Nachricht senden). Unser Team wird sich das dann anschauen.
Zum Thema CPU-Auslastung: Da unser System die CPU-Auslastung je nach aktueller Situation anpasst, möchten wir fragen, ob die derzeitige Nutzung von 18 % tatsächlich Probleme verursacht oder ob dir etwas Ungewöhnliches aufgefallen ist? Wie hoch war deine typische CPU-Auslastung vor dem Update? Vielen Dank!
Wie sammle ich die Debug-Protokolle von HBS3 und alle notwendigen Informationen zur Analyse? | QNAP
Die Verbindung ist letzte Nacht wieder abgerissen. Ich werde dir auch die Logs der beiden NAS schicken, zu denen keine Verbindung aufgebaut werden kann (es sind jedes Mal dieselben zwei), sowie die Logs der vier NAS, die sich nicht verbinden können. Die zwei betroffenen NAS stehen kilometerweit auseinander und haben unterschiedliche, feste IPs. Andere NAS am selben Standort haben jedoch keine Probleme.
Das betreffende NAS lief jahrelang mit 6–9 % CPU-Auslastung. Seit dem Update von HBS sind es 26–29 % CPU-Nutzung. Wenn ich HBS stoppe und neu starte, geht die CPU-Auslastung wieder auf 6–9 % zurück. Am nächsten Tag sind es wieder 26–29 %. Für dieses NAS schicke ich dir die Logs ebenfalls.
Habe gleiche Probleme auf TS-251, TS-264 und TS-464 - jeweils mit dem neuesten QTS-Stand und dem neuesten HBS3-Stand. Ist mit dem letzen HBS3-Update Anfang Juni aufgetreten. Debug Logs bringen für mich keine Klarheit. In meinen steht nur drin, dass die Verbindung über Port 8899 nicht aufgebaut werden kann. Ein manuelles Stoppen des RTRR_DAEMON Prozesses und dann ein Neustart des RTRR-Dienstes (Neustart der NAS macht es nicht besser) führt dazu, dass genau ein Sicherungsjob durchgeführt wird - der nächste bleibt wieder hängen.
Ich denke, dass Beste wird sein,das HBS3-Update zurückzudrehen.
Ich habe wochenlang damit gekämpft. Das Wechseln von 6 von 7 NAS-Geräten auf andere Ports hat das Problem gelöst, dass nach einem Backup keine Verbindung mehr bestand. 9988, 8898, 8989, 8999, 9898, 9888. Eins habe ich auf 8899 gelassen, aber dort war die CPU-Auslastung bei ca. 27 %, vorher waren es ca. 7 %. Ein Neustart hat das nur so lange behoben, bis HBS wieder lief. Nach einem Tipp von @NA9D in einem anderen Thread über Zombie-Prozesse habe ich HBS gestoppt, das NAS komplett heruntergefahren, den Strom getrennt und wieder neu gestartet. Damit HBS auf diesem NAS wieder funktioniert, musste ich bei den NAS-Geräten, auf denen es Speicherbereiche hatte, auf Dienste gehen und dort auf Übernehmen klicken. Es erscheint eine Meldung, dass dadurch alle Verbindungen zurückgesetzt werden. Genau das will man erreichen. Die CPU-Auslastung ist jetzt wieder normal und alle meine 160 HBS-Jobs laufen.
Das ist mit ziemlicher Sicherheit ein Bug. In der ersten Woche hatten wir Probleme mit unserem Internetanbieter und viele Pakete gingen verloren, aber sie haben das behoben und ich wusste, dass es ein Problem mit HBS war.
Gleiches Problem hier mit der neuesten Firmware 5.2.9.3499.
Ich habe ein paar TS-230 und TS-251A Geräte mit RTRR zwischen einigen von ihnen. Mit den vorherigen Firmware-Versionen haben alle Jobs einwandfrei funktioniert, aber jetzt können sie keine Verbindung mehr zum Dienst herstellen. Ein Neustart von RTRR behebt das Verbindungsproblem, beim nächsten Replikationsvorgang tritt der Fehler allerdings wieder auf.
Ich habe mich wohl zu früh gefreut. Nach 2 Tagen nutzt der RTRR-Daemon schon wieder 18 % CPU. Die neuen Ports funktionieren weiterhin.
Das heutige Update ist gelöst.
Wieder zu früh gefreut. Nach 2 Tagen hat RTRR wieder 17-18% CPU genutzt. Auf diesem NAS war der RTRR-Server deaktiviert. Ich habe den RTRR-Server eingeschaltet und nach 2 Tagen lag die gesamte CPU-Auslastung bei ca. 7%. QVR-472XT. QTS 529..3499, neueste Version von HBS.
Stimmt, das Update brachte keine Verbesserung - nach 2 Tagen wieder “alles beim Alten” .. dieses sowohl auf TS-251+ als auch TS-264 und TS-464 jeweils mit aktuellem QTS.
Ziemlich frustrierend .. in den DebugLogs steht aus meiner Sicht auch nichts Weiterführendes was auf den Fehler hinweist
Tja, jetzt ist es wieder bei 17 %. Auf meinen 6 anderen NAS passiert das nicht.
Ich habe das gleiche Problem mit einem TS-873AeU und einem TS-264, beide laufen mit der neuesten Firmware und der aktuellen Version von HBS 3.
RTRR-Verbindungen brechen plötzlich ab, obwohl Port 8899 weiterhin erreichbar ist und keine Änderungen am Netzwerk oder an den Einstellungen vorgenommen wurden. In den meisten Fällen reicht es, die RTRR-Einstellungen erneut zu übernehmen bzw. das Passwort erneut einzugeben, um die Verbindung sofort wiederherzustellen. Gelegentlich muss ich jedoch auch das gesamte NAS neu starten.
Da beide NAS-Systeme betroffen sind, sieht es für mich sehr nach einem HBS 3 / RTRR-Dienstproblem aus und weniger nach einem Netzwerk- oder Firewallproblem.
Ich habe gestern ein Ticket eingereicht.
Ergebnis des Tickets:
Es sieht so aus, als hätte mein Team dies als einen Fehler in unserer Software gemeldet. Dieser wird in HBS3 26.4.2 behoben. Ich habe jedoch keinen Zeitplan für diese Veröffentlichung.
Bitte beobachte deine Apps auf Updates.
Melde dich gern, wenn du weitere Fragen hast.
Es ist eine neue Version verfügbar
-
HBS 3 Hybrid Backup Sync 26.4.2.617
15.07.2026
[Behobene Probleme]
- Ein Problem wurde behoben, bei dem SSH-basierte Rsync-Jobs mit dem Fehler “unknown option” auf bestimmten NAS-Firmware-Versionen fehlschlagen konnten.
- Ein Problem wurde behoben, bei dem der RTRR-Server (rr2 gateway) nach einem Port-Scan nicht mehr reagierte.
- Ein Problem wurde behoben, bei dem die Azure-Cloud-Backup-Sicherung beim Hochladen von Metadaten mit kleinen Multipart-Größen und großen Dateien fehlschlagen konnte.
- Die Fehlermeldung wurde verbessert, wenn ein Box-Sync-Job wegen eines abgelaufenen Change Streams nach längerer Netzwerkunterbrechung fehlschlägt.
- Ein Problem wurde behoben, bei dem Active Sync-Jobs den Zielordner nach Verschlüsselung/Entschlüsselung nicht finden konnten.
- Ein Problem wurde behoben, bei dem zu viele Active Sync-Jobs temporäre Mount-Dateien hinterließen, die Speicherplatz belegten.
- Ein Problem wurde behoben, bei dem ein SSH-Login-Banner dazu führte, dass Sync-Jobs fälschlich als fehlgeschlagen gemeldet wurden, obwohl die Übertragung erfolgreich war.
- Ein Problem wurde behoben, bei dem die Anzahl der aufbewahrten Versionen nicht den Einstellungen entsprach, wenn auf ein älteres HBS-Ziel gesichert wurde.
- Ein Problem wurde behoben, bei dem wachsende Dateien im OneDrive Personal Zwei-Wege-Sync mit Größen-Ausschluss-Filter nicht hochgeladen werden konnten.
- Ein Problem wurde behoben, bei dem Echtzeit-Sync-Jobs nach einem MR-Scan fehlschlagen konnten, wenn ein USB-Laufwerk “USBDisk” plus einer Nummer hieß.
[Release Notes HBS 3 Hybrid Backup Sync](Release Notes for Apps | QNAPproduct-line=nas)