Suche Linux und OS X kompatibles Dateisystem

[abgemeldeter Benutzer]

problematisch wird es dann - platt gesagt und wenn ich dich richtig verstanden habe - bei daten, die in irgendeiner form von OS X "selber" verwaltet werden oder aber auch bei anwendungsdaten, die die features des OS-X FS benutzen... wa?

So in etwa.

sehe ich das richtig, dass ich beim einsatz von gnu/darwin keine problem mit der rsync/ssh-Sicherung von Linux-Clients zu erwarten habe?

Umgekehrt gibt es natürlich keine Probleme. Denn das, was flache Dateisysteme können, das kann das Mac-Dateisystem sowieso. (Eine Ausnahme: Den Doppelpunkt in Dateinamen mag HFS nicht, das ist das einzige verbotene Zeichen.)

 

[ratti]

sehe ich das richtig, dass ich beim einsatz von gnu/darwin keine problem mit der rsync/ssh-Sicherung von Linux-Clients zu erwarten habe?

Leider falsch.

Mac OS verwendet als Filesystem HFS+, und das ist in der Lage, zwei "Streams" pro Datei zu speichern. Diese Streams heissen Ressource-Fork und Data-Fork.

Das, was du von "normalen" Dateisystemen kennst, ist unter HFS+ die Data-Fork. Wenn ein Programm die Ressource-Fork benutzt, und diese Datei wird auf ein anderes Filesystem verschoben, geht diese Fork verloren.

Die Wirkung ist unterschiedlich: Ein EPS-Bild aus einem alten Illustrator verliert "nur" seine Voransicht. Eine klassische Schriftendatei wird völlig zerstört. Eine HTML-Datei übersteht das völlig unbeschadet.

Es kommt also auf die Inhalte an, welche Dateitypen du hast.

Übrigens ruiniert rsync Dateien mit Ressourcefork sowieso, ob nun mit ohne ohne HFS+. Es gibt im Web eine freie Version namens rsyncX, welche das eingebaute rsync ersetzt und dann auch mit Forks umgehen kann. Das ändert aber nichts daran, daß die Ressourcefork beim kopieren auf sagenwirmal ext3 oder fat weg muß, weil diese FS nur eine Fork beherrschen.

Der Mac löst dieses Problem, indem er die Ressourcefork absplittet und sie in einer zweiten Datei versteckt. Es existieren dann auf flachen Filesystemen zwei Dateien:

datei.eps
._datei.eps

Die "._"-Datei enthält die Ressource.

Ich verwende rsyncX zum sync'en zwischen zwei hfs+-Systemen. Wie es sich bei hfs+ nach "flach" verhält, weiss ich nicht.

Gruß, Ratti


Nachtrag: Oder meinstest du, du sicherst Daten von einem flachen FS auf HFS+? Ne, dann keine Probleme.

 

[NicolasX]

P.S. Ich bezog mich in erster Linie auf die Aussage "ein gecraschtes OS-X system ggf. restaurieren" (was mit Daten, die auf einem flachen Dateisystem gespeichert wurden niemals klappen wird, aber auch kaum nötig sein wird).
Bei den Apache Daten dürfte das kein großes Problem sein.

Da das System aber als Disk Image vorliegt und dann auf den Server kopiert wird ist das aber nicht der Fall

Gruß

Nicolas

 

[abgemeldeter Benutzer]

@ ratti
Ich glaube, "Sicherung von Linux-Cilents" heißt, der Inhalt der Festplatten der Linux-Clients wird auf den Darwin-Server gesichert. Das ist kein Problem.

@ NicolasX
*Wenn*, nicht *Da*.
DMG-Images möchte catvarlog aber nicht benutzten, wenn ich Post#50 recht verstanden habe.

 

[catvarlog]

Mac OS verwendet als Filesystem HFS+, und das ist in der Lage, zwei "Streams" pro Datei zu speichern. Diese Streams heissen Ressource-Fork und Data-Fork.

ohja.. ich erinner mich ganz dunkel an mein altes g3-powebook (das schwarze) mit mac os 8.x . da gab damals ständig probleme beim datenaustausch... dunkel erinnere ich mich auch ein dateien, die in irgendeiner x-beliebigen anwendungen gestartet wurden, wenn die meta-information im eimer waren... grusel... die zeiten sind aber wohl vorbei, oder?

Nachtrag: Oder meinstest du, du sicherst Daten von einem flachen FS auf HFS+? Ne, dann keine Probleme.

ja genau. ich würde nur von ext3 nach hfs+ oder von hfs+ nach hfs+ sichern.

mir ist nur wichtig, dass ich zum mounten der hfs+-platten nicht zwingend auf apple-hardware angewiesen bin. das scheint gnu/darwin zu ermöglichen.

fazit: ich hätte gerne eine raid 5 lösung, mit der ich sowohl mac als auch linux sichern kann.

und da scheint im moment nur ein hfs+-dateisystem mit osx/darwin-server in frage zu kommen. es sei denn, ich sichere vom mac ausschließlich daten, die auch auf flachen fs existieren können bzw. muss ich die mac-daten in ein image verpacken, wenn ich auf einen ext-3 Linux-Server sichern möchte... right?

boah ist das kompliziert!

 

[catvarlog]

@ ratti
Ich glaube, "Sicherung von Linux-Cilents" heißt, der Inhalt der Festplatten der Linux-Clients wird auf den Darwin-Server gesichert. Das ist kein Problem.

@ NicolasX
*Wenn*, nicht *Da*.
DMG-Images möchte catvarlog aber nicht benutzten, wenn ich Post#50 recht verstanden habe.

ja, sichern der clients heißt z.B.

rsync -avz -e ssh server1:/var/www /mnt/backup/server/var/
rsync -avz -e ssh client1:/home /mnt/backup/client/

oder so ähnlich....

ja, DMG-Images möchte ich eigentlich nicht nutzen. das ist mir zu "closed". für das system wäre es OK. aber nicht für daten wie z.B. quelltexte, layouts, ooo-dateien etc. .

 

[NicolasX]

Wenn die Dateien vom Mac aus auf den Server geschrieben werden ist alles OK.

Wenn du dir den Ordner/Share im Server unter Linux oder von nem Win Client ansiehst, sind dort 2 Dateien das ist war. Vom Mac aus betrachtet allerdings nur eine.

Die SUN mit Gentoo läuft seit über 8 Monaten ohne Probleme, KEIN Datenmüll oder was in der Art ob Illustrator, Photoshop, EPS-DCS oder Quark. Wichtig ist nur, daß sich die Mac User an die Naming-Standarts halten (keine Leerzeichen, komische Sonderzeichen und so). Du solltest lediglich für jeden Rechner nen eigenen System und Daten Share/Ordner anlegen damit keiner von den Win/Linux Clients die Mac Daten schießen kann, aber das ist ja klar denk ich.

Das System vom Mac also als DI sichern und die Dokumente ganz normal.
Da du das DI mounten kannst, verhält es sich wie gesagt wie ne Platte ergo, kannst du auch Teile daraus zurücksichern. Das DI Mounten kann allerdings nur der Mac.

Es gibts Löungen die sehr teuer sind und nix anderes machen, da wären:
Helios EtherShare, PCShare die übrigens beide auf OSX, Solaris, Linux oder Irix aufsetzen. Für kleinere, gemischte Netze tuts auch die normale Single User von OSX, wenn du ein GUI für die Shares brauchst kannst du SharePoints installieren was echt ein top Utility ist.

Auf die SUN 450 greifen 15 Macs, 4PC's und 2 Andere Server zu wie gesagt, wenn es da Probleme gäbe, würde das Dingens nicht mehr laufen

Konfig:
SUN Enterprise 450 + JMR Fortra Fibre 2TB Hardware RAID5
Das Ganze wird auf ein weiteres (langasameres) RAID5 gesichert.

Die eleganteste Lösung für Macs ist halt X Server mit Netboot und so hab damit zwar keine Erfahrung (wir hatten mal testweise OSX Server 1.2 laufen, daß noch voll NeXT like war)

Gruß

Nicolas

 

[ratti]

Wichtig ist nur, daß sich die Mac User an die Naming-Standarts halten (keine Leerzeichen, komische Sonderzeichen und so).

Mac-User können das nicht. Wenn sie 5 Minuten lang keinen Dateinamen mit Umlaut angelegt haben, kriegen sie Zuckungen im Genick und schlagen solange mit der Stirn auf die Ä-Taste, bis der Linux-Server seinen Kernel zusammenfaltet und auswandert. ))))

Gruß,
Ratti

 

[ratti]

Moin,

ja genau. ich würde nur von ext3 nach hfs+ oder von hfs+ nach hfs+ sichern.

Ersteres: Kein Problem.

Letzteres... kann ich so gar nicht sagen, würde ich unbedingt testen, und unbedingt rsyncX dafür verwenden.

Zum Testen brauchst du eine Datei mit Ressourcefork. Hmm... mir fällt gerade gar keine ein. Ich würde einfach einen unserer klassischen PostScript-Fonts nehmen, aber ich glaube, in OS X sind gar keine mehr dabei... Ach, einfach einen Freefont aus dem Web laden. Postscriptfonts bestehen immer aus einem Koffer und einer PS-Datei, ungefähr so:

Schrift.bmap
SchriBolIta

(Letzteres ist kein Tipfehler. Name gekürzt auf 5 Zeichen plus Bold plus Italic, jeweils gekürzt auf drei Zeichen, und niemals eine Extension)

Wenn du sowas auf deinen Server gesynct kriegst, sollte dort in der Shell folgendes auftauchen:

Schrift.bmap
SchriBolIta
._SchrioBolIta
(evtl. auch noch "._Schrift.bmap")

...vom Mac aus gesehen aber nur die zwei Origionaldateien.

Wenn das beim Zurückkopieren auf den Mac wieder eine laufende Fontdatei ergibt, dann klappt alles. Erhältst du stattdessen ein 0-Byte-Datei: Möööööp, Totalschaden.

Gruß, Ratti

 

[catvarlog]

vielen, vielen dank für eure unterstützung!

ich werde jetzt beim bisherigen debian-server bleiben und die linux-clients dort wie bisher auf ext3 sichern.

für den vorerst einzigen mac wird es eine externe 160GB firewire-platte geben, auf die mindestens ein komplettes images der festplatte (80GB) passt. resource-fork-freie daten will ich per rsync auf den debian-server sichern (also z.B. psd-dateien, quelltexte)

melde mich, sobald der mac da ist und ich erfahrungen gesammelt habe. gnu/darwin werde ich mir mal in einer ruhigen minute ansehen...

cheers, cat

 

[NicolasX]

Mac-User können das nicht. Wenn sie 5 Minuten lang keinen Dateinamen mit Umlaut angelegt haben, kriegen sie Zuckungen im Genick und schlagen solange mit der Stirn auf die Ä-Taste, bis der Linux-Server seinen Kernel zusammenfaltet und auswandert. ))))

Gruß,
Ratti

Ja, denen das Auszutreiben war hart
Lief dann aber mit Hilfe einer "Bad Naming" Kasse (1 Euro pro Verstoß)

Gruß

Nicolas

 

[NicolasX]

Wenn das beim Zurückkopieren auf den Mac wieder eine laufende Fontdatei ergibt, dann klappt alles. Erhältst du stattdessen ein 0-Byte-Datei: Möööööp, Totalschaden.

Also, hab nen PS Zeichensatz (Ganzer Ordner) vom Mac auf den Server gelegt, dann zurückkopiert und zugewiesen, ging ohne Probleme.

Mit rsync gings nicht, erst als ich die Dateien als .sit gepackt hab lief es ohne Probleme.

Gruß

Nicolas

 

[abgemeldeter Benutzer]

Stuffit-Archive sind nach außen ja auch flache Dateien, die ohne weitere Metainformationen auskommen. Drinnen gibt es aber einen Resourcen-Zweig und die Metainformationen werden auch gespeichert und beim Auspacken auch in das Dateisystem geschrieben.

 

[NicolasX]

Stuffit-Archive sind nach außen ja auch flache Dateien, die ohne weitere Metainformationen auskommen. Drinnen gibt es aber einen Resourcen-Zweig und die Metainformationen werden auch gespeichert und beim Auspacken auch in das Dateisystem geschrieben.

Darum gehts ja gar nicht, der springende Punkt ist doch das es funktioniert wenn die Daten vom Mac auf den Server und zurück geschrieben werden und mit rsync klappts nicht.

Gruß

Nicolas

 

[abgemeldeter Benutzer]

Wenn Du alles vorher schön in sit-Dateien packst (oder ZIP-Archive aus dem Finder oder Images) dann geht es auch mit rsync.

 

[NicolasX]

Wenn Du alles vorher schön in sit-Dateien packst (oder ZIP-Archive aus dem Finder oder Images) dann geht es auch mit rsync.

Genau das soll ja umgangen werden.

Die einzige Lösung die mir eingefallen ist, wenn man ein scrpt auf dem Mac schreibt, das alle Dateien auf den Server legt.

Denn:

1. Kopiert man Dateien vom Mac auf den Server (XFS) oder zurück sind diese OK.

2. Bei verwendung von .zip, .sit oder .tar funktioniert rsync

3. Wenn ich von dem Ordner/Share eine Kopie auf ein anderes RAID (XFS) erstelle, sind die Dateien ebenfalls OK.

Also liegt es anscheinend nur an rsync.

Gruß

Nicolas

 

[abgemeldeter Benutzer]

Nein, es liegt nicht an rsync.
Es liegt daran, dass die Shell nicht für Mac OS X programmiert wurde und deshalb keinen Resoucenzweig und keine Metadaten kennt. Deshalb können alle normalen Shell-Tools nicht mit diesen umgehen.

Nur, wenn die Daten über die GUI von Mac OS X oder über ein speziell angepasstes Shell-Tools (z.B. cpMac statt cp) kopiert wird, werden die Resourcen und die Metadaten auch mitbewegt. Sie werden in die ._-Dateien bewegt und als zweite Datei mit kopiert. (Das war Dein Punkt 1.)

Da die Resourcen und Metadaten in den ._-Dateien gespeichert werden, ist es auch logisch, dass ein Duplikat des Ordners auf dem flachen Dateisystem auch wiederum die Resourcen und Metadaten enthält. Wenn Du aber nur die eigentlichen Dateien kopierst (also nicht die unsichtbaren ._-Dateien), gehen diese verloren. (Dein Punkt 3.)

Zip funktioniert nur, wenn die ZIP-Datei im Finder angelegt wurde, denn dieser benutzt eine ähnliche Methode, wie bei der Dateikopie auf ein flaches Dateisystem, um die Resourcen und Metadaten innerhalb der ZIP-Datei zu sichern (der __MACOSX-Ordner. Normale ZIP-Archive (also mit anderen Programmen oder über die Shell erstellt) enthalten nur den Datenzweig, die Metadaten und die Resourcen gehen beim Erstellen des Archives verloren, desgleichen bei .tar. (Zu .sit hatte ich ja schon was geschrieben.) (Punkt 2.)

Trotz der Tatsache, dass Mac OS X in der Lage ist, die Resourcen und Metadaten auf flachen Dateisysteme zu bewahren (nämlich in den ._-Dateien) ist es nicht ratsam ein Back-Up von Mac OS X auf einem flachen Dateisystem zu machen, denn dabei gehen auch die Volume-Informationen verloren, ohne die die vollständige Rekonstruktion eines Mac OS X kaum möglich ist.

 

[NicolasX]

._ut,

Danke, das macht die Sache klar.

In dem "SUN FALL" fungiert der Server ja nur als so ne Art externe Netzwerk-Festplatte sprich, Jeder User hat sein eigenen Ordner/share in dem er seine daten ablegt. Da diese Vorgänge nur über den Finder stattfinden, gibt es da auf keinerlei Probleme.

Die System Backups sind als komprimiertes Image auf dem Server abgelegt, so das es hier auch keine Probleme gibt und stehts ein "Stable Backup" vorhanden ist falls einer der Rechner mal ausfallen sollte.

Great Info, much appreciated!

Danke

Nicolas

 

[ratti]

Mit rsync gings nicht,

Sag ich doch. Posting 62.

Du brauchst rsyncX, das kann beide Forks verwalten.

Ich weiss nicht, ob du mit rsyncX nur hfs+-auf-hfs+ kopieren kannst oder auch hfs+-auf-$ANY, aber du hast auf jeden Fall eine Chance, also ausprobieren. Das normale rsync war von Anfang an chancenlos.

Hint: rsyncx schmeisst das rsync-Binary aus dem System raus und ersetzt es durch seine eigene Version. Also nicht verwirren lassen.

http://archive.macosxlabs.org/rsyncx/rsyncx.html

rsyncx ist übrigens nur eine gepatchte Version von rsyncx. Für Weichlinge ist sogar eine GUI dabei.

Gruß,
Ratti

 

[NicolasX]

Sag ich doch. Posting 62.

Du brauchst rsyncX, das kann beide Forks verwalten.

Ich weiss nicht, ob du mit rsyncX nur hfs+-auf-hfs+ kopieren kannst oder auch hfs+-auf-$ANY, aber du hast auf jeden Fall eine Chance, also ausprobieren. Das normale rsync war von Anfang an chancenlos.

Hint: rsyncx schmeisst das rsync-Binary aus dem System raus und ersetzt es durch seine eigene Version. Also nicht verwirren lassen.

http://archive.macosxlabs.org/rsyncx/rsyncx.html

rsyncx ist übrigens nur eine gepatchte Version von rsyncx. Für Weichlinge ist sogar eine GUI dabei.

Hi,

wollte es nur mal ausprobieren, benötige es sowieso nicht.

Danke für den Hint mit rsyncx ich werds morgen mal probieren und posten ob das mit HFS+ > XFS funktioniert.

BTW wer braucht schon n GUI

Danke nochmal

Nicolas