Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Backup OS X Fileserver mit Mavericks

Backup OS X Fileserver mit Mavericks

jensche17.04.1415:00
Hallo zusammen

Wie backupt ihr eigentlich Eure Fileserver. Die Ausgangslage wird bald wie folgt:

Mac Mini mit OSX Server Mavericks und eine Pegasus R6.
dazu in 3facher Ausführung jeweils
Netzwerkserver für die Backups (Synology NAS).

Was empfielt ihr für das Backup der daten auf das Netzwerkvolume?

((die Synology NAS Backupen sich dann selbst weiter))
0

Kommentare

Cyco
Cyco17.04.1415:41
Wie aufwändig darf das ganze denn werden?

Ich würde einen regelmäßigen Sync der Daten auf einen 2ten MacMini mit Pegasus R6 machen, der in einem anderen Teil des Gebäudes steht.
Dazu jeweils eine lokale externe HD für TimeMachine, um ungewollte Änderungen oder das versehentliche Löschen von Dateien wieder rückgängig machen zu können.

Die Synologys mag ich nicht, da es RAID-Systeme sind die man nicht mal eben direkt an einen Rechner anschließen kann um von dort aus dann drauf zu zugreifen.
Evtl. als zusätzliches Backup, idealerweise über eine VPN-Verbindung in ein anderes Gebäude.
0
jensche17.04.1415:48
Zur Zeit haben wir Fileserver in Raum 1 (Keller)

Backup 1 im gleichen Raum
von Backup 1 werden automatisch 2 Backup gemacht (auf weiteres Raid im gleichen Raum)
dann wird von Backup 1 automatisch auch noch ein Backup gemacht auf Raid im 3. Stock des Gebäudes. Sprich die Backups (bestehende NAS) backupen sich selbst inkrementiell.

Die Frage ist eigentlich nur... wie bringe ich die Daten vom neuen Mavericks Fileserver auf das Netzwerk-NAS?
0
Cyco
Cyco17.04.1416:01
Wie wäre es mit einem Zeitplan im Carbon Copy Cloner?
Der einzige Nachteil hierbei ist, dass veränderte Dateien in Archivordner verschoben werden.

TimeMachine würde ich nicht nutzen, da es auf einer Freigabe in ein Image sichert.
0
jensche17.04.1416:03
Cyco
Wie wäre es mit einem Zeitplan im Carbon Copy Cloner?
Der einzige Nachteil hierbei ist, dass veränderte Dateien in Archivordner verschoben werden.

TimeMachine würde ich nicht nutzen, da es auf einer Freigabe in ein Image sichert.

mmmh. Irgendwie findet sich kein Gescheites Backupprogramm.

Retrospect hatten wir früher. finde ich nicht das Gelbe vom Ei.

CCC weiss ich auch nicht. Archivordner wäre ja nicht so schlecht, dann würde man die Version im Archivordner haben. wie siehts denn aus wenn das Backupvolume voll ist?
0
Thomas Kaiser
Thomas Kaiser17.04.1416:14
Cyco
TimeMachine würde ich nicht nutzen, da es auf einer Freigabe in ein Image sichert.

Yep. Und an der Stelle könnte es sich lohnen, über iSCSI (also konzeptionell SAN statt NAS, die ganzen NAS-Eimer können ja eigentlich auch iSCSI-Target spielen) nachzudenken. Dann ist das entfernte RAID aus Sicht des Macs lokales Volume.

Fehlt halt nur am Mac der passende iSCSI-Initiator. Den von ATTO kann man sich anscheinend bei Drobos Software "ausleihen" oder zu globalSAN greifen (gleich mit Anleitung für DiskStations: ). Mit dem hab ich null Erfahrung.
jensche
Irgendwie findet sich kein Gescheites Backupprogramm.

Unsere Kunden nutzen fast ausschließlich und cross-platform Archiwares Lösungen für Backup, Sync und Archiv: . In einem reinen OS X Umfeld kann man aber wohl mit einer gscheiden Strategie drauf verzichten.
0
jensche17.04.1416:25
Danke. das werde ich mal testen. Vor der geplanten Migration auf den neuen Server haben wir 3-4 Wochen zeit zu testen... vorab aber die Strategie zu finden.
0
Cyco
Cyco17.04.1416:34
Merci Herr Kaiser.

Dann missfällt mir bis zu dem Punkt nur, dass der MacMini und das Daten-RAID nur einmalig vorhanden sind.
Das OSX würde ich auf einer Partition auf dem Pegasus anlegen, und zumindest nach Änderungen am System dieses stoppen und auf eine externe HD kopieren, damit man ein Notfallsystem hat.
Wenn man einen Clone mit CCC auf eine Synology macht, kann man mit dem Notfallsystem dann zumindest recht kurzfristig einen Zugriff auf diese Freigabe anlegen.

Ergo meine Empfehlung:
1x TimeMachine per iSCSI auf eine Synology im Keller.
1x CCC per iSCSI auf die andere Synology im Keller, und diese auf die im 3ten Stock spiegeln lassen.
1x externe HD um die ServerHD nach jeder Änderung der Einstellungen mit CCC zu kopieren.

Das ist zwar weit weg von Perfekt, aber sollte unter den Voraussetzungen ordentlich funktionieren, und im Notfall ein baldiges Weiterarbeiten gewährleisten.
0
Cyco
Cyco17.04.1416:35
jensche
Vor der geplanten Migration auf den neuen Server
Ihr wollt aber nicht wirklich einen älteren OS-X Server auf einen neuen migrieren, oder?
0
jensche17.04.1416:40
Cyco
jensche
Vor der geplanten Migration auf den neuen Server
Ihr wollt aber nicht wirklich einen älteren OS-X Server auf einen neuen migrieren, oder?

Ah nein... wir werden unser Synology NAS durch einen Mac Server ersetzen. Sprich mit der Migration meine ich mehr die kompletten Files.


Ansonsten wird alles sauber und frisch aufgesetzt. Von Null auf.
0
jensche17.04.1416:43
Cyco
Merci Herr Kaiser.

Dann missfällt mir bis zu dem Punkt nur, dass der MacMini und das Daten-RAID nur einmalig vorhanden sind.
Das OSX würde ich auf einer Partition auf dem Pegasus anlegen, und zumindest nach Änderungen am System dieses stoppen und auf eine externe HD kopieren, damit man ein Notfallsystem hat.
Wenn man einen Clone mit CCC auf eine Synology macht, kann man mit dem Notfallsystem dann zumindest recht kurzfristig einen Zugriff auf diese Freigabe anlegen.

Ergo meine Empfehlung:
1x TimeMachine per iSCSI auf eine Synology im Keller.
1x CCC per iSCSI auf die andere Synology im Keller, und diese auf die im 3ten Stock spiegeln lassen.
1x externe HD um die ServerHD nach jeder Änderung der Einstellungen mit CCC zu kopieren.

Das ist zwar weit weg von Perfekt, aber sollte unter den Voraussetzungen ordentlich funktionieren, und im Notfall ein baldiges Weiterarbeiten gewährleisten.

Genau, wir werden auf einer Partition beim Pegasus Raid OS X Server laufen lassen. Das ganze dann auf die interne Platte spiegeln. Zudem auf dem Admins Arbeitskiste das gleiche aufsetzen. Im schlimmsten Fall könnte das Pegasus via Admins Mac laufen.

iSCSI werde ich mich reinlesen. das kannte ich bis anhin nicht.
0
Cyco
Cyco17.04.1416:43
OK. Das klingt sauber
Apple bietet die Möglichkeit der Migration, jedoch geht dabei gerne mal was schief.
0
Thomas Kaiser
Thomas Kaiser17.04.1416:49
Cyco
Dann missfällt mir bis zu dem Punkt nur, dass der MacMini und das Daten-RAID nur einmalig vorhanden sind.
Das OSX würde ich auf einer Partition auf dem Pegasus anlegen, und zumindest nach Änderungen am System dieses stoppen und auf eine externe HD kopieren, damit man ein Notfallsystem hat.

Und wenn man in diesem Notfallsystem die Chose mit dem iSCSI-Initiator passend konfiguriert hat und parallel dafür sorgt, dass wie Du schon vorschlägst das Pegasus 1:1 gesynct wird, ist die fehlende Redundanz bei Mini und Pegasus auch nicht mehr das Thema. Im Worst Case wäre dann die Performance beim Zugriff auf die Daten via iSCSI eingeschränkt, womit man sicher leben kann (abgesehen von ggf. fehlenden Änderungen im OD oder anderen Settings, wenn man das Syncen des Notfallsystems nicht sehr kurz vorher durchgeführt hat). Allerdings sollte der Worst Case paarmal durchgespielt werden, grad wenn man iSCSI-Rookie ist
0
Cyco
Cyco17.04.1418:22
Deshalb ja der Hinweis das System nach jeder Änderung mit CCC kopieren, damit das notfallsystem annähernd aktuell bleibt.

Was jedenfalls nicht geht ist das Backup genauso zu benennen wie das Pegasus.
Optisch wird es gleich heißen, aber systemintern hängt OS-X Zahlen an um die zu unterscheiden. Und dann kommt es gerne mal zu Problemen.

Aber solange man eine Downtime von ca. einer Stunde verkraften kann, dann braucht man nur die Freigaben neu anlegen, was bei einer kleineren Firma normalerweise kein Problem ist, solange man die zugriffsrechte nicht zu sehr verschachtelt.

Insgesamt bekommt man meiner Meinung nach, damit eine günstige Backuplösung inkl Notfallsystem.
Natürlich sollte man auch bedenken, dass sie keinen 100% Schutz für jede einzelne Datei bietet, und es wenn es knallt eine gewisse Downtime gibt die man überbrücken muss.
0
Thomas Kaiser
Thomas Kaiser17.04.1418:57
Cyco
Deshalb ja der Hinweis das System nach jeder Änderung mit CCC kopieren, damit das notfallsystem annähernd aktuell bleibt.

Grad nochmal kurz drüber nachgedacht. Da das ja eh nichts mit Backup zu tun hat sondern nur 1:1 Sync, damit man im "worst case" ein möglichst identisches System hat, von dem man auch Booten kann, könnte man an der Stelle ggf. alternativ oder ergänzend über Apples Software-RAID nachdenken, um zwei Platten permanent synchron halten zu lassen.

Ein aufgedröseltes Spiegel-AppleRAID funktioniert ja einfach so, auch wenn eine Hälfte fehlt. Manche Leute machen das ja sogar gleich mit ganzen Macs, siehe .

Soweit braucht man ja nicht gehen bzw. im konkreten Szenarium, wo's mehr darum geht, das Notfallsystem "weit genug weg" vom "Server" unterzubringen, wäre ein Spiegel mit einer direkt angeschlossenen Partition/Platte und einer weiter entfernten evtl. sinnvoll. Blöd nur, dass optische TB-Kabel mit denen man evtl. bis in andere Brandabschnitte käme, hierzulande wohl nach wie vor nicht liefer-/bezahlbar sind und dort, wo man sie bestellen könnte, noch schicke Phantasiepreise abrufen:

Naja, letztlich braucht man mit 'nem Mini eh nicht beliebig über Redundanz nachdenken...
0
Cyco
Cyco17.04.1419:52
Ja deshalb mein Vorschlag lokal zumindest eine externe HD für TimeMachine zu nutzen.
Und den Sync der Daten über CCC zu realisieren, wo man die gelöschten und geänderten Dateien in ein Archiv packen lässt.
0
jensche22.04.1411:18
Ich bin mich gerade am reinschauen bei iSCSI, Global SAN Setup usw.

Was ich mich bei iSCSI LUN und Databackup nicht verstehe ich wann macht es Sinn wann nicht.
Beim LUN ist das Problem das man eigentlich nur via jeweiliger Software was restoren kann. Bei Databackup kann man inkrementiell einfach 1 Datei rausholen. Man hat die Daten voll offen.

Aber vielleicht stehe ich da auf dem Schlauch.
0
Cyco
Cyco22.04.1412:01
Also einfach gesagt, sorgt iSCSI dafür, dass Du einen Netzwerkspeicher hast, der vom Rechner als lokaler Speicher erkannt wird.
Also auf die Art kannst Du sogar mit TimeMachine auf die Synoloy sichern, ohne den Nacheil, dass das Backup in ein Image geschrieben wird. Und den gelegentlichen Problme die da gerne mal auftreten.
0
jensche22.04.1412:08
Cyco
Also einfach gesagt, sorgt iSCSI dafür, dass Du einen Netzwerkspeicher hast, der vom Rechner als lokaler Speicher erkannt wird.
Also auf die Art kannst Du sogar mit TimeMachine auf die Synoloy sichern, ohne den Nacheil, dass das Backup in ein Image geschrieben wird. Und den gelegentlichen Problme die da gerne mal auftreten.

Eben iSCSI macht ja ein Image auf dem Fileserver... das ist ja nicht so optimal.
0
Thomas Kaiser
Thomas Kaiser22.04.1412:34
jensche
Eben iSCSI macht ja ein Image auf dem Fileserver... das ist ja nicht so optimal.

Nein, nix Image.

iSCSI reicht das Dateisystem der Synology als sog. "block device" raus, d.h. es ist kein NAS-Protokoll, bei dem sowas wie Locking, konkurrierender Zugriff, das Verhalten von Programmen bzw. APIs eine Rolle spielt, sondern es ist wie eine lokal verfügbare Platte, die ihre "Sektoren"/"Blöcke" an OS X hochreicht (nix anderes passiert bei iSCSI, bloß dass hier besagte Blöcke über TCP/IP an den Mac herangereicht werden).

Für den Mac ist das eine Abstraktionsschicht (also iSCSI/Netzwerk) aber oberhalb dieser Schicht sieht er nix weiter als ein Disk Device mit soundsoviel Blöcken. Und da klatscht er bzw. Du nun sein HFS+ drauf und fertig. Die ganzen Zugriffssemantiken sind anschl. 1:1 so, als hättest Du eine lokale Platte per SATA, Firewire, USB oder eben... tätäää... SCSI am/im Rechner. Auf diese iSCSI-LUN (dazu kurz unten noch was) wirst Du auch unfallfrei nur von einem Mac zur gleichen Zeit zugreifen können. Die iSCSI-LUN verhält sich eben wie eine Disk/Partition einer lokal angeschlossenen Platte.

Damit Du diese LUN an einem anderen Mac verwenden kann (also analog dem Umhängen einer externen Firewire-Platte bspw.) braucht's dort aber identische Randbedingungen, d.h. auch wieder einen passenden iSCSI-Initiator mit identischen Settings. Dann wird dort die iSCSI-LUN genauso behandelt wie eine stinknormale Platte und dann klappt's auch da wieder mit quasi-lokalem TimeMachine-Backup und -Restore.

Thema LUN bzw. iSCSI generell: Ohne Adaption der iSCSI-Grundlagen wirst Du leider nicht besonders weit kommen. Kann da leider keine spezifische Literatur empfehlen, da als "Hardcore-Techniker" zu betriebsblind. Und iSCSI abseits reiner Nutzung für Backup bedingt, sehr genau im LAN zu wissen, was man tut. Da kann man sich durch Fehlkonzeption nämlich gerne mal die Performance komplett zerschießen (es geht auch anders: Übers lange WE einen iSCSI-Filer aus OS X VMs raus vermessen: Lesend/schreibend ohne weiteres Tuning um die 500 MByte/sek)
0
jensche22.04.1413:04
ja. ich bin gerade am reinlesen. und ich werden auch LUN iSCSI Szenarien getestet. soviel ich gelesen habe braucht neben Target, Initiator (global SAN) auch noch eine SAN Userverwaltung.. z.b. SAN MP.

ich bin da dran.



0
jensche22.04.1413:20
Je mehr ich mich mit dem Thema auseinandersetze Frage ich mich was die Vorteile von iSCSI gegenüber normalem Fileserver (AFP oder SMB2) sind...

Was spricht für iSCSI? Was für AFP oder SMB2, sprich normaler OS X Fileserver Umgebung?

0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.