Hyper Backup Hyper Backup USB Festplatten
- Ersteller ralfoertner
- Erstellt am
- Mitglied seit
- 05. Sep 2012
- Beiträge
- 3.242
- Punkte für Reaktionen
- 587
- Punkte
- 174
- Mitglied seit
- 26. Okt 2009
- Beiträge
- 9.156
- Punkte für Reaktionen
- 1.117
- Punkte
- 314
Hm... zumindest wissen wir nun, wo der Hund begraben liegt.
Die Frage, die sich mir bzw. uns jetzt stellt, ist, ob ich AutoPilot abwärtskompatibel zu DSM 7.1.x sowie Hyper Backup 3.0.x anpassen möchte, oder ob ich einfach als Mindestanforderungen DSM 7.2.x sowie Hyper Backup ab Version 4.0.x voraussetze... wobei es hier hauptsächlich um die Hyper Backup Version und weniger um die DSM Version geht.
Mindestanforderungen würden mir das Leben einfach machen. Abwärtskompatibilität bringt in der Regel weitere, unerwünschte Seiteneffekte mit sich. Auch müsste ich stets ein Testsystem mit DSM 7.1.x und Hyper Backup 3.0.x vorhalten. Ein einfaches Abfragen, wo sich der Pfad der synobackup.conf befindet, stellt erstmal kein Problem da. Sollte der Aufbau der synobackup.conf in der Version 3.0.x jedoch ein anderer sein als in der 4.0.x Version, könnte es lustig werden. Man müsste dann je nach vorliegender Hyper Backup Version andere Script-Modul-Bausteine heranziehen.
Ich bin noch unschlüssig, aber die Erfahrungen der letzten Jahre zeigen eindeutig, das Abwärtskompatibilität oftmals zu einem Flickenteppich aus Kompromissen führt. Ultimate Backup ist hier das beste Beispiel. Unter DSM 6 was diese App der Renner. Eine nie veröffentliche Version, die Ultimate Backup NG heißen sollte, wobei NG für Next Generation stehen sollte, wurde nie veröffentlicht, da DSM 7 bereits in den Startlöchern stand und zu dem Zeitpunkt niemand wusste, wo die Reise hingeht. Am Ende gingen unzählige Stunden Programmierarbeit den Bach runter, eben weil Synology ständig das Rad neu erfinden muss. Basic Backup kann gegen Ultimate Backup nicht anstinken und fristet seit Beginn nur ein Nischendasein.
Ich stimme mich nochmal mit @luddi ab, da er den Codeschnipsel zur Auswertung von Hyper Backup Aufträgen initiiert hat. Ebenfalls befindet sich grade ein Update in der Pipeline, damit AutoPilot noch besser mit Hyper Backup harmoniert, Stichwort: Bereinigungsprozess nach einem Hyper Backup. Ob man das wiederum auf die Version 3.0.x portieren kann, weiß ich ehrlich gesagt nicht.
Tommes
Die Frage, die sich mir bzw. uns jetzt stellt, ist, ob ich AutoPilot abwärtskompatibel zu DSM 7.1.x sowie Hyper Backup 3.0.x anpassen möchte, oder ob ich einfach als Mindestanforderungen DSM 7.2.x sowie Hyper Backup ab Version 4.0.x voraussetze... wobei es hier hauptsächlich um die Hyper Backup Version und weniger um die DSM Version geht.
Mindestanforderungen würden mir das Leben einfach machen. Abwärtskompatibilität bringt in der Regel weitere, unerwünschte Seiteneffekte mit sich. Auch müsste ich stets ein Testsystem mit DSM 7.1.x und Hyper Backup 3.0.x vorhalten. Ein einfaches Abfragen, wo sich der Pfad der synobackup.conf befindet, stellt erstmal kein Problem da. Sollte der Aufbau der synobackup.conf in der Version 3.0.x jedoch ein anderer sein als in der 4.0.x Version, könnte es lustig werden. Man müsste dann je nach vorliegender Hyper Backup Version andere Script-Modul-Bausteine heranziehen.
Ich bin noch unschlüssig, aber die Erfahrungen der letzten Jahre zeigen eindeutig, das Abwärtskompatibilität oftmals zu einem Flickenteppich aus Kompromissen führt. Ultimate Backup ist hier das beste Beispiel. Unter DSM 6 was diese App der Renner. Eine nie veröffentliche Version, die Ultimate Backup NG heißen sollte, wobei NG für Next Generation stehen sollte, wurde nie veröffentlicht, da DSM 7 bereits in den Startlöchern stand und zu dem Zeitpunkt niemand wusste, wo die Reise hingeht. Am Ende gingen unzählige Stunden Programmierarbeit den Bach runter, eben weil Synology ständig das Rad neu erfinden muss. Basic Backup kann gegen Ultimate Backup nicht anstinken und fristet seit Beginn nur ein Nischendasein.
Ich stimme mich nochmal mit @luddi ab, da er den Codeschnipsel zur Auswertung von Hyper Backup Aufträgen initiiert hat. Ebenfalls befindet sich grade ein Update in der Pipeline, damit AutoPilot noch besser mit Hyper Backup harmoniert, Stichwort: Bereinigungsprozess nach einem Hyper Backup. Ob man das wiederum auf die Version 3.0.x portieren kann, weiß ich ehrlich gesagt nicht.
Tommes
- Mitglied seit
- 26. Okt 2009
- Beiträge
- 9.156
- Punkte für Reaktionen
- 1.117
- Punkte
- 314
Eins noch!
Die Intention von AutoPilot liegt primär darin, x-beliebige Shellscripte beim Einstecken eines externen Datenträgers auszuführen und den Datenträger im Anschluss ggf. wieder zu trennen. Das AutoPilot ein bereits vordefiniertes Shellscript zur Ausführung von Hyper Backup Aufgaben mitbringt, zeigt eigentlich nur die Möglichkeiten auf, was man mit AutoPilot alles so anstellen kann. Es steht demnach jedem frei, sich eigene oder angepasste Scripte für z.B. älterere Versionen von Hyper Backup zu schreiben, um dieses dann in Verbindung mit AutoPilot auszuführen. Dann halt ohne, das es in der GUI explizit auftaucht.
Nichtsdestotrotz ist @luddi mit sehr viel Engagement und Herzblut dabei, die Integration von Hyper Backup in AutoPilot weiter voranzutreiben und dafür bin ich ihm sehr dankbar. Aber hier sollten wir den Bogen auch nicht überspannen um am Ende nicht übers Ziel hinauszuschießen. AutoPilot ist nur die Plattform für solche Dinge und nicht dafür verantwortlich, das alle Scripte auch das tun, was von ihnen verlangt wird.
Tommes
Die Intention von AutoPilot liegt primär darin, x-beliebige Shellscripte beim Einstecken eines externen Datenträgers auszuführen und den Datenträger im Anschluss ggf. wieder zu trennen. Das AutoPilot ein bereits vordefiniertes Shellscript zur Ausführung von Hyper Backup Aufgaben mitbringt, zeigt eigentlich nur die Möglichkeiten auf, was man mit AutoPilot alles so anstellen kann. Es steht demnach jedem frei, sich eigene oder angepasste Scripte für z.B. älterere Versionen von Hyper Backup zu schreiben, um dieses dann in Verbindung mit AutoPilot auszuführen. Dann halt ohne, das es in der GUI explizit auftaucht.
Nichtsdestotrotz ist @luddi mit sehr viel Engagement und Herzblut dabei, die Integration von Hyper Backup in AutoPilot weiter voranzutreiben und dafür bin ich ihm sehr dankbar. Aber hier sollten wir den Bogen auch nicht überspannen um am Ende nicht übers Ziel hinauszuschießen. AutoPilot ist nur die Plattform für solche Dinge und nicht dafür verantwortlich, das alle Scripte auch das tun, was von ihnen verlangt wird.
Tommes
Ich hänge nicht an Hyperbackup!
Ich habe weiter vorne ja schon beschrieben was ich machen möchte.
Wäre das denn mit Basicbackup oder einem anderen Programm in verbindung mit Autopilot möglich?
Ich habe weiter vorne ja schon beschrieben was ich machen möchte.
Wäre das denn mit Basicbackup oder einem anderen Programm in verbindung mit Autopilot möglich?
- Mitglied seit
- 26. Okt 2009
- Beiträge
- 9.156
- Punkte für Reaktionen
- 1.117
- Punkte
- 314
Also… einen Link zu Basic Backup findest du ebenfalls in meiner Signatur. Und ja… AutoPilot bietet dir ebenfalls vor definierte Scripte für Basic Backup an und hier garantiere ich dir auch, das diese im entsprechenden Aufklappmenü auftauchen werden 
Ob Basic Backup etwas für dich ist, musst du selbst herausfinden. Am Ende führt Basic Backup eine dateibasierte Datensicherung auf Grundlage von rsync aus, also im Prinzip ist das das Gleiche, was Hyper Backup auch macht, wenn es nicht in eine Datenbank sichert. Basic Backup ist es auch erstmal egal, auf welchem Datenträger der Auftrag ausgeführt wird. Somit könntest du theoretisch auch 5 Backups auf 5 Datenträgern anlegen, die über einen Auftrag ausgelöst, werden... vorausgesetzt, die Datenträger erhalten immer den selben Mountpoint. Das kann man aber nie so genau sagen. Daher hat man auch die Möglichkeit, den Auftrag fest an einen Datenträger zu binden. Stichwort ist auch hier die UUID des Datenträgers.
Führst du einen Basic Backup Auftrag jedoch über AutoPilot aus, dann wird in jedem Fall das auszuführende Script an dem Datenträger gebunden und du müsstest demnach 5 Aufträge anlegen, die am Ende jedoch alle das gleiche machen. Dein Vorhaben entspricht halt nicht dem Mainstream und daher muss man manchmal Umwege gehen und einiges ausprobieren.
Ob du am Ende mit Basic Backup glücklich wirst, kann ich dir nicht sagen. Auch bleibt dir eine automatische Recovery Option verwehrt. Das müsstest du am Ende alles zu Fuß machen. Hyper Backup bietet dir hier eine sehr komfortable Wiederherstellung an, sogar innerhalb versionierter Backups. Das kann Basic Backup nicht leisten. Du hast also die Wahl…
Ob Basic Backup etwas für dich ist, musst du selbst herausfinden. Am Ende führt Basic Backup eine dateibasierte Datensicherung auf Grundlage von rsync aus, also im Prinzip ist das das Gleiche, was Hyper Backup auch macht, wenn es nicht in eine Datenbank sichert. Basic Backup ist es auch erstmal egal, auf welchem Datenträger der Auftrag ausgeführt wird. Somit könntest du theoretisch auch 5 Backups auf 5 Datenträgern anlegen, die über einen Auftrag ausgelöst, werden... vorausgesetzt, die Datenträger erhalten immer den selben Mountpoint. Das kann man aber nie so genau sagen. Daher hat man auch die Möglichkeit, den Auftrag fest an einen Datenträger zu binden. Stichwort ist auch hier die UUID des Datenträgers.
Führst du einen Basic Backup Auftrag jedoch über AutoPilot aus, dann wird in jedem Fall das auszuführende Script an dem Datenträger gebunden und du müsstest demnach 5 Aufträge anlegen, die am Ende jedoch alle das gleiche machen. Dein Vorhaben entspricht halt nicht dem Mainstream und daher muss man manchmal Umwege gehen und einiges ausprobieren.
Ob du am Ende mit Basic Backup glücklich wirst, kann ich dir nicht sagen. Auch bleibt dir eine automatische Recovery Option verwehrt. Das müsstest du am Ende alles zu Fuß machen. Hyper Backup bietet dir hier eine sehr komfortable Wiederherstellung an, sogar innerhalb versionierter Backups. Das kann Basic Backup nicht leisten. Du hast also die Wahl…
Basic Backup kommt also mit DSM 7.1 und niedriger zurecht. Ich habe auch noch Synology Rack NAS die max. mit DSM 6x arbeiten. Auch dafür könnte ich es brauchen.
Restore ist für mich nicht wichtig.
Kopiert werden sollen Dateien die ein ImageBackup Programm erstellt und die auf dem Nas in einem Freigabe Ordner ablegt.
Damit diese Files Offsite transportiert werden können brauche ich die tägliche Kopie auf die USB-Festplatte.
Das ganze könnte ich mit einem Linuxrechner und ein paar Skripten vielleicht leichter erreichen.
Aber die Synology NAS sind ja da und haben noch andere Vorteile.
Nochmal zu Basic Backup:
Du sagst Autopilot bringt Skripte für Basicbackup mit woher bekomme ich die?
Von Github?
Du schreibst: "vorausgesetzt, die Datenträger erhalten immer den selben Mountpoint" was ist damit gemeint? Wohin in die in der Synology gemountet werden oder was?
Für einen simplen copy job wie diesen ist das doch egal?
Oder verstehe ich was falsch?
Restore ist für mich nicht wichtig.
Kopiert werden sollen Dateien die ein ImageBackup Programm erstellt und die auf dem Nas in einem Freigabe Ordner ablegt.
Damit diese Files Offsite transportiert werden können brauche ich die tägliche Kopie auf die USB-Festplatte.
Das ganze könnte ich mit einem Linuxrechner und ein paar Skripten vielleicht leichter erreichen.
Aber die Synology NAS sind ja da und haben noch andere Vorteile.
Nochmal zu Basic Backup:
Du sagst Autopilot bringt Skripte für Basicbackup mit woher bekomme ich die?
Von Github?
Du schreibst: "vorausgesetzt, die Datenträger erhalten immer den selben Mountpoint" was ist damit gemeint? Wohin in die in der Synology gemountet werden oder was?
Für einen simplen copy job wie diesen ist das doch egal?
Oder verstehe ich was falsch?
Zuletzt bearbeitet:
- Mitglied seit
- 26. Okt 2009
- Beiträge
- 9.156
- Punkte für Reaktionen
- 1.117
- Punkte
- 314
Sowohl Basic Backup als auch AutoPilot sind Programme, die für DSM 7 geschrieben wurden, nicht jedoch für DSM 6 oder niedriger, steht aber auch alles auf den entsprechenden Forumsseiten des jeweiligen Programms bzw. auf GitHub.
Ein externer Datenträger wird nach dem einstecken in das Dateisystem des DSM eingebunden, sprich gemounted. Der Mountpoint wäre dann z.B. /volumeUSB1/usbshare. Wenn du nun zusätzlich zu dem ersten, einen weiteren externen Datenträger einsteckst, erhält dieser z.B. /volumeUSB2/usbshare. Wenn du nun 5 verschiedene externe Datenträger einzeln hintereinander an die DS steckst, wird der Mountpoint i.d.R. immer /volumeUSB1/usbshare sein, kann aber auch /volumeUSB2/usbshare oder /volumeUSB3/usbshare etc. sein. Spätestens dann würde Basic Backup das Script abbrechen, außer du sagst Basic Backup, das er den externen Datenträger nicht an den Mountpoint binden soll, sondern an die UUID des externen Datenträgers. In dem Fall passt Basic Backup den Mountpoint selbstständig an.
Bei AutoPilot hingegen wird generell die UUID eines externen Datenträger mit dem auszuführenden Script fest verbunden, so das das Script nur ausgeführt wird, wenn dieser eine Datenträger und kein anderer anschlossen wird. Sollte hier dann aber der Mountpoint wieder ein anderer sein, als im Basic Backup Auftrag angegeben, hast du das gleiche Problem. Daher solltest du in deinem Fall in der Auftragskonfiguration von Basic Backup angeben, das der externe Datenträger anhand seiner UUID identifiziert werden soll.
Aber wie gesagt… am besten schaust du dir das selber alles mal an, probierst, testest, machst und tust um am Ende zu schauen, ob du mit all dem zurecht kommst und dies ein gangbarer Weg für dich wäre. Denn wie heißt es so schön, es gibt nichts gutes, außer man tut es.
Tommes
Sobald du Basic Backup installiert und mindestens einen Auftrag erstellt hast, poppt in AutoPilot ein neues Aufklappmenü mit dem Namen Basic Backup auf, genauso, wie es auch ein eigenes Aufklappmenu für Hyper Backup gibt, sobald Hyper Backup installiert wurde. Innerhalb des Aufklappmenüs kannst du dann deinen gewünschten Basic Backup Auftrag auswählen und mit einem, im Vorfeld verknüpften Scriptdateinamen verbinden. Steht aber auch alles in AutoPilot.
Ein externer Datenträger wird nach dem einstecken in das Dateisystem des DSM eingebunden, sprich gemounted. Der Mountpoint wäre dann z.B. /volumeUSB1/usbshare. Wenn du nun zusätzlich zu dem ersten, einen weiteren externen Datenträger einsteckst, erhält dieser z.B. /volumeUSB2/usbshare. Wenn du nun 5 verschiedene externe Datenträger einzeln hintereinander an die DS steckst, wird der Mountpoint i.d.R. immer /volumeUSB1/usbshare sein, kann aber auch /volumeUSB2/usbshare oder /volumeUSB3/usbshare etc. sein. Spätestens dann würde Basic Backup das Script abbrechen, außer du sagst Basic Backup, das er den externen Datenträger nicht an den Mountpoint binden soll, sondern an die UUID des externen Datenträgers. In dem Fall passt Basic Backup den Mountpoint selbstständig an.
Bei AutoPilot hingegen wird generell die UUID eines externen Datenträger mit dem auszuführenden Script fest verbunden, so das das Script nur ausgeführt wird, wenn dieser eine Datenträger und kein anderer anschlossen wird. Sollte hier dann aber der Mountpoint wieder ein anderer sein, als im Basic Backup Auftrag angegeben, hast du das gleiche Problem. Daher solltest du in deinem Fall in der Auftragskonfiguration von Basic Backup angeben, das der externe Datenträger anhand seiner UUID identifiziert werden soll.
Aber wie gesagt… am besten schaust du dir das selber alles mal an, probierst, testest, machst und tust um am Ende zu schauen, ob du mit all dem zurecht kommst und dies ein gangbarer Weg für dich wäre. Denn wie heißt es so schön, es gibt nichts gutes, außer man tut es.
Tommes
Zuletzt bearbeitet:
Ok werde Ich machen.
Kompliment an euch für die Entwicklerarbeit!
Nochmal danke an alle für die ausdauernde Hilfe hier im Forum!!!
Kompliment an euch für die Entwicklerarbeit!
Nochmal danke an alle für die ausdauernde Hilfe hier im Forum!!!
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
