Hallo zusammen,

wenn man zur Zeit einen neuen Macserver für 10-15 Leute braucht was soll man den da als Rechner nehmen (Eigentlich nur Filesharing).
Ein iMac kann es ja wohl nicht sein, der neue MacPro als extremer Rechenknecht auch nicht und ein Mini... muß erstmal extern mit Raids erweitert werden.

Also auf die Suche gehen nach einem gebrauchten MacPro? Einen Hackinotosh basteln??? Gar einen PC mit welchem Betriebssystem fürs Filesharing? Oder ein NAS und wenn ja welches kann gut mit Spotlight umgehen?

Wichtig ist das er gut läuft und Spotlighttauglich sein muß. Optimal wäre natürlich wenn das System "Dau-tauglich" ist und man jemand ggf vor Ort im Falle eines Falles per Telephon instruieren kann

Jeder neue Entwicklung birgt neue Gefahren, keine Frage.

Wäre dies mit der oben in der oben mit nachdrücklichen Worte beschriebenen Härte korrekt, dann müssten wir heute alle einen Mercedes 190D mit 60 PS fahren, denn der hielt/hält ewig. Die Realität auf den Straßen ist aber eine andere, oder!?

Tausende Euro in ein Thunderbolt-Raid-System zu stecken ohne Ersatz daneben in Bereitschaft stehen zu haben bringt auch keine wirkliche Sicherheit, was ist wenn dort ein Firmware-Bug oder Hardwaregebrechen auftritt?

Richtig.
Alles was Du Dir nur einmal hinstellst wird irgendwann kaputt gehen, und das System bleibt so lange stehen bis Du Ersatz beschafft hast.
Mal ganz von der Entwicklung abgesehen, dass man identische Geräte nicht mehr bekommt.
Bzw. bei RAIDs unterschiedliche Controller verbaut werden, so dass Du nicht einmal die Platten dann umstecken kannst.

Aber das ist alles nicht wichtig, wenn Du sagst, dass der Zeitausfall des Systems irrelevant ist.
Auch wenn ich keine Firma kenne bei der es so sein könnte. Alleine die Personalkosten fressen meistens an einem Tag mehr Geld auf, als ein Notfallsystem.

Weil das Umstecken des Aufbaus einfacher ist, wenn die Live-Daten extern liegen.
Unsere Anzahl an betreuten Systemen und Berufsjahren läßt solche grundlegenden Aussagen zu, ja.
Das habe ich auch nicht behauptet, es ging um mir nur um "Live-Daten nicht auf den internen Platten/SSDs des Mac minis".

Seit 27 Jahren arbeite ich mit Macs im grafischen Gewerbe. 2 Jahre bei einem Apple-Händler der ersten Stunde (ich sag mal Macintosh Plus), 1 Jahr in einem Verlag, 10 Jahre in einer Druckerei, nun seit 15 Jahren selbstständig. Immer war auch die Technik mein Zuständigkeitsbereich.

An genutzter Servertechnologie gingen AppleShare (war echt süß), Windows NT 3.51 (Intel Pentium Pro mit dickem icp-Vortex-SCSI-RAID-Controller und 4-Port 10-Mbit-Netzwerkkarte), Windows 2000 (auch mit icp-Vortex-Controllern und GBit-Netz) und nun für einige Jahre Linux (mit Software-Raid) durch meine Hände.

Am meisten Ärger machte noch der Server, der am aufwändigsten auf Seriosität getrimmt war -- leider ein Faktum. 5-Kanal-SCSI-Raid-Controller, 19"-Einschübe mit Wechselrahmen und viele 80-GB-Festplatten, die dann nach Monaten reihenweise ausfielen ... ein Hardware-Serienfehler, Conner waren's glaub ich mich zu erinnern. Und nun ist gerade mein Linux-Spiegel mit 6 Stück herkömmlicher Festplatten am sterben.

Gewissheit gibt es keine, das ist die Lektion. Daher stehe ich auf mehrere kleinere Server, da kann ich den Betrieb zumindest teilweise aufrechterhalten, und mehrfach vorhandene technisch idente Hardware, wegen der Austauschbarkeit und dem schlankeren Know-how, denn wenn was nicht klappt ist das Hirn meist eh schon stark genug gefordert.

Einen gewissen Überblick über Risken, Chancen und deren Konsequenzen meine ich schon zu haben.

Ein Mac mini ist per se keine gute Hardware für den Aufbau eines Servers. Jedoch gut genug für viele Zwecke. Leider gibt es keine Apple-Geräte mehr, die eine interne Erweiterung zulassen, a la Mac Pro.

Einen Mac mini aufzuschrauben und eine defekte SSD zu ersetzen sollte in einer guten Stunde erledigt sein. Im Katastrophenfall ein 500-GB-Backup auf die vorhandene Ersatzhardware zurückzuspielen wird wohl an die 3 bis 5 Stunden verschlingen. Das sind Zeiträume, mit denen ich mich arrangieren kann.

Grundsätzlich hat eine externe Raid-Box ihren Charme. Einfach in der Administration, wenig Kabel und Wackelkontakte, schnell umgesteckt.

Kontrapunkte sind der Preis, das Vorhalten-müssen eines Ersatzgerätes wegen des proprietären Raid-Verbundes, der in einem neueren Gehäuse wahrscheinlich nicht reaktiviert werden kann und meiner Abneigung gegen Raid 5. Ich finde Raid 1 reagiert spritziger, ist softwaretechnisch einfacher und performanter, Einzelplatten können ausgelesen werden.

Wenn das Deine Vorgaben sind, dann spricht nicht mehr viel dagegen.
Vor allen Dingen, da Du kein Problem mit einem Systemstillstand hast.
Trotzdem würde ich die Daten extern legen. Dann kannst Du das reine Serversystem an dem sich ja eigentlich nichts ändert regelmäßig auf den 2ten Mini spielen und das externe Daten-RAID1 einfach an den Ersatz-Mini klemmen, sollte der Haupt-Mini mal aussteigen.

Definitiv würde ich Server-System und Daten getrennt lagern, oder eine ständige Kopie des RAIDs auf Ersatz-Hardware vornehmen. Das sorgt für weniger Probleme im Falle eines Problems.

Ok, kürzen wir's ab. Vermutlich hab ich schon wieder Widersprüche vermutet, weil ich gewisse Sachen als implizit verstanden habe, die Du gar nicht gemeint hast.

Aber genau dazu: Warum die Fokussierung auf "Live-Daten"? Wenn ich an einem Mini ein Storage-System mit ausreichender Redundanz (was in jedem Fall RAID-6, Hot-Swap und getestete Rebuild-Funktionalität bedeutet, d.h. bekannte Zeitfenster für Performance und Dauer der Wiederherstellung der notwendigen Redundanz) betreibe -- egal ob per USB, Firewire, SAS oder Fibrechannel angeschlossen -- warum sollte ich dann nochmal irgendwas auf die interne Platte legen? Letztlich ernstgemeinte Frage, vielleicht sitze ich da einem Irrtum auf

2,5"-HDs sind lahm und der Betrieb im Mini ist doof (weil sterben wie die Fliegen grad wenn zwei drin sind im oberen Schacht und kein Hot-Swap. Jede Sorte HD im Mini bedeutet zwangsläufig, dass man sich Streß vorprogrammiert, weil wenn das Ding stirbt, muß man sofort den Mini runterfahren, aufprokeln und rumbasteln. Will man das? Eher nicht)

SSDs im Mini sind schnell. Wenn da nur das System draufliegt und die Kiste Fileserver ist, dann bringt mir das was? Über die gesamte Lebensdauer so eines Systems vielleicht sogar ein halbes Promille mehr Verfügbarkeit, weil die SSD nur eines machen wird: Systemstarts beschleunigen, was man üblicherweise bei Servern selten tut.

SSDs in einem als Server genutzten Mini sind aber auch doof, v.a. als RAID-1 (dazu sag ich jetzt nix mehr) aber auch wenn ich sie innerhalb des Minis sonstwie zur Schaffung von Redundanz nutzen wollte (weil zu viele andere SPoF involviert und prinzipiell viel zu hohe Gefährdung für Firmware-basierte Ausfälle). Also Schaffung von Redundanz im Mini geht irgendwie nur schwer und ohne Redundanz ist es auch nur doof, weil wenn die SSD ausfällt, muß ich sofort den Mini aufmachen, drin rumprokeln, etc. pp.

Warum nicht auf einem auf hinreichende Redundanz ausgelegten externen RAID zwei Partitionen abzwacken und auf die "das System" und "das System in der letzten bekanntermaßen funktionierenden Version" (also der Klon vor dem Upgrade, der ein Backup ergänzt). Ein externes RAID-6 wird natürlich niemals bzgl. Random-IO so performant sein wie eine interne SSD. Zum Glück aber völlig wurscht.

Performance könnte nur bei Firewire, USB 2.0 oder USB 3.0 ohne UASP ein Thema sein. Aber wenn man drauf achtet, SAS oder FibreChannel am Mini anzuschließen, dann ist das doch... äh... die Lösung der Wahl (zumindest solange man leichtgläubig genug ist und von "bisher noch nie was passiert" darauf schließt, dass fehlendes ECC-RAM im Mini einen nicht böse in den Ar*** beißen kann )

Kleines Problemchen: Wie schließe ich externe Hardware wirklich schnell und sicher an einen Mac mini an, außer über Thunderbolt? Welche Thunderbolt-Raid-Gehäuse-Preisklasse schwebt dir hier vor?

Ich bin nämlich inhaltlich ganz bei dir. Nur finde ich kein attraktives Angebot, vermutlich komme ich dafür 1 Jahr zu früh.

Was m.E. für SSDs im Mac mini spricht ist die relativ geringere Wärmeentwicklung (3 W peak und wenige mW permanent) und die geringe Latenz was Random-Zugriffe beschleunigt.

Ja, die Diskussion um "OS drinnen, samt Klon und TM-Backup" oder "OS auch draußen, und natürlich auch Klon und Backup" führen wir auch regelmäßig.

Ok, "Einzelplatten können ausgelesen werden" lasse ich gelten, ansonsten hat ein Software RAID Level 1 keine gute Karten gegen ein TB-RAID Level 5.

Wenn's ein aktueller Mini ist, spricht -- solange man nur die Technik an sich betrachtet -- nichts gegen USB 3.0, wenn man darauf achtet, dass Topologie (direkter Anschluß) und Chipsatz/Firmware im Gehäuse auch UASP unterstützen (weiß man leider erst am Ende oder wenn man sich sehr detailliert im Detail vorab informiert: .

Das objektiv Blöde an USB ist, dass es Massen- und damit Billigtechnologie ist und damit die Chance, Ramsch zu shoppen, recht hoch ist. Noch blöder beinahe ist, dass der Umkehrschluß mal wieder nicht zulässig ist, und auch teure und wertig aussehende USB3-Enclosures keineswegs automatisch besser sein müssen.

Was allerdings absurderweise beinahe Fakt ist, ist, dass einfache Enclosures, die nur USB3 implementieren (mit aktuellem Chipsatz wie bspw. 'nem ASM1051/ASM1053, wie er auch in vielen Billiggehäusen steckt) denen, die mehrere Protokolle implementieren, überlegen sind, wenn's einem nur um Performance geht.

Grundsätzlich ist aber wichtig, dass Du auf Erfahrungswerte bzgl. der Zuverlässigkeit der einzusetzenden Hardware zurückgreifen kannst (seien es eigene oder valide von Dritten). Und damit dürfte USB dann rausfallen, weil wer weiß denn schon, was in einem Enclosure verbaut ist und wie lange das halten wird und in welcher Form das mal wegsterben wird (bei Hardware ist ein schneller Tod immer vorzuziehen im Vergleich zu Siechtum, weil Letzteres mit schwer zu reproduzierbaren Fehlern einhergeht)

Trifft mehr oder weniger auch auf Thunderbolt- bzw. SAS/SATA-Lösungen zu. Ohne dass Du Erfahrungswerte zur Verläßlichkeit hast, würde ich das nicht einsetzen.

Und dass Thunderbolt per se null mit Schnittstellen wie Firewire oder USB in einen Topf geworfen werden kann, ist hoffentlich klar?

Ausgerechnet mir? Ernsthaft? Ich bin kein Freund von kleinen RAID-Kisten. Ich hab im Lauf der letzten 2 Jahrzehnte so viel Scheize mit RAID erlebt, dass ich wo's nur geht, eher die Finger davon lasse, weil Du nur mit Erfahrungswerten ausgestattet weißt, ob die Dinger das Versprechen, das sie geben (Verfügbarkeit herstellen) dann auch halten, wenn's drauf ankommt.

Deshalb überlassen wir den Part komplett anderen Systemhäusern, die aufgrund ihrer Installationszahlen wissen, was Sache ist und immer genügend Ersatzblech rumstehen haben (und selbstredend nur bekanntes Zeugs verbauen und sich wo's geht, nicht auf Experimente einlassen, auch wenn das heißt, veraltete Technik rauszustellen, weil bekanntermaßen zuverlässig).

Als kleiner Anwender geht das nicht -- rein prinzipiell. Dass das so ist, weiß man dann aber eben erst, wenn's zu spät ist und der GAU eingetreten ist.

Ich fand den Nachtrag von "gfhfkgfhfk" sehr interessant bzgl. Hardware-Impulsen. Allerdings um einen redundanten Filer auf Basis von (Open)Solaris aufzubauen, dabei auf non-proprietäres RAIDZ2 setzend, damit man die Daten an beliebiger anderer Hardware mit ausreichend SAS-Ports wieder zum fliegen bekommt. Aber das zugrundelegende Konzept und die Randbedingungen (mit Unix-Checker im Zugriff, etc. pp.) finde ich nach wie vor nicht zur Situation "kleiner Mac-Fileserver" passend.

Ich glaub ja, wenn man die Kosten aus der richtigen Richtung her kommend betrachtet (was kostet Systemstillstand und Datenverlust) sich automatisch eine viel einfacherere Betrachtung der Kosten für eine "Lösung" des eigentlichen Problems einstellt.

Die zweifellos zigfach höheren IOPS-Raten von SSDs sind aber nunmal im Gros der Arbeitsgruppenserver-Szenarien irrelevant. Und das mit der Wärmeentwicklung würde ich ja als Argument gegen HDs im Mini verstehen können. Aber nicht als Argument für SSD im Mini. In nen Mini gehört, wenn extern was Gscheides dranhängt, gar nix rein.

BTW: Ich hab aus meinem Mini die beiden HDs vor Kurzem rausrupfen und durch 'ne SSD ersetzen lassen. Weil ich nicht zuverlässig rausgefunden habe, ob das auf dem Mini laufende Linux Treiber für das mich interessierende SAS-RAID (Pegasus R4) mitgebracht hätte bzw. wie viel Gefrickel das gewesen wäre. Der Mini ist Spielkiste für virtuelle Maschinen und läuft unter VMWare ESXi

Erster! Ich hab den Tippfehler gefunden! Du meinst natürlich RAID-6?

Gut. Fassen wir zusammen:

• Ein Mac mini ist ziemlich suboptimal
• Alternativen mit Mac OS X gibt es keine, zumindest keine, die das Problem verkleinern
• Interne klassische Festplatten werden zu warm, besonders schnelle 7.200er-Ausführungen begrenzen die Lebenserwartung
• Interne SSDs sind aus mechanischen Gründen inakzeptabel
• RAID 1 mit zwei identen Festplatten ist sinnvoll, RAID 1 mit zwei identen SSDs nicht
• RAID 1 mit zwei verschiedenen Massenspeichern wird wegen möglicher Probleme durch unterschiedliches Latenzverhalten nicht empfohlen, schon gar nicht über unterschiedliche Anschlüsse
• Günstige externe Gehäuse sind nur über USB 3.0 schnell, aber mit großen Risken betreffend Verbindungsqualität anschließbar
• Verlässliche, belastbare Informationen über die Qualität externer Massenspeichergehäuse gibt es nicht
• Externe Gehäuse sind über Thunderbolt gut anschließbar, aber richtig teuer
• Proprietäre RAID-Boxen sind noch viel teurer und erfordern die Vorhaltung baugleicher Reservegeräte um Hardwaregebrechen im Bereich Box/RAID-Controller/Schnittstelle erfolgreich begegnen zu können
• FireWire 800 ist zu langsam
• Linux und Netatalk 3.1 brauchen Spezialisten zur Konfiguration und Wartung, auf die ich keinen Zugriff habe und in deren mit unbekannten Hände ich nicht meinen Unternehmenserfolg legen will
• Netaltalk 3.1 bietet nur mit spezieller darangefrickelter Software Funktionalität von Mac OS X Server (siehe Sherlock)
• Alles ist wahnsinnig kompliziert und vermutlich noch viel teurer

Gut, ich verkaufe jetzt meine Bude und gehe Erbsen züchten.

Warte, ich komme mit.

Danke für die konkrete Listung. Mit SuperMicro haben wir schon immer gute Erfahrungen gemacht. Aber paar Dinge waren mir komplett neu (weil Hardware nicht mehr so das Thema ist bei uns), kommt in jedem Fall in die engere Wahl, wenn das nächste mal ein ähnliches Setup auf unixoider oder Linux-Basis angegangen werden soll

Das sehe ich jetzt grad nach den Erfahrungen mit einem Ex-Kunden bzw. dessen untauglichen Backup-Lösungen und -Methodiken (TSM als auch Legato) ausgesprochen kritisch. Vor allem, wenn einen nicht nur Backup sondern auch das interessiert, wie man an die Daten wieder rankommt.

Das Problem mit den AFP-Servern unter Unix sind 3 Besonderheiten:

a) Ressourceforks und Finder-Metadaten: Helios legt für jede Mac-Datei zwei Dateien an (einmal Datafork und im Unterordner .rsrc eine kombinierte für Metadaten+evtl. Ressourcefork), Netatalk kann in aktueller Version den Kram auch in EAs des Dateisystems auf dem Server speichern, so die Daten denn reinpassen (ist heutzutage dann beim Gros der Dateien der Fall). Beim Backup ist das noch kein Problem, wohl aber beim Restore, denn wenn die Software das Konzept an sich nicht kennt, muß sich der User selbst drum kümmern

b) CNID-Datenbanken (bei Helios heißen die .Desktop-Datei, bei Netatalk .AppleDB). Die können zwar einfach so gesichert werden (dann gerne inkonsistent, weil sind ja Datenbank-Dateien. Alternativ mit Snapshots herumspielen) aber in keinem Fall bei partiellen Restores wiederhergestellt werden (weil dann automatisch ein Teil der IDs eines Volumes nicht mehr zu den Dateien/Ordnern auf dem Volume passen)

c) inzwischen Spotlight-Indizes. Auf die trifft alles wie bei b) zu. Es sind Datenbank-Dateien, die speziell behandelt werden müssen. Ohne dass eine Backup-Software sich damit auskennt, wird ein partieller Restore zum Problem (außer man empfindet es als lustig, dass nach einem Restore Dateien nicht mehr gefunden werden können, im Fall inkonsistenter CNID-Datenbanken dann durchaus auch verwehrter Zugriff im Finder obwohl die zurückgeholten Daten im Dateisystem des Servers liegen)

Dann gibt es noch weitere Spezialitäten, die man zwar lösen kann, indem man schon beim Backup manche Dateien vom Backup exkludiert (bspw. Helios' .DeskServer-Datei je Volume) aber v.a. die Restore-Problematik ist happig. Weshalb wir bei allen Kunden kommerzielle Backup-Softwares im Einsatz haben, die mit den spezifischen Formaten von Helios und Netatalk (und praktischerweise auch noch HFS+ nativ und das unter Windows übliche NTFS-Streams-Schema für Mac-Dateien) direkt zurechtkommen.

Und wie sehr das in die Hose gehen kann, wenn die Backup-Software inkompatibel zur AFP-Server-Lösung ist, konnte ich bei besagtem Ex-Kunden im Detail studieren (inkl. zig Datenverlusten und dem "witzigen" Fakt, dass Daten zwar im Backup waren, sie aber aufgrund des mehrstufigen Prozederes, das mit einem Restore verbunden war, nicht mehr herauszubekommen waren -- naja, das war eh alles nur verrückt)

Mit anderen Worten: Grad wieder für die vom Threadersteller angedachte Aufgabenstellung halte ich das an der Stelle für sehr problematisch, wenn man's unter Unix/Linux angehen will bzw. kann nur dringend zu den beiden kommerziellen Lösungen raten: und (P5 ist leider nicht zu Netatalk ab Version 3.0 kompatibel, wie's um MediaManager steht, weiß ich gar nicht. Wird anscheinend eh nur noch mit Hardware gebundlet)

Ach ja: Wenn jetzt seitens Apple der Schwenk von AFP nach SMB2 ansteht, ändert sich an obiger Problematik teils gar nichts (Helios) bzw. nur b) falls man mal Samba anstatt Netatalk als vollwertiger Mac-Fileserver einsetzen können wird.

Was ja mit einer der Gründe ist, warum wir Menschen gerne die "einfachen Wahrheiten" bevorzugen, egal wie falsch die auch sein mögen. Und lästige Details, die die schöne Aussicht trüben... über die schaut man dann gerne mal hinweg

Ich will jetzt gar nicht groß auf Deine Liste eingehen. Nur: da war einiges falsch wiedergegeben bzw. schlußgefolgert. Ist aber eigentlich wurscht weil:

Meines Erachtens gibt es für das ganze Thema keinen universellen Ansatz und schon gar keine allgemeingültige technische Lösung. Wenn wir uns als Dienstleister gegen Gage der Aufgabenstellung nähern, dann ist "konkrete technische Implementierung" beinahe das Allerletzte, um das es geht.

Erstmal kommt Analyse der Arbeitsabläufe, der produktionsrelevanten Zeitfenster, Produktionsspitzenzeiten, Abhängigkeit von weiterer Infrastruktur (ich brauch meinen Server nicht hochredundant machen, wenn meine Klitsche auch von "100% Internet" abhängig ist und ich da nicht ähnliche bzw. adäquate Redundanz schaffe -- stark vereinfacht gesagt), ein Verständnis dafür entwickeln, wie die Daten "entstehen" (wichtig, um Strategien für Datenwiederherstellung abseits Restore zu entwickeln), welche Sorte Daten da rumliegen und wie man die noch klassifizieren würde (nach Alterung/Aktualisierungszyklen, was ist Archiv, was sind Produktionsdaten, usw. usf.)

Davon leiten sich dann Anforderungen ab bzgl. Verfügbarkeit und garantierter Wiederherstellungszeiträume welcher Daten (die kann man meistens auch noch klassifizieren), Entwicklung von Notfallplänen und Einbeziehung weiterer Faktoren (wenn das zum Beispiel eine kleine Bude ist, wo's sowas wie "anderen Brandabschnitt" eh nicht gibt, dann kann man den Ball bzgl. serverseitiger Ausfallsicherheit etwas flacher halten, weil wenn's da brennt, ist eh alles weg. Dafür braucht man dann erhöhte Vorkehrungen für Off-Site-Datenhaltung, sei's ein Sync-Ziel und/oder Backup)

Dann kommt langsam eine Idee, wie man das technisch angehen könnte. Und diese Idee bzw. dieser erste Entwurf wird dann bzgl. Akzeptanz zus. mit Kunde abgeklopft (wenn sich technisch bspw. eine Linux-Lösung aufdrängen würde aber die Leute, die damit umgehen sollen, dagegen allergisch sind vergiß es eher, allein schon aus diesem Grund). Und dann kristallisiert sich ein Feinkonzept heraus, dem Implementierung und immer auch Review nach paar Wochen/Monaten folgt.

Ich weiß, ich weiß, ganz schöner Aufwand. Aber als Dienstleister darf man das eigentlich gar nicht anders sehen, weil man ja in der Veranwortung steht. Drum ist es ja so angenehm, hier einfach so drauflos plappern zu können ohne Sinn und Zweck und einfach nur 'ne differenzierte Betrachtung der verschiedenen technischen Implikationen zu machen ohne an all den Schraddel denken zu müssen

Dazu ein paar Anmerkungen

• Es gibt noch den MacPro, der zumindest das ECC Problem löst.
• Richtig schnell sind nur 2.5" 15k Platten, die passen aber in keinen Mini.
• Bei den meisten ThunderBolt RAIDs ist vollkommen unklar was für ROCs verbaut sind. Das ist ein Problem, weil man nicht weiß, ob das RAID von einem seriösen Anbieter stammt, der die Firmware auch über Jahre pflegt und bei Problemen einen beisteht, oder ob man im Regen steht bei Problemen.

Erschwerend kommt an der Stelle abseits des Controllers (ROC RAID on Chip) ja noch was ganz anderes hinzu. Da Thunderbolt eben nicht etwas irgendwie mit traditionellen Storage-Schnittstellen Vergleichbares ist sondern einfach nur "PCIe am Kabel", stellen sich bzgl. externer Thunderbolt-Gehäuse, egal ob RAID oder sonstwas, ja noch zwei Fragen:

a) welches Protokoll kommt eigentlich zum Einsatz?

b) welcher konkrete PCIe-Controller im Enclosure wird verbaut?

Meines Wissens setzen fast alle Hersteller von TB-Enclosures aus nachvollziehbaren Gründen Richtung PCIe auf SATA, SAS oder natürlich vermehrt NVMe und auf Controller-Chips, die Apple auch selbst verbaut (bzw. für die durch enge Zusammenarbeit mit Apple sichergestellt ist, dass heute und in Zukunft Treiber in sowohl EFI -- wichtig fürs Booten vom externen Storage-Device -- als auch in OS X enthalten sind -- wichtig für problemlosen Zugriff auf das externe Enclosure und heutige und in Zukunft anstehende Performance-Optimierungen auf Treiber-Ebene)

Wenn der Hersteller des Enclosures an der Stelle fröhlich eine Extrawurst brät, am Besten noch, indem er ein Protokoll über die TB-Strippe transportiert, das eigentlich schon längst tot ist, dann passiert Folgendes:

- man kann von seinem TB-Enclosure so lange nicht booten, bis nicht auch Apple einen Treiber für den im Gehäuse verbauten Controller in die EFI-Firmware aller TB-fähigen Macs eingebaut bzw. ausgerollt hat (Firmware-Upgrade läßt grüßen)

- man kann schlichtweg gar nicht auf sein Enclosure zugreifen, solange in OS X kein Treiber (Kernel Extension) geladen ist. Damit ist Folgendes vorprogrammiert: grundsätzlich potentielles Treiber-Geschissel bei jedem Upgrade und bei Fehlereingrenzung (Stichwort "Safe Boot"), 100% Abhängigkeit von der Treiberversorgung durch den Hersteller des Gehäuses, 100% Abhängigkeit von der Qualität der Treiber, die der Enclosure-Hersteller liefern muß)

- wenn man im Hinterkopf hat, dass viele der Optimierungen der letzten Jahre in OS X unter der Haube stattgefunden haben, dann würde ich zumindest davon ausgehen, dass uns ein paar weitere Optimierungen bzgl. Storage im Zusammenspiel mit high- und lowlevel-Treibern bevorstehen (bspw. weitere Verheiratung von HFS+ bzw. eher CoreStorage und den lowlevel-Treibern, die das eigentliche Storage-Protocol implementieren). Und ich vermute ganz stark, dass sich da sämtliche Bemühungen auf zukunftsweisende Protokolle konzentrieren werden, eben SATA, SAS, UASP und NVMe wohingegen paralleles SCSI wie auch das andere Auslaufmodell Firewire draußen bleiben werden.

Letzteres ist Stand jetzt bloße Vermutung, die beiden ersten Punkte Fakt. Und wer darauf nicht achtet, macht gerade wenn er auch nur ein Sekündchen über "Verfügbarkeit" nachdenkt, einen ziemlichen Fehler. Man sollte meinen, dass kein Hersteller 2013/2014 noch auf so eine Idee kommt. Doch, gibt mindestens einen -- leider.

Darauf läuft es hinaus, wenn man alles perfekt haben will.
Das kann sich kein kleineres Unternehmen mehr leisten.

Deshalb liebe ich die Ausführungen von Thomas aus technischer Sicht.
Da gibt es verdammt viele gute Tipps und Tricks wie man trotz gewisser Abstriche immer noch ein sehr gutes System mit recht hoher Datensicherheit hinbekommt.
Man muss sich nur darüber klar sein, dass es kein perfektes System im bezahlbaren Rahmen gibt, wenn wir über kleinere Unternehmen sprechen die sich diesen Technik-Overkill nicht leisten können.
Kleinere Unternehmen können es sich leisten, wenn ein Server mal eine Stunde down ist, oder wenn mal eine Datei über den Jordan geht. Die 2 Überstunden des Mitarbeiters kosten weit aus weniger als die notwendige Technik um dies zu verhindern.

Kann ich so nicht unterschreiben. Bzw. muß man die Aufgabenstellung einfach mal von der anderen Seite her angehen (also was macht der Laden, was sind die Daten wert, wie schnell müssen sie wiederherstellbar sein und was sind die Konsequenzen in welchem Fall. In größeren aber nicht zu großen Unternehmen kann man durch sowas als Nebeneffekt auch noch wunderbar Arbeitsabläufe iterativ verbessern).

Grad für ITler ist die Versuchung, IT als Selbstzweck zu betreiben, natürlich groß. Und fast immer falsch. Bspw. werden oft Sachen einfach als "gesetzt" betrachtet, die man hinterfragen sollte. Z.B. RAID: Erhöhung der Komplexität eines Systems ist immer Nachteil, der erstmal durch entsprechende Vorteile aufgewogen werden will. Also muß man sich, wenn man den Kram aus der Technik-Perspektive aufzieht, erstmal die Fragen stellen:

1) was man von RAID als Konzept erwartet

2) ob's das überhaupt wert ist (bspw. weil man feststellt, dass weil man ein stündliches Backup+Sync hat und die Wiederherstellungszeitfenster entspannt sind und man das bisserl an Arbeit, was in einer Stunde verloren ginge, dann im Worst Case halt nochmal macht)

3) und ob's die angedachte Implementierung überhaupt hergibt (und gerade hier wird's witzig bzw. traurig, weil das ist ohne erheblichen Aufwand gar nicht so einfach möglich -- etwas, das man wohl nur selbst "erfahren" kann und nicht durch Zuhören oder gar von Dritten "lernen" kann)

Zieht man die Chose von der anderen Seite auf und überlegt nur, was man eigentlich abfedern will/muß, dann spart man Zeit, Kosten und meist auch Enttäuschung, weil man erst gar nicht beim Konzept RAID (gut gemeint) und dessen Implementierung (meist nicht gut gemacht) landet.

Nicht falsch verstehen: RAID ist ab gewissen Randbedingungen als notwendiges Übel quasi Pflicht (neben vielen anderen Maßnahmen, die man parallel ergreifen muß). Aber wenn man drauf verzichten kann, dann läßt man's lieber bleiben (außer es geht vorrangig um die psychologische Komponente: "Bei mir Büro läuft die gleiche geile Scheize wie in Rechenzentren")

Ich wüsste ja schon, was ich an Austro-Diesels Stelle machen würde. Aber die Lebenserfahrung lehrt, dass gewisse Sachen völlig anders wirken, wenn man sie selbst macht und nicht andere erledigen läßt.

Beispiel Sport: Da passiert mit dem Körper etwas Unterschiedliches in Abhängigkeit davon, ob man sich 'nen Kasten Bier schnappt und auf dem Sofa anderen beim Ball-hinterher-rennen zuschaut oder selbst rumrennt. Und ähnliches gilt für Nachdenken im Allgemeinen bzw. "Probleme differenziert betrachten" im Speziellen. Für die Birne dann natürlich

Aber genau das meine ich doch.
Es kommt nicht immer auf die Ausfallsicherheit an, oder dass man eine Lösung erarbeitet bei der die Datensicherheit so hoch angesetzt wird, dass man erheblichen Aufwand dafür betreiben muss.

Man muss immer schauen, dass man eine Lösung findet die zum Unternehmen passt.
Deshalb finde ich Deine Ausführungen immer sehr interessant, wenn auch so in der Gesamtheit meistens nicht umsetzbar, da die von Dir angesprochenen Lösungen für kleinere Unternehmen den totalen Overkill darstellen.

Äh, ich hoffe aber, dass nichts davon zumindest hier im Thread als angepriesene Universallösung verstanden wurde. Mir geht's hier grad darum, dazuzulernen als auch eigene "als gesetzt betrachtete" Standpunkte abzuklopfen. Indem man das ganze Thema mal in voller Breite ausrollt

So wichtig es ist, Thematiken ab und an mal bis ins letzte Detail durchzudenken, so wichtig ist es auch, dann davon simple Handlungsvorgaben abzuleiten (bspw. "Backup statt nur Sync") aber die wiederum in regelmäßigen Abständen abzuklopfen (bzw. abklopfen lassen, wie hier jetzt, wenn denn Feedback kommt

Grad als ITler ist man ja nicht nur permanent vom Dunning-Kruger-Effekt bedroht sondern auch davon, Technik losgelöst vom eigentlichen Sinn dahinter zu betrachten. Vom einsetzenden Altersstarrsinn mal ganz zu schweigen

Da hast Du wohl Recht mit.
Nur was haben die 3 Seiten Technik-Diskussion mit dem eigentlichen Topic dieses Threads zutun?

Die Frage diesmal war was günstig ist, als Fileserver mit guter Spotlight-Suche arbeitet, 10-15 Mitarbeiter versorgt, und im Problemfall einfach wieder ans laufen gebracht werden kann, wenn mal ein Ausfall auftritt.
Die ganzen interessanten Ansätze liefen fast alle am Punkt "einfach" oder spätestens am Punkt "günstig" vorbei.
Wäre es nicht für die Fragenden User hier sinnvoller direkt auf die Frage einzugehen, und ggf. entsprechende Diskussionen in parallele Threads mit eigenem Diskussions-Topic zu packen, damit der Thread-Ersteller auch eine Antwort auf seine Frage bekommt und nicht nach spätestens 10-20 Posting das Handtuch wirft, weil er mit der Thematik hoffnungslos überfordert ist?

Wie gesagt, ich verfolge die Diskussionen sehr gerne, weil ich sehr viele Ansätze bekomme die ich weiterverfolgen kann.
Nur zerstören wir mit diesen Diskussionen innerhalb des Threads die eigentlichen Topics.

Ne ganze Menge, immerhin ist beinahe alles, was man ohne die konkreten Randbedingungen zu kennen, berücksichtigen müsste, erwähnt worden.

Wenn man die Sache richtig angehen wollte, müsste man wie schon erwähnt von der anderen Seite her kommen. Am Ende weiß man dann, was technisch zu dem Laden paßt. Aber das ist kundenspezifisches Consulting und das gibt's zumindest von mir nicht für lau

Und mir machte der Threadersteller nicht den Eindruck, dass er auf "einfache Wahrheiten" wie "Alder, nimm ein NAS, das rat ich Dir!" aus ist. Und wäre er's wär's mir zumindest auch wurscht. Ich mach hier keinen 1st-level-Support und erst recht keine Beratung

Wink, ich bin noch da und lese fleißig mit Auch wenn das ganze hier schon arg abgedriftet ist wie Cyco so trefflich bemerkt hat.

Aber was die Diskussion an sich zeigt ist ja, das es derzeit keine einfache Lösung ala "MacPro mit OS X Server" + Raid oder gibt. Entweder ein Mini mit den angesprochenen "Problemen & Folgen" oder der Aufwand steigt...

Jede Lösung beinhaltet einen gewissen Aufwand.
Es gibt keine Out-of-Box Lösung die einfach ist und in allen Bereichen passend und gut.
Bei 10-15 Mitarbeitern dürfte sich ein eigener IT'ler noch nicht lohnen.
Weshalb man auf einen externen zurückgreifen sollte der im Thema drin ist.
Der kann dann auch ggf Support von außerhalb leisten. Sei es per Fernwartung oder auch bei simplen Dingen per Telefon anleiten.
Oder Du setzt dich hin und lernst das komplette Thema selbst und lässt dich schulen. Was auch wiederum teurer ist als ein externer Dienstleister.

Das war halt mal eine klein wenig differenziertere Betrachtung der vielen Aspekte, die das Thema so mit sich bringt

Ich find sowas immer besser als Pauschalisierungen, von denen es grad im ersten Teil des Threads nur so gewimmelt hat.

Ich würd's an Deiner Stelle ja nach wie vor von der nicht-technischen Seite aufziehen, also Arbeitsorganisation und Notwendigkeiten bzgl. Verfügbarkeit abklopfen, Daten klassifizieren. Davon ableiten, was in welchem Notfall getan werden müsste, Stichwort Notfallkonzept/-pläne (gfhfkgfhfk), was Stillstand/Ausfall/Verlust kostet (Cyco) und dann langsam mal über die Technik nachdenken (da hilft dann evtl. die ganze Diskussion hier im Thread endlich weiter).

Was weiß ich, vielleicht erscheint dann am Ende eine Lösung, die auf ausgemusterten Käsereiben-MacPros mit internem Storage aufsetzt, als ideal? Du hast ja gesehen, was hier in München grad bei den Wertstoffhöfen abgeht?! Die ganzen Agenturfuzzies schmeißen den alten Schraddel weg und stellen auf schwarzes Alu um!

In meinem Dunstkreis schmeißt keiner (auch keine Agenturen etc) alte Macs weg. Die werfen alle 2, 3. und 4. verwertet. Irgendwer will immer einen "alten" Mac haben oder braucht den

Billige, akzeptable Lösung:

Gebrauchter MacPro 3,1: 800€
8GB RAM: 200€
2x2 TB HDD: 300€
4TB FW HDD für Backup: 400€

Zusammen: 1700€.

Betriebssystem samt Shares auf internes Software-RAID. Du solltest noch überlegen, ob du weitere Platten oder einen zweiten MacPro vorhältst.

Mit Ausfallzeiten von 1 Tag musst du natürlich rechnen.

Bei einem Brand ist alles futsch. Also immer noch ein weiteres Backup auslagern.

Die ganzen Probleme habe ich mit meiner Lösung nicht.

Ich danke für die Diskussion und die wertvollen Beiträge!

Dass eine bezahlbare Lösung immer gewisse Kompromisse erfordert und nicht zwangsläufig jeder wenige Stunden dauernde Stillstand fürs Unternehmen kritisch ist, das ist klar. Gegen höhere Gewalt (Erdbeben, langfristiger Stromausfall, Vandalismus) gibt es auch keine kurzfristig greifenden Absicherungen.

Ich habe mir da meine Gedanken gemacht und meine nicht zuletzt durch eure Beiträge ein Konzept gefunden zu haben, das bezahlbar bleibt, im Fall des Totalausfalls in wenigen Stunden wieder einsatzbereit ist und die Daten gegen Hardwareausfall sowie Fehlbedienung zumindest auf dem Vor-24-Stunden-Niveau wiederherstellbar sind.

Das Paket besteht aus zwei völlig identen Servern, die jeweils ungefähr gleichviele Kundendaten-Mengen und Mitarbeiter bedienen.

Klar ist ein Mac mini wegen der Notwendigkeit externer Laufwerkserweiterungen und des ECC-RAM-Defizits wie auch OS X wegen seiner hier immer wieder angezweifelten Stabilität keinen idealer Server, beides bietet jedoch auch klare Stärken: Energieeffizienz, einfache Administration und Notfallinstallation, hohe Austauschbarkeit mit Komponenten, die im Büro jederzeit verfügbar sind.

Die Kompromisse sind klar definiert: Im Fall des Ausfalls übernimmt ein zweiter Server die FileSharing-Dienste, die Serverfreigabe muss unter demselben Freigabenamen neu eingerichtet werden und zuvor die Daten von der Timemachine zurückgespielt werden. Damit die Daten im Fall des Falles schnell wiederherstellbar sind ist das Timemachine-Volume jeweils am anderen Server lokalisiert, also dort für den Notfall lokal und damit schneller im Zugriff.

Als 2. Rückfallsebene gibt es noch ein Backup auf einen außerhalb des Büros platzierten Server, der als zweites Timemachine-Ziel dient, damit den Schutz gegen Diebstahl und Vandalismus verbessert.

Es stehen zwei bootfähige externe USB-3-Festplatten mit vorinstalliertem Mac OS X Server als eiserne Reserve im Regal, womit man schnell einen beliebigen, baugleichen Arbeitsplatz-Computer zum Notafall-Server umkonfigurieren kann.


Ich denke, das kann ich mal so wagen.

Und berichte dann bitte, wie sich TimeMachine im Netzwerk verhält, grad unter der Prämisse "schnell mal zugreifen" nach Schwenk auf anderen Server

Beim Wiederherstellen auf den Ersatzserver wäre das dann ein lokaler Zugriff!

Ausnahme, wenn die 2. Rückfallsebene (externer Backupserver) zum Tragen kommt.

Nur auf was? Wenn Du vorher quer durchs Netz gesichert hast, dann liegen die Daten natürlich lokal am anderen Server. Aber in einem dicken SparseBundle. Und ob/wie man das dann für einen normalen TimeMachine-Restore gebrauchen kann, weiß ich zumindest grad nicht. Evtl. hilft gedrückte -Taste beim Klicks ins TM-Menü, evtl. auch nicht -- keine Ahnung.

Muss ich selber ausprobieren, bin mit Timemachine noch nicht fit. Ich dachte ich wähle einfach am anderen Server-Mac dieses Volume als Timemachine-Volume und wähle den Freigabe-Ordner zur Wiederherstellung an einen selber bestimmten, lokalen Ersatzort aus.

Das Problem ist wie folgt: Mac A und B sind gegeben.

Wenn Du an einem der beiden Macs auf eine lokale Platte (extern oder intern, egal, eben direkt auf HFS+) sicherst, dann landen die Daten direkt im HFS+ (inkl. des ab 10.5 neuen Features "directory based hardlinks" zur TM-Versionsverwaltung).

Wenn Du jetzt von Mac A auf B übers Netz sicherst, dann ist die Transportschicht AFP und auf der Share auf B wird (von A) ein SparseBundle angelegt und dort hineingesichert. Aus Sicht von Mac B liegt der ganze Kram zwar "irgendwie" immer noch auf HFS+ aber in Form eines dicken Images, auf das TM meines Wissens erstmal nicht direkt zugreifen will (kann mich täuschen, die -Taste wird's Dir berichten. Weil die mußt Du drücken, wenn Du auf ein anderes Backup zugreifen willst).

Das ist nämlich gleich das nächste "Problem". TimeMachine kennt meines Wissens keine solchen niedlichen Failover-Überlegungen, wie wir sie hier spinnen. D.h. TM kodiert in ein Backup sowohl hinein, welche Maschine es gemacht hat (mit mehreren Kriterien, weil viel hilft viel) und welche Volumes gesichert wurden.

Bzgl. Maschine klatscht es MAC-Adresse und Host-UUID als Extended Attributes an das Verzeichnis des Hosts. Und im Verzeichnis kleben die jeweiligen Partitions-UUIDs an den dortigen Ordner.

EAs zeigt in der Shell xattr an. Geht sicher auch anders aber ich halt GUI-Depp

Maschinen-Metadaten anhand der Sicherung meines Notebook:


Und je TM-Sicherung werden weitere Metadaten bzgl. der Volumes (und wieviel Platz das Ganze braucht, etc. etc.) dito als Metadaten an den jeweiligen Sicherungsordner geklebt (innen drin finden sich dann weitere Infos noch zus., die man mit Tools wie "tmutil" bequem nutzen kann):


Und genau diese UUIDs bzw. TimeMachines Sicherheitsnetz beißen Dich dann im Fall des Failovers in den Ar*** bzw. mußt Du dem Rechnung tragen. Ich würde sowas komplett per Skripting angehen (man hat halt dann auf beiden Maschinen 2 Skripte, die sich doppelklicken lassen und den jeweiligen Failover-Szenarien gerecht werden, indem sie UUIDs automatisch anpassen). Aber wie schon gesagt: Dass aus Sicht von Mac B die Daten von Mac A "falsch" weil als SparseBundle vorliegen, kann zum Showstopper werden.

Weshalb ich mein hier im Thread mal aufgemaltes Mini-Szenarium (A ist produktiv, B erhält einen 1:1 Sync auf ein Volumes und spielt parallel TM-Volume) vermutlich so ändern würde, dass A immer schön nach B synct, und der 1:1-Sync-Bestand dann auf B per TimeMachine weggesichert wird. Dann entfällt die SparseBundle-Problematik und grad bei Backup/Restore ist jedes Bit weniger Komplexität im Zweifel Gold wert.

Guter Rat, muss ich mal ausprobieren ob das dann tatsächlich hakt.

Getestet müssen solche Lösungsansätze immer werden, _bevor_ man seinen Hals in die Schlinge schiebt.

Ansonsten bleibt als "einfache" Lösung das lokale Timemachine-Backup und der Ersatz des ausgefallenen Computers bzw. Neustart mit externer Notfall-HD und dessen lokale Wiederherstellung.

Per Alt-Taste kann man nicht auf Netzwerk-Backups zugreifen, das kann ich bestätigen. Deswegen habe ich neben jedem Mac zusätzlich ein lokales Time-Machine-Backup.

Und per "Timemachine öffnen" oder wie das heißt, wo dieser spacige Bildschirm kommt?

Mit Alt-Taste ins Time-Machine-Menü klicken und dort „Andere Backup-Volumes durchsuchen …“.

Das ist das eigentliche Restore-UI. Aber ohne dass TM vorher weiß, auf welches Backup-Volume es zugreifen soll, kein Restore.

Das Problem ist, dass wenn TM lokal zugreifen will, es direkt auf ein HFS+ schreiben/lesen will (also überhaupt nicht an einem dort aus welchen Gründen auch immer herumliegenden SparseBundle interessiert ist) und wenn es per Netzwerk zugreifen will, immer per AFP noch ein SparseBundle oben drauf erwartet. Und beide Modi zueinander inkompatibel sind. Und genau dieses Problem erzeugt man automatisch, wenn man von A auf B per Netzwerk sichert. Dann liegt das aus Sicht von B immer falsch vor. Damit Du die lokale Sicherung, die dann an B hängt, wieder von B aus zugänglich machen kannst, mußt Du sie im Prinzip zu C tragen und dann übers Netz drauf zugreifen (der AppleFileServer unterstützt meines Wissens immer noch keine sog. "loopback"-Mounts, sonst könnte man das "durchs Netzwerk" über localhost/127.0.0.1) machen.

Das jüngst angesprochene Problem war übrigens nicht, übers Netzwerk zu restoren, sondern lokal auf ein Backup zuzugreifen, das übers Netzwerk entstanden ist. Also eigentlich das Gegenteil

Falsche Konsequenz (zumindest, wenn's aus dem Grund ist). Restore übers Netz funktioniert mehrstufig:

- Der Mac guckt im Netz per Bonjour nach, ob AFP-Server anwesend sind, die spezifische Bonjour-Records publizieren (wenn es interessieren sollte: )

- dann wird das entsprechende TM-Backup-Volume automatisch angeboten

- wenn der User das Volume auswählt, wird versucht, das darauf enthaltene SparseBundle zu mounten und dann das Restore-GUI auf Basis des im SparseBundle enthaltenen HFS+ angezeigt

Und das Ganze funktioniert auch aus der Recover Partition für einen Komplettrestore und sogar wenn überhaupt keine IP-Adressen konfiguriert sind oder DHCP am Start ist (wegen Bonjour und den sog. link local IP-Adressen). Es gibt abgesehen davon, dass Backups in dem Modus gerne öfter mal kaputtgehen nur noch ein echtes Problem, das auch nur wieder mal auftreten kann, wenn man kein OS X als TimeMachine-Server verwendet hat.

Der Restore kann schnarchlahm sein, weil Apple saudummerweise auch heute noch einen gewissen TCP/IP-Parameter häßlich konservativ eingestellt hat. Wen es interessieren sollte: Man muß den Wert net.inet.tcp.delayed_ack dann im Restore-Fall ggf. manuell auf 2 setzen (default ist 3), weil sich sonst OS X mit den TCP/IP-Stacks diverser moderner Unices und Linuxe nicht verträgt und alles fürchterlich lahm wird (trifft auch auf viele der üblichen NAS-Eimer oder FreeNAS zu, denn das läuft ja auch alles nur unter Linux oder FreeBSD).

Weshalb wir bei den Macs aller Kunden sofort net.inet.tcp.delayed_ack=2 in die /etc/sysctl.conf eintragen lassen, weil das auch im normalen Netzwerk-Betrieb nachhaltig die Performance versauen kann, wenn man nicht auch wieder OS X auf der Serverseite hat.

Das lokale Backup habe ich, weil das Netzwerk-Backup manchmal korrupt wird und neu angelegt werden muss. Das ist mit einem lokalen noch nie passiert.

Ich hab nun die ganze Hardware da, bin in den nächsten Tagen am Basteln.

Aktuelle Verbesserungsidee:

Backup per Carbon Copy Cloner auf eine gleichgroße (1 TB) Partition einer externen USB-3-Festplatte mit 4 TB, somit gibt es ein schnell verfügbares und bootfähiges Serverbackup.

Die restlichen 3 TB als Timemachine-Volume, womit eine komfortabler Restoremöglichkeit mit Historie gibt.

Bootbarer 1:1-Klon auf selbem physischem Medium wie TimeMachine-Sicherung ohne "galvanische Trennung"? Klingt für mich eher nach konzeptioneller Fehler (Stichwort "Surge", der Dir alles auf einen Schlag weggrillt), wenn Du nicht noch weitere Redundanz bzw. rotierende "Medien" implementierst.

BTW: Ich hab das, also die Nummer mit den "rotierenden Medien", für 'ne Freundin Ende letzten Jahres mittels einer USB-fähigen Steckerleiste gelöst (weil Madame prinzipiell zu bequem ist, die Dinger an- und abzustecken). So 'ne Leiste kostet ca. 40,- €, hat irgendsoeinen Überspannungschutz (mit irgendeiner Garantie, wenn der nicht greifen sollte) und 4 Ports können per USB vom Mac geschaltet werden. Das Tool dafür (sispmctl) ist gratis respektive OpenSource. Ich hab Ihr das so automatisiert, dass abwechselnd mal die eine, mal die andere externe USB-Platte an ist und somit im Fall des Falles hoffentlich nur das produktive System und eine Backup-Instanz futsch ist (ein weiteres TM-Medium in Form einer externen USB-Platte sollte sie alle paar Wochen mal von Hand anschließen -- glaub ich zwar nicht dran aber mei... mehr als warnen kann man dann auch nicht mehr)

Das mit der USB-Schalterei fängt wenigstens ein klein bisschen mehr noch ab bei moderatem Aufpreis. Ein Spezl von mir will das jetzt mit 4 externen Platten an so 'ner Steckerleiste in der Spielart "Türme von Hanoi" machen (http://de.wikipedia.org/wiki/Datensicherung#T.C3.BCrme_von_Hanoi_f.C3.BCr_vier_Medien ). Hat ich nix davon, einfach weil die Medien (also Platten) noch viel zu nah am aktiven System vorgehalten werden müssen. Ich arbeite da lieber noch mit Sync an anderen Standort.

Der Beitrag ist im Kern gut. Bei meinen Eltern war im Einfamilienhaus fast alles an Elektronik kaputt, als zwei oder drei Häuser weiter der Blitz einschlug.

Ein "richtiger" Surge wird jedoch auch zwei Festplatten an zwei Netzteilen zumindest halbgar grillen. Da bei uns alles an USVs hängt, auch der iNet-Anschluss durch einen Filter in der USV geschliffen ist, könnte das Risiko zumindest stark gemildert sein. Ob der Kontaktabstand einer schaltbaren Steckerleiste ausreicht?

Auch ist die zweite Backupebene natürlich durch einen Surge in Gefahr, da im selben Gebäude. Extern sichern geht nicht wirklich.

Beim Archiv ist mein Ansatz 2x externe Festplatte, diese nach Nutzung von Netz und USB mechanisch trennen.

So, heute hab ich ein bisserl mit meinem extra gekauften Mac mini i5 und den beiden Samsung EVOs herumgespielt. Es gibt was zu berichten, zu lachen, zu fragen.

Beide SSDs in externe USB-3-Gehäuse, RAID-1-Verband angelegt, OS X installiert, alles problemlos. Bootet flink, wenngleich nicht so spritzig wie von der internen Original-SSD meines Mac mini mit i7.

Den Mac mini zerlegt, HD raus, beide SSDs mit einem "Upper-Kabel" (über Amazon bezogen) montiert, zusammengebaut, Neustart, Bootvorgang recht langsam und der RAID-Verband beklagt sich über ein fehlendes Mitglied. Die zweite Platte des RAID-Verbandes wird als einzelnes Laufwerk dargestellt, aber ohne Bezeichnung für die Partition, nur in der Art einer unformatierten Platte (disk2irgendwas).

Aha, Kontaktproblem? Also wieder alles zerlegt, Steckverbindungen kontrolliert, wieder zusammen, dito. Einbinden in den RAID-Verband nicht möglich. Spaßeshalber versucht diese SSD neu zu formatieren, geht nicht. Also SSD raus, ins externe USB-3-Gehäuse, alles funktioniert rein technisch. Formatieren, Daten kopieren, alles unauffällig.

Aber in den RAID-Verband wieder aufnehmen oder eine Ersatzplatte einbinden ist nicht möglich, sollte lt. support.apple.com ja nicht weiter schwierig sein.

Liegt's daran, dass interne Platte nicht mit externer Platte logisch verbunden werden können? Check ich das Festplattendienstprogramm nicht? Leider kenne ich das "normale Verhalten" nicht.

Dann in den Kritiken auf der Amazon-Produktseite mal detailliert herumgelesen und ich dürfte nicht der einzige mit diesem Problem sein -- das Kabel fürfte elektrisch problematisch sein, OWC DataDoubler wird von den Schreibern als Abhilfe empfohlen.

Jetzt schau ich amal dumm ...

Aber immerhin kann ich den Mac mini schon in 20 Minuten auseinander- und wiederzusammenbauen!

Auf jeden Fall lerne ich gerade eine Menge!

Carbon Copy Cloner kann auch auf Netzwerkvolumes sichern, ob das dann Images sein müssen oder ob die Sicherungen bootbar sind wäre auszuprobieren. Mit rotierenden externen Platten auf denen das komplette Server OS incl. Daten und allem geschrammel drauf ist habe ich persönlich gute Erfahrungen gemacht, Mac OS ist da nämlich recht gnädig was booten auf anderer Hardware angeht (testen sollte man das allerdings schon).

Nimm 2 Mac Pro in Gebraucht für 350 das Stück Punkt 1
pack identische Platten und Ram rein, wennst Lustig bis noch ne Hotplug Raid Karte Punkt 2

fahr einen als Server und einen als Backup und Fallback Lösung, mit Zusätzlicher Sicherung Extern Punkt 3

ét Voilà

Edit:
Wenn ich mir gerade auf die Schnelle aber die Raid Karten anschaue,
wird mir schlecht…um die 500 Taler das Stück…naja…muss man genau schauen

http://www.dooyoo.de/speicherkarten/apple-mac-pro-raid-card/

Schön. Wenn jetzt noch bei Dir ankommt, dass ein RAID-1 aus zwei quasi baugleichen SSDs eh nur Quatsch ist, dann kannst Du Dir auch das Gebastel sparen.

Mich würd noch interessieren, ob Du geprüft hast, ob Dein USB3-Setup UASP oder nur Mass-Storage-Protocol kann. Welcher Controller steckt denn in den Gehäusen?

Ach, und noch ein Hinweis bzgl. "Messen der Startzeiten". OS X hat wie nicht anders zu erwarten, ein paar Tricks auf der Pfanne, um Systemstarts zu beschleunigen. Die wirken aber ggf. iterativ, d.h. es kann Situationen geben (bspw. nach einem Update), wo der erste Neustart im Anschluß ziemlich lahm, der nächste flotter und der dritte und alle folgenden dann rasch ablaufen (bis man wieder ein Ereignis heraufbeschwört, das diesen Mechanismus erneut in Gang setzt und dazu gehört unter anderem auch Gebastel an der Hardware). Stichwort Kernel- bzw. Extensions Cache:

https://developer.apple.com/library/mac/documentation/darwin/conceptual/kernelprogramming/booting/booting.html