- Mitglied seit
- 04. Sep 2008
- Beiträge
- 2.341
- Punkte für Reaktionen
- 13
- Punkte
- 84
Mit Einführung von DSM 5.1 hat Synology das Feature "Backup und Restore" für Pakete integriert. Damit kann jedes Paket so präpariert werden, dass es in der Liste der Anwendungen für Sicherung & Replication als Auswahl erscheint.
Ich zeige euch hier, wie man mit wenig Aufwand sein Paket um diese Funktion erweitert, um z.B. die Konfigurationsdateien seiner Anwendung mittels DSM Sicherung & Replication zu Sichern und Wiederherzustellen.
Voraussetzungen
Inhalt des Verzeichnisses "backup"
Die folgenden Dateien müssen sich im Verzeichnis befinden, damit das Feature überhaupt funktioniert, andernfalls erscheint die Anwendung nicht unter Applikationen in Sicherung & Replication.
Zum Parsen von JSON-Daten im CLI benutzt Synology das CMDline Tool jq. jq ist wie sed, nur eben für JSON-Daten. Einige Funktionen, welche das Arbeiten mit jq ein wenig erleichtern, hat Synology in der Datei "jsoncmd" zusammengefasst. jq kann auch direkt benutzt werden, es befindet sich in /bin.
Aufbau der Dateien
Anpassen der Scripte an eure Bedürfnisse
Zwischen dem Kopfteil, in dem das Backupziel bzw. die Restorequelle überprüft und übergeben wird und dem Fussteil "jout_begin..." können eure notwendigen Befehle eingefügt werden.
Zum Testen der Kopierabschnitte eignet sich ein extra Script, in diesem ihr zuvor Alles mit statischen Daten für Ex- und Importpfad verseht. Wenn eure Routinen fertig sind, kopiert den Scripteil zum Kopieren in das entsprechende Script und tauscht die statischen Daten gegen die Variablen "EXPPATH" und "IMPPATH" aus.
Anpassen der optionalen Dateien
Alle Angaben wie immer ohne Gewähr!
Ich zeige euch hier, wie man mit wenig Aufwand sein Paket um diese Funktion erweitert, um z.B. die Konfigurationsdateien seiner Anwendung mittels DSM Sicherung & Replication zu Sichern und Wiederherzustellen.
Voraussetzungen
- Euer gewünschtes Paket
- Erfahrungen mit der Erstellung von Scripten auf der Shell
- meldet euch per Telnet oder SSH auf eurer Diskstation als root mit dem Passwort vom admin an
- wechselt in das Verzeichnis "/var/packages"
Inhalt des Verzeichnisses "backup"
Die folgenden Dateien müssen sich im Verzeichnis befinden, damit das Feature überhaupt funktioniert, andernfalls erscheint die Anwendung nicht unter Applikationen in Sicherung & Replication.
- export - hier kommen die Befehle für das Backup rein
- import - hier kommen die Befehle für das Restore rein
- version - Textdatei mit Versionsnummer
- can_export - kann für eine Prüfung der Vorraussetzungen für das Aktivieren des Backup's benutzt werden (z.B. Versionsprüfung)
- can_import - kann für eine Prüfung der Vorraussetzungen für das Aktivieren des Restore's benutzt werden (z.B. Versionsprüfung)
- info - Konfigurationsdatei im JSON-Format
Zum Parsen von JSON-Daten im CLI benutzt Synology das CMDline Tool jq. jq ist wie sed, nur eben für JSON-Daten. Einige Funktionen, welche das Arbeiten mit jq ein wenig erleichtern, hat Synology in der Datei "jsoncmd" zusammengefasst. jq kann auch direkt benutzt werden, es befindet sich in /bin.
Aufbau der Dateien
export
Beim Start des Scriptes wird der Inhalt von "/usr/syno/bin/jsoncmd (siehe jsoncmd und jq)" mit dem Befehl "source" (kurz .) eingelesen und evaluiert. Im Anschluss wird der Variable "DDUCONF" der Pfad der Anwendung (in diesem Fall "/var/packages/ddnsupdater2") plus /etc zugewiesen, dort befinden sich die Konfigurationsdateien vom DDNS Updater 2. Jetzt folgt eine Stelle aus einer Synology Anwendung, von der ich diese Infos für das HowTo bezogen habe. Es wird der Zielpfad für das Backup ermittelt und der Variable "EXPPATH" zugewiesen. "SYNOPKG_BKP_INPUT" ist eine Synology-interne Variable, die uns nicht weiter interessieren soll. Dieser Scriptschnippsel, also von "EXPPATH bis fi", war in jeder "Backup/Restore-aktivierten" Anwendung vorhanden, weshalb ich ihn direkt übernommen habe.
Nun folgt noch eine Prüfung, ob das Konfigurationsverzeichnis überhaupt existiert und der eigentliche Kopierbefehl. Am Schluss werden noch JSON-Daten an die Backup-Anwendung gesendet, bzw. in einer Variable abgelegt (Block von jout_begin bis jout_end) und das Script mit exit 0 beendet.
import
Der Start für den Import entspricht im Grossteil dem export-Script, nur das diesmal der Importpfad ermittelt wird, welches aber mit dem Verzeichnis des export-Scripts identisch ist (Exportziel = Importquelle).
version
Eine einfache Textdatei mit einer dezimalen Versionsnummer im Format xx.xx, Beispiel: 1.0
Über die Anzahl der Stellen vor und nach dem Komma kann ich keine Aussage machen.
Im Grunde unterscheiden sich die beiden Scripte "export" und "import" in diesem einfachen Backup/Restore nur im Teil zum Kopieren der Daten von A->B oder B->A.
Beim Start des Scriptes wird der Inhalt von "/usr/syno/bin/jsoncmd (siehe jsoncmd und jq)" mit dem Befehl "source" (kurz .) eingelesen und evaluiert. Im Anschluss wird der Variable "DDUCONF" der Pfad der Anwendung (in diesem Fall "/var/packages/ddnsupdater2") plus /etc zugewiesen, dort befinden sich die Konfigurationsdateien vom DDNS Updater 2. Jetzt folgt eine Stelle aus einer Synology Anwendung, von der ich diese Infos für das HowTo bezogen habe. Es wird der Zielpfad für das Backup ermittelt und der Variable "EXPPATH" zugewiesen. "SYNOPKG_BKP_INPUT" ist eine Synology-interne Variable, die uns nicht weiter interessieren soll. Dieser Scriptschnippsel, also von "EXPPATH bis fi", war in jeder "Backup/Restore-aktivierten" Anwendung vorhanden, weshalb ich ihn direkt übernommen habe.
Nun folgt noch eine Prüfung, ob das Konfigurationsverzeichnis überhaupt existiert und der eigentliche Kopierbefehl. Am Schluss werden noch JSON-Daten an die Backup-Anwendung gesendet, bzw. in einer Variable abgelegt (Block von jout_begin bis jout_end) und das Script mit exit 0 beendet.
Rich (BBCode):
. /usr/syno/bin/jsoncmd
DDUCONF="${SYNOPKG_PKGPATH}/etc"
EXPPATH=$(jget "${SYNOPKG_BKP_INPUT}" ".temp_path")
if [ $? -ne 0 ]; then
jerr "Failed to get export path"
exit 1
fi
if [ -d "${DDUCONF}" ]; then
/bin/cp -rf ${DDUCONF}/* ${EXPPATH}
fi
jout_begin
joutstr "app_data_version" "1.0"
jout_end
exit 0
import
Der Start für den Import entspricht im Grossteil dem export-Script, nur das diesmal der Importpfad ermittelt wird, welches aber mit dem Verzeichnis des export-Scripts identisch ist (Exportziel = Importquelle).
Rich (BBCode):
. /usr/syno/bin/jsoncmd
DDUCONF="${SYNOPKG_PKGPATH}/etc"
IMPPATH=$(jget "${SYNOPKG_BKP_INPUT}" ".temp_path")
if [ $? -ne 0 ]; then
jerr "Failed to get import path"
exit 1
fi
if [ -d "${IMPPATH}" ]; then
/bin/cp -rf ${IMPPATH}/* ${DDUCONF}
fi
jout_begin
joutstr "app_data_version" "1.0"
jout_end
exit 0
version
Eine einfache Textdatei mit einer dezimalen Versionsnummer im Format xx.xx, Beispiel: 1.0
Über die Anzahl der Stellen vor und nach dem Komma kann ich keine Aussage machen.
Im Grunde unterscheiden sich die beiden Scripte "export" und "import" in diesem einfachen Backup/Restore nur im Teil zum Kopieren der Daten von A->B oder B->A.
Anpassen der Scripte an eure Bedürfnisse
Zwischen dem Kopfteil, in dem das Backupziel bzw. die Restorequelle überprüft und übergeben wird und dem Fussteil "jout_begin..." können eure notwendigen Befehle eingefügt werden.
Zum Testen der Kopierabschnitte eignet sich ein extra Script, in diesem ihr zuvor Alles mit statischen Daten für Ex- und Importpfad verseht. Wenn eure Routinen fertig sind, kopiert den Scripteil zum Kopieren in das entsprechende Script und tauscht die statischen Daten gegen die Variablen "EXPPATH" und "IMPPATH" aus.
Anpassen der optionalen Dateien
Die folgenden Dateien sind, wie schon erwähnt, optionale Dateien. Sind sie vorhanden, müssen diese mit gültigen Daten gefüllt sein, damit das Backup bzw. das Restore funktioniert. Fehlen diese Dateien, dann gilt das hinter "default" genannte.
info
default: online_backup: true, external_data: []
Dies ist eine Konfigurationsdatei im JSON-Format. Ich selbst benutze sie derzeit in keinem meiner Backupscripte, weshalb ich damit noch keine Erfahrungen gesammelt habe. Ein paar Dinge sind aber selbsterklärend, welche ich hier nun vorstellen möchte. Da wäre zum einen die Möglichkeit mit dem Property "online_backup" und dem Value "true oder false" zu bestimmen, ob die Anwendung zum Zeitpunkt des Backup's/Restore's gestoppt und im Anschluss wieder gestartet wird (Value = false). Dann gibt es da noch das Property "external_data", dem ein Array mit weiteren Properties und Values folgt. Hiermit können ein oder mehrere abhängige Freigaben und auch DB-Tabellen angegeben werden, die zwingend mitgesichert werden müssen.
Erklärung: Wird bei Erstellung einer Backup oder Restoreaufgabe z.B. die Freigabe nach Auswahl der Anwendung wieder abgewählt, erscheint eine Meldung über die Verknüpfung mit dieser Anwendung. Schaut euch für weitere Informatioen die anderen Anwendungen mit backup-Verzeichnis an.
Als Beispiel der Inhalt der Datei "info" der PhotoStation (Copyright Synology):
can_export und can_import
default: keine Prüfung
Wie ich oben schon schrieb, können hier vorab Prüfungen durchgeführt werden, welche das Aktivieren/Deaktivieren des Features erlauben. Synology benutzt dies meistens zur Versionsabfrage, um Backup- und Restoreinkompatibilitäten entgegenzuwirken. Diese beiden Scripte können auch ohne weitere Prüfungen vorhanden sein, dann muss aber der folgende Teil als Minimum enthalten sein.
Nun viel Spass beim Erstellen der eigenen Backup/Restore Scripte für eure Anwendung.info
default: online_backup: true, external_data: []
Dies ist eine Konfigurationsdatei im JSON-Format. Ich selbst benutze sie derzeit in keinem meiner Backupscripte, weshalb ich damit noch keine Erfahrungen gesammelt habe. Ein paar Dinge sind aber selbsterklärend, welche ich hier nun vorstellen möchte. Da wäre zum einen die Möglichkeit mit dem Property "online_backup" und dem Value "true oder false" zu bestimmen, ob die Anwendung zum Zeitpunkt des Backup's/Restore's gestoppt und im Anschluss wieder gestartet wird (Value = false). Dann gibt es da noch das Property "external_data", dem ein Array mit weiteren Properties und Values folgt. Hiermit können ein oder mehrere abhängige Freigaben und auch DB-Tabellen angegeben werden, die zwingend mitgesichert werden müssen.
Erklärung: Wird bei Erstellung einer Backup oder Restoreaufgabe z.B. die Freigabe nach Auswahl der Anwendung wieder abgewählt, erscheint eine Meldung über die Verknüpfung mit dieser Anwendung. Schaut euch für weitere Informatioen die anderen Anwendungen mit backup-Verzeichnis an.
Als Beispiel der Inhalt der Datei "info" der PhotoStation (Copyright Synology):
PHP:
{
"online_backup": true,
"external_data": [
{
"handler_type": "built-in",
"handler": "share",
"data": [
{"share_name": "photo"}
]
},
{
"handler_type": "built-in",
"handler": "pgsql",
"data": [
{
"db": "photo"
}
]
}
]
}
default: keine Prüfung
Wie ich oben schon schrieb, können hier vorab Prüfungen durchgeführt werden, welche das Aktivieren/Deaktivieren des Features erlauben. Synology benutzt dies meistens zur Versionsabfrage, um Backup- und Restoreinkompatibilitäten entgegenzuwirken. Diese beiden Scripte können auch ohne weitere Prüfungen vorhanden sein, dann muss aber der folgende Teil als Minimum enthalten sein.
Rich (BBCode):
. /usr/syno/bin/jsoncmd
jdone
exit 0
Alle Angaben wie immer ohne Gewähr!
Zuletzt bearbeitet: