Hallo nochmal,
ist mir leider jetzt erst eingefallen.
M.E. sollte die Version doch auf jeden Fall angelegt werden - die Daten sind schließlich schon da. Das Anlegen der Version wäre sogar schon zu Beginn des Backups möglich und würde dann eben bedeuten, dass zum Zeitpunkt X (nämlich Beginn des Backups diese Daten vorhanden waren).
Ich kann mir auch vorstellen, dass durch den Zusatz der sehr langen Bezeichner "Hauptversion" und "Versionsverlauf"+Zeitstempel sich beim Sichern der Daten Probleme ergeben (wenn Ziel ein verschlüsselter shared folder ist.... oder ist das bei Hardlinks die ihr verwendet kein Problem?).
Ich habe mir das generierte Script mal angesehen. Nachdem das erste Backup "durchgelaufen" ist (mit oder ohne Fehler) prüft ihr häufig
Code:
...
if [ -z "$rsync_code" ]
...
Es kann nun aber sein, dass in Eurem Skript Rsync irgendwo Fehler meldet (z.B. den 23). Dann wird
nach der Sicherung der Hauptversion geprüft ob (und wie) es weitergeht.
Block
- # RSync Exit-Code = Fehlermeldung : die Prüfung stört nicht
- # RSync Exit-Code = Erfolgreich bzw. Unvollständig : die Prüfung stört nicht
- # DSM-Systemkonfiguration exportieren : die Prüfung stört - oder? Die Sicherung der DSM-Settings sollte doch evtl. unabhängig von der voher stattgefundenen Sicherung sein. OK, falls die Verbindung weg (rsync Fehler 43) ist scheint mir ein Abbruch sinnvoll, wenn aber nur irgendwelche Dateien Fehler verursachten sollte die Sicherung der DSM doch klappen.
- # Rotationszyklus für das Löschen von @Recycle, @Logfiles und @DSMConfig : Warum ist es hier wichtig, dass nur gearbeitet wird, wenn rsync keinen Fehler gemeldet hat?
- # Versionierung : m.E. sollte dies doch fortgesetzt werden, wenn rsync Fehler 23 (aus man rsync 23)auftritt. Der Nutzer erhält immerhin einen Hinweis, dass etwas nicht geklappt hat. Dieses Etwas scheint sich aber nicht so einfach ermitteln zu lassen (vielleicht durch eine Simulation)
Vielleicht sollte es bei rsync Fehler 23 einfach weiterlaufen? Müsste dann wohl ungefähr so sein (hier eine Beispielstelle)
Code:
# RSync Exit-Code = Erfolgreich bzw. Unvollständig
#-------------------------------------------------------------------------
if [COLOR="#FF0000"][[ -z "$rsync_code" ] && [ $rsync_code ! -eq 23 ]][/COLOR] && [ ! -f "$stop" ] && [ -z "$source_error" ]; then
Zugegeben, gerade an exakt dieser Stelle mag auch bisheriger Code reichen (da Entscheid über Fehler oder kein Fehler). An den späteren Stellen scheint mir ein Fortsetzen eher sinnvoll (s.o.)
Hier wäre m.E. die schonmal angesprochene Prüfung der Größe der Log-Datei sinnvoll bevor sie unbedacht versendet wird:
Rich (BBCode):
# E-Mail senden
if [ "$emailfail" -eq 1 ] && [ -n "$rsync_code" ] || [ -f "$stop" ] || [ -n "$error" ]; then
ssmtp "$email" < "$log"
elif [ "$emailfail" -eq 0 ]; then
ssmtp "$email" < "$log"
fi
Noch ein kleiner Wunsch:
Nach
Code:
for source in $sources; do
fänd' ich das Schreiben des Zeitstempels klasse, damit man sehen kann wie lange die einzelnen sources benötigen. In etwa so:
Code:
timestamp_end=`date +%d.%m.%Y%t%H:%M:%S`
echo "$lang_script_start /$share - $timestamp_end" >> "$log"
das gleiche dann nochmals nach Schluss des
for
Code:
done
[COLOR="#FF0000"]timestamp_end=`date +%d.%m.%Y%t%H:%M:%S`
echo "$lang_script_version_created /$share - $timestamp_end" >> "$log"[/COLOR]
done
fi
# RSync Exit-Code = Fehlermeldung
Vielleicht ist es sinnvoll für
Start und
Ende neue Variablen zu definieren
Freue mich über Feedback.
Nein, ich habe selbst noch nie in shell gescripted - daher hier alles nur "aus der Hand".
Olaf
