Hyper Backup Hyper Backup - Backup-Aufgaben (Legacy Rsync) auf frisches DSM übertragen?

[mb01]

Mein Plan ist, in meiner DS415+ mal vier neue Platten zu testen, und wollte die Daten per Backup wieder zurückspielen. Ich hab nahezu alles per "RSync Legacy" auf ein "rsync-kompatibles NAS" gesichert, was immer gut geklappt hat. Jetzt mit frisch installierten DSM hab ich das Problem, dass logischerweise die "Backup-Aufgabe" in Hyper Backup weg ist und ich daher das Backup nicht einfach zurückspielen kann. Ich hab die Einstellungen des alten DSMs gesichert und im frischen DSM auf den neuen Platten wieder zurückgespielt, aber da werden ja keine Hyper-Backup-Aufgaben gesichert. Neu "drüber" anlegen kann ich die Aufgabe auch nicht, da der betreffende Ordner auf der zweiten NAS nicht wieder verwendet werden kann. Importiert werden können ja nur Backups im neuen Datenbank-Format.

Klar, ich kann die Daten per SMB und bereitgestellten Ordner rüberkopieren, von daher ist mein Problem nicht kritisch, aber mich würde dennoch interessieren, ob ich etwas übersehe oder ob jemand da eine bessere Idee hat, wie man auf einem frischen DSM ein Rsync-Legacy-Backup "mit einem Klick" wieder zurückspielen kann.

 

[PsychoHH]

Ja das ist eine gute Frage und ich glaube das kann man nicht so mit einem Klick zurückspielen.

Mit unserem Script (Signatur) wäre dies aber z.B. möglich gewesen.

 

[Tommes]

Ich hab nahezu alles per "RSync Legacy" auf ein "rsync-kompatibles NAS" gesichert, was immer gut geklappt hat. Jetzt mit frisch installierten DSM hab ich das Problem, dass logischerweise die "Backup-Aufgabe" in Hyper Backup weg ist und ich daher das Backup nicht einfach zurückspielen kann.

Wenn du den DSM "frisch" installiert hast, wirst du auch keine "datenbankgestützte Backup-Aufgabe" unter Hyper Backup finden. Eine Wiederherstellung einer per Hyper Backup angelegten Sicherung sollte aber aus beiden Varianten heraus funktionieren, da bin ich mir ziemlich sicher. Häng dein externen Datenträger mal ein und such mit Hyper Backup mal nach einer Wiederherstellung des Backups

Tommes

 

[rednag]

Ich habs noch nicht getestet, aber ich vermute damit sollte es funktionieren.

 

[Tommes]

Meine Güte rednag, du hast da aber ein Haufen Backup-Job's. Wäre es nicht einfacher das alles etwas zu komprimieren, oder läuft jeder Backup-Job auf ein anderes Medium? Ist nur so eine Frage?

 

[rednag]

Wäre es nicht einfacher das alles etwas zu komprimieren

Was meinst Du damit @Thommes?

Echt? Sovel kommt mir das garnicht vor. Die sind von meiner DS415+. Gesichert wird per HyperBackup Legacy (rsync) auf meine DS213.
Natürlich könnte ich auch alles in einen lokalen Ordner sichern lassen, aber die zu sichernden Ordner werden trotzdem nicht weniger.

 

[mb01]

Ich habs noch nicht getestet, aber ich vermute damit sollte es funktionieren.

Perfekt, danke! So funktioniert´s ...

Das mit "Repositories herstellen" hatte ich auch schon gesehen. Ich war aber vorher an anderer ähnlicher Stelle gescheitert, weil es sich dort auf die datenbankbasierte Version bezog. Und weil bei dann bei Repositories herstellen keinerlei Hinweis auf die Legacy-Variante war, hab ich es wohl gleich unterbewußt verworfen.
Geht man darüber, kann man die Daten seines Rsync-Servers angeben und er zieht sich dann die darauf abgelegte "Module". Nach dem Auswählen kann man ggf. gleich ein eine Systemwiederherstellung ziehen, anschließend die gemeinsamen Ordner und Anwendungen ... und dann geht´s los.

 

[Tommes]

Erstmal sorry für's Highjacken des Thread's... aber das Thema ist ja scheinbar durch.

@rednag
Da zum wiederholten male aufgefallen... ich heiße Tommes, nicht Thommes

Und genau das meinte ich mit komprimieren. Du hast scheinbar für jeden gemeinsamen Ordner einen Backup-Job erstellt die alle zur selben DS wandern. Warum also nicht einen Auftrag mit allen Ordnern? Ich war nur neugierig, kann ja sein, das du einen bestimmten Zweck damit verfolgst.

Tommes

 

[rednag]

Sorry @Tommes,

ich versuche die Namensgebung zukünftig besser zu berücksichtigen. Blöde Angewohnheit, -vermutlich weil man Thomas auch mit "h" schreibt.

Du hast vermutlich Recht, daß ich sämtliche Ordner und Pakete in einen Job packen könnte. Ich bilde mir aber ein, so eine bessere Übersicht zu haben. Am Ziel ist schließlich auch alles in einem Ordner "Netbackup". Und so habe ich Fall der Fälle (wenn das Backup abbricht o. ä.) auch einen Anhaltspunkt in welchem Ordner und was bisher gesichert worden ist. Wenngleich das Protokoll von Hyper Backup durchaus gesprächiger sein könnte. Backup Task failed ist halt nicht sehr aussagekräftig und für eine Fehlersuche auch nicht zu gebrauchen. Weiß zufällig wer wo das ausführliche Log unter /var/log liegt?

 

[dil88]

Ich kanns nur für das "alte" Datensicherung & Replikation sein, auf dem aber m.W. die rsync-Legacy-Option in Hyper Backup basiert. Dort wird das Logfile abgelegt unter /var/log/synolog/synobackup.log. Schau 'mal, ob das so geblieben ist.

 

[Tommes]

Nix für ungut bezüglich meines Nickname, mir fällt sowas natürlich eher auf jemand anderem. Ich hab mit manchen Nickname's aber auch so meine Probleme *g*

Mir ist nicht bekannt, das Hyper Backup irgendwo ein aussagekräftiges Protokoll ablegt. Ultimate Backup kann das *gg* du kannst sogar einen Trockenlauf (ohne Daten zu kopieren) der Datensicherung durchführen um im Vorfeld zu schauen, was passiert!

Und dein Vorgehen beim Backupen erschließt sich mir zwar nicht recht, aber solang du dich damit besser fühlst und deine Backup-Strategie einem "Worst Case" stand hält ist ja alles gut. Ich war, wie gesagt, nur neugierig!

Nachtrag: dill88 ist da wohl wissender, was den Speicherplatz des Protokolls angeht.

Tommes

 

[rednag]

@Tommes,

(ich habs diesmal ohe "h" geschafft)

Ok, sagen wir ich erstelle einen Backupjob, packe da alle Ordner und Anwendungen wie z. B. CalDAV, CardDAV, MariaDB und dergleichen rein und das Backup scheitert aus einem -weil nicht aussagekräftigem Log- undefinierbaren Fehler. Woher weiß ich was bisher gesichert worden ist und was nicht. Natürlich kann ich das Ziel und die Quelle per Größe aufdröseln aber wer macht das schon? Im übrigen weiß ich damit auch nicht was bisher gesichert worden ist.

 

[PsychoHH]

Woher weiß ich was bisher gesichert worden ist und was nicht.

Keine Ahnung.
Hab seit dem es auch Probleme mit Hyper Backup gab dies nicht mehr genutzt, eher nur am Anfang getestet.
Aber genau aus dem Grund nutze ich unser Script, da dort für jeden Quellordner eine Meldung ins Log geschrieben wird.

 

[rednag]

Ja @PsychoHH,

ich werde nicht umhin kommen mir eure gute Arbeit mal genauer anzusehen und auch produktiv zu verwenden.
Probleme habe ich mit Hyper Backup zwar keine aber es scheint mir insgesamt sehr wackelig zu sein. Wenn man Datenbankbasierend wählt und die Datenbank korrupt oder defekt ist, ist Essig mit dem Backup. Auch stört es mich, daß es anscheinend kein fundiertes Log dazu gibt.

 

[Tommes]

Demnach scheint das Logfile unter var/log/synolog/synobackup.log nicht sehr aussagekräftig zu sein, richtig?

Das mit deiner Befürchtung, nicht zu wissen wann bzw. warum das Backup abgebrochen hat, lässt sich i.d.R. aber schon aus dem Protokoll bzw. aus dem Protokollcenter entnehmen. Das in Ultimate Backup erstellte Protokoll ist durchaus umfangreicher und man kann auch noch weiter ins Detail gehen und jeden Schritt protokollieren (wenn man weiß an welcher Schraube man drehen muss), was natürlich auf Kosten der Übersichtlichkeit geht. Ist halt auch ein Stück weit Geschmacksache ob man ein kurzes und knackiges, oder ein umfangreiches und evtl. langatmiges Protokoll haben möchte.

Tommes

 

[rednag]

Na ja, sehr viel umfangreicher als das per GUI ist es auch nicht. Ob ich hier im Falle eines Abbruchs verwertbare Informationen finde mag ich bezweifeln.

info	2016/08/13 03:00:02	SYSTEM:	[Network to share][Backup Backup] Backup task started.
info	2016/08/13 04:42:51	SYSTEM:	[Network to share][Backup Backup] Backup task finished successfully.
info	2016/08/13 04:42:52	SYSTEM:	[Network][Backup CardDAV] Backup task started.
info	2016/08/13 04:43:41	SYSTEM:	[Network][Backup CardDAV] Backup task finished successfully.
info	2016/08/13 05:00:03	SYSTEM:	[Network to share][Backup Homes] Backup task started.
info	2016/08/13 05:00:35	SYSTEM:	[Network to share][Backup Homes] Backup task finished successfully.
info	2016/08/13 05:30:02	SYSTEM:	[Network to share][Backup Kalender u. WebDAV] Backup task started.
info	2016/08/13 05:30:21	SYSTEM:	[Network to share][Backup Kalender u. WebDAV] Backup task finished successfully.
info	2016/08/13 06:00:03	SYSTEM:	[Network to share][Backup Mailserver] Backup task started.
info	2016/08/13 06:00:22	SYSTEM:	[Network to share][Backup Mailserver] Backup task finished successfully.
info	2016/08/13 06:30:03	SYSTEM:	[Network to share][Backup Musik] Backup task started.
info	2016/08/13 06:30:17	SYSTEM:	[Network to share][Backup Musik] Backup task finished successfully.
info	2016/08/13 07:00:03	SYSTEM:	[Network to share][Backup Test2] Backup task started.
info	2016/08/13 07:05:33	SYSTEM:	[Network to share][Backup Test2] Backup task finished successfully.
info	2016/08/13 07:30:03	SYSTEM:	[Network to share][Backup Video] Backup task started.
info	2016/08/13 07:32:22	SYSTEM:	[Network to share][Backup Video] Backup task finished successfully.
info	2016/08/13 08:00:03	SYSTEM:	[Network to share][Backup Web _ MariaDB-WebStation] Backup task started.
info	2016/08/13 08:01:32	SYSTEM:	[Network to share][Backup Web _ MariaDB-WebStation] Backup task finished successfully.
info	2016/08/13 08:30:03	SYSTEM:	[Network to share][Backup nextcloud-data] Backup task started.
info	2016/08/13 08:30:18	SYSTEM:	[Network to share][Backup nextcloud-data] Backup task finished successfully.

 

[Tommes]

Vielleicht solltest du das mal testen, indem du mit einem Testbackup ein paar Fehler provozierst und dann schaust was das Log-File dazu sagt! Weil bisher scheint ja immer alles funktioniert zu haben.., das erkennt man jedenfalls sehr gut im Protokoll

 

[rednag]

Vielleicht solltest du das mal testen, indem du mit einem Testbackup ein paar Fehler provozierst

Das ist ein guter Tipp. Wie kann ich gezielt Fehler provozieren?

 

[Tommes]

Netzwerkkabel vor und während der Sicherung ziehen. Während der Sicherung den Testordner löschen, umbenennen oder in ein Zip-File packen und anschließend die Orginaldateien löschen? Berechtigungen von Dateien und Ordner im Ziel ändern um so Schreibfehler zu erzeugen... u.s.w.

Aber wie gesagt... nur mit unwichtigen Testdaten arbeiten.

Tommes

 

[rednag]

Das klingt doch mal gut.
Das werde ich mal probieren.

Extra Sicherungsjob anlegen und dann mit Deinen Tipps unbeliebtes Verhalten produzieren.