Log von HyperBackup

[rednag]

Servus @all,

Weiß jemand ob es möglich ist ein ausführliches Log von HyperBackup zu bekommen?
Das Log über die GUI ist ja ein Witz. Das wird übrigens seit Jahren bemängelt.
Die Info "geht nur teilweise" ist mir nicht hilfreich.

 

[blurrrr]

Schau mal unter /var/log/packages/, da gibt es eine Datei namens "HyperBackup.log", da geht es allerdings nur um das Paket als solches. Für "etwas" mehr Details bzgl. der eigentlichen Backup-Jobs kannst Du mal unter /var/log/synology/ schauen, dort gibt es eine Datei namens "synobackup.log", aber ich befürchte so "wirklich" glücklich wirst Du damit auch nicht.

Je nach Backup-Art gibt es dann auch noch unterschiedlich "viele" Infos...

info 2021/10/02 22:43:49 SYSTEM: [Network to share][rsync Copy 1] Backup task started.
info 2021/10/02 22:50:28 SYSTEM: [Network to share][rsync Copy 1] Backup task finished successfully.

vs. z.B.

info 2021/02/20 22:15:47 SYSTEM: [Amazon S3][S3 Backup 1] Backup task started.
info 2021/02/20 22:16:19 SYSTEM: [Amazon S3][S3 Backup 1] Backup task finished successfully. [16 files scanned] [3 new files] [13 files unchanged]

Unter /var/packages/HyperBackup/target/etc/ findet sich noch die Datei "backend.conf". Dort ist beschrieben, wie was ausgeführt werden soll:

[backup]
unique="{{BACKEND}}.backup.{{task_id}}"
command_local=["/var/packages/HyperBackup/target/bin/synolocalbkp","--backup","-k","{{task_id}}"]
command_network=["/var/packages/HyperBackup/target/bin/synonetbkp","--backup","-k","{{task_id}}"]
command_cloud=["/var/packages/HyperBackup/target/bin/synocloudbkp","--backup","-k","{{task_id}}"]
command_image=["/var/packages/HyperBackup/target/bin/img_backup","-B","{{image_now}}","-k","{{task_id}}"]
command_resume=["/var/packages/HyperBackup/target/bin/img_backup","-B","{{image_now}}","-k","{{task_id}}","-n"]

Da sieht man aber schon, dass Synology da wieder ordentlich rumgeschraubt hat - keine Spur von rsync, stattdessen etwas namens "synolocalbkp" - und bzgl. Doku hat man es halt auch nicht so wirklich:

root@host:~# /var/packages/HyperBackup/target/bin/synolocalbkp --help
Copyright (c) 2003-2021 Synology Inc. All rights reserved.

root@host:~#

Synology hat zwar einen "CLI-Guide" veröffentlicht, da taucht "synolocalbkp" aber auch grade mal nur bei den Fehlern auf (Seite 5 "The dest ID in local (/etc/synolocalbkp.conf) does not exist.". Sie halten es halt für wichtiger, dass man selbst Handbücher für 19"-Rails veröffentlicht...

"synobackup" ist wohl lediglich etwas, um ein bereits bestehenden Backup-Job in Gang zu setzen, also da darf man auch nichts an zusätzlichen Log-Infos erwarten, mal ganz abgesehen davon, dass es sowas auch garnicht hergibt:

root@host:~# synobackup
Usage:
synobackup <action> [options...]

Actions:
-h, --help
-v, --version
--running-on-dev <dev name> check local backup is running on dev or not.
--cancel-backup
--backup <task id> --backend <backend>
--backup <task id> --type <branch>
--lun-backup <task name>
--lun-cancel <task name>
--is-restoring return 1 if is restoring.
--is-backup-restore-running return 1 if backup application is running.
--schedule-remove-by-app <app>
--schedule-export-by-app <app> <export file>
--schedule-enable-list-by-app <app>
--schedule-disable-list-by-app <app>
root@host:~#

Man könnte halt - wenn das alles via rsync läuft - mal schauen, ob es etwas bringt, wenn man unter /etc/rsyncd.conf bzw. /etc.defaults/rsyncd.conf mal folgende Zeile wieder mit rein nimmt (also "#" weg).

#log file = /var/log/rsyncd.log

Das müsste dann aber auf dem Zielgerät passieren (rsyncd = Daemon = lauscht auf eingehende Verbindungen, das macht die Quelle ja nicht). Zudem sollte dann - theoretisch - auch ein entsprechendes rsync-Modul auf dem Zielsystem existieren (mit Backup-Pfad, etc.). In der Modul-Config könnte man dann noch den Parameter "max verbosity" anpassen, allerdings kann man sich damit dann auch ziemlich schnell das System zumüllen... Wie man sieht... ganz so einfach ist es dann anscheinend doch nicht (ausser jemand hat noch eine glorreiche Idee).

Alternativ könntest Du es ja ggf. auch einfach mal mit BasicBackup von @Tommes ausprobieren, oder bastelst Dir selbst ein rsync-Script (wo dann eben alles 100%ig unter "Deiner" Kontrolle steht), oder halt UltimateBackup (Projekt von @Tommes und PsychoHH). Auf der anderen Seite kann ich es aber auch gut nachvollziehen... ein einfacher Haken für etwas wie ein "ausführlicheres Log" wäre schon ganz "nett"

....oder um es kurz zu machen:

ob es möglich ist ein ausführliches Log von HyperBackup zu bekommen?

"Nein, geht nicht." ...

... fast jedenfalls... Hilft mitunter nicht, aber "im Fall der Fälle" könnten auch noch nützliche Informationen vorhanden sein:

cat messages |grep -i -E 'hyper*|synolocalbkp*'

Dann aber wohl eher bzgl. der Backup-Jobs allgemein und nicht spezifisch auf irgendwelche gesicherten Dateien.

Frage ist ja irgendwo auch, das genau Du Dir da eigentlich vorstellst, aber ich befürchte, dass es schwer in die Richtung "selber machen" geht, oder eben eines der bereits o.g. Pakete (BasicBackup/UltimateBackup).

Vorteil bei der Variante "selbst ein rsync-Job basteln" ist halt, dass Du alles bis ins kleinste Detail selbst angeben kannst, so dass Du ganz genau das rausbekommst, was Du willst. Nachteil ist natürlich, dass es keine GUI zum "zusammenklicken" gibt und auch Dinge, wie z.B. diese "App"-Sicherung da jetzt auch nicht einfach so mit drin sind. Wäre dann halt eher etwas für "Dateien". Aber auf der anderen Seite....:

- Backup der Apps via HyperBackup (auf einen lokalen Pfad (/VolumeX/Temp-Backup/apps.hbk)
- Dump der MariaDB (auf einen lokalen Pfad (/VolumeX/Temp-Backup/db.sql)
- Alles einsammeln (zu sichernde Dateien + apps.hbk + db.sql) und via rsync auf das Ziel schieben
(- ggf. lässt man sich nach Beendigung des Jobs noch eine Mail schicken)

Eigentlich recht überschaubar... diese 3 Sachen verfrachtet man in ein Bash-Script und nutzt das Script dann in einem Cronjob. Jeder dieser 3-4 Punkte ist dann halt ein kleines Hindernis für sich, das eine lässt sich leichter bewältigen, das andere ggf. schwieriger, kostet halt ein wenig Zeit, aber: Wenn läuft, dann läuft. Man könnte auch "mixen", z.B. App-Backup via HyperBackup + Datenbank-Dump via sqldump + BasicBackup, oder wie auch immer. Ist aber auch nur so eine Idee und ich kann durchaus auch verstehen, wenn einem das zuviel Gebastel ist.

So... das war doch jetzt ungefähr die Antwort, welche Du niemals hören wolltest, sie aber schon durchaus erwartet hast, oder?

 

[Tommes]

Hey @blurrrr
Ich glaub, du hast da etwas falsch verstanden. @rednag wollte ein ausführliches Protokoll und keine ausführliche Analyse darüber, warum Hyper Backup kein ausführliches Protokoll ausspuckt.

Aber mal im Ernst. Deine Antwort ist echt der Hammer. Etwas so banales wie eine Protokollausgabe so haarklein und detailliert zu erforschen, ist selbst mir noch nie in den Sinn gekommen. Von daher, Hut ab.

Nun rühre ich noch schnell ein wenig die Werbetrommel für Basic Backup, bevor ich wieder ins Off verschwinde. Bei Basic Backup kannst du einem Backup Auftrag u.a. den Optionsschalter -v (für Verbose), bzw. -vv oder auch -vvv mitgeben, um eine bessere Analyse fehlgeschlagener Backups durchführen zu können. Über den Optionsschalter -n oder --dry-run kannst du eine Simulation von rsync ausführen, ohne das Daten geschrieben werden, um zu schauen, ob das Backup funktioniert oder nicht.

So, ich muss los

Tommes

 

[blurrrr]

Bei Basic Backup kannst du einem Backup Auftrag u.a. den Optionsschalter -v (für Verbose), bzw. -vv oder auch -vvv mitgeben

Über den Optionsschalter -n oder --dry-run kannst du eine Simulation von rsync ausführen

Sowas sind mal "vernünftige" Optionen

 

[rednag]

Danke für eure Antworten. Daraus schließe ich, das es keine alltagsgängigen Lösungen für den "Normalverbraucher gibt". Abgesehen von BasicBackup von @Tommes . Mir absolut nicht begreiflich warum man so eine Kleinigkeit nicht implementiert. Das ist für ein Backup doch eine elementare Information, daß ich wissen will woran, bzw. an welchen Daten Probleme auftraten. Wie soll man sich auf ein Backup welches nur sagt, daß es Probleme gibt verlassen. Unabhängig davon hatte ich die letzten Wochen erst ein Problem mit einem Restore. Quelle: DS415+, Ziel: DS1019+. rsync via *.hbk mit Versionierung. An der Quelle war kein einziger Tag eines Backups mit dem HyperBackup-Explorer zu finden. Aus so einem Verhalten wird deutlich, das Synology Dinge wie "Synology Fotos -ehemals Moments, ehemals FotoStation wichtiger sind. Wie soll man sich hier auf ein Backup verlassen können? Langsam wird es echt Zeit, sich nach Alternativen umzusehen. Eigentlich traurig sowas. Obwohl ich hier im Forum als QNAP-Basher betitelt werde -das kann QNAP besser.

 

[Tommes]

Hi!

Vielleicht solltest du dich mal vertrauensvoll an den Support wenden, um deinem Unverständnis Ausdruck zu verleihen und bestenfalls Wünsche äußerst, wie man es besser/anders/schöner machen könnte, oder auf was es dir bei einem Protokoll genau ankommt. Sich hier herumzuärgern bringt halt leider nichts, auch wenn ich deinen Unmut durchaus verstehen kann.

Soweit ich das in Erinnerung habe, kannst du dich mit Basic Backup auch nicht wirklich anfreunden (was ja absolut legitim ist). Daher kann ich dir bedauerlicherweise auch keine Alternative anbieten. Ich kenn’ und verwende halt nur Basic Backup und Hyper Backup auf der DS... und eine QNAP kommt mir garnicht erst ins Haus, nachdem, was ich da alles schon gelesen habe.

Tommes