Seite 1 von 1
Backup per ssh/rsync
Verfasst: 05.01.2019, 02:05
von Psi
Hi,
ich hab mir /bin/createBackup.sh angesehen und mir sind ein paar Dinge aufgefallen:
1.) Wenn ich täglich ein Backup mache, dann erstelle ich jedes Mal eine (größere) Datei auf der SD was ich gerne vermeiden würde.
Dies würde ich vermeiden in dem ich alle Dateien per rsync direkt auf den Backup-Server kopiere.
2.) Es wird per crypttool eine Signatur erstellt.
Für was genau wird die signature und key_index benutzt? Könnte jemand kurz die Idee und das Verhalten dahinter umreißen?
Danke
Re: Backup per ssh/rsync
Verfasst: 05.01.2019, 07:52
von NickHM
Hallo
wenn Du selbst etwas bauen möchtest, kannst Du Dir folgendes ansehen
- ioBroker
Entweder ioBroker betreiben und mit dem Adapter BackItUp ein CCU Backup auf einer Netzwerkfreigabe erstellen lassen.
Oder bei GitHub in den Quellcode des Adapters sehen und die entsprechende Funktionalität selbst in einem Script auf dem Server laufen lassen
- CuxD
IMHO gibt es auch dort eine Backupmöglichkeit mit Angabe des Zielpfades. Allerdings muss man dann die fertigen backups noch abholen / verschieben oder vorher auf der CCU einen Pfad zu einer Netzwerk Freigabe mounten.
Re: Backup per ssh/rsync
Verfasst: 05.01.2019, 11:53
von Psi
Hi,
danke für deine Antwort aber genau hier werden die Funktionalitäten genutzt die ich nicht möchte (/config/cp_security.cgi?sid=@${sid}@&action=create_backup) da hier wieder jedes Mal eine Datei auf der SD landet.
Ich möchte die (geänderten) Files per rsync oder tarpipe direkt auf den Backup-Space schieben was erst mal auch kein Problem ist nur verstehe ich die Verwendung von crypttool (noch) nicht.
Re: Backup per ssh/rsync
Verfasst: 05.01.2019, 14:52
von jmaus
Psi hat geschrieben: ↑05.01.2019, 02:05
ich hab mir /bin/createBackup.sh angesehen und mir sind ein paar Dinge aufgefallen:
1.) Wenn ich täglich ein Backup mache, dann erstelle ich jedes Mal eine (größere) Datei auf der SD was ich gerne vermeiden würde.
Dies würde ich vermeiden in dem ich alle Dateien per rsync direkt auf den Backup-Server kopiere.
Das ist nicht ganz richtig. /bin/createBackup.sh generiert lediglich in dem als BACKUPDIR angegebenen Verzeichnis irgendwelche temporären Dateien. D.h. man kann es ohne Probleme mit einem anderen Pfad am Ende aufrufen (z.B. /bin/createBackup.sh /mnt) und wenn dieser Pfad (z.B. /mnt) ein NFS Laufwerk ist werden lediglich auf diesem Laufwerk dann Dateien (auch temporärer Art) erzeugt und keinerlei Dateien auf der SD Karte.
Und wenn du die aktuelle Funktionalität des "cronBackup.sh" Skriptes nutzt das standardmäßig um 00:07 ausgeführt wird und in einer Datei /etc/config/CronBackupPath eben den besagten Pfad (/mnt) hinterlegst musst du überhaupt nichts machen und das cronBackup wird jede nacht vollautomatisch in dem angegeben Pfad dann ein aktuelles Backup ablegen.
Psi hat geschrieben: ↑05.01.2019, 02:05
2.) Es wird per crypttool eine Signatur erstellt.
Für was genau wird die signature und key_index benutzt? Könnte jemand kurz die Idee und das Verhalten dahinter umreißen?
Die Nutzung von "crypttool" ist eine Art konsistenzprüfung bzw. Verschlüsselung anhand des selbst angegeben Sicherheitsschlüssels (wenn man einen verwendet) Es wird dann in dem Falle in der Datei "signature" eine Signatur abgelegt die es erlaubt die Konsistenz des Backups zu überprüfen. Und genau deshalb macht /bin/createBackup.sh das eben genauso wie es das WebUI basierte Backups selbst auch tut.
Re: Backup per ssh/rsync
Verfasst: 05.01.2019, 15:23
von Psi
jmaus hat geschrieben: ↑05.01.2019, 14:52
Das ist nicht ganz richtig. /bin/createBackup.sh generiert lediglich in dem als BACKUPDIR angegebenen Verzeichnis irgendwelche temporären Dateien.
irgendwelche temporären Dateien ist fast alles aus /usr/local was wiederum über 300MB Addons enthält.
Lediglich das finale .tar.gz (bzk sbk) landet dann im BACKUPDIR. Ich würde also schon jede Nacht kanpp 400MB auf der SD schreiben.
jmaus hat geschrieben: ↑05.01.2019, 14:52
Die Nutzung von "crypttool" ist eine Art konsistenzprüfung bzw. Verschlüsselung anhand des selbst angegeben Sicherheitsschlüssels (wenn man einen verwendet) Es wird dann in dem Falle in der Datei "signature" eine Signatur abgelegt die es erlaubt die Konsistenz des Backups zu überprüfen. Und genau deshalb macht /bin/createBackup.sh das eben genauso wie es das WebUI basierte Backups selbst auch tut.
Ah verstanden! Wenn ich das Backup manuell einspielen würde dann brauche ich das nicht unbedingt. Auch restoreBackup.sh scheint hier keine Verifizierung vorzunehmen.
Danke, damit sollte mir nun alles klar sein.
Re: Backup per ssh/rsync
Verfasst: 05.01.2019, 17:12
von jmaus
Psi hat geschrieben: ↑05.01.2019, 15:23
jmaus hat geschrieben: ↑05.01.2019, 14:52
Das ist nicht ganz richtig. /bin/createBackup.sh generiert lediglich in dem als BACKUPDIR angegebenen Verzeichnis irgendwelche temporären Dateien.
irgendwelche temporären Dateien ist fast alles aus /usr/local was wiederum über 300MB Addons enthält.
Lediglich das finale .tar.gz (bzk sbk) landet dann im BACKUPDIR. Ich würde also schon jede Nacht kanpp 400MB auf der SD schreiben.
Schau dir das /bin/createBackup.sh noch einmal genau an:
https://github.com/jens-maus/RaspberryM ... sh#L25-L27
Hier wirst du sehen das dort BACKUPDIR als temp dir gesetzt wird und somit wird definitiv nichts auf die SD karte geschrieben wenn man BACKUPDIR z.B: auf ein NFS Laufwerk oder einen externen USB Stick verlinken lässt.
Re: Backup per ssh/rsync
Verfasst: 05.01.2019, 18:02
von Psi
jmaus hat geschrieben: ↑05.01.2019, 17:12
Hier wirst du sehen das dort BACKUPDIR als temp dir gesetzt wird und somit wird definitiv nichts auf die SD karte geschrieben wenn man BACKUPDIR z.B: auf ein NFS Laufwerk oder einen externen USB Stick verlinken lässt.
Ja, WENN hier ein Mountpoint liegt. Aber nen Stick würd ich dafür jetzt nicht verwenden wollen müssen und CIFS ... naja, wenn dann SSHFS aber das ist auf dem Image nicht dabei.
Vielen Dank für deine Erklärungen! Glaub aber, ich bin mit einfachem rsync ganz gut bedient.