Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, 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 Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, 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 Bereichen, welche für Gäste verwehrt bleiben

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

    Nobody is reading this thread right now.
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:
root auf HP-T5730 am 19.07.2016 14:29
[~] # df -h /mnt/usbdrive
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdc1        37G     16G   20G   44% /mnt/SSDSA2CT040G3
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:
# Neu:  Profiloption: minfree[$nr]. Wert in Megabyte. Freier Platz, der auf dem Ziel    #
#       mindestens frei sein muss. Bei Unterschreitung wird eine Warnung angezeigt und  #
#       in das Fehlerlog geschrieben. Das Backup wird (noch) NICHT angehalten!          #

Edit: 01.08.2016, 17:48 Uhr

Jetzt mit Option das Profil zu überspringen.
Code:
# [optional] Wenn gesetzt, dann wird bei ungenügend freioem Speicher das Profil
# nicht gestartet und ein Logeintrag im Fehlerlog erstellt
#skip_full[$nr]="1"  # Wenn gesetzt (1, yes, True, ...) wird das Profil übersprungen
 
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:
      # TEST: Dry-Run
      rsync "${RSYNC_OPT[@]}" --dry-run --log-file="$LOG" --exclude-from="$EXFROM" \
        --backup-dir="$BAK_DIR" "${SOURCE}/" "$R_TARGET" >/dev/null 2>> "$ERRLOG"
      echo "Rückgabecode: $?" ; exit
Das exit beendet das Skript! Interessant ist, was geloggt wird:
Code:
root auf HP-T5730 am 09.08.2016 11:28
[~] # cat /mnt/SSDSA2CT040G3/tmp/Backup-Test/l_root/2016-08-09_Test.log
2016-08-09 11:28 - MV_Backup.sh [#160809ß] - Start:
rsync -savPbh --delete --numeric-ids --stats --log-file=/mnt/SSDSA2CT040G3/tmp/Backup-Test/l_root/2016-08-09_Test.log --exclude-from=/tmp/MV_Backup.vXjQ/tmp.rsync.zsoR --backup-dir=/mnt/SSDSA2CT040G3/tmp/Backup-Test/l_root/Geloeschte Dateien/2016-08-09 /root /mnt/SSDSA2CT040G3/tmp/Backup-Test/l_root/_DATEIEN
2016/08/09 11:28:37 [16619] building file list
2016/08/09 11:28:37 [16619] .d..t...... ./
2016/08/09 11:28:37 [16619] .d..t...... .cache/mc/
2016/08/09 11:28:37 [16619] .d..t...... .config/mc/
2016/08/09 11:28:37 [16619] .d..t...... .local/share/mc/
2016/08/09 11:28:37 [16619] Number of files: 119 (reg: 73, dir: 46)
2016/08/09 11:28:37 [16619] Number of created files: 1 (reg: 1)
2016/08/09 11:28:37 [16619] Number of deleted files: 0
2016/08/09 11:28:37 [16619] Number of regular files transferred: 6
2016/08/09 11:28:37 [16619] Total file size: 1.63M bytes
2016/08/09 11:28:37 [16619] Total transferred file size: 75.41K bytes
2016/08/09 11:28:37 [16619] Literal data: 0 bytes
2016/08/09 11:28:37 [16619] Matched data: 0 bytes
2016/08/09 11:28:37 [16619] File list size: 0
2016/08/09 11:28:37 [16619] File list generation time: 0.001 seconds
2016/08/09 11:28:37 [16619] File list transfer time: 0.000 seconds
2016/08/09 11:28:37 [16619] Total bytes sent: 2.90K
2016/08/09 11:28:37 [16619] Total bytes received: 98
2016/08/09 11:28:37 [16619] sent 2.90K bytes  received 98 bytes  5.99K bytes/sec
2016/08/09 11:28:37 [16619] total size is 1.63M  speedup is 543.77 (DRY RUN)
 
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:
# [optional] Wenn gesetzt, wird vor dem Backup mit einem Testlauf (Dry-Run) geprüft,
# ob noch genug Platz auf dem Ziel vorhanden ist (Langsam). Überschreibt minfree[$nr].
# Kann mit skip_full[$nr] verwendet werden
#dry_run[$nr]="1"  # Wenn gesetzt wird ein Testlauf durchgeführt (Nur im Modus normal)
Wenn skip_full[$nr] gesetzt ist, wird das Backup nicht durchgeführt

Hier mal die Dateien:



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:
# 17.08.2016                                                                            #
# Neu:  Profiloption: minfree_bg[$nr]. Wert in Megabyte. Freier Platz, der auf dem Ziel #
#       mindestens frei sein muss. Bei Unterschreitung wird eine Warnung angezeigt und  #
#       in das Fehlerlog geschrieben. Das Backup wird abgebrochen! Darf nicht mit       #
#       minfree[$nr] verwendet werden. Wird alle 5 Minuten geprüft.                     #
#       (Nur im Modus normal)                                                           #
#minfree_bg[$nr]="100"  # Mindestens frei auf dem Ziel (in MB). Wird alle 5 Minuten geprüft
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:

 
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:
#!/bin/bash
PIDFILE=/path/to/MVbackup.pid
if [ -f $PIDFILE ]
then
  PID=$(cat $PIDFILE)
  ps -p $PID > /dev/null 2>&1
  if [ $? -eq 0 ]
  then
    echo "Process already running"
    exit 1
  else
    ## Process not found assume not running
    echo $$ > $PIDFILE
    if [ $? -ne 0 ]
    then
      echo "Could not create PID file"
      exit 1
    fi
  fi
else
  echo $$ > $PIDFILE
  if [ $? -ne 0 ]
  then
    echo "Could not create PID file"
    exit 1
  fi
fi
/path/to/MVbackup.sh -pe -d 7
rm $PIDFILE
 
Im aktuellen Skript ist ein "Locking" schon drin:
Code:
####################################### LOCKING #########################################

PIDFILE="/var/run/${SELF_NAME%.*}.pid"
if [[ -f "$PIDFILE" ]] ; then  # PID-Datei existiert
  PID="$(< "$PIDFILE")"        # PID einlesen
  ps --pid "$PID" &>/dev/null
  if [[ $? -eq 0 ]] ; then     # Skript läuft schon!
    echo -e "\e[1;41m FEHLER \e[0;1m Skript läuft bereits!\e[0m (PID: $PID)"
    f_exit 4                   # PID-Datei nicht löschen
  else  ## Prozess nicht gefunden. PID-Datei überschreiben
    echo "$$" > "$PIDFILE" \
      || { echo -e "\e[1;41m FEHLER \e[0;1m PID-Datei konnte nicht überschrieben werden!\e[0m" ; f_exit 1 ;}
  fi
else                           # PID-Datei existiert nicht. Neu anlegen
  echo "$$" > "$PIDFILE" \
    || { echo -e "\e[1;41m FEHLER \e[0;1m PID-Datei konnte nicht erzeugt werden!\e[0m" ; f_exit 1 ;}
fi
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