kein zeitgesteuerter Start, Angaben zum Speichermedium verschwinden

[rogschmi]

Hallo,

ich habe ein neues Problem mit Backup Service Home, es werden keine Backups mehr erstellt.

Ich verwende unter Windows 10 die Version BSH 3.9.1 und speichere via FTP auf einem Synology NAS. Die zeitliche Steuerung erfolgt über die Aufgabenplanung von Windows (Backups sollen auch ohne Login des Admin stattfinden), innerhalb von BSH ist "manuell" eingestellt. Der Aufruf erfolgt mit "C:\Program Files (x86)\Backup Service Home 3\BSH.Main.exe" und den Argumenten startbackup --autodelete --shutdownapp.

Wenn ich alles in BSH konfiguriere und manuell auslöse, wird das Backup korrekt erstellt. Allerdings verschwindet nach einem Logout aus dem Windows-Konto (Administratorkonto) die Einstellung zum Speichermedium. Alle Felder des Tabs sind leer und im oberen Drop-Down steht "Verzeichnis oder Laufwerk". Stelle ich dann auf Server, erscheinen die ursprünglich von mir eingegebenen Werte des NAS-Zugriffs wieder. Allerdings erfolgt auch wenn ich im Konto eingeloggt bin und die Werte eingetragen sind, kein Start über die Aufgabenplanung.

Im Protokoll von BSH findet sich kein Eintrag, nur der Hinweis auf den Start, gemeinsam mit Windows.

Im Protokoll der Aufgabenplanung findet sich: Die Anforderung wurde vom Operator oder Administrator zurückgewiesen. (0x800710E0)

Für Tipps wäre ich dankbar.

[rogschmi]

PS: Ich habe den Dienst in der Aufgabenplanung deaktiviert und es mit der internen Zeitsteuerung probiert. Auch hier verschwindet nach einem Logout aus dem Windows-Konto die Einstellung zum Speichermedium und es wird kein Backup-Lauf durchgeführt. Das Nichtspeichern der Einstellungen zum Speichermedium scheint mir die Ursache zu sein. Anderen Einstellungen, z.B. die zu sichernden Ordner, werden gespeichert und stehen auch nach einem Neustart /Wiederanmelden im Konto zur Verfügung.

[Alex]

Hallo rogschmi,

Wird denn BSH in der Aufgabenverwaltung mit dem gleichen Benutzer gestartet, mit dem auch BSH konfiguriert wird?

Hintergrund: BSH ist benutzerspezifisch und hat daher für verschiedene Benutzer auch unterschiedliche Konfigurationen. Falls es nicht möglich ist die Aufgabe mit dem gleichen Benutzer zu starten, lässt sich mittels ´ --databasefile´ die entsprechende Datenbankkonfiguration festlegen.

[rogschmi]

Hallo Alex,

danke für Deine Rückmeldung. Ja, der Benutzer ist der Gleiche.

Ich habe, wie oben geschrieben, die Aufgabenplanung aus dem Spiel genommen und es mit der internen Zeitsteuerung probiert. Das hat leider auch nicht funktioniert; die Einträge für das Speichermedium verschwinden/werden nicht gespeichert und es kommt zu einer Fehlermeldung:

2025-03-10 07:44:12.767 +01:00 [INF] Backup Service Home 3.9.1.0 started.
2025-03-10 07:44:14.155 +01:00 [INF] Service for "Scheduled backups" is started.
2025-03-10 07:44:14.289 +01:00 [INF] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2025-03-10 07:44:14.290 +01:00 [INF] Quartz Scheduler created
2025-03-10 07:44:14.290 +01:00 [INF] RAMJobStore initialized.
2025-03-10 07:44:14.290 +01:00 [INF] Quartz Scheduler 3.13.1.0 - 'QuartzScheduler' with instanceId 'NON_CLUSTERED' initialized
2025-03-10 07:44:14.291 +01:00 [INF] Using thread pool 'Quartz.Simpl.DefaultThreadPool', size: 1
2025-03-10 07:44:14.291 +01:00 [INF] Using job store 'Quartz.Simpl.RAMJobStore', supports persistence: False, clustered: False
2025-03-10 07:44:14.295 +01:00 [INF] Scheduler QuartzScheduler_$_NON_CLUSTERED started.
2025-03-10 09:35:39.588 +01:00 [INF] Service for "Scheduled backups" is stopped.
2025-03-10 09:35:39.591 +01:00 [INF] Scheduler QuartzScheduler_$_NON_CLUSTERED shutting down.
2025-03-10 09:35:39.592 +01:00 [INF] Scheduler QuartzScheduler_$_NON_CLUSTERED paused.
2025-03-10 09:35:39.595 +01:00 [INF] Scheduler QuartzScheduler_$_NON_CLUSTERED Shutdown complete.
2025-03-10 09:35:39.595 +01:00 [INF] Service for "Scheduled backups" is started.
2025-03-10 09:35:39.695 +01:00 [INF] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2025-03-10 09:35:39.695 +01:00 [INF] Quartz Scheduler created
2025-03-10 09:35:39.695 +01:00 [INF] RAMJobStore initialized.
2025-03-10 09:35:39.695 +01:00 [INF] Quartz Scheduler 3.13.1.0 - 'QuartzScheduler' with instanceId 'NON_CLUSTERED' initialized
2025-03-10 09:35:39.695 +01:00 [INF] Using thread pool 'Quartz.Simpl.DefaultThreadPool', size: 1
2025-03-10 09:35:39.695 +01:00 [INF] Using job store 'Quartz.Simpl.RAMJobStore', supports persistence: False, clustered: False
2025-03-10 09:35:39.696 +01:00 [INF] Scheduler QuartzScheduler_$_NON_CLUSTERED started.

Lässt sich damit etwas anfangen?

Wo wird --databasefile eingetragen? In der Aufgabenplanung oder direkt als manueller Start in der Konsole?

Würde es Sinn machen, die Einstellungen von BSH zu löschen und komplett neu einzutragen?

[Alex]

Das klingt in der Tat nicht richtig.

Ich habe eine Vermutung (nicht getestet), aber vielleicht hilft es die ältere Version zu testen: https://download.brightbits.de/backupse ... -win64.exe

Falls es noch möglich ist, am besten nochmal damit von vorne beginnen (Einstellungen zurücksetzen).

[rogschmi]

Ich habe die Ver. 3.9.1 zurückgesetzt und gelöscht, PC neu gestartet. Auf dem FTPServer habe ich den Backup-Ordner umbenannt. Die Vers. 3.9.0.3 habe ich installiert. Leider startet sie nicht, weil ....

Datenbankversion ist neuer als die installierte Backup Service Home Version. Installieren Sie eine neuere Version von Backup Service Home.
at Brightbits.BSH.Engine.Database.DbMigrationService.InitializeAsync()
at Brightbits.BSH.Main.BackupLogic.LoadDatabaseAsync()

Irgendwo scheint noch ein Hinweis auf die bisherige Konfiguration versteckt zu sein.

[Alex]

Ah ja und zwar unter: C:\Benutzer\<Benutzername>\AppData\Roaming\Alexosoft\Backup Service Home 3

Dort findet sich die Datenbankdatei für BSH die die gesamte Konfiguration beinhaltet. Einfach eine Sicherung davon machen oder umbenennen, dann ist BSH im Auslieferungszustand.

[rogschmi]

Hallo Alex,

danke, mit diesem Hinweis konnte ich die ältere Version neu installieren und konfigurieren. Ein erster manueller Lauf in einen leeren Sicherungsordner führte dann jedoch bei (fast) allen zu sichernden Dateien zu folgender Fehlermeldung:

Exception of type 'Brightbits.BSH.Engine.Exceptions.FileNotProcessedException' was thrown.

Diesen Fehler hatte ich in der jüngeren Vergangenheit bei einzelnen Dateien (alle aus einem Ordner) schon einmal. Der Fehler verschwand dann, nachdem ich auf die aktuelle Version von BSH aktualisiert hatte. Das jetzige Auftreten der Fehlermeldung tritt jedoch bei allen Ordnern auf. Ich sichere ca. 12550 Dateien, die Fehlermeldung wurde ca. 12350 mal ausgeworfen. Welche Dateien nicht betroffen sind, konnte ich noch nicht feststellen. Vielleicht ist der Lauf auch einfach an dieser Stelle abgebrochen.

[Alex]

Irgendwie scheint bei dir der Wurm drin zu sein. Schau doch mal in das Protokoll (über Konfigurationsfenster --> Extras & Hilfe --> Protokoll anzeigen). Dort sollten sich detaillierte Informationen finden.

[rogschmi]

Ja, da scheint Einiges durcheinander gekommen zu sein.

Die Fehlermeldung im Protokoll lautet lapidar: "File XXX could not be backuped." Und das bei ca. 11200 Dateien. 1300 Dateien scheinen verarbeitet worden zu sein.

Ich denke, ich beende das hier und wechsele erstmal auf ein anderes Verfahren. Im Sommer setze ich wegen Wechsel auf Win11 einen neuen PC auf; dann probiere ich es nochmal. Zwischenzeitlich kann ich noch ein wenig experimentieren; vielleicht finde ich noch etwas heraus.

Vielen Dank für Deine Mühe und Deine Geduld!

[rogschmi]

PS: Ich habe mit der Ver. 3.9.0.3 ein Backup auf der lokalen Platte erstellen können. Das ist fehlerfrei durchgelaufen. Die vorher aufgetretenen Fehler scheinen alle mit mit dem FTP in Verbindung zu stehen. Ich habe es mit einem neuen Ordner ("Freigegebener Ordner")probiert, das hat aber die selben Fehler ausgeworfen.

Es gab ungefähr zum Zeitpunkt des Ausfalls von BSH sowohl ein Update für das NAS, als auch eine von mir initiierte Umstellung auf eine neue IP des NAS. Vielleicht hängt es mit einem dieser Punkte zusammen.

[Alex]

Es gab ungefähr zum Zeitpunkt des Ausfalls von BSH sowohl ein Update für das NAS, als auch eine von mir initiierte Umstellung auf eine neue IP des NAS.

Verrätst du mir welches NAS du hast? Es gab leider in der Vergangenheit damit ein paar Probleme in Verbindung mit FTP. Vielleicht kann es einfach auf BSH Seite gelöst werden.

[rogschmi]

Das NAS ist ein Synology DS215j.

Ich habe die Vers. 3.9.0.3 jetzt via SMB mit dem NAS verbunden; das funktioniert über die interne Zeitsteuerung einwandfrei. Da bin ich schon einmal wieder beruhigt.

In den nächsten Testschritten werde ich die Zeitsteuerung wieder auf die Aufgabenplanung übertragen und außerdem grundsätzlich den FTP-Transfer auf das NAS überprüfen.

Die Update-Suche der Vers. 3.9.0.3 scheint nicht zu funktionieren; die neuere Vers. 3.9.1 wird nicht gefunden.

[xdcc_master]

Das Problem besteht auch hier, hier ist der FTP allerdings auf einem openmediavault.

[rogschmi]

@xdcc_master
Willkommen im Club, xdcc_master, vielleicht sind wir da doch einem Fehler auf der Spur.

@Alex

Hallo Alex,

der manuelle Transfer via FTP, z.B. mit Filzilla, funktioniert einwandfrei. Am NAS scheint es nicht zu liegen.

Die Aufgabenplanung mit der Verbindung über SMB funktioniert nicht. Ich habe die Aufgabe neu angelegt und sie wird mit der Fehlermeldung "Die Anforderung wurde vom Operator oder Administrator zurückgewiesen (0x800710E0)" zur Laufzeit abgewiesen. Wir hatten das Thema schon einmal unter der Überschrift: "BSH startet nicht mehr über Aufgabenplanung" im April 2023. Damals lag es am falsch dokumentierten Parameter --autodelete, aber das kann dieses Mal nicht die Ursache sein. Aber das ist ein anderes Thema, das möchte ich jetzt nicht mit dem FTP-Thema vermischen.