Business Active Backup for "Business" (ABFB) Agent - Probleme nach Bare-Metal Restore

[Revlef]

Hallo,

ich bin René aus Kassel und könnte etwas Hilfe gebrauchen.

Ich sichere meinen WIN10-PC mit ABFB mit einem Synology DS923+ (DSM 7.1.1-42962 Update 4). Leider musste ich auf meinem WIN10-PC ein Bare-Metal Restore durchführen, weil mein SSD nicht mehr funktioniert hat.

In erster Linie hat die Wiederherstellung gut funktioniert, aber leider funktioniert mein ABFB-Agent nicht mehr.

Wenn ich den ABFB-Agent starte, bekomme ich den Fehler: „Sie dürfen diesen Dienst nicht verwenden. (Grund: Das aktuelle Gerät wurde vom Server entfernt).“

Wenn ich auf Verbindung bearbeiten gehe, um manuell mit meinem Konto anzumelden, bekomme ich die Warnung: „Das SSL-Zertifikat des Synology-NAS ist nicht vertrauenswürdig.“ Nach drücken des Buttons „Trotzdem fortfahren“ bekomme ich die Meldung: „Wollen Sie sich wirklich mittels (IP-Adresse) verbinden? Sie müssen dem Zertifikat später vertrauen. Der Agent wird vom Server getrennt, wenn das Zertifikat in Zukunft geändert oder aktualisiert wird.“ Nachdem ich auf OK drücke, macht der ABFB-Agent schon eine Verbindung, aber ich bekomme wieder oben genannte Meldung „Sie dürfen diesen …“.

Wenn ich mich von dem ABFB-Agent abmelde und wieder anmelde, bekomme ich wieder eine Verbindung mit meinem Synology DS923+, aber mit dem Durchführen des ABFB-Backups macht er das ganze Backup von vorne (4 TB).

Ich habe auch noch versucht ein anderes Zertifikat zu nutzen, welches der ABFB-Agent auch erkennt, aber ich bekomme noch immer keine Verbindung.

Vielleicht kann jemand von Euch mir schreiben, was ich hier noch machen kann, um mein altes Backup durchführen zu können.

In meinen Ereignissen bei Windows 10 kann ich keine Meldung bezüglich ABFB-Agent finden. Allerdings bei den Protokollen von ABFB-Agent konnte ich nachfolgende Ereignisse finden:

Log.txt ABFB-Agent:
Mrz 31 13:31:05 +0200 [ERROR] update-task-handler.cpp (97): get task failed (4106: 'Token not found')
Mrz 31 13:31:05 +0200 [INFO] server-requester.cpp (81): get response '{"@proto": {"date": 1680262264, "type": "header", "version": {"major": 1, "minor": 0}}, "alive": 150, "error": {"action": 0, "code": 4106, "params": null, "reason": "Token not found"}, "server": {"dsm": {"build": 42962, "fix": 4, "major": 7, "minor": 1, "unique": "DS923+"}, "package_version": {"build": "12631", "major": 2, "mini": 0, "minor": 5}, "protocol_version": {"build": "12631", "major": 1, "mini": 0, "minor": 0}}, "type": "response"}'
Mrz 31 13:31:05 +0200 [ERROR] get-running-task-result-handler.cpp (72): Failed to update running task result
Mrz 31 13:31:05 +0200 [INFO] server-requester.cpp (81): get response '{"@proto": {"date": 1680262264, "type": "header", "version": {"major": 1, "minor": 0}}, "alive": 150, "error": {"action": 0, "code": 4106, "params": null, "reason": "Token not found"}, "server": {"dsm": {"build": 42962, "fix": 4, "major": 7, "minor": 1, "unique": "DS923+"}, "package_version": {"build": "12631", "major": 2, "mini": 0, "minor": 5}, "protocol_version": {"build": "12631", "major": 1, "mini": 0, "minor": 0}}, "type": "response"}'

Ich hoffe, ich habe mein Problem verständlich erklärt. Es ist für mich als Niederländer nicht ganz einfach, mich auf Deutsch korrekt auszudrücken, obwohl ich schon über 10 Jahre in Deutschland lebe.

Viele Grüße

René

 

[plang.pl]

Willkommen im Forum!
Die Sicherheitswarnung beim Verbinden via IP ist normal.
Hat der Benutzer, mit dem du dich anmelden willst, Rechte für AB4B?

 

[Benie]

Also ich hatte das auch mal, und da haben die Rechte nicht gestimmt. Hatte da etwas verändert und nicht an ABB gedacht. Nachdem ich die Rechte korrigiert habe, ging wieder alles seinen Gang.

 

[Revlef]

Hallo plan.pl, hallo Benie,

danke für Eure Antwort und Willkommen!

Ich weiß das die Sicherheitswarnung über IP normal ist.

Die Backup-Benutzer mit dem ich mich anmelden will, hat Rechte für ABFB. (siehe Anhang).

Nach dem Bare-Metal Restore hat der ABFB-Agent immer diese Fehlermeldung (siehe Anhang).

Gruß René

 

[synfor]

Offensichtlich reicht das nicht. Schaue in der Systemsteuerung > Benutzer und Gruppen in den Einstellungen des Benutzers nach, welche Anwendungen er nutzen darf.

 

[Revlef]

Hi Synfor,

Anwendungsberechtigungen für den Einstellungen des Benutzer ABFB stehen alles auf Zulassen (Siehe Anhang).
Ich führe mit dieser Benutzer Konto ab Januar Sicherungen durch.

 

[synfor]

Falsche Baustelle. Der Active Backup for Business Agent ist nicht Active Backup for Business.

 

[Revlef]

Hi Synfor,

ich weiß, ich hatte den falschen Printscreen genommen, Entschuldigung. Die Anwendungsberechtigungen für die Einstellungen des Benutzers ABFB, -Agent, -Portal stehen alle auf „Zulassen“ (siehe Anhang). Das Problem muss woanders liegen. Von Januar bis Ende März hat es mit diesem Benutzerkonto reibungslos funktioniert und seit dem Bare-Metal Restore von meinem WIN10-PC bekomme ich mit ABFB-Agent keine Verbindung mehr mit meinem DS 923+.

 

[plang.pl]

Hi
Ich habe, wenn die Berechtigungen stimmen, leider keine andere Idee mehr.
Das, was ich noch beitragen kann:
Mach die Sicherung neu und sichere die bisherige Sicherung auf eine externe HDD oder woanders hin weg, wenn du sie aufbewahren willst (KB-Artikel)

 

[Benie]

Was Du machen kannst, wäre Dich mit diesem Problem mal an den Synology Support wenden und dort diesen Umstand mal schildern.

 

[nas-central.de]

Hallo Rene,

es ist in dem von dir beschriebenen Fall nicht möglich, die neue Verbindung des Agenten an das alte Backup zu knüpfen.

Das hängt damit zusammen, wie Snapshot basierte Backups geschrieben werden. Der Agent kennt den Zustand des Backups auf dem Server gar nicht, er weiß nur, was er als letztes übertragen hat. Bei einer Neuverbindung gibt es keinen letzten Übertragungsstand, deswegen muss er von vorne anfangen.

Was den Speicherbedarf angeht ist das aber nahezu egal, weil die Backups deduplizert gespeichert werden. Man muss halt nur einmal die Daten neu übertragen. Die alten Backups kannst du einfach auf dem NAS liegen lassen, bis du sie nicht mehr brauchst.

 

[Revlef]

Hallo zusammen,

erst einmal vielen Dank für Eure Mühe und Unterstützung!

Ich habe mein ABFB-Backup am 8. April neu gemacht.

Heute mache ich mein 2. ABFB-Backup von meinem WIN10-PC.

Schnappschuss-Satz für C:\, F:\H: \, D:\, E:\ erfolgreich erstellt. Hochladen von Geräteinformationen erfolgreich geladen. Volume-Inhalts von D:\, E:\ und C:\ werden gestartet als CBT (Change Block Tracking) und sind sehr schnell fertig. Aber meine größten Festplatten F:\ und H:\ werden normal gestartet und ABFB macht erneut die komplette 3.18 TB und nicht nur die Änderungen. Warum werden diesen Festplatten nicht mit CBT gestartet?

Bei meinen alten ABFB-Backups hat das für die größten Festplatten gut funktioniert, aber jetzt nicht mehr. Ich weiß nicht, was ich falsch mache.

Grüße

René

 

[Revlef]

Meine VSS-List-Writers weisen keine Fehler auf und ich habe genügend Speicherbereich für all meine Volumen. Die Dienst Volumenschattenkopie steht auf „automatisch“.

Das Einzige, was ich nicht verstehe, dass ich nur bei meinem lokalen Datenträger (C) (System) den Computerschutz aktivieren kann, aber nicht bei meinen anderen Festplatten (F:\ u d H:\ - da sind die Felder ausgegraut). Vor die Bare-Metal-restore war das nicht.

 

[Revlef]

Das Problem hatte nichts mit dem ABfB-Agenten zu tun. Nach dem Bare-Metall Restore auf die neue SSD war meine Systemwiederherstellung nicht mehr konfiguriert und bei Schutzeinstellungen standen zwei C:\ Laufwerke, wovon eine aktiv aber nicht vorhanden war, was natürlich meine alte SSD war. Ich habe die Bare-Metall Restore erneut ausgeführt, das alte C:\ Laufwerk (nicht vorhanden) bei den Schutzeinstellungen gelöscht und Systemwiederherstellung aktiviert. Jetzt hat der Agent den Backup erkannt und alle Schnappschüsse gesehen.