Allgemeines Backupskript! Würdet Ihr das verstehen?

CoolTux · 16 Februar 2019, 19:08:38

Hallo,

Ich habe die letzten Tage an ein allgemeines Backupskript in Perl gearbeitet.
Diesem Skript wird eine Konfigurationsdatei übergeben und ich würde Euch gerne fragen ob Ihr versteht was genau die einzelnen Punkte machen. Mir geht es darum eine ausreichende kleine Dokumentation zur Konfiguration zu machen.

Code Auswählen


### Konfiguration
# wie soll das Verzeichnis heißen wo die Backups hin geschrieben werden
BACKUPDIRNAME=fhem_backups

# Name der Backupdatei
BACKUPFILENAME=fhem_backup

# Startverzeichnis wo Daten liegen zum sichern
SOURCEPATH=/opt/fhem/backup

# Dateien Komma getrennt welche gesichert werden sollen. Kann auch zum Beispiel mittels *.md oder * fur alles lauten. Muss sich aber unterhalb von SOURCEPATH befinden
FILES_TO_BACKUP=FHEM-"`date +%Y%m%d`"*.tar.gz

# Verzeichnis unter welches die Backupstruktur aufgebaut werden soll.
BACKUPPATH=/home/marko/Google_Drive_Secure/pi-webapp01_BACKUPS

# wie viele Backups sollen aufgehoben werden.
DAILY_DATA_BACKUPS=6



### Special Konfiguration
# Soll bei nicht vorhanden sein des Backupverzeichnis das Skript abgebrochen werden. Sinnvoll bei encfs oder eingebundenen Netzwerkverzeichnissen. 0 nein 1 ja
SPECIALCHECK_BACKUPPATH=1

# Verzeichnisse welche aufgeräumt werden sollen. Löschen aller Daten älter CLEAN_UP_DAYS Tage
CLEAN_UP_PATHS=/opt/fhem/backup/*

# löschen älter X Tage
CLEAN_UP_DAYS=4

# soll das Ergebnis des Backups (ok|error) in ein FHEM Dummy geschrieben werden? 0 nein 1 ja
# telnet Instanz muss ohne SSL und Passwort vorhanden sein
FHEMSUPPORT=1

# Name des FHEM Dummys für das schreiben des Ergebnisses
FHEMDUMMY=dummyBackupScript


### MySQL DB Dumps
# soll ein MYSQL Dump erstellt werden  0 nein 1 ja
MYSQLDUMP=0

# Datenbank User
DBUSER=

# Datenbank User Passwort
DBPASS=

# Instanzname der Datenbank
DBNAMES=fhemLogHistory

#  wo soll der Dump hingeschrieben werden
DBBACKUPPATH=/opt/fhem/backup

Grüße
Leon

Frank_Huber · 16 Februar 2019, 19:19:10

Hi Leon,

FILES_TO_BACKUP=
Sieht für mich eher nach dem Name der Sicherungsdatei aus.
Unter FILES_TO_BACKUP= würde ich eher z.B. "/opt/fhem/*" sehen.

Grüße
Frank

Gesendet von meinem Doogee S60 mit Tapatalk

rischbiter123 · 16 Februar 2019, 19:25:34

Moin,

ich versuchs mal.

### Konfiguration
FINDCMDPATH=/usr/bin/find ?
BACKUPDIRNAME=fhem_backups Name des Ordners, in dem das Backup abgelegt wird
BACKUPFILENAME=fhem_backup Name des Files
SOURCEPATH=/opt/fhem/backup ?
FILES_TO_BACKUP=FHEM-"`date +%Y%m%d`"*.tar.gz Erstellen des Files
BACKUPPATH=/home/CoolTux/Google_Drive_Secure/pi-webapp01_BACKUPS Dort wird das Backup extern gespeichert
DAILY_DATA_BACKUPS=6 Anzahl der täglichen Backups?

### Special Konfiguration
SPECIALCHECK_BACKUPPATH=1 ?
CLEAN_UP_PATHS=/opt/fhem/backup/* 'Normales' Backup-Directory
CLEAN_UP_DAYS=4 Löschen von Backups, die älter als 4 Tage sind?
FHEMSUPPORT=1 ?
FHEMDUMMY=dummyBackupScript Dummy, in den die Konfigurationsdatei geschrieben wird?

LG

Andreas

CoolTux · 16 Februar 2019, 19:31:19

Ich sehe schon da gibt es noch einiges zu Dokumentieren.

Das Skript arbeitet komplett FHEM unabhängig, einzig der Status des durchgelaufenden Skriptes kann in FHEM dar gestellt werden.
Ich werde nachher noch ein paar Sätze in den ersten Thread schreiben. Mal schauen ob das dann schon ausreichend ist.

Danke Euch
Grüße

CoolTux · 16 Februar 2019, 20:46:30

schaut mal bitte ob die Erklärungen soweit verständlich sind.

Grüße

Frank_Huber · 16 Februar 2019, 20:55:05

Ja, jetzt ist es deutlicher, wobei hier jetzt das Beispiel nicht passt, oder?

FILES_TO_BACKUP=FHEM-"`date +%Y%m%d`"*.tar.gz # Dateien Komma getrennt welche gesichert werden sollen. Kann auch zum Beispiel mittels *.md oder * fur alles lauten. Muss sich aber unterhalb von SOURCEPATH befinden

FHEM-"`date +%Y%m%d`"*.tar.gz
Würde ja bedeuten dass er nur Sicherungen von heute sichert.

Gesendet von meinem Doogee S60 mit Tapatalk

rischbiter123 · 16 Februar 2019, 21:12:23

Moin,

Zitatschaut mal bitte ob die Erklärungen soweit verständlich sind.

Für mich jetzt ja.

LG

Andreas

CoolTux · 16 Februar 2019, 21:13:06

Zitat von: Frank_Huber am 16 Februar 2019, 20:55:05
Ja, jetzt ist es deutlicher, wobei hier jetzt das Beispiel nicht passt, oder?

FILES_TO_BACKUP=FHEM-"`date +%Y%m%d`"*.tar.gz # Dateien Komma getrennt welche gesichert werden sollen. Kann auch zum Beispiel mittels *.md oder * fur alles lauten. Muss sich aber unterhalb von SOURCEPATH befinden

FHEM-"`date +%Y%m%d`"*.tar.gz
Würde ja bedeuten dass er nur Sicherungen von heute sichert.

Gesendet von meinem Doogee S60 mit Tapatalk

Genau. FHEM macht ja selber ein Backup und legt die Datei ins /opt/fhem/backup Verzeichnis ab, diese Datei wird dann weg gesichert. Backup vom Backup so zu sagen. Man kann dem Skript auch sagen sichere das FHEM als ganzes dann brauch man das FHEM Backup nicht mehr. Aber ich lasse FHEM Backup ein Backup von FHEM machen und sichere die FHEM Backupdatei und noch andere Sachen dann in ein weiteres Nachtbackup weg.

CoolTux · 16 Februar 2019, 22:00:30

Ich habe die Kommentare für die Konfigdatei mal entsprechend oben eingefügt. Was denkt Ihr? Kann man das soweit an User aushändigen?

Aktuell hat das Skript leider noch keine Simulation. Heißt wenn falsch konfiguriert dann im schlimmsten Fall Daten überschrieben oder gelöscht. Nicht so gut, oder?

rischbiter123 · 16 Februar 2019, 22:16:15

Moin,

wenn Du hier

Code Auswählen

DAILY_DATA_BACKUPS=6 oder hier

Code Auswählen

CLEAN_UP_DAYS abfangen könntest, dass mindestens die Eingabe größer 1 sein muss, dürfte bei falscher Konfiguration doch höchstens ein nicht funktionieren sein. Oder sehe ich das falsch?

LG

Andreas

CoolTux · 16 Februar 2019, 22:32:19

Das ist eine sehr gute Idee.
Dennoch besteht die Gefahr bei CLEAN_UP_PATHS ein falsches Verzeichnis an zu geben und dann sind darin alle Daten älter X Tage gelöscht.

rischbiter123 · 16 Februar 2019, 22:47:43

Moin,

meine Programmierkenntnisse sind leider nur rudimentär, aber könnte man das nicht mit Sourcepath verknüpfen, so dass nur das gelöscht werden kann, was gesichert wurde?

LG

Andreas

CoolTux · 16 Februar 2019, 22:58:56

Das sollte gehen. Zu mindest kann dann nichts vom System gelöscht werden. Man kann zwar immer noch im Sourcepath was anderes sichern wie löschen aber eben nur im Sourcepath. Das muss reichen.
Danke Dir für Deine tollen Ideen.

CoolTux · 19 Februar 2019, 14:20:33

Ich denke mal ich bin dann soweit durch mit meinem Backupscript. Wer möchte kann es gerne verwenden

https://github.com/LeonGaultier/backupME

r00t2 · 19 Februar 2019, 15:04:48

Danke dafür!

Noch eine Sache zum Verständnis.

Aus den Elementen BACKUPDIRNAME, BACKUPFILENAME und BACKUPPATH der Config wird die letztendliche Backupstruktur aufgebaut, oder?

Also bei Deinem Beispiel würde die Backupstruktur aufgebaut in:

Code Auswählen

/home/marko/Google_Drive_Secure/pi-webapp01_BACKUPS/fhem_backups/fhem_backup

Hab ich das richtig verstanden?

Wenn ja: Setzt das Script automatisch ein Datum in das Element BACKUPFILENAME, um es nicht zu überschreiben, wenn mehrere Backupfiles gesichert werden sollen?

Und: Müssen alle Konfigurations-Elemente in der Datei gesetzt sein, auch wenn sie nicht notwendig sind? Z. B. muss das Element DBUSER etc. vorhanden (aber nicht gesetzt) sein, wenn keine DB verwendet wird oder kann man die Elemente einfach komplett weglassen?

CoolTux · 19 Februar 2019, 15:20:18

Es müssen nur die unter Konfiguration gesetzt sein.
Die anderen sind optional.

Zitat von: r00t2 am 19 Februar 2019, 15:04:48
Danke dafür!

Noch eine Sache zum Verständnis.

Aus den Elementen BACKUPDIRNAME, BACKUPFILENAME und BACKUPPATH der Config wird die letztendliche Backupstruktur aufgebaut, oder?

Also bei Deinem Beispiel würde die Backupstruktur aufgebaut in:
Code Auswählen Erweitern
/home/marko/Google_Drive_Secure/pi-webapp01_BACKUPS/fhem_backups/fhem_backup

Hab ich das richtig verstanden?

Wenn ja: Setzt das Script automatisch ein Datum in das Element BACKUPFILENAME, um es nicht zu überschreiben, wenn mehrere Backupfiles gesichert werden sollen?

Nicht ganz
Das Sktipt baut seine eigene Backupstruktur unterhalb von
/BACKUPPATH/BACKUPDIRNAME/
zusammen. Es werden unterhalb davon 2 weitere Verzeichnisse automatisch erstellt.
daily und archive
Im daily landen dann täglich BACKUPFILENAME.1.tar.bz2 ausserdem wird je nach Anzahl DAILY_DATA_BACKUPS vorher die anderen Backupfiles um eines hoch verschoben.
BACKUPFILENAME.1.tar.bz2 wird zu BACKUPFILENAME.2.tar.bz2, BACKUPFILENAME.2.tar.bz2 wird zu BACKUPFILENAME.3.tar.bz2 und so weiter.

Code Auswählen


/home/marko/Google_Drive_Secure/pi-webapp01_BACKUPS/fhem_backups/daily/fhem_backup.1.tar.bz2

Jeden Sonntag erfolgt eine Sondersicherung in archive.

Probiere es einfach mal aus. Wenn Du CLEAN_UP_PATHS= so lässt, also hinter = nichts schreibst wird auch aus dem zu Backupen Ordner nichts gelöscht.

Grüße

r00t2 · 19 Februar 2019, 15:34:10

Klingt gut, danke!

Evtl. wäre es noch gut, die notwendigen Voraussetzungen für das Skript ins Git zu schreiben (also minimale Perl Version, andere Abhängigkeiten, etc.) und wie man es letztendlich sinnvoll aufruft (z. B. zyklisch per cronjob oder per Hand).

Edith:
Was mir gerade noch in den Sinn kommt. Könnte man das Skript so erweitern, dass es ein Netzwerklaufwerk bei Ausführung mounted, prüft, ob alles korrekt ist, dann das Backup ausführt und abschließend das Netzwerklaufwerk wieder unmounted? Sind viele Dinge, ich weiß und vielleicht ist es auch sinnvoller das ganze in ein Shellskript auszulagern, was die "Vorarbeit" macht, dann das Perlskript startet und danach "aufräumt". Ich spreche den Gedanken aber dennoch einfach mal an.

CoolTux · 19 Februar 2019, 15:52:55

Zitat von: r00t2 am 19 Februar 2019, 15:34:10
Klingt gut, danke!

Evtl. wäre es noch gut, die notwendigen Voraussetzungen für das Skript ins Git zu schreiben (also minimale Perl Version, andere Abhängigkeiten, etc.) und wie man es letztendlich sinnvoll aufruft (z. B. zyklisch per cronjob oder per Hand).

Edith:
Was mir gerade noch in den Sinn kommt. Könnte man das Skript so erweitern, dass es ein Netzwerklaufwerk bei Ausführung mounted, prüft, ob alles korrekt ist, dann das Backup ausführt und abschließend das Netzwerklaufwerk wieder unmounted? Sind viele Dinge, ich weiß und vielleicht ist es auch sinnvoller das ganze in ein Shellskript auszulagern, was die "Vorarbeit" macht, dann das Perlskript startet und danach "aufräumt". Ich spreche den Gedanken aber dennoch einfach mal an.

Mir war schon klar das solche Anforderungen kommen werden

Das Skript testet jetzt schon ob das Zielverzeichnis überhaupt da ist. Also ob /BACKUPPATH/ existiert als Verzeichnis. Je nachdem ob man dann gesetzt hat SPECIALCHECK_BACKUPPATH=1 oder SPECIALCHECK_BACKUPPATH=0 wird bei ersterem hart abgebrochen oder bei zweiteren die Struktur angelegt.

Ich kann das mounten einbinden. Voraussetzung ist aber das der mount in der /etc/fstab drin steht. Ich mache kein händischen komplett mount.

Code Auswählen


mount /home/backup/

kann man machen, sofern /home/backup als mount point definiert ist. Als Quelle muss dann natürlich das cifs Share oder nfs share mit entsprechenden Optionen konfiguriert sein.

Grüße

r00t2 · 19 Februar 2019, 16:10:22

Zitat von: CoolTux am 19 Februar 2019, 15:52:55
Mir war schon klar das solche Anforderungen kommen werden
...

Ich kann das mounten einbinden. Voraussetzung ist aber das der mount in der /etc/fstab drin steht. Ich mache kein händischen komplett mount.
Code Auswählen Erweitern
mount /home/backup/
kann man machen, sofern /home/backup als mount point definiert ist. Als Quelle muss dann natürlich das cifs Share oder nfs share mit entsprechenden Optionen konfiguriert sein...

Danke für Deine schnelle Antwort!

Prinzipiell müsstest Du es nicht einbauen, wenn man von der Philosophie ausgeht, dass ein Tool genau eine Aufgabe bearbeiten soll (diese aber entsprechend gut)

Man kann das Ganze ja auch per Shellskript "außenrum" bauen, sodass Dein Perlskript nicht unnötig aufgebläht wird. War nur eine Idee, die gerne weiter diskutiert werden darf.

Wichtiger wären mir tatsächlich Dinge wie Abhängigkeiten oder das Einbinden des korrekten Aufrufs in die crontab.