Thread zur Backup-FAQ

[martinibook]

Was die machen ist mir grob klar, aber die werden jedes Mal kopiert, dabei hat sich doch nichts verändert

 

[maceis]

...
Einfach ignorieren und gut isses, im Mac OS siehst Du die ueblicherweise einfach nicht, da Dateien, die mit . beginnnen in Unixen versteckte Dateien sind.

Aussage richtig, Begründung falsch. Die Metainformationen stecken auf HFS+ im Resource Zweig der Datei. Die Double Files werden erst erzeugt, wenn die Dateien auf Dateisysteme kopiert werden, die Resourceforks nicht unterstützen.
Beweis: Terminal

 

[martinibook]

Aber warum kopiert rsync diese Dateien von HFS auf HFS jede mal neu, obwohl sich da nix verändert hat?

 

[Wile E.]

Aussage richtig, Begründung falsch.

Finde ich nicht falsch, in OS X sehe ich die .-Dateien erst mal nicht, weil sie nicht angezeigt werden, obwohl sie z.B. auf meinem FAT-formatierten Stick durchaus vorhanden sind. Aber brauchen wir nicht zu vertiefen, da OT.

...Aber ich meine, genau dieses Thema mit den ._-Dateien kam hier auch schon mal in dem Thread, evtl. mal durchsuchen.

Wile

 

[fabigraphy]

Löschen, wenn das jetzt zu sehr nach Crosspost aussieht, mir gehts eher darum, dass dieser Thread noch aktueller und auch der Richtige zu sein scheint, da meine Frage sich ja auf das Script, nicht auf das Tutorial bezieht.

Ich habe eine Frage zu den inkrementellen Backups: Was ist mit "Versionen" gemeint, die man im Script neben Quelle und Ziel noch einstellen soll?

 

[martinibook]

Ich glaube, das ist die Anzahl der Schritte, die du zurück gehen möchtest. Also 7 würde bei täglichen Backups bedeuten, dass du die letzte Woche aufgelöst hast.

 

[fabigraphy]

Okay, danke, das hatte sich im anderen Thread schon geklärt.

Hier meine nächste Frage:
https://www.macuser.de/threads/diskussion-zu-automatische-backups-und-syncs-unter-os-x.153983/page-14

 

[JMG]

Hi,

mal eine Frage: kann mir jemand erklären wie ich meine Datensicherung in fortlaufend neuen Ordnern (z.B. "Datensicherung_16.01.2011" etc.) einstellen kann? Also so, dass immer ein neuer Zielordner erstellt wird, ähnlich der Datensicherung von Time Machine? Kennt wer den Code, den ich vielleicht noch in mein backup script einfügen kann?

Der Code für die Sicherung eines Verzeichnisses per Terminal läuft bereits bestens, aber ich sichere so halt alles nur in einem Ordner, der immer wieder mit der aktuellsten Version überspeichert wird. Brauche eben eine Kopie von einem bestimmten Ordner zu jedem Tag und ich will das nicht täglich manuell ausführen...

Wäre cool, wenn mir da jemand auf die Sprünge helfen könnte!

Danke!

 

[magheinz]

Finde ich nicht falsch, in OS X sehe ich die .-Dateien erst mal nicht, weil sie nicht angezeigt werden, obwohl sie z.B. auf meinem FAT-formatierten Stick durchaus vorhanden sind. Aber brauchen wir nicht zu vertiefen, da OT.

ohne zu vertiefen: .$DATEINAME sind versteckte dateien und werden unter unix/linux standardmässig nicht angezeigt.
teste mal den unterschied zwischen
ls -l
und
ls -la

im terminal in einem Verzeichnis in dem du sicher weist da solche Dateien vorhanden sind. (im zweifel einfach eine mit touch .test anlegen)

 

[magheinz]

Hi,

mal eine Frage: kann mir jemand erklären wie ich meine Datensicherung in fortlaufend neuen Ordnern (z.B. "Datensicherung_16.01.2011" etc.) einstellen kann? Also so, dass immer ein neuer Zielordner erstellt wird, ähnlich der Datensicherung von Time Machine? Kennt wer den Code, den ich vielleicht noch in mein backup script einfügen kann?

Einfach das Zielverzeichnis um den entsprechen Verzeichnisnamen erweitern
Das Kommande "date" gibt dir das datum.
In "man date" steht auch wie man das formatiert ausgibt.
Ich würde aber die Verzeichnisse einfach durchummerieren und per hardlink rotieren. Das spart ungemein Platz da somit eine inkrementelle Speicherung erfolgt.
Kopieren per hardlink geht mit "cp -al"

 

[maceis]

Kopieren per hardlink geht mit "cp -al"

Hast Du das mal ausprobiert?

 

[magheinz]

Hast Du das mal ausprobiert?

nicht unter osx.
unter linux und solaris klappt das hervorragend.
hab grad mal in die manpage von osx reingeschaut: apple hat mal wieder was kaputt gemacht.
also den tipp bitte ignorieren oder das backup auf einem anständigen os machen...

 

[JMG]

ok... dann danke für den versuch, aber geht das trotzdem irgendwie in osx?

 

[maceis]

... oder das backup auf einem anständigen os machen...

... oder auf Gnu-ismen verzichten und einfach das richtige Werkzeug benutzen.
Es muss nicht jedes Werkzeug alles können.

aber geht das trotzdem irgendwie in osx?

magheinzens Unkenrufen zum Trotz geht das natürlich in OS X und zwar mit rsync und dem Schalter "--link-dest"
Details findest Du in dem manpage

 

[magheinz]

... oder auf Gnu-ismen verzichten und einfach das richtige Werkzeug benutzen.
Es muss nicht jedes Werkzeug alles können.

dann solltest du direkt ln nehmen.
keine ahnung ob rsync das so auf allen plattformen unterstützt.
in gnuimus ist das übrigens nicht, oder verwendet solaris das gnu-cp?

magheinzens Unkenrufen zum Trotz geht das natürlich in OS X und zwar mit rsync und dem Schalter "--link-dest"
Details findest Du in dem manpage

typisch macjünger, äh, macuser.
kaum sagt man mal was gegen eine spezialität von apple, hier das kleine programm "cp", schon hat man behauptet irgendwas würde mit osx grundsätzlich nicht funktionieren.
lies mein posting am besten noch mal.
im übrigen hier dann also der algorithmus.

wenn  dir $BACKUP/daily.0
    dann rsync --link-dest $BACKUP/daily.0 $BACKUP/daily.1
rsync $DATA  $BACKUP/daily.0

statt daily.X kannst du natürlich auch andere namen, z.b. das datum nehmen.
das ganze jetzt noch in eine schleife und eventuell nur ein paar backupstände aufheben oder bei plattenfüllung von X% den letzten backupstand löschen.
fertig ist timemachine

 

[maceis]

typisch macjünger, äh, macuser.
kaum sagt man mal was gegen eine spezialität von apple, hier das kleine programm "cp", schon hat man behauptet irgendwas würde mit osx grundsätzlich nicht funktionieren.

Jetzt komm mal wieder runter. Du hast doch behauptet, Apple hätte cp kaputt gemacht.
Das ist übrigens keine Spezialität von Apple sondern uneingeschränkt SuSv3 konform.

 

[ls172212]

inkrementelle Backups, Problem mit Leerzeichen in Datei- und Pfadnamen

Das cpio-Kommando im Skript für die inkrementellen Backups kann (in dieser Form) nicht mit Leerzeichen in Datei- oder Pfadnamen umgehen. In der Folge wird dieses Kommando abgebrochen und immer ein vollständiges Backup erzeugt. (HW: Imac Intel Core I5, OS: Snow Leopard)

Kennt jemand eine Lösung für diese Problem?

 

[maceis]

Wäre schön, wenn Du die konkrete Skriptzeile hier posten würdest.
Dann muss man sich das nicht selbst zusammensuchen.

Schuß ins Blaue: Variablen nicht in Anführungszeichen.

 

[ls172212]

Sorry:

Die Zeile stammt aus dem Script im Beitrag "UPDATE: Inkrementelle Backups" von Sheep, Mai 2006, im Thread "Automatische Backups und Syncs unter OS X".


cd $b/backup.$c && find . -print | cpio -dpl ../backup.$d

Sie legt wohl die Links an, die dann nicht mehr synchronisiert werden müssen. Wie auch immer, find findet Dateien die Leerzeichen enthalten, cpio kann aber damit nichts anfangen, auch dann nicht, wenn man bei find die Option -print0 und xargs verwendet, wie z.B:

find . -print0 | xargs -0 -n 1| cpio -pdl ../backup.$c

 

[maceis]

find findet Dateien die Leerzeichen enthalten, cpio kann aber damit nichts anfangen

Nein, das ist nicht richtig.
Lässt sich durch einen kurzen Test leicht nachvollziehen:

ls -l
total 16
drwxr-xr-x  2 maceis  staff  68 24 Mai 20:48 dest
-rw-r--r--  1 maceis  staff   6 24 Mai 20:44 file 1
-rw-r--r--  1 maceis  staff  24 24 Mai 20:44 file2

find . -iname file\* | cpio -pl dest
0 blocks

ls -l dest
total 16
-rw-r--r--  2 maceis  staff   6 24 Mai 20:44 file 1
-rw-r--r--  2 maceis  staff  24 24 Mai 20:44 file2

Dein Problem muss also eine andere Ursache haben.

Abgesehen davon.
Welchen Hintergrund die cpio geschichte hat, habe ich jetzt nicht nachvollzogen.
Hardlinks von nicht geänderten Dateien anlegen kann rsync jedenfalls selbst.
Schau Dir mal den Schalter --link-dest an.