HBS3 - Verbindungsfehler zu Remote Servern?!

    Moin zusammen,


    lange ging es bei mir (relativ) gut mit HBS3, nun aber zickt es und ich verstehe nicht warum...


    Quellsystem: TVS473 (QTS 4.5.3, HBS 19.1.0517 und 19.0.303)
    Zielsystem 1 (LAN): TS251+ (QTS 4.5.3, HBS 19.1.0517 und 19.0.303); RTTR, 4 Backup-Jobs mit QuDedup, 1 Backup-Job ohne Dedup
    Zielsystem 2 (VPN): TS253pro (QTS 5.0.1b, HBS 19.1.0517); RTRR, 4 Sync-Jobs


    Gestern um 1500 liefen alle Jobs einwandfrei an das Zielsystem 2, heute Nacht um 0300 sind alle 4 Jobs mit Dedup an das Zielsystem 1 abgebrochen, lediglich der Job ohne Dedup lief ordentlich durch.

    Fehlermeldung laut Log:

    Code
    [Hybrid Backup Sync] Failed to complete Backup job: "Media". Failed to connect to cloud storage service after multiple attempts. Check network settings.

    Das gleiche Verhalten kann ich nun jederzeit manuell replizieren, auch nach Neustart aller Systeme und unterschiedlichen HBS Versionen auf Quelle und Ziel.


    Bei den Remote Spaces werden mir beide Zielsysteme (auch das, zu dem alles funktioniert) mit einem Fehler angezeigt:

    pasted-from-clipboard.png


    Bearbeite ich die Zielsyteme, bekomme ich zunächst eine funktionierende Verbindung ausgewiesen, beim Speichern allerdings Gegenteiliges:

    pasted-from-clipboard.png


    Das Neuanlegen der Systeme bringt das selbe Ergebnis.


    Bearbeite ich die Jobs selbst um an den Netzwerkeinstellungen etwas zu ändern, bekomme ich egal was ich einstelle dieses Ergebnis:

    pasted-from-clipboard.png
    Allerdings nur für die Jobs, die nicht funktionieren, bei dem funktionierenden Job (bei Sync-Jobs gibt es die Einstellung nicht) bekomme ich den Fehler nicht, allerdings wird auch hier bei der manuellen Auswahl "not available" bei allen Interfaces ausgewiesen.


    Neue Jobs kann ich zu beiden Zielsystemen nicht erstellen, das gibt jedes Mal einen System error.


    Mir fällt nun nichts mehr ein, was ich noch prüfen kann... habt ihr noch Ideen und könnt ihr mal bitte schauen, ob die Zielsysteme (RTRR) bei euch korrekt als verfügbar angezeigt werden?

    Ticket werde ich gleich wohl schonmal erstellen...

    Hab mal auf zwei Systemen den externen Speicherplatz getetstt. DIe waren erreichbar udn auch das neu anlegen funktioniert. Scheitnalso der Fehler bei den NAS zu sein.
    Frage: Hattest du beide Systeme mal komplett neugestartet? Ping auf die IP des externen NAS/Speicherplatz geht? Login funktioniert? Wurdne ggf. Ports geändert im Router etc.?

    Zitat von hhaneder

    Hattest du beide Systeme mal komplett neugestartet?

    Jap. Alle wurden mal neugestartet, bzw. werden die Zielsysteme ohnehin immer erst kurz vor dem Job eingeschaltet.

    Zitat von hhaneder

    Ping auf die IP des externen NAS/Speicherplatz geht? Login funktioniert?

    Geht alles wunderbar. HBS weist beim Speicherplatz zunächst ja auch aus, dass die Verbindung funktioniert und wie schnell diese ist... erst beim Speichern fangen die Probleme an.

    Zitat von hhaneder

    Wurdne ggf. Ports geändert im Router etc.?

    Nein... also nicht wirklich. Einzige Änderung, die aber schon einige Backups überstanden hat:

    Vor knapp einer Woche habe ich die IP meines virt. Switches angepasst... Da aber sämtliche Konnektivität gegeben ist und ich ja auch noch ein weiteres Interface habe, über das HBS normalerweise arbeitet, glaube ich nicht, dass es damit zusammenhängt.

    Vorweg: RRTR nutze ich nicht, sondern Rsync, kann daher keine konkrete Hilfe geben.


    Wenn das Backup über Rsync auf das ferne NAS fehlschlug, war immer ein Netzwerkproblem oder ein Problem auf dem fernen Server die Ursache.


    Bei Netzwerkproblem kann das eine komplette Unterbrechung eines der beiden Anschlüsse sein, aber auch eine vorangegangene Störung mit dem Effekt, dass das ferne NAS eine neue IP-Adresse hat, der Dyndns-Eintrag aber noch auf die alte zeigt. Ich hatte auch schon den Fall, dass der Dyndns-Anbieter vergessen hatte, sein Zertifikat zu erneuern, so dass die automatischen Updates der IP-Adresse fehlschlugen.


    Bei einer Ursache auf dem fernen Gerät: Gibt es da irgendwelche Meldungen in den Qnap-Logs oder in System-Logs?

    Eine vollgelaufene Festplatte, System- (womit dann womöglich auch keine Logs mehr geschrieben werden könnten) oder Datenpartition.

    Rechteprobleme im Dateisystem. Korrupte Containerdateien für die Dedup-Jobs (z. B. nach Stromausfall).

    Ein abgestürzter Rsync- oder RRTR-Server.

    Generelle Netzwerkprobleme kann ich ausschließen, alle Geräte sind einwandfrei erreichbar und vom Quellsystem pingbar...

    Das Zielsystem bei dem die Jobs fehlschlagen ist direkt über das LAN erreichbar, da ist nix weiter dazwischen...


    Zitat von Anthracite

    Gibt es da irgendwelche Meldungen in den Qnap-Logs oder in System-Logs?

    Nope... kurz nach dem manuellen Einschalten heute morgen gab es für wenige Sekunden die Meldung dass Adp. 1 keine Verbindung hat, wurde aber direkt klar gemeldet. Gestern als die Jobs fehlgeschlagen sind ist nichts dergleichen passiert. Das Zielsystem bekommt nichtmal mit, dass ein Job gestartet wurde.

    Zitat von Anthracite

    Eine vollgelaufene Festplatte, System- (womit dann womöglich auch keine Logs mehr geschrieben werden könnten) oder Datenpartition.

    Beide Speicherpools sowie alle Volumes haben ausreichend freie Kapa, hier ist also auch nichts zu befürchten.

    Zitat von Anthracite

    Rechteprobleme im Dateisystem. Korrupte Containerdateien für die Dedup-Jobs (z. B. nach Stromausfall).

    Keine Ahnung wie ich das prüfe... Stromausfall gab es nicht und alle NAS sind USV versorgt.

    Die Containerdaten hatte ich zunächst auch verdächtigt, allerdings fangen die Probleme ja schon bei den Speicherplätzen an... selbst bei dem, der einwandfrei funktioniert... Daher glaube ich nicht an Probleme mit den Containern, zumal die Verbindung zum Ziel ja gar nicht erst aufgebaut wird...

    Zitat von Anthracite

    Ein abgestürzter Rsync- oder RRTR-Server.

    RTRR habe ich schon neugestartet, aber auch hier: Bei funktionierenden RTRR wird mir ja ebenfalls angezeigt, dass dieser nicht erreichbar sein.


    Zu verwirrend alles :D


    Mittlerweile gehe ich aber sehr stark davon aus, dass mein HBS auf dem Quellsystem defekt ist:

    Wollte hier gerade den RTRR aktivieren um zu schauen ob andersrum die Verbindung klappt...

    pasted-from-clipboard.png


    Da geht also gar nichts mit rechten Dingen zu.

    Ticket habe ich mir bislang gespart, da passiert eh nichts solange ich mit 4.5.3 unterwegs bin. :cursing:


    Ich probiere nochmal ein bissl rum, wenn nix klappt, dann schlafe ich noch ein paar Nächte drüber... bleibt trotzdem die Frage, wie sowas auf einmal passieren kann.

    Mit HBS3 (aktuelle Version) hatte ich letzte Woche zwei Tage am Stück ebenfalls Probleme.

    Um12:15 Uhr wird das tägliche Backup angestoßen. Angeblich konnte die Netzwerkverbindung nicht aufgebaut werden.

    Ohne Änderungen vorzunehmen war am dritten Tag alles wieder gut. :|

    Zitat von H3llF15H

    Ohne Änderungen vorzunehmen war am dritten Tag alles wieder gut.

    Na Du machst mir Hoffnung :)

    Habe die Jobs erstmal deaktiviert (das hat trotz Fehlermeldung geklappt). Dann schaue ich am WE nochmal wie es aussieht.

    Welches QTS läuft auf dem Quellsystem?


    Habe mittlerweile auch mal Systemvolume sowie den HBS Installationspfad (anderes Volume) per Snapshot zurückgesetzt... keine Änderung.

    ich meine mich zu Erinnern das ich ähnliche Probleme hatte( VPN Verbindung zum 2. Standort, lokal jedoch nicht getestet).

    Dies war auf untgerschiedliche HBS Versionen zurück zuführen. Das ZFS System wurde erst später mit der aktuellen HBS Version beglückt :)

    Unterschiedliche HBS Versionen kann ich ja ausschließen... und dass ein Update auf QTS 5 etwas bewirkt dann wohl auch :(


    Ich warte jetzt ein paar Tage und schaue ob es von Geisterhand wieder funktioniert, ansonsten wird HBS neu installiert und eingerichtet.

    Zitat von tiermutter

    ansonsten wird HBS neu installiert und eingerichtet

    Das nervigste überhaupt, an HBS3. Eine Konfig-Datei, die man später einfach wieder kopiert, wäre genial :)

    Ja wäre wirklich chic... Dank Dedup kann ich immerhin die Backup Jobs neu verlinken, das geht fix. Trotzdem nervig, aber vielleicht nehme ich mir ja die Zeit mal zu schauen wo die Jobs gespeichert sind... Wobei das dann kein sauberer Neuanfang mehr wäre... :/

    Zitat von tiermutter

    Beide Speicherpools sowie alle Volumes haben ausreichend freie Kapa, hier ist also auch nichts zu befürchten.

    Ich meine nicht nur die angelegten Pools, sondern auch die Systempartitionen.


    Wenn du in der Shell

    Code
    df -h

    eingibst, hast du dann eine Partition, die bei Use auf 100% steht? (Am besten auf Quell- und Zielsystem ausführen, geht schnell.)

    Hehe, wie dumm von mir :D

    Hier ist alles in Ordnung, zumindest am Quellsystem... Die Zielsysteme sind beide nicht online, schaue ich später nochmal...

    Zitat von H3llF15H

    Ohne Änderungen vorzunehmen war am dritten Tag alles wieder gut. :|

    Es hat zwar länger als drei Tage gedauert, aber so war es hier dann auch...

    Eines Tages wurde der Speicherplatz vom 253pro (dessen Jobs ja alle liefen) wieder korrekt erkannt, woraufhin ich die anderen Jobs wieder aktivierte und das 251+ eingeschaltet habe um zu sehen ob dies auch erkannt wird. Dem war so und die anschließenden Jobs liefen wieder alle durch.


    HBS ist und bleibt ein Mysterium...


    Edit: es kam mir zwar länger vor, tatsächlich waren es hier aber auch drei Tage... Das macht es alles irgendwie noch gruseliger =O

    Ich glaub ja langsam dieses Zugrundeliegende RTRR Zeugs zickt da gerne mal. Einer meiner SyncJobs via VPN hat bei mir regelmäßig dazu geführt, dass der QNAP der RAM restlos überging. Jedes Mal wars der RTRR-Prozess des besagten Jobs der sich einfach mal > 40GB RAM allokierte (von installierten 32GB) und QTS restlos zum erliegen brachte bis man den Prozess mit kill -9 abgestochen hat. QNAP Support meinte auch. HBS3 neu installieren:X :qnap:

    Zitat von tiermutter

    Es hat zwar länger als drei Tage gedauert, aber so war es hier dann auch...

    Mein Backup hat´s heute auch wieder erwischt :D

    Mit QTS 4 hatte ich auch immer wieder Probleme mit dem HBS3 Backup, seit QTS 5 ist das aber nicht mehr aufgetreten.

    Man mag ja darüber denken was man will, aber erst mit dieser Version wurde der alte Sicherungs Manager wirklich vollständig durch HBS3 ersetzt.


    Ich habe daher die Vermutung, dass dieser immer wieder mal mit dem HBS3 in Konflikt geraten ist.

    Was ich mit QTS 4 erlebt haben. Port war von einem Dienst belegt, man musste diesen für RTRR ändern sonst funktionierte der Server nicht.

    Jobs liefen Wochen/Monate und dann waren die defekt, hier musste dann ein Klon erstellt werden, erst dieser lief wieder.

    Laufende Jobs wurden beim Empfänger nur selten angezeigt.

    Wurde ein Job angehalten war er noch über Tage ja sogar über einen Neustart auf dem Ziel zu sehen, wenn mal einer angezeigt wurde.


    Aus dieser Sicht man daher der Umstieg auf QTS 5 Sinn, aber es ist deine Entscheidung, denn immerhin gibt es das jetzt seit über 6 Monaten.