Diskussion zu "Automatische Backups und Syncs unter OS X"

Hast du denn den rSync Patch schon eingespielt? Wenn nicht, dann lies diesen Thread nochmal durch ;)
 
also ich hab 10.4.4 drauf. mein Rsync hat 2.6.3

wo kann ich die neueste Version runterladen?

deine Version ist auch 2.6.3 gibt keine neuere?
 
Hey Leute!

Ich habe das exakt gleiche Problem wie Silence7 3-4 Posts weiter oben beschrieben. Ich habe mein rsync auch nicht gepatched, aber: es hat vorher immer einwandfrei funktioniert. Dann bekam ich diese Fehlermeldung, mit ich überhaupt nichts anfangen kann.

Mich würde interessieren, ob Jemand die Fehlermeldung deuten kann, bevor ich anfange rumzupatchen:
Code:
Command terminated abnormally.
      189.36 real         5.29 user        28.64 sys
rsync: writefd_unbuffered failed to write 85 bytes: phase "unknown" [receiver]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-20/rsync/io.c(909)

Edit: Entschuldigung! Ich habe gesehen, dass diese Fehlermeldung auch schon vor mir und Silence7 angesprochen wurde. Ich werde es dann einfach mal mit dem Patch probieren. Aber es wundert mich, dass es vorher definitv ging und auf einmal nicht mehr.
 
Silence7 schrieb:
also ich hab 10.4.4 drauf. mein Rsync hat 2.6.3

wo kann ich die neueste Version runterladen?

deine Version ist auch 2.6.3 gibt keine neuere?

Auf meiner Page gibt es das Tutorial zum Patchen. Es bleibt die gleiche Version, nur werden eben diese Fehler durch Patches beseitigt.
 
mactie schrieb:
Edit: Entschuldigung! Ich habe gesehen, dass diese Fehlermeldung auch schon vor mir und Silence7 angesprochen wurde. Ich werde es dann einfach mal mit dem Patch probieren. Aber es wundert mich, dass es vorher definitv ging und auf einmal nicht mehr.

Es schien ja bei einigen zu gehen. Durch das patchen machst du ja auch nicht deine Original rsync Version kaputt. Steht alles in der Anleitung drin. Du hast dann ein eigenes gepatchtes rsync in einem anderen Verzeichnis.
 
Hi,

ich habe eine Frage betreffend des 'time' Programms, dass ihr auch in euren skripten verwendet. Die man-page für 'time' unter 10.4.4 gibt für 'time' nur zwei Parameter an. In anderen man-pages im netz, konnte ich weit umfangreichere Parameterlisten finden, u.a. mit der Möglichkeit die Ausgaben von 'time' in einer Datei (Parameter -o file) zu speichern.
Der Befehl ... time rsync (...) > log.txt, schreibt auch nur die Ausgaben von rsync in die Datei, nicht aber die Ausgaben von 'time'.

Ich würde gerne die Ausgaben von time protokollieren.

Weiss von euch jemand Rat, ob man 'time' updaten kann ?

s.
 
Ich habe jetzt nach einem Backup mal das erste Mal in die Protokoll.log geschaut. Und was musste ich dort entdecken:

file has vanished: "/Users/Shared/Musik/Robbie Williams/Swing When You're Winning/._08 Mr. Bojangles.m4a"

Und davon hunderte Einträge, praktisch meine ganze Musik. Die Files selber sind aber vorhanden, sowohl am Originalort, als auch am Backuport. Das gesamte gesicherte Verzeichnis ist nur ca. 10 GB groß. Das kann doch nicht am "kauputten" rsync liegen?

Außerdem ist dort ja ein "." = Punkt vor dem Dateinamen. Aber das ist doch keine versteckte Datei, das Lied.

Was steht überhaupt alles in der protokoll.log? Fragen über Fragen... :rolleyes:
 
._dateiname steht für die Resourceforks.
Über das "verschwinden" brauchst Du dir keine Gedanken zu machen.
Die werden zum Kopieren gesplittet und am Ziel einfach wieder zusammengeführt.
 
Danke maceis!
Ich finde das Ganze Thema mit dem Backup ja sehr interessant und vor allem lehrreich, aber auch irgendwie "stressig". Na ja, schei.. Halbwissen, oder besser: fast gar kein Wissen... :D
 
uff

Vielen Dank an alle in diesem Thread für die Hinweise und Tips. Nachdem ich mir alles zusammengesucht habe, was ich für meine Bedürfnisse brauche, will ich das Ergebnis meines Backupskripts hier posten. Vielleicht nützt es jemandem oder vielleicht findet auch jemand noch einen gravierenden Fehler und teilt ihn mir mit.

Ziel: Backup des Userverzeichnisses von einem Powerbook, auf die FireWire-Platte eines iMacs im lokalen WLAN. Dabei sollen immer die letzen drei vollen Versionen des Userverzeichnisses als Backup vorhanden sein. Es soll täglich ein Backup durchgeführt werden. Das Skript läuft auf dem iMac.

Ich verwende dafür die rsync Version von RsyncX, installiert auf beiden Rechnern. (mit 10.4.4) (Die Option --eahfs muss bei der Tiger-Version von rsync durch -E ersetzt werden; --showtogo gibt es in der Tiger-Version nicht.)

Hier der Code:

Code:
#!/bin/bash
# Dieses Skript alle 15 minuten von launchd gestartet

# Firewireplatte gemountet ?
if [ -e /Volumes/Fire ]
then
	# Ins Backupverzeichnis wechseln.
	cd /Volumes/Fire/Backup/Powerbook/user

	# letztes Backupdatum mit aktuellem Datum vergleichen und bei > 1 Tag, Backup ausführen.
	bdatum=`less backupdatum`
	jdatum=`date +%y%m%d`

	if test $jdatum -gt $bdatum
	then
		# Überprüfen ob Powerbook im lokalen Netzwerk verfügbar ist.
		powerb=`ping -qn -c 1 192.168.1.4 | grep -c "1 packets received"`
		
		if test $powerb = 1 
		then
			# Backupordner anlegen
			mkdir Backup.0
			# Backup starten (hardlink auf vorheriges Backup, Archiv, Kompression, Quiet, HFS enabled, über SSH)
			/usr/local/bin/rsync --rsync-path=/usr/bin/rsync -azq --eahfs --exclude-from="excluded.txt" -e ssh --link-dest="/Volumes/Fire/Backup/Powerbook/user/Backup.1/" "user@192.168.1.4:/Users/user/" "/Volumes/Fire/Backup/Powerbook/user/Backup.0/"

			# Wenn Backup erfolgreich (komplett oder teilweise gesichert), dann akzeptieren und ältestes Backup löschen, ansonsten Backup verwerfen. Fehler 23 -> Dateien oft nicht kopiert wegen fehlender Rechte
			if test $? = 0 -o $? = 23
			then
				i=3
				while [ $i -ge 0 ]                                       
				do
  					mv -f Backup.$i Backup.$(($i+1))
  					i=$(($i-1))	
				done
				rm -rf Backup.4
				# Backupdatum sichern
				date +%y%m%d > backupdatum
				echo Backup erfolgreich abgeschlossen
			else
				rm -rf Backup.0
				echo Backup nicht erfolgreich
			fi
		fi
	fi
fi
 
Zuletzt bearbeitet:
hi smart

Bei deinem Vorschlag bezüglich Prüfung, ob Powerbook am Netzi ist, habe ich folgendes Problem:

Sofern ich das Skript per sudo aus einem Terminal starte, funktioniert die Prüfung gut. Sofern ich dies über cron mache, gehts nicht. Irgendwie will der Ping über corn nicht.

Hast du eine Idee, warum dies so ist?

Vielen Dank und Gruss
Tom
 
@ smart
Das hast du ganz toll gemacht :). Die Idee und Umsetzung für das Behalten mehrerer Versionen finde ich sehr sinnvoll! Wenn du erlaubst, werde ich das bald mal in die Anleitung einfügen, sodass auch diejenigen, die vielleicht nicht den ganzen Thread lesen, davon profitieren können!
 
Danke.

@Schmüdu

Keine Ahnung.

Wie ich mich erinnere, empfiehlt Apple ab Tiger nicht mehr cron, sondern den launchd zu benutzen. Mit dem GUI "Lingon" funktioniert das bestens, wie ich finde. Probier es doch mal damit.

Ich lasse mein Backupskript nicht als sudo laufen, sondern nur unter dem Nutzer, dessen Daten gesichert werden. Dabei konnte ich feststellen, dass einige Dateien wegen fehlender Rechte nicht kopiert werden (v.a. Einstellngsdateien aus ~/Library). Ist das normal, dass unter ~/Library Dateien sind, die root-Rechte brauchen ? Würde gerne auf den sudo verzichten wenn möglich.

s.
 
Habs rausgefunden:

Damit alle Commands in Cron laufen, muss ich zwingend den Pfad angeben, in welchem sich das jeweilige Command befindet wie beispielsweise:
/sbin/mount_afp
/sbin/umount
/usr/sbin/chown
usw.


ansonsten werden die Commands aus der Cron nicht richtig ausgeführt. Aus dem Terminal aber schon.

Mann, ich bin froh, habe heute den ganzen Tag gesucht...

Allen vielen Dank für eure Tips

Gruss
Tom
 
Also launchd und cron funktionieren unterschiedlich.
Mit launchd kann man nur dann verlässlich zu bestimmten Tagen/Uhrzeiten Jobs starten, wenn der Rechner nie schläft und nie ausgeschaltet wird.
Zum Starten in bestimmten Intervallen kann man launchd aber sehr gut einsetzen.

Was das Skript von smart angeht, würde ich vor der while Schleife i mit 2 initialisieren, dann kann man sich das rm sparen.
Ein rm -rf - noch dazu in einem Skript - *brrrr* ;).

Grundsätzlich empfinde ich auch bdatum=`cat backupdatum` als sauberer.
In diesem Fall mag das keinen Unterscheid machen, in einer anderen Situation sehr wohl.

Ansonsten: schöne Sache.
 
na immerhin kein: sudo rm -rf ... aber man sollte sich schon nicht beim ordner irren ... ;)

was i=2 und ohne rm betrifft: Das klappt so nicht. Wenn Ordner Backup.3 besteht, wird mit "mv -f Backup.2 Backup.3" Backup.2 in den Ordner Backup.3 verschoben und nicht umbenannt.

Irgendwo muss also ein rm kommen, sonst ist die Platte voll.
 
Ach so - jetzt blick erst, dass das Ordner sind *g*
Ich leg meine Backups immer in ein tar file.
Da hab ich dann das Problem nicht und spare auch noch Platz ;)
Naja: TMTOWTDI
 
maceis schrieb:
Also launchd und cron funktionieren unterschiedlich.
Mit launchd kann man nur dann verlässlich zu bestimmten Tagen/Uhrzeiten Jobs starten, wenn der Rechner nie schläft und nie ausgeschaltet wird.
Zum Starten in bestimmten Intervallen kann man launchd aber sehr gut einsetzen.

Tatsächlich ?
Ich war immer der Meinung, dass im Ruhezustand (und auch wenn der Rechner ausgeschaltet ist :) ) cron-jobs nicht ausgeführt werden. Wie bei launchd auch.

Der Vorteil von launchd sind eben die Intervalle. Wenn ein Run verpasst wurde, weil der Rechner im Ruhezustand war (und die Zeit im Ruhezustand war wird mitgezählt), wird der Job einmal ausgeführt sobald der Rechner wieder wach ist.
 
Bei launchd ist es so, dass ein Job der täglich um 8:00 eingestellt ist nur dann täglich um 8:00 läuft, wenn der Rechner nie im Ruhezustand ist.
Wenn der Rechner z.B. von 6:00 bis 7:00 schlaft, läuft der Job erst um 9:00.

Wenn der Rechner von 7:30 bis 9:30 schläft, wird der Job nachgeholt, und zwar um 10:00, aber da fängt es schon langsam an kompliziert zu werden.
Noch konfuser wird es, wenn der Rechner dann um 9:55 neu gestartet wird, dann wird nämlich der 8:00 Job nicht mehr nachgeholt.

Bei einem wöchentlichen Job, sagen wir mal jeden Freitag um 12:00, würde ein tägliches Schlafen von 6h dazu führen, dass der Job (angenommen der Rechner wird am ersten Freitag um 12:01 gebootet) dazu führen, dass der erste Job am übernächsten Montag um 18:00 ausgeführt werden würde, ...

Weiter möchte ich gar nicht darüber nachdenken und auch nicht darüber, was passiert, wenn man zwischendurch mal bootet. Da brummt mir nämlich bald der Schädel.
Ist jedenfalls nicht das was ich mir unter "StartCalendarInterval" vorstelle.

Die Zeit im Ruhezustand wird nämlich eben *nicht* mitgezählt.
Das ist wie eine Uhr, die stillsteht, wenn der Rechner schäft und neu gestellt wird, wenn der Rechner bootet.
 
Das ist aber sehr dubios. Hast du diese Erfahrungen gemacht ?

in der man-page von launchd.plist steht:

StartCalendarInterval <dictionary of integers>
This optional key causes the job to be started every calendar interval as
specified. Missing arguments are considered to be wildcard. The semantics
are much like crontab(5). Unlike cron which skips job invocations when
the computer is asleep, launchd will start the job the next time the computer
wakes up. If multiple intervals transpire before the computer is
woken, those events will be coalesced into one event upon wake from
sleep.

Das stimmt irgendwie so gar nicht überein ...
 
Zurück
Oben Unten