Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben

Support RSYNC BACKUP - MV_Backup.sh (Linux - Bash)

AW: RSYNC BACKUP - backup-321tux.sh

Ich bin gerade am Aufbrechen in den Urlaub und kann mir das erst ende nächster Woche genauer anschauen.

Ich kann zwar den Einhängepunkt abfragen, wie viel Platz noch frei ist, aber woher soll das Skript wissen wie viel Platz man benötigt.
Beispiel einer Abfrage:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
Ich kann einbauen, dass z. B. mindesten x MB Frei sein müssen (MINFREE), welche dann vor der Sicherung abgefragt werden.

Einen kompletten (oder teilweisen) Abbruch bei Fehler kann ich sicher auch einbauen (Mit anschließender Mail)
Ich würde eigentlich eine *.error.log im Sicherungsziel erwarten. Wenn aber kein Platz frei ist, kann das Log auch nicht geschrieben werden. Ich baue vielleicht hier auch noch ein Check ein...

Bis ich am Skript arbeiten kann, kannst Du Dir eventuell mit der PRE_ACTION behelfen, in dem Du da testest, ob das Ziel noch freien Platz hat.
 
AW: RSYNC BACKUP - backup-321tux.sh

Danke. Ein MINFREE wäre eine Option. Aber ohne zu wissen wieviel kopiert werden muss, würde es zum gleichen Fehler führen. Nämlich dann, wenn MINFREE ein OK zurückgibt aber eine größere Dateimenge als MINFREE rsync'ed werden muss.
Ich hatte die Hoffnung, dass rsync dies schon ausgibt und man das abfängt.
Jedenfalls lese ich im Netz von Fehlern die rsync generieren kann:
rsync: write failed on "/dir/file": No space left on device

Ein error.log gab es bei dem Sync mit dem Fehler nicht, obwohl noch etwas Platz frei war. Die Files, die zu kopieren sind, sind sehr groß. Deshalb fiel jeder Sync der Datei auf die Nase, da nur noch knapp 500MB frei sind.
Deshalb hätte ich auch mit einem error.log gerechnet.

Im Skript habe ich
RSYNC_OPT=("-savPbh" "--delete" "--numeric-ids" "--stats" "--no-owner" "--no-group" "--no-perms")

Danke und viel Spaß im Urlaub.
 
Ich habe jetzt mal einen Check eingebaut, der eine Meldung ausgibt, das Backup aber nicht anhält:

Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Edit: 01.08.2016, 17:48 Uhr

Jetzt mit Option das Profil zu überspringen.
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
 
Zuletzt bearbeitet:
HI MegaVolt,

vielen Dank.
Verstehe ich es richtig, dass der Check jetzt nur prüft wieviel frei ist (gesetzt durch eigene Vorgabe) und dann optional abbricht?
Geht es nicht, dass das script den Rsync Fehler als solchen erkennt und daher abbricht?
Danke und viele Grüße
 
Rsync hat leider keine Möglichkeit abzubrechen. Ich kenne zumindest keine. Einzige andere Möglichkeit wäre vorher das rsync mit "dryrun" laufen zu lassen. Ich müsste dann erst mal schauen, ob da überhaupt vernünftige Werte zurück kommen, die ich im Skript abfragen kann.
Problem mit dem dry-run ist aber dass das Backup dann deutlich mehr (doppelt?) Zeit benötigt.

Bau mal das an Zeile 528 (vor den tatsächlichen rsync) ein:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
Das exit beendet das Skript! Interessant ist, was geloggt wird:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
 
Habe jetzt mal versucht einen Dry-Run Modus einzubauen. Es wird rsync im Testlauf gestartet und danach werden die Statistiken ausgelesen und mit dem freien Platz auf dem Ziel verglichen. Ist erst mal ein Versuch.
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
Wenn skip_full[$nr] gesetzt ist, wird das Backup nicht durchgeführt

Hier mal die Dateien:
Du musst dich Anmelden oder Registrieren um diesen link zusehen!

Du musst dich Anmelden oder Registrieren um diesen link zusehen!


Interessant wäre zu erfahren, ob der Testlauf genau so lange dauert wie das spätere Backup und ob die ermittelten Werte stimmen
 
Danke MegaVolt. So könnte man es angehen.
Leider bleibt mein Problem bestehen, da der DryRun bei mir zu lange dauert. Das Backup kann schon locker einen Tag dauern kann. Und ohne deine Option samt DryRun weiß man nicht wieviel Daten geschrieben werden.
Ich werde wohl ein zusätzliches Skript anlegen müssen, welches alle 5 Minuten läuft und schaut, wieviel Platz noch frei ist und ab einem Schwellwert das Rsync Script samt childs gnadenlos mit kill abschießt oder stoppt und eine Email versendet.
 
Doch, der DRYRUN gibt die zu übertragenden Daten aus. Die Frage wie lange das dann dauert, musst Du mal testen. Da die Daten bei einem DRYRUN nicht wirklich geschrieben werden, müsste das schon ein wenig schneller gehen als das tatsächliche Backup.

Ein Skript wie Du vorgeschlagen hast, könnte man per PRE_ACTION (skript.sh &) im Hintergrund laufen lassen. Allerdings müsste das Skript sich nach dem Backup auch selbst beenden. Ich kann morgen oder so mal schauen, ob ich schnell was gebastelt bekomme.

Bitte prüfe doch mal, ob der DRYRUN wirklich so lange dauert.
 
Danke. Ich werde es am Wochenende zu testen. Vorher schaffe ich es leider nicht. Aber ich erwarte trotz des Dry Run bei vielen TB von Daten eine Dauer von mehreren Stunden. Der Dry Run müsste schon sehr schnell sein.
Danke und viele Grüße
 
Ich habe jetzt noch eine weitere Möglichkeit eingebaut:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
Das Skript startet einen Hintergrundprozess, der alle fünf Minuten prüft, ob der eingestellte Wert auf dem Ziel frei ist, und bricht das Backup bei unterschreiten ab. Erst mal nur im Modus "normal"

Bitte mal testen und Rückmeldung mit den Ausgaben am Bildschirm und die Logs (*.log, *.err.log)
Hier mal die Dateien:
Du musst dich Anmelden oder Registrieren um diesen link zusehen!

Du musst dich Anmelden oder Registrieren um diesen link zusehen!
 
Wow...vielen Dank. Ich teste es am Samstag. Eine Rückfrage... reicht es aus nur die rsync Prozesse zu killen? Das Backup Script wird ja per cron nächtlich gestartet. Die rsync sind ja nur die child Prozesse. Andere rsync Prozesse würden dabei auch gekillt. Danke.
Vielleicht als netten Zusatz. Per cron führe ich dieses Script aus, welches wiederum das Backup Script startet. Da erlaubt mir direkten PID Zugriff und verhindert, dass per cron parallel zwei Jobs gestartet werden.


Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
 
Im aktuellen Skript ist ein "Locking" schon drin:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!
Das bedeutet auch, dass rsyncs nur vom Skript sein können. Das Skript selbst mach nach dem beenden der rsync's ja noch weiter (Logs sammeln, Mail versenden)
Ist alles erst mal nur ein Test, sollte aber gut funktionieren.
 
Zurück
Oben