Hyper Backup Zeitgesteuertes Backup schlägt fehl.

[Keen]

Hallo,
ich habe 2 Synologys, eine 720+ und eine 218J, auf der 218 ist nur das Backup der 720+. Die 720+ läuft die ganze Zeit durch. Die 218J fährt jeden Dienstag Früh hoch und fertigt mit Hyper Backup ein Backup an, gegen Mittag fährt sie wieder runter. Das hat auch lange so geklappt, nur vor meinem letzten Urlaub hatte ich die 218J ganz vom Netz gezogen. Seit dem funktioniert das automatische Backup nicht mehr. Manuell kann ich es anstoßen.
Hier die Fehlermeldung in der 720+

Failed to start backup task. (The backup service is not available. Please check protocol is enabled at the destination)
Failed to run backup task.

In der 218J finde ich keine Fehlermeldung, womöglich fährt sie gar nicht hoch? Der Energie Zeitplan ist aber nach wie vor aktiviert, die Uhrzeiten stimmen auch.

 

[plang.pl]

Ob die DS tatsächlich hochfährt, müsstest du halt mal testen.
Ansonsten mal via ssh das Protokoll von Hyper Backup (Vault) auslesen
/var/log/synolog/synobackup.log und auf der Backup DS /var/log/synolog/synobackup_server.log

 

[Keen]

Das mit ssh auslesen hat leider nicht geklappt, vielleicht weil ich eine 2FA nutze?

Ich habe gerade einen neuen Zeitplan erstellt um zu testen um dieser funktioniert. Auf dem Dashboard kann man die nächsten Aufgaben anzeigen lassen. Bei meinen alten Zeitplan steht Powertask 0 , beim neuen Powertask 1, das deutet darauf hin das der alte Zeitplan deaktiviert ist. Wie kann das sein wenn er in der Systemsteuerung doch aktiviert ist?

 

[plang.pl]

Schick doch mal nen Screenshot. Der Name hat aber eigentlich nix zu sagen. Zum Thema ssh: https://kb.synology.com/de-de/DSM/tutorial/How_to_login_to_DSM_with_root_permission_via_SSH_Telnet

 

[Tommes]

Zum Betrachten der Log-Files über die GUI könnte ich LogAnalysis empfehlen. Link findest du in … *räusper* … meiner Signatur

 

[plang.pl]

Natürlich - Schande über mich, dass ich da nicht dran gedacht habe, obwohl ich es selbst verwende

 

[Tommes]

Ganz genau. Schäm dich. Mögen dir die Ärmel beim Händewaschen runter rutschen. Wobei ich grade feststelle, das ich den Ordner /var/log/synology garnicht habe, obwohl ich auch Hyper Backup benutze. Komisch.

 

[plang.pl]

Ich schon - unter DSM 7.2 mit neuester HB Version. Der heißt aber "synolog" und nicht "synology"

 

[Tommes]

Der heißt aber "synolog" und nicht "synology"

Ähm... stimmt. Ich Seppel. Schande also auch über mich, das ich dieses Detail übersehen habe. Daher wieder Back to Topic.

 

[Keen]

Im Ordner synolog ist gar nix drinnen.

 

[Keen]

per ssh hat es jetzt doch geklappt, es hatte der befehl sudo gefehlt.

root rechte scheinen hier aber nicht zu reichen.

Powertask 0 hat anscheinend doch nix zu sagen, die Tasks sind nur durchnummeriert.

 

[Keen]

Ein neuer Zeitplan funktioniert auch nicht, ich vermute jetzt das die Lithium Batterie im Inneren der Schuldige ist. Sie hat nur noch 0,25 Volt.

Ich habe den Admin als Benutzer deaktiviert, kann es sein das ich deswegen kein Zugriff auf den Log bekommen habe?

 

[plang.pl]

Du versuchst auch, die Datei auszuführen. Du musst nano voranstellen und dann den Dateipfad
Aber bei dir liegt es dann wohl an der Batterie.
Nein, an dem Admin User liegt das nicht.

 

[Tommes]

Du musst nano voranstellen...

... wobei dieses Programm meines Wissens standardmäßig nicht im DSM verfügbar ist. Die Programme cat, more oder less dagegen schon.

 

[plang.pl]

Oh man das vergesse ich immer wieder, da ich es bei mir mittels Community Package nachinstalliert habe

 

[Tommes]

Alles gut. Passiert den Besten

 

[Keen]

So, ich habe eine neue Batterie eingelegt, dies konnte mein Problem aber nicht lösen! Die Synology fährt einfach nicht hoch.
Ich habe jetzt mit SSH den Log auslesen können. Es sind aber keine Fehlermeldungen aufgelistet, nur der Standard Kram der immer gespeichert wird.

Das sind die Einträge als die automatschen Backups noch funktioniert haben.

info 2023/07/11 07:16:04 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup started. info 2023/07/11 07:20:51 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup complete. info 2023/07/11 07:21:11 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotation started. info 2023/07/11 07:22:10 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Version [2021-08-24 07:15:07] rotated. info 2023/07/11 07:22:10 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotated. info 2023/07/11 08:45:13 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup integrity check has started. info 2023/07/11 09:46:42 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup integrity check is finished. No error was found. info 2023/07/18 07:15:47 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup started. info 2023/07/18 07:20:33 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup complete. info 2023/07/18 07:20:54 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotation started. info 2023/07/18 07:24:01 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Version [2021-08-31 07:15:07] rotated. info 2023/07/18 07:24:02 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotated. info 2023/07/18 08:45:13 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup integrity check has started. info 2023/07/18 09:45:29 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup integrity check is finished. No error was found.

Das sind die Einträge von Backups die ich manuell angestoßen habe, nachdem die Automatik nicht mehr funktioniert hat.

info 2023/08/23 12:29:47 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup started. info 2023/08/23 12:38:18 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup complete. info 2023/08/23 12:38:36 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotation started. info 2023/08/23 12:39:57 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Version [2021-09-21 07:15:06] rotated. info 2023/08/23 12:39:57 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotated. info 2023/08/29 11:30:02 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup started. info 2023/08/29 11:34:56 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [192.168.178.20] Backup complete. info 2023/08/29 11:35:13 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotation started. info 2023/08/29 11:36:20 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Version [2021-09-28 07:15:06] rotated. info 2023/08/29 11:36:20 backup: {"TARGET_UNIQUE_ID":"1","USER":"backup"} [Localhost] Backup rotated.

Ich denke es liegt nicht an Hyperbackup und hier gibt's ein anderes Problem.

 

[synfor]

So, ich habe eine neue Batterie eingelegt, dies konnte mein Problem aber nicht lösen! Die Synology fährt einfach nicht hoch.

Das ist ja auch nur die halbe Miete. Danach musst du den Zeitplan neu speichern.

 

[Keen]

Ja natürlich! Ich habe einen neuen Zeitplan erstellt, das ganze habe ich zweimal gemacht, es passiert nichts

 

[Keen]

Ich habe mal var/log/messages aufgerufen.

Ist es normal das beim Booten Ein Zeit Stempel von 1970 angezeigt wird?

Woanders wurde gebeten folgenden Befehl einzugeben:

tail -n 300 /var/log/messages | grep CPU:

Darauf kommt folgende Meldung:

1970-01-01T01:00:38+01:00 Backup kernel: CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c53c7d
1970-01-01T01:00:38+01:00 Backup kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache

Hier wieder 1970. Hat die neue Batterie ne Macke?