Timer

E

EchoMac

Aktives Mitglied
Thread Starter
Dabei seit
12.11.2004
Beiträge
349
Reaktionspunkte
-2
Hello Leute,

also in diesem Bereich bin ich eine Leihe!
Sagt mir bitte wie ich dieses Backup script Jeden Tag um die Selbe Zeit laufen lassen kann??

time sudo rsync -a -e ssh "/Library/FTPServer/FTPRoot" /Volumes/ftp_spiegel/FTP_Backup --showtogo

Jetzt zieh ich das Script bzw. die Datei jeden morgen am terminal und führe es manuell aus!!

lg
 
Als cronjob laufen lassen. "man cron" ist dein Freund.
 
wo als cronjob laufen lassen?? Wie mach ich das ??
Mit einem tool oder soll ich in das script was hinzufügen?!
 
EchoMac schrieb:
wo als cronjob laufen lassen?? Wie mach ich das ??
Mit einem tool oder soll ich in das script was hinzufügen?!

Habe doch geschrieben. Du sollst "man cron" im Terminal eingeben und lesen. Da steht alles drin, was du wissen musst. Oder auch mal "man crontab".
 
Oder du gibst auf die Schnelle ein:

sudo crontab -e

0 20 * * * /usr/bin/rsync -a -e /usr/bin/ssh "/Library/FTPServer/FTPRoot" /Volumes/ftp_spiegel/FTP_Backup --showtogo
[ESC]
:wq
[ENTER]

Das führt dein "Script" jeden Tag um 20.00 Uhr aus.

Die Sachen in den Eckigen Klammern bedeuten einfach, dass du die jeweilige Taste drücken musst.

Beachte, dass du im Cronjob bei allen Befehlen den vollen Pfad angeben musst (das habe ich im Beispiel bereits gemacht) -- /usr/bin/rsync muss ev. durch /usr/local/bin/rsync ersetzt werden, je nach Paket.

Edit:
Noch einfacher wäre es, den langen Befehl oben in ein Script schreiben und dieses mit chmod +x ausführbar machen. Ausserdem lässt man (als Tipp) Backup- und andere wichtige Cronjobs mit Vorteil protokollieren, um besser überprüfen zu können, ob sie ordnungsgemäss funktionieren. Ich mache das so, dass ich Anfangs- und Endzeit des Vorgangs in einer Datei aufzeichnen und zusätzlich ein vollständiges Protokoll von rsync anlegen lasse.
 
Zuletzt bearbeitet:
Mal ne (oder zwei) Frage am Rande.
Code:
/usr/bin/rsync -a -e /usr/bin/ssh "/Library/FTPServer/FTPRoot" /Volumes/ftp_spiegel/FTP_Backup --showtogo
Wofür ssh, wenn sich alles auf der lokalen Maschine abspielt?
Was soll die Option --showtogo bewirken? Die gibts bei mir nicht.
Warum ist der erste Pfad mit " gequotet?
 
maceis schrieb:
Was soll die Option --showtogo bewirken? Die gibts bei mir nicht.
--showtogo bewirkt, dass angezeigt wird, wieviele Daten noch zu übertragen sind. Es sind allerdings (mindestens?) zwei Versionen von rsync im Umlauf, die sich interessanterweise recht wesentlich unterscheiden -- ich habe die von Apple sowie diejenige, welche mit rsyncX mitgeliefert wird, beide haben teilweise ganz andere Optionen oder diese müssen anders angegeben werden.

Die anderen beiden Sachen sind mir allerdings auch ein Rätsel...
 
@sheep
die Mac OS X Version, die er ja mit "/usr/bin/rsync" offensichtlich verwendet, kennt die option "showtogo" aber nicht.

Aber jetzt seh ich was: hfsrsync kennt die option showtogo auch - alles klar, danke.
hfsrync ist, glaube ich, identisch mit rsyncx, aber nur CLI.
 
maceis schrieb:
@sheep
die Mac OS X Version, die er ja mit "/usr/bin/rsync" offensichtlich verwendet, kennt die option "showtogo" aber nicht.
Das /usr/bin/rsync ist ja auch von mir (wegen absolutem Pfad für Cronjobs), ich war nicht sicher, welche Version jetzt welche ist, entschuldige, falls ich dich verwirrt haben sollte
smile15x18.gif
.

Lustig ist ja auch, dass mit der Installation von syncX (was ich sowieso nicht brauche, aber was man halt alles mal so installiert) dessen rsync-Version im $PATH landet und standardmässig benutzt wird -- hatte ich einen Ärger, bis ich herausgefunden habe, warum rsync auf einmal die Option -E für ResourceForks nicht mehr schlucken wollte...
 
sheep schrieb:
...
hatte ich einen Ärger, bis ich herausgefunden habe, warum rsync auf einmal die Option -E für ResourceForks nicht mehr schlucken wollte...
Wie, was?
Kann rsync auf einmal ressource forks?
Tatsache!
Prima, wusste ich noch gar nicht.
Für was so Thread alles gut ist ;).
 
maceis schrieb:
Wie, was?
Kann rsync auf einmal ressource forks?
Tatsache!
Prima, wusste ich noch gar nicht.
Für was so Thread alles gut ist ;).
Glücklicherweise ja
smile15x18.gif
. Ohne das würden Backups mit rsync ja keine richtige Freude machen -- es hat mich allerdings auch einige Zeit gekostet, das herauszufinden, weil ich von Linux komme und Resource Forks überhaupt nicht gekannt habe. Ich benutze rsync jetzt auch unter OS X wieder für das Spiegeln des kompletten Systems sowie für inkrementelle Backups des Home-Verezeichnisses, dank der Option -E funktioniert das wunderbar.
 
@sheep
ich hab in letzter Zeit immer tar benutzt, rsync ist aber fast komfortabler ;).

von EchoMac hört man gar nichts mehr.
Hast Du es jetzt hinbekommen?
 
maceis schrieb:
@sheep
ich hab in letzter Zeit immer tar benutzt, rsync ist aber fast komfortabler ;).
Muss bei tar nicht immer -- trotz möglicher Update-Option -- der ganze "Klumpen" übertragen werden? Ich glaube mich erinnern zu können, dass ich das unter Linux auch mal im Netzwerk versucht und beim Warten fast graue Haare bekommen habe.

Ausserdem empfinde ich die (standardmässig) fehlende Komprimierung gerade als Vorteil, weil man z.B. eine versehentlich gelöschte Datei blitzschnell wiederherstellen kann.

Aber eigentlich ist das ja OT, der Hilfesuchende hat sich wie du feststellst immer noch nicht gemeldet
yayaa21x28.gif
.
 
sheep schrieb:
Muss bei tar nicht immer -- trotz möglicher Update-Option -- der ganze "Klumpen" übertragen werden?
...
Nein, rsync ist aber beim Updaten trotzdem wesentlich schneller, dafür beim Erstellen deutlich langsamer.

Hab grade mal getestet und einen Ordner mit Bilder (~ 300MB) zuerst auf einem entfernten Rechner (über afp) erstellt (1:11 min) und dann upgedatet, ohne was zu ändern (0:36 min)

Mit rsync über ssh:
Erstellen: 2:31 min
Update: 0:10 min

Über afp ist rsync ziemlich schwach, weil es Schwierigkeiten mit -og hat - zumindest bei mir.
Ich bekomme immer jede Menge Fehler:
rsync: chgrp "/Volumes/maceis/ziel/Bild.JPG" failed: Operation not supported (45)

Geht das bei Dir?
 
maceis schrieb:
Nein, rsync ist aber beim Updaten trotzdem wesentlich schneller, dafür beim Erstellen deutlich langsamer.

Hab grade mal getestet und einen Ordner mit Bilder (~ 300MB) zuerst auf einem entfernten Rechner (über afp) erstellt (1:11 min) und dann upgedatet, ohne was zu ändern (0:36 min)

Mit rsync über ssh:
Erstellen: 2:31 min
Update: 0:10 min
Sehr interessant, danke für die ausführliche Erklärung
smile15x18.gif
. In dem Falle bin ich mit rsync also richtig bedient, weil ich ja immer nur update, wie lange das Erstellen dauert, ist eher unerheblich, das muss ja nur einmal gemacht werden.

maceis schrieb:
Über afp ist rsync ziemlich schwach, weil es Schwierigkeiten mit -og hat - zumindest bei mir.
Ich bekomme immer jede Menge Fehler:
rsync: chgrp "/Volumes/maceis/ziel/Bild.JPG" failed: Operation not supported (45)

Geht das bei Dir?
Kann ich leider nicht testen, da ich nur den einen Mac habe. Ich mache vom PB aus Backups eines Windows-Rechners mit rsync über Samba, da gehen die Berechtigungen ohnehin verloren -- Fehlermeldungen gibt es allerdings keine, obwohl da die Option -a, welche ich aus Gewohnheit verwende (enthält u.a. -og), ja teilweise auch ins Leere läuft. Vielleicht gibt es ein geeigneteres Protokoll, ich weiss gar nicht, ob AFP Permissions unterstützt, das gab es doch schon unter OS 9 (?). Ausserdem muss rsync natürlich mit root-Rechten ausgeführt werden, ansonsten funktioniert -og ohnehin nicht, aber ich nehme jetzt einfach mal an, dass du daran selber gedacht hast
zwink15x18.gif
.
 
sheep schrieb:
...
ich weiss gar nicht, ob AFP Permissions unterstützt, das gab es doch schon unter OS 9 (?).
...
Mit tar (und ditto) z. B. schon.
Unter OS 9 gabs ja auch schon Eigentümer und Gruppen.

An sudo hab ich natürlich gedacht ;).

rsync hat unter Tiger übrigens noch einen echten bug.
die Kombination -aE führt dazu, dass bei allen Dateien, die eine Ressourcefork enthalten, das Datum auf das Datum des Kopierens und nicht auf das Datum der Originaldatei gesetzt wird.
Ziemlich bescheiden.
Dafür kopiert es aber auch ACLs; das kann tar z. B. noch nicht.
 
Zurück
Oben Unten