Neuer WG Server, Datensicherung

tarzan

New member
Themenstarter
Registriert
12 Nov. 2008
Beiträge
669
Hi,

unser Server in der Bude muss mal wieder überarbeitet werden (Im Moment ein Duron 800, 384 MB Ram, Debian 4.0). Anforderungen:

-Samba
-LAMP (Wiki, /WebDAV
-Streaming (Twonky Media scheint sein Geld wert zu sein?)
-Subversion

Zunächst werde ich vermutlich ein altes Asrock Board weiterverwenden, mit einem alten P4 drauf. Energiespartechnisch natürlich nicht grade das gelbe vom Ei, aber es hat einen SATA Controller und liegt im Moment eh nur hier rum. 1 GB Ram sollten mehr als ausreichen. Hatte noch überlegt gleich ein Intel Atom Board mit zu bestellen, gibts ja auch schon für wenig Geld.

In Sachen Verfügbarkeit der Daten habe ich mich für ein RAID1 (Software RAID) mit zunächst 2x 1TB entschieden (Platten sind schon unterwegs). Als Backup dienen erstmal diverse Platten aus dem alten Server, die dann eingemottet werden. Auf die Dauer ist das aber nichts, ich bin mittlerweile ernsthaft am überlegen mir ein DLT Laufwerk zuzulegen. Die Datenmengen bekommt man ja heutzutage kaum noch in den Griff. Oder vielleicht doch noch eine dritte Platte, per USB oder eSATA? Wie löst Ihr das Dilemma?

Hat jemand Erfahrungen mit diesen NAS Geräten gemacht? Wie lässt sich die Datensicherung hier einfach realisieren?
 
Warum keine SATA-Raid-Controllerkarte mit Raid 5? 3x 1TB Platte resultiert in 2TB.

Ansonsten gehts fast nur noch mit zusätzlichen, physikalisch getrennten Laufwerken, welche nicht ständig online sind. DLT geht ja auch nur bis 400GB und kostet heftig..
 
Ein SATA Raid Controller kostet extra und macht mich abhängig vom Hersteller. RAID5 hatte ich mir für die nächste Generation vorbehalten (wenn das RAID1 voll ist Daten sichern, neue Platte dran, RAID5 aufsetzen, Daten zurückspielen).

Aber ich glaube auch die einzig vernünftige Lösung ist einfach noch eine weitere externe Platte. DLT in der Größenordnung ist ja wirklich unbezahlbar.
 
Nahezu alle "consumer" Nas Geräte sind ellendig langsam. Siehe diverse Tests auf tomshardware.de/us Es gibt ein paar "flashbare" wo man Debian drauf spielen kann, hier kenne ich mich allerdings nicht gut genug aus.
Von dem Asrock board als server würde ich fix Abstand nehmen, ich habe zwar auch 2 in Betrieb aber als server sind die gänzlich ungeeignet. Würde dir nen "kleines" Board mit 700er SB von AMD samt 4450e CPU empfehlen. Den Ram (ist ja ddr2?) kannst du übernehmen. Die backup Festplatten würde ich ebenfalls per esata anschließen. Das ist die schnellste Lösung. Ein entsprechendes Board wäre zb das hier: http://www.heise.de/preisvergleich/a345900.html Dieses bringt den esata controller gleich mit. Entsprechende externe Cases kosten auch nicht die Welt, so sparst du ne Menge knete. Das Ganze sollte dich dann nicht mehr als 120€ kosten. Board 65+ CPU 45€ +20€ Esata Hd Gehäuse. Ist halt die Frage ob ihr bereit seit soviel auszugeben. Sparsamer gehts allerdings immernoch. An der CPU kannst du noch deutlich sparen. Eventuell einen Sempron nehmen und runtertakten. DAnn hast nen schön sparsames System (obwohl der 4450 auch shcon recht nett ist, grade mit cnq).

Esata Raid controller ist Overkill für ne Studi bude :) Da reicht sw raid doch dicke aus! Evtl. ist hier freenas auch was für dich. musst mal schaun ob da LAMP (Wiki, /WebDAV Streaming und
Subversion drauf laufen. Glaube eher nicht. Hier könnte Xen evtl. ne Möglichkeit sein. Debian als host, freenas und der rest virtualisiert. Da die cpu auch amd-v unterstütz wäre das sogar einigermaßen performant. :)
 
Ich kenne die Mythen um die Asrock Boards, bin bisher aber verschont geblieben. Die Kiste hat mir jahrelang gute Dienste geleistet. Zudem läuft sie noch mit DDR1 Modulen, DDR2 hatte ich damals dezent übersprungen. Warum sollen die Boards für den Serverbetrieb (für daheim!) ungeeignet sein?

Den Eindruck von den NAS Geräten teile ich, die Performance scheint nicht so der Hammer zu sein. Irgendwann soll dann halt doch mal Gigabit Lan her, und spätestens dann beißt man sich in den Allerwertesten.
 
Ungeeignet für den dauerbetrieb aufgrund der bei 24h betrieb ziemlich strapazierten elkos. Das board was ich dir vorgeschlagen habe hat zB "All Solid Capacitors" was eine längere lebensdauer verspricht. Wie gesagt, ich hab auch 2 Asrock boards und bin zufrieden aber als server, neeeee danke :)
 
Da es "nur" um ein Volumen von 1TB geht kopierst du einfach den kompletten Inhalt einmal pro Woche auf eine externe Platte. Du kannst ja zwei externe Platten kaufen und abwechselnd benutzen,... alles andere DLT etc.. kommt wesentlich teurer.

Im folgenden Thread habe ich mein System ein wenig beschrieben:

Stromspar NAS

Eine Intel-Server-Netzwerkkarte lohnt sich was die Performance angeht, gerade auf schwachen Systemen, den Adaptec Controller kann ich echt empfehlen.

MfG Hanussen
 
Was sagt ihr zum Dateisystem? Bisher läuft ext3, keine Probleme. ext4 ist mir noch etwas zu neu, Opensolaris in Verbindung mit ZFS würde mich ja fast mal reizen. Scheint ja doch ziemlich komfortabel zu sein.
 
Ich betreibe schon länger einen Linux Samba Fileserver und zwar folgendermaßen:

Kein RAID - was nützt dir denn die Hochverfügbarkeit? Wenn du es wirklich als nötig erachtest bitteschön, aber immerhin geht die da ordentlich Platz flöten - ein Backup musst du ja so oder so noch machen, daher würde ich persönlich auf RAID verzichten.
Ich habe mehrere Festplatten zu einem LVM zusammengefasst, genauer gesagt habe ich 2 LVMs die gleich groß sind, das eine LVM dient als Backup für das andere. Man mag sich jetzt natürlich streiten das ein richtiges Backup am besten auf einer anderen Maschine in einem anderen Gebäude liegt, aber für meine Zwecke reicht das aus.
Wenn der Platz ausgeht kaufe ich einfach 2 neue Festplatten, was auch immer grade in €/GB am günstigsten ist und nehme diese ins LVM auf. Als Dateisystem verwende ich XFS, bisher ohne jegliche Probleme.

Wegen der Hardware: 780G Chipsatz mit AMD 'e' CPU wäre auch meine Empfehlung.
 
In Sachen Sicherheit bringt es auch nicht wirklich viel, da du ja dennoch das Risiko hast, dass dir zwei neue Platten gleichzeitig abrauchen. So gesehen hast du sicherheitstechnisch effektiv das gleiche wie ich mit dem Raid, durch den LVM machst du es dir aber komfortabler, grade was das das Einbinden neuer Platten angeht.
 
Naja, ein Backup machst du ja nicht nur, damit deine Daten noch da sind wenn dir eine Platte abraucht (dafür würde ja RAID auch reichen), sondern auch falls mal ungeplant ein paar wichtige Daten gelöscht wurden oder defekt sind.
Diese Änderungen werden ja z.B. bei RAID 1 direkt auf die Spiegelplatte übertragen und dann hast du einen Datenverlust, den du ohne Backup nicht kompensieren kannst.

D.h. man kommt zwar ohne RAID aus, aber nicht ohne Backup.

Die Problematik, dass zwei neue Platten möglicherweise gleichzeitig kaputt gehen wird zudem dadurch abgeschwächt, dass die Backup-Platte ja deutlich weniger in Betrieb ist (z.B. nur einmal pro Tag um das aktuelle Backup zu erstellen).

Ich plane zur Zeit auch einen Homeserver und werde nach aktuellen Erkenntnissen wohl auf ein LVM ohne RAID aber mit reversem inkrementellem Backup (rdiff-backup) setzen. Das letzte Backup liegt dabei immer als Snapshot des zu diesem Zeitpunkt aktuellen Datenbestands vor und kann bei einem Crash der Hauptplatte bzw. sonstigem Datenfehler direkt gemountet werden, während sich die weiter zurück liegenden Backups dann inkrementell rekonstruieren lassen, falls der Bedarf besteht.

Ob das dann in der Praxis alles so gut klappt, kann ich allerdings erst sagen, wenn das System auch tatsächlich läuft :)

PS: Beim Board tendiere ich übrigens zu dem von Hanussen verwendeten Gigabyte GA-MA78G-DS3H
 
da ich die Betriebssysteme Klausur schiebe kann ich dir nur sagen wie ich das unter Windows mache, die Technik dort heißt Soft- bzw. Hardlinks. Damit lassen sich platzsparend verschiedene Versionsstände archivieren und einfach Backuppen. Ich glaube das Tool kommt sogar aus dem Unix-Umfeld: Rsync.

MfG Hanussen
 
Also ich bin mittlerweile soweit das ohne RAID zu machen. Würde einfach LVM aufsetzen und erstmal nur eine Platte in den Pool hängen, damit ich das zur Not später noch einfach erweitern kann. Problematisch ist jetzt, wie mache ich das Backup hierzu? Sobald ich mehr als eine Platte im LVM habe klappt das mit rsync nicht mehr ohne weiteres.

Möglichkeit wäre ein zweites LVM aufzusetzen, auf das die Daten gespiegelt werden (in meinem Fall hier eSATA Platten, die ich einmal pro Woche anschließe). Problem hier: Sobald eine der (Backup) Platten ausfällt sind die Daten (des Backups) komplett weg (man benutzt LVM ja nicht ohne Grund in der Regel mit einem RAID1 dahinter).

Bleibt die Möglichkeit die internen Platten über ein LVM aneinanderzuhängen und das Backup manuell auf mehrere Platten zu verteilen. Das ist zwar reichlich umständlich, scheint mir aber das einzig praktikable im Moment zu sein.
 
???????????????????????????

Du kommst doch ganz normal an deine Dateien heran und kannst sie mit jedem Tool (tar,...) auf eine externe Festplatte kopieren...

Einmal pro Woche alle Benutzerverzeichnisse auf ne externe Platte und gut ist... Die Bootplatte mit dem Betriebssystem würde ich mit Acronis sichern.

Alternativ definierst du bestimmte Restore-Points (wie auch immer die im LVM heißen) und gibst als Ziel eine dritte Platte an.

Oder du fährst den Server einmal die Woche herunter und machst ein komplettes Acronis-Backup (Einmal pro Monat voll, sonst inkrementell)

MfG Hanussen
 
Das Problem ist nach wie vor wie erstell ich zur Laufzeit nen Backup des kompletten Inhalts? Um den Snapshot zwischenzuspeichern brauch ich ja euch erstmal Platz (genausoviel wie auf der Kiste liegt, bei mehreren Platten im Pool wird das problematisch), bevor ich den auf mehrere (externe Backup) Platten splitten kann... Sprich ich bräuchte einen Storage Pool (wo die Daten liegen), einen Snapshot Pool (wo ich den Snapshot hinziehe) und die externen Backup Platten, auf die ich den Snapshot dann verteile... wobei, erstellt LVM den Snapshots mittels Links oder zieht der wirklich eine Kopie jeder Datei?

Edit: Typo, genauere Erklärung
 
Also ich versteh dein Problem auch grad nicht so wirklich.

Du hast ein logisches Volume (LV1) auf dem deine Daten liegen, und ein LV2, das du für das Backup verwendest. Dabei sollte LV2 natürlich mindestens die Kapazität von LV1 haben, um wenigstens einen Snapshot aufnehmen zu können (wenn du mehrere Snapshots sichern willst, brauchst du natürlich mehr Speicherplatz).
Außerdem sollten die LVs auf jeweils eigenen physischen Platten liegen, damit bei einem Defekt entweder nur dein aktueller Datenbestand, oder dein Backup kaputt gehen kann und nicht beides gleichzeitig.

Da du ja einen Linux-Server einsetzt, ist als Backup-Software ja das von mir angesprochene rdiff-backup vielleicht auch eine Lösung für dich, meine Überlegungen bzgl. dieses Tools hab ich ja schon oben etwas näher erläutert.
 
Das Problem ist ich will keinen 2. Pool für das Backup haben. Wenn von den Backup Platten eine ausfällt, ist in diesem Fall das komplette Backup im Eimer, sonst nur die Daten die auf dieser Festplatte waren. So gesehen kann ich auch keinen tarball aus allen Daten machen und auf mehrere Platten splitten. Ich fürchte da muss ich mir selbst was zusammenskripten:

1. Platten ro remounten
2. Skript schreiben, was die Daten möglichst effizient auf mehrere externe Platten sichert. Dabei soll kein RAID und kein Storage Pool zum Einsatz kommen.
3. Platten rw remounten

Edit: Zu 2.: Womit ich beim Rucksackproblem wäre wenn ich mich nicht irre :(
 
Wenn du (warum auch immer) ein ausfallsicheres Backup haben willst, dann kommst du an einem RAID ohnehin nicht vorbei.

Ansonsten musst du bei einem Defekt ja ohnehin die Platte austauschen, und ob du dann nur einen Teil oder das gesamte Backup neu erstellst, spielt dabei auch keine Rolle mehr.

Ansonsten solltest du nicht vergessen, dass mit der Anzahl der Festplatten auch das Ausfallsrisiko insgesamt steigt, weshalb ich bei deinem Ansatz mit dem splitten des Backups auf mehrere Platten eigentlich keinen Vorteil erkennen kann.
 
  • ok1.de
  • IT Refresh - IT Teile & mehr
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben