staging.inyokaproject.org

Ich wollte mal nachfragen, ob dass Skript insgesamt erweitert werden soll. Habe folgendes eingebaut:

1. Wie schön erwähnt, die E-Mail Benachrichtigung.

2. Kleine Zeitstatistik mit Dauer des Skripts und wann das Skript endete.

3. Auch schon vorgeschlagen, Liste der installierten Pakete sichern. (Brauche ich selber nicht unbedingt, wird aber immer mal wieder zu geraten.)

4. Logdatei mit Zeitstempel in Tagesbackupordner. Ist hilfreich, wenn man öfters am Tag sichert oder nach Wochen was kontrollieren will.

5. ein paar Kommentare

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

#!/bin/bash
# Simple backup with rsync

# SOURCES and TARGET must end with slash
# MOUNTPOINT must end without slash
SOURCES="/root/ /etc/ /home/ /boot/"
TARGET="/media/server/backup/"
MOUNTPOINT="/media/server"
LOGFILE="/root/backup.log"
EXPIREDAYS=0
RSYNC="--delete"

PACKAGES="/tmp/packages.list"
MAILREC="root@hostname"

#SSHUSER=""
#SSHHOST=""
#SSHPORT=22 

### do not edit ###

TICK=$(/bin/date +%s)
/bin/date > $LOGFILE

MOUNTED=$(/bin/mount | /bin/fgrep "$MOUNTPOINT");
if [ -z "$MOUNTPOINT" ] || [ -n "$MOUNTED" ]; then

  # search for last backup (ordering is: today, yesterday or older) for the incremental backup
  if [ -e $TARGET ]; then
    LASTBACKUP=$(/bin/ls -d $TARGET[[:digit:]]* 2>> $LOGFILE | /usr/bin/sort -r | /usr/bin/head -1)
  fi

  TODAY=$(/bin/date +%y%m%d)

  # delete expired backups
  if [ $EXPIREDAYS -gt 0  ]; then
    EXPIRED=$(/usr/bin/find $TARGET[[:digit:]]* -maxdepth 0 -ctime +$EXPIREDAYS  2>> $LOGFILE)
    for EX in $(/bin/echo $EXPIRED)
    do
      /bin/echo  "rm -rf $EX " >> $LOGFILE
      /bin/rm -rf $EX
    done
  fi

  # make backup for each source
  for SOURCE in $(/bin/echo $SOURCES)
  do
    echo "------------------------------------------" >> $LOGFILE
    echo "---------- next source: $SOURCE " >> $LOGFILE
    echo "------------------------------------------" >> $LOGFILE
    if [ "$LASTBACKUP" ]; then
      INC="--link-dest=$LASTBACKUP$SOURCE"
    fi

    if [ "$SSHUSER" ] && [ "$SSHHOST" ] && [ "$SSHPORT" ]; then
      SSH="ssh -p $SSHPORT -l $SSHUSER";
      SOURCEDIR="$SSHHOST:$SOURCE";
    else
      SOURCEDIR=$SOURCE;
    fi
    /bin/mkdir -p $TARGET$TODAY$SOURCE >> $LOGFILE 2>> $LOGFILE;
    echo "/usr/bin/rsync -e \"$SSH\" -av $SOURCEDIR $RSYNC $INC $TARGET$TODAY$SOURCE "  >> $LOGFILE 2>> $LOGFILE;
    /usr/bin/rsync -e "$SSH" -av $SOURCEDIR $RSYNC $INC $TARGET$TODAY$SOURCE  >> $LOGFILE 2>> $LOGFILE;
  done

  echo "------------------------------------------" >> $LOGFILE
  echo "---------- finalize backup ---------------" >> $LOGFILE
  echo "------------------------------------------" >> $LOGFILE

  # backup the installed-packages list
  if [ -n "$PACKAGES" ]; then
    echo "dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1}' > $PACKAGES " >> $LOGFILE 2>> $LOGFILE
    dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1}' > $PACKAGES 2>> $LOGFILE
    echo -e "/bin/mv $PACKAGES $TARGET$TODAY \n" >> $LOGFILE 2>> $LOGFILE
    /bin/mv $PACKAGES $TARGET$TODAY 2>> $LOGFILE
  fi

  # time statistics 
  /bin/date >> $LOGFILE
  TOCK=$(/bin/date +%s)
  DURATION=`echo $((TOCK - $TICK))`
  echo "Duration: $((DURATION / 3600)) h $((DURATION / 60)) min $((DURATION % 60)) sec" >> $LOGFILE 2>> $LOGFILE
  
  /bin/cp $LOGFILE $TARGET$TODAY/backup-$(/bin/date +%T).log 2>> $LOGFILE

else
  /bin/echo "$MOUNTPOINT not mounted" >> $LOGFILE
fi

# send mail with logfile 
if [ -n "$MAILREC" ];then
  /bin/echo -e 'Backup is finished!\n'$(/bin/date)  | /usr/bin/mutt -s "Backup" -a $LOGFILE -- $MAILREC
  /bin/rm $LOGFILE
fi

Gruß Moon

Ich finde die Vorschläge persönlich nicht zu gut. Kommentare sind zwar nett, aber eigentlich sollten die rsync-Befehle vollkommen ausreichen. Das mag ich mehr als irgendwelche Trennlinien und Informationen. Ein Befehl sagt mehr als jeder Kommentar. Der Anwender sollte schon ein wenig die Befehle verstehen. Es verführt eher die Backupsoftware blind einzusetzen.

Das mit dem Zeitmessen finde ich überflüssig. Zu Beginn steht im Logfile ein Datum und im Zweifel findet man auch das Enddatum raus. Oder man lässt am Ende noch ein Datum ins Logfile schreiben. Zudem würde eine EMail auch ein Datum enthalten.

Das Logfile korrekt zu backupen wäre wohl nicht das Schlechteste. Aktuell wird es fehlerhaft gebackupt, da es während der Erstellung gebackupt wird. Aber was solls, es steht ja im Original z.B. unter /root/backup.log .

Die Paketliste zu sichern wäre schon ganz nett. Aber eigentlich reicht es die Ausgabe von "dpkg --get-selections" zu sichern. Das "install"-Zeug kann man im Zweifelsfall auch bei der Neuinstallation mit "cut" wieder raussuchen. Vielleicht kann man auch irgendwas unter /var sichern, woraus man die Paketliste generieren könnte. Bin mir da aber nicht sicher.

Hi uname,

uname schrieb:

Ich finde die Vorschläge persönlich nicht zu gut. Kommentare sind zwar nett, aber eigentlich sollten die rsync-Befehle vollkommen ausreichen. Das mag ich mehr als irgendwelche Trennlinien und Informationen. Ein Befehl sagt mehr als jeder Kommentar. Der Anwender sollte schon ein wenig die Befehle verstehen. Es verführt eher die Backupsoftware blind einzusetzen.

Für die Kommentare sprechen die ein oder andere Frage, die hier bereits gestellt wurde. Meiner Meinung nach sind manche Befehle nicht mehr einfach zu verstehen, sonder haben es schon in sich. Für einen Anfänger, und für mich auch, kann ein kurzer Kommentar schon ein große Hilfe sein.

Das mit dem Zeitmessen finde ich überflüssig. Zu Beginn steht im Logfile ein Datum und im Zweifel findet man auch das Enddatum raus. Oder man lässt am Ende noch ein Datum ins Logfile schreiben. Zudem würde eine EMail auch ein Datum enthalten.

Jetzt mal ehrlich, rechnest du Die Zeit aus? Bei mir läuft das Skript automatisch und wenn ich mit einem kurzen Blick sehe, dass es ungewohnt lang/kurz läuft, kontrolliere ich es kurz. Wäre ja auch nur eine Zeile in der Log-Datei.

Das Logfile korrekt zu backupen wäre wohl nicht das Schlechteste. Aktuell wird es fehlerhaft gebackupt, da es während der Erstellung gebackupt wird. Aber was solls, es steht ja im Original z.B. unter /root/backup.log .

Schön, dass wir hier einer Meinung sind 😀 . Ich weiß nicht genau was du mit "fehlerhaft" und "während der Erstellung" meinst. Aber mit folgender Zeile hätte man doch die Logfile zum entsprechenden Backup abgelegt, was bei mehrere aumtomaitschen Sicherungen an einem Tag hilfreich ist.

1

  /bin/cp $LOGFILE $TARGET$TODAY/backup-$(/bin/date +%T).log 2>> $LOGFILE

Die Paketliste zu sichern wäre schon ganz nett. Aber eigentlich reicht es die Ausgabe von "dpkg --get-selections" zu sichern. Das "install"-Zeug kann man im Zweifelsfall auch bei der Neuinstallation mit "cut" wieder raussuchen. Vielleicht kann man auch irgendwas unter /var sichern, woraus man die Paketliste generieren könnte. Bin mir da aber nicht sicher.

Was das beste Vorgehen ist weiß ich auch nicht. Vielleicht kann ja jemand, der da mehr Erfahrung hat seinen Senf zu geben.

Also, alles so lassen wie es war, oder kann dich der ein oder andere Vorschlag als Verbesserung überzeugen?

Gruß, Moon

Einigen wir uns darauf:

- keine weiteren Kommentare

- vielleicht am Ende die Uhrzeit ins Logfile schreiben

- Kopieren des Logfiles nach der Kopieraktion als letzten Schritt

- Zeitraum kann man dann leicht ermitteln aufgrund des Datums im Logfile am Ende und am Anfang. Sollte ausreichen.

- das mit der Paketliste könnte man auch noch einbauen

- vielleicht noch eine Empfehlung was zu sichern wäre. Ich bin mir nicht sicher ob Teilbereiche von /var aufgrund der Paketverwaltung gesichert werden sollten

Also ist ein Wiki. Ändere es gerne um.

Gehe ich richtig der Annahme, dass ich die "EXPIREDAYS" Option gefahrlos Nutzen kann für folgendes Szenario:

Ich möchte mit rsync hauptsächlich eine Spiegelung als Backup durchführen. D.h. ich habe deine Datenplatten A welche regelmässig auf eine Backupplatte B gesichert werden soll. Dabei _ändern_ sich die Daten auf A selten, es kommen jedoch häufig neue Daten hinzu. Da sich bereits vorhandene Daten sowieso nur selten ändern, brauche ich also 'ältere Versionen von Dateien' nur, falls ich mal ausversehen was ändern/überschreiben sollte.

Wenn ich nun EXPIREDAYS z.B. auf 7 setze, müssten ja die entsprechend älteren Backup-Ordner jeweils gelöscht werden. Damit würden sicherlich auch ältere Versionen von Dateien von welchen inzwischen neuere Versionen vorliegen draufgehen (das ist ja der Sinn des ganzen). ABER, versteh ich das hoffentlich richtig, dass dabei alte Dateien (die in der Quelle noch existieren) auch im Ziel erhalten bleiben?

Sprich: Wir gehen von 7 Tagen EXPIREDAYS aus.

Datei X kommt im Backup vom 1.1. hinzu. Datei Y kommt im Backup vom 1.1 ebenfalls hinzu.

Datei Y wird am 2.1. geändert, Datei X bleibt gleich.

Am 5.1. müsste nun eine Version von Datei X und zwei Versionen von Datei Y vorhanden sein.

Aber wie schauts am 10.1. aus? Sind dann (so verstehe ich es und so ist es sinnvoll) von X und Y jeweils noch eine Version vorhanden (nämlich bei X diejenige vom 1.1. und bei Y diejenige vom 2.1.) oder sind beide Dateien komplett weg, da die Ordner vom 1.1 und 2.1. ja inzwischen entsorgt wurden. (Letzteres kann ich mir kaum vorstellen und es wäre hirnrissig, aber der Text in der Wiki ist an dieser Stelle sprachlich undeutlich).

Wie heisst es so schön: Im Zweifel hat man genau ein Backup zuwenig.

Es bleibt natürlich ein Backup bestehen. In deinem Beispiel X vom 1.1 und Y vom 2.1.

Grund sind die Hardlinks, die auf Dateien verweisen.

100101  X Y   (Dateien liegen irgendwo rum)
100102  X Y   -> X: gleiche Datei wie 100101; Y nicht gleiche Datei wie 100101, da geändert
100103  X Y   -> X: gleiche Datei wie 100101; Y gleiche Datei wie 100102
100104  X Y   -> X: gleiche Datei wie 100101; Y gleiche Datei wie 100102
100105  X Y   -> X: gleiche Datei wie 100101; Y gleiche Datei wie 100102
100106  X Y   -> X: gleiche Datei wie 100101; Y gleiche Datei wie 100102
100107  X Y   -> X: gleiche Datei wie 100101; Y gleiche Datei wie 100102

Wenn nun das Backup 100101 gelöscht wird verweisen alle noch existierenden X auf eine gemeinsame Datei, die im Ursprung auch mal im Backup 100101 war. Da jedoch mindestens noch eine Datei auf das Original verweist, bleibt es erhalten. Somit kann eine Datei beliebig alt werden, sofern sie in den letzten EXPIREDAYS-Versionen nicht geändert wurde.

oder sind beide Dateien komplett weg, da die Ordner vom 1.1 und 2.1. ja inzwischen entsorgt wurden

Antwort somit definitiv NEIN.

Beim Löschen vom Backup 100101 geht Y vom 100101 endgültig verloren. Alle Y verweise auf die Version, die erstmalig am 100102 vorlag. Das Löschen von 100102 hat im Prinzip weder Auswirkungen auf X noch auf Y.

Der Befehl lautet übrigens:

stat /pfad/zum/backup/JJMMTT/pfad/<dateiname>

und gibt in der Anzeige "Links" die Anzahl der Hardlinks aus. Dort sollte im Beispiel für X ein Wert von 7 und für Y ein Wert von 6 stehen.

@lg51 Schau doch mal hier. Dann sollte dir das Prinzip klar werden.

Vielen Dank für die Auskunft! Hab mir schon gedacht, dass es so ist - aber bei Backups geh ich lieber auf Nummer sicher und frag nochmal nach ☺

Wie reagiert das Skript denn auf teilweise veränderte Dateien? Rsync kopiert ja dann eigentlich einzelne Blöcke und ändert die Zieldatei entsprechend anstatt die Datei komplett neu zu kopieren. Wenn das hier der Fall sein sollte, würden doch frühere Versionen einer Datei verlorengehen?!

Gruß,
sensorpixel

Hi sensorpixel,

rsync arbeitet, wie Du schon bemerktest, intelligent und überträgt nur geänderte Blöcke.

Was aber für dich wichtig ist, auf dem Zielsystem wird eine neue Datei angelegt. Somit bleibt die Datei von gestern bestehen und einen weitere ist hinzu gekommen. Um das zu kontrollieren hilft der der Befehl "stat".

Beispiel: Die Datei wurde 8 mal gesichert, ohne dass sie verändert wurde. Somit wurden 8 Hardlinks auf die selbe Datei gerichtet und der Inode-counter der Datei steht bei 8. (Eine Datei wird erst gelöscht, wenn der I-Node-Counter auf 0 steht, somit kannst du die Datei 8 mal löschen, bis sie wirklich im Nirwana landet.)

Jetzt wird die Datei geändert, z.B. nur teilweise. Beim Backup wird die neue Datei angelegt. Und die nicht veränderten Blöcke und die neuen Blöcke ergeben die neue Datei. Die neue Datei unterscheidet sich von der alten Datei durch ihren Inhalt (Blöcke, die sich geändert haben) und der Inode-counter steht auf 1, da sie neu ist und nur das aktuelle Backup auf diese Datei verweist.

Gruß Moon

Ok, danke, daran habe ich gar nicht gedacht. Das hieße dann, dass auf der Ziel-Seite die Blöcke, die gleich geblieben sind, intern nochmal kopiert werden und mit den neu übertragenen, veränderten Blöcken zusammengesetzt werden. Korrekt?

Gruß,
sensopixel

Interessant wird es eigentlich nur, wenn man das Backup-Script am gleichen Tag noch einmal laufen lässt, dann mit der geänderten Datei. In dem Fall wird kein neuer Ordner angelegt und die Datei wird übergemüllt.

Ich denke aber eher, dass "rsync" das merkt bzw. "rsync" nur bei der Übertragung auf Teile der Datei verzichtet. Am Ende wird sie ganz normal am anderen Ende auf die Platte kopiert. Hoffe ich, trotzdem würde ich mich freuen wenn jemand entsprechend eine Quelle im Internet dazu zitiert, konnte selbst nichts finden.

Ja, sollte korrekt sein.

Gerade dass ist einer der Vorteile von rsync.

Ich denke die Antwort kam noch auf die vorherige Antwort. Meine Frage ist somit noch offen:

Interessant wird es eigentlich nur, wenn man das Backup-Script am gleichen Tag noch einmal laufen lässt, dann mit der geänderten Datei. In dem Fall wird kein neuer Ordner angelegt und die Datei wird übergemüllt.

Ich denke aber eher, dass "rsync" das merkt bzw. "rsync" nur bei der Übertragung auf Teile der Datei verzichtet. Am Ende wird sie ganz normal am anderen Ende auf die Platte kopiert. Hoffe ich, trotzdem würde ich mich freuen wenn jemand entsprechend eine Quelle im Internet dazu zitiert, konnte selbst nichts finden.

uname schrieb:

Interessant wird es eigentlich nur, wenn man das Backup-Script am gleichen Tag noch einmal laufen lässt, dann mit der geänderten Datei. In dem Fall wird kein neuer Ordner angelegt und die Datei wird übergemüllt.

Ich denke aber eher, dass "rsync" das merkt bzw. "rsync" nur bei der Übertragung auf Teile der Datei verzichtet. Am Ende wird sie ganz normal am anderen Ende auf die Platte kopiert. Hoffe ich, trotzdem würde ich mich freuen wenn jemand entsprechend eine Quelle im Internet dazu zitiert, konnte selbst nichts finden.

Hm, ok, sonst teste ich das halt mal in 'ner VM 😉

Gruß,
sensorpixel