Hyper Backup Ziel angeblich nicht erreichbar, Vault protokolliert aber Loginversuche ("authorization failure")

[Cyberbrat]

Hallo zusammen,

ich habe ein ziemlich merkwürdiges Problem mit Hyper Backup und komme inzwischen nicht mehr weiter.

Setup

Quell-NAS

• Synology DS920+
• DSM aktuell
• Hyper Backup aktuell

Ziel-NAS

• Synology DS216j (Offsite-Backup)
• DSM aktuell
• Hyper Backup Vault aktuell

Verbindung

• Synology DDNS
• DSM extern über einen alternativen Port erreichbar
• Hyper Backup über Port 6281

Die Konfiguration lief über Jahre problemlos.

Zeitlicher Ablauf

Die letzte erfolgreiche Sicherung lief heute morgen.

Am Abend wollte ich aus einem lokalen USB-Hyper-Backup eine ältere Version von DS Note wiederherstellen.

Dabei habe ich versehentlich nicht DS Note, sondern das Paket Hyper Backup wiederhergestellt.

Im Hyper-Backup-Protokoll finden sich dazu folgende Einträge:

• Restore started to restore package [Hyper Backup]
• Package [Hyper Backup] is restored successfully

Unmittelbar danach begannen die Probleme mit dem Remote-Backup.

Symptome

Die bestehende Remote-NAS-Sicherungsaufgabe wird seitdem angezeigt als:

• Authentifizierung fehlgeschlagen
• Ziel: Offline

Beim Versuch der Neuverbindung erscheint:

Verbindung zum Datensicherungsziel konnte nicht hergestellt werden.

Besonders verwirrendes Verhalten

Nicht nur die bestehende Aufgabe ist betroffen.
Wenn ich versuche, eine komplett neue Hyper-Backup-Aufgabe anzulegen und die Ziel-NAS als Remote-NAS auswähle, schlägt die Verbindung bereits beim Verbindungsaufbau fehl.
Es erscheint sofort:
Verbindung zum Datensicherungsziel konnte nicht hergestellt werden.
Ich komme dabei gar nicht erst bis zur Eingabe von Benutzername und Passwort.
Der Assistent behandelt das Zielsystem bereits vorher als nicht erreichbar.
Gleichzeitig protokolliert die Ziel-NAS im Hyper Backup Vault jedoch bei jedem Verbindungsversuch:
User [Admin] failed to log in via [Hyper Backup Vault] due to authorization failure.
Das erscheint widersprüchlich:

• Die DS920+ behauptet, das Ziel sei nicht erreichbar.
• Die DS216j empfängt die Anfrage nachweislich.
• Hyper Backup Vault verarbeitet die Anfrage.
• Hyper Backup Vault kennt sogar den Benutzernamen.
• Trotzdem wird die Anmeldung mit "authorization failure" abgelehnt.

Genau dieser Widerspruch macht die Fehlersuche schwierig.



Was funktioniert weiterhin?

• DSM der DS216j ist von außen problemlos erreichbar. (Gleiche Adresse wie in Hyperbackup angegeben), Anmeldung am DSM mit dem Backup-Benutzer funktioniert.
• Hyper Backup Vault startet normal.
• Das Repository wird im Vault korrekt angezeigt.
• Die Sicherungsstatistiken können angezeigt werden.
• Die letzte erfolgreiche Sicherung wird korrekt angezeigt.
• Das Repository enthält weiterhin alle Daten.

Netzwerkprüfung
PowerShell-Test von einem externen Windows-PC:
Test-NetConnection <DDNS-Name> -Port 6281
Ergebnis:
TcpTestSucceeded : True
Port 6281 ist also von außen erreichbar.

Hyper Backup Vault
Im Vault werden angezeigt:

• Repository vorhanden
• Sicherungsgröße ca. 2,3 TB
• Sicherungshistorie vorhanden
• Statistiken verfügbar

Das Repository wirkt auf den ersten Blick nicht beschädigt.

Bereits erfolglos getestet

Auf der DS920+

• Neustart
• Hyper Backup neu installiert
• Hyper Backup erneut aus einem funktionierenden Backup wiederhergestellt

Auf der DS216j

• Neustart
• Hyper Backup Vault gestoppt und neu gestartet
• Hyper Backup Vault deinstalliert und neu installiert

Benutzer / Rechte

• Passwort des Backup-Benutzers geändert
• Benutzer kann sich weiterhin am DSM anmelden
• Benutzer Mitglied der Gruppe administrators
• Benutzer besitzt Vollzugriff auf den Repository-Ordner
• Hyper Backup Vault ist für den Benutzer erlaubt
• Passwort läuft nicht ab

Netzwerk

• Firewall auf der DS216j deaktiviert
• Firewall auf der DS920+ geprüft
• Port 6281 erreichbar
• DDNS funktioniert
• DSM extern erreichbar

Keine dieser Maßnahmen hat das Verhalten verändert.

Offene Frage

Hat jemand schon einmal erlebt, dass Hyper Backup Vault Loginversuche mit authorization failure
protokolliert, obwohl:

• der Benutzer gültig ist,
• DSM-Login funktioniert,
• Repository vorhanden ist,
• Hyper Backup Vault läuft,
• Port 6281 erreichbar ist,

und gleichzeitig Hyper Backup auf der Quell-NAS behauptet, das Zielsystem sei nicht erreichbar?

Kann die versehentliche Wiederherstellung des Pakets Hyper Backup interne IDs, Vertrauensbeziehungen oder Metadaten zwischen Quelle und Ziel beschädigt haben?

Für jeden Hinweis wäre ich sehr dankbar.

 

[DaveR]

I had a problem, maybe not the same problem as you, when the Hyper Backup Vault on the target NAS was not compatible with Hyper Backup on the source NAS.

I also had problems when I had "Transfer encryption" set to Off.

And I often find that "Certificate authentication" shows Failed and I have to click the Trust button again.

 

[Ronny1978]

@Cyberbrat Mal blöd gefragt: Hast du schon einmal einen anderen Browser für die neue Einrichtung probiert oder mal den Browser Cache gelöscht? Nur um hier Fehler auszuschließen?

 

[Rotbart]

Ich würde mal die Rechte im Backup Verzeichnis prüfen, vielleicht ist da etwas verrutscht.

 

[Cyberbrat]

@Cyberbrat Mal blöd gefragt: Hast du schon einmal einen anderen Browser für die neue Einrichtung probiert oder mal den Browser Cache gelöscht? Nur um hier Fehler auszuschließen?

Ja, das habe ich auch versucht, aber auch hier (mit erlaubten Popups komme ich nicht bis zur Eingabe meiner Credentials, Hyperbackup meldet sofort dass das das Ziel nicht erreichbar ist.

 

[Cyberbrat]

Ich würde mal die Rechte im Backup Verzeichnis prüfen, vielleicht ist da etwas verrutscht.

Sowohl der zugriff auf das Backup Verzeichnis (shared Folder), die Backup Datei sowie HyperBackup Vault sind für den Benutzer freigegeben (read&write).

Das irre ist ja dass ich noch nicht mal zur Eingabe von Credentials komme wenn ich testweise eine neue Sicherungsaufgabe zu meinem Ziel erstelle (komplett neue Sicherung, nicht mit der Aufgabe neu verbinden)

Ich habe getestet ob ich eine Verbindung zu einem anderem NAS bekomme hab einfach mein eigenes NAS als externe Quelle eingerichtet) das funktioniert, ich komme zur Loginseite.

Es muss also irgendetwas den Zugriff auf das alte Ziel verhindern.

 

[Cyberbrat]

Was auffällig ist: Ich habe versucht den "kaputten" Sicherungsjob zu löschen, danach hat sich der Status auf "Abgestürzt" geändert.
Ich habe daraufhin HyperBackup komplett deinstalliert inkl. Jobs und reinstalliert, das hat wohl geklappt. zumindest ist der Job nicht mehr sichtbar. Aber mein Ziel bekomme ich trotzdem nicht angesprochen wenn ich einen neuen Sicherungsjob anlegen will.

 

[Ronny1978]

Blocklisten sind bei dir aktiv? Konten im NAS sind alle "frei"? Blocklisten sind "sauber"? Kannst du das mal prüfen?

 

[Cyberbrat]

Eigentlich eine gute Idee, danke für den Hinweis, Aber ich komme ja nach wie vor ins DSM des Ziels mit dem gleichen Benutzer. Der Benutzer ist nicht deaktiviert oder gesperrt, in der Blockierliste ist kein Eintrag.

 

[Ronny1978]

Hast du die Verifizierung mal mit der IP statt dem DynDNS Namen probiert? Ich hatte/habe bei meinem Offside Backup per Tailscale das Problem, dass er den DynDNS Namen nicht "frisst", obwohl ich mit diesem mich auf die beiden NAS anmelden kann. Die Tailscale IP geht aber ohne Probleme.

P.S. Wird der Backup Benutzer bei den Verbindungen noch angezeigt? Dann die vielleicht mal "killen".

 

[Cyberbrat]

Ja, hab ich beides ausprobiert, hat leider keinen Erfolg gebracht. Aber danke für die Hinweise

 

[Ronny1978]

Also mehr fällt mir nicht mehr ein. Da musst du ggf. ein Ticket bei Synology aufmachen.

 

[Cyberbrat]

Also mehr fällt mir nicht mehr ein. Da musst du ggf. ein Ticket bei Synology aufmachen.

Schade, ich hab die ganze Zeit das Gefühl ich übersehe was ganz Wichtiges. Irgendwo hab ich gelesen, dass Hyperbackup für den initialen Handshake auch port 5000 bzw 5001 offen haben muss. Den hab ich beim Ziel aber umgeleitet, der ist unter einem anderen Port erreichbar und die Fritzbox dort leitet den dann intern auf 5001 um.... Das weiß aber Hyperbackup ja nicht.... Ist meine letzte Chance bevor ich das Ziel komplett neu aufsetze..... Ich denke ich muss morgen mal eine Reise zum Offsite Ziel machen....
Aber danke fürs mitgrübeln, zwei Hirne denken mehr als eins

Ticket hab ich mittlerweile erstellt.

 

[Ronny1978]

Den hab ich beim Ziel aber umgeleitet, der ist unter einem anderen Port erreichbar und die Fritzbox dort leitet den dann intern auf 5001 um

Nimm doch erst einmal die 5001. Hast du die DSM Ports umgestellt? Also von 5001 zu irgendwas anderes? Hier hatte ich nämlich auch mal einen Fehler. Da ich Tailscale nutze und die NAS von außen nicht erreichbar sind, habe ich wieder auf 5001 zurückgestellt.