Neu Datenbank auf einen NAS-Server verschieben

[Rihino]

Das war passiert:
Der PC auf dem sich die Datenbamk der WAWI befand fiel plötzlich durch einen Defekt für einen Tag aus.

Die Folgen:
Die WAWI konnte nicht verwendet werden.

Die Lösung:
Es wurde ein NAS-Server mit zwei gespiegelten Festplatten installiert und zusätzlich noch eine weitere Netzwerkfestplatte um auch noch das NAS zu sichern.
Mittlerweile wurden alle relevanten Daten auf den NAS-Server verschoben, alles funktioniert reibungslos. Ich kann jetzt wieder einigermaßen durchschlafen.

Problem:
Es verbleibt jedoch noch ein Problem: Wie bekomme ich die Datenbank der WAWI auf den NAS-Server (konfiguriert als File-Server) verschoben? Der Server wird nicht als Arbeitsplatzrechner verwendet werden. Bei den Access-Datenbanken war das recht einfach: Diese wurden einfach auf den Server verschoben. Bei der SQL Datenbank hab ich leider keinen Schimmer.

Kann mir jemand einen Tipp oder Hinweis geben?

 

[elevennerds.de]

Du möchtest die Datenbank von einem Share aus betreiben? Das ist nicht möglich.

 

[Shopworker.de]

Lass die SQL-Datenbank auf einem performaten Rechner laufen und sichere die Datenbank lieber regelmäßig auf dein NAS, z.B. auch stündlich ... theoretisch auch jede Transaktion ...

 

[maydo]

auf einer nas würde ich min. nen i5 mit 16 GB Ram und min. 5er Raid SSDs empfehlen.

 

[Rihino]

Die Datenbank lief auf einerm I7 mit 16 GB und 256 GB SSD.

Auch ein häufiges sichern der Daten hilft nicht weiter wenn der performante Rechner durch einen defekt ausfällt. Denn die Daten mögen dann zwar erst einmal auf dem neuesten Stand als bak-Datei vorliegen, dennoch fällt der performante Rechner im Falle eines Defektes nun mal definitiv aus und die WAWI kann ersteinmal nicht mehr genutzt werden!

Der deutlich sicherer Weg ist die von mir beschriebene Konfiguration durch eine NAS mit mind. 2 Festplatten. Fällt hiervon eine aus, läuft die WAWI problemlos weiter. Sollte das NAS komplett ausfallen ist immer noch die zusätzliche Netzwerkfestplatte vorhanden. Mit wenigen Handgriffen bzw Clicks stellt diese dann die Daten zur Verfügung. Hier natürlich kann überlegt werden wie oft die Daten (automatisiert) vom NAS auf die Netzwerkplatte gesichert werden; z.B. stündlich oder öfter.

Anders als dropshppoint meint meine ich, dass die Datenbank durchaus irgendwie auf eine NAS übertragen werden kann, denn die WAWI kann von Natur aus auf eine beliebige freigegebene Datenquelle zugreifen kann, denn die Software ist Netzwerkfähig!

Die Frage ist daher immer noch: Wie bekomme ich die Daten auf das NAS?
Oder anders gefragt: Wie bekomme ich die Daten auf einen separaten Server kopiert?

 

[rmb]

Anders als dropshppoint meint meine ich, dass die Datenbank durchaus irgendwie auf eine NAS übertragen werden kann, denn die WAWI kann von Natur aus auf eine beliebige freigegebene Datenquelle zugreifen kann, denn die Software ist Netzwerkfähig!

Die Frage ist daher immer noch: Wie bekomme ich die Daten auf das NAS?
Oder anders gefragt: Wie bekomme ich die Daten auf einen separaten Server kopiert?

Netzwerkfähig ist die Software, das ist korrekt. Allerdings muss sie im Netzwerk auch einen passenden Server finden, mit dem sie kommunizieren kann. Ein NAS ist üblicherweise ein reiner Fileserver, der Dateien über beliebige Protokolle zur Verfügung stellt. Das kann SMB sein, NFS, FTP oder derlei mehr.
Die Wawi setzt allerdings einen SQL-Server voraus, sprich ein Programm, das zur Verwaltung von SQL-Datenbanken dient. Einfach nur die Backupdatei auf dem NAS abzulegen bringt da nichts. (Ist allerdings im Sinne der Datensicherheit eine gute Idee.)

 

[elevennerds.de]

Versuche es mal mit iSCSI, damit kannst Du ein NAS als Laufwerk im Netzwerk einbinden. Mit einer 10Gbit-Anbindung sollte das sogar einigermaßen schnell laufen. (TCP-Latenz bleibt natürlich)

 

[SebiW]

Wenn Du in Deinen performanten Rechner ein Raid 1 einbaust und einen externe Platte jede Stunde die Wawi DB spiegeln lässt ist dies exakt genau so sicher wie Dein NAS. Der einzige Unterschied ist, dass Du dann auch die Wawi betreiben kannst.
Das Problem ist hierbei nicht die Wawi sondern der SQL Server, denn Du mit Umwegen vielleicht dazu bringen kannst Dein NAS als Speicherbereich zu akzeptieren, bspw durch oben vorgeschlagenes mounten. Performant wird das aber nicht.
Und Du hast dann zwei Systeme die bei einem Ausfall Dein Büro lahmlegen, also rechnerisch eine deutliche Verschlechterung der Verfügbarkeit.
Willst Du Hochverfügbarkeit kommst Du an redundanten Systemen, also nicht nur mehrfach gespiegelten Platten sondern mehrfach vorhandenen kompletten Rechnersystemen, nicht vorbei.

Bei uns steht neben dem Wawi Server deshalb auch ein mittlerer i5 dessen einzige Aufgabe es ist im Falle einens Serverausfalles hochgefahren zu werden, die neuesten Backups gefüttert zu bekommen und dann die WAWI Verfügbarkeit für die Zeit des Ausfalles des Hauptsystemes sicherzustellen. Der ist zwar nicht so performant wie der dicke, war aber billiger als es rechnerisch ein halber Ausfalltag wäre...

 

[Rihino]

Liebe Freunde,

es ist im Grunde ganz einfach. Hier ein Lösungsvorschlag:

Schritt 1:
Das NAS oder einen Teil der Festplattenkapazität als Server freigeben.
Dieser steht nun Netzwerlfestplatte zur Verfügung.

Schritt 2:
Am besten einen neuen PC - oder preiswerter: ein einfaches Notebook - bereitstellen.
Das Netzlaufwerk ist im Windows-Explorer sichtbar.

Schritt 3:
Diese Laufwerk kann nun im Windows-Explorer als eigenständiges Laufwerk mit einem einem eigenen Laufwerksbuchstaben eingebunden werden.
Damit sieht das NAS-Laufwerk für Windows so aus als handle es sich um eine im Rechner vorhandene Festplatte.
Als Laufwerksbuchstaben enpfehle ich N (als NAS) oder S (als Server).

Schritt 4:
Die WAWI wird nun auf dem neuen Rechner ganz normal installiert.
Der SQL-Server landet dabei ganz wie von Zauberhand auf dem NAS-Server!

Schritt 5:
Von der vorhandenen WAWI eine Sicherungskopie erstellen.
Die Datei-Endung laztet ".bak".

Schritt 6:
DIe Sicherungskopie nun einfach in der neu aufgesetzten WAWI ausspielen.
Die aktuellen Daten liegen nun auf dem NAS-Server und kann vom neuen Rechner bereits verwendet werden.

Schritt 7:
Alle anderen Rechner, welche die WAWI nutzen sollen, wird nun der NAS-Server ebenfalls hinzugefügt.
So wie in den Schritten 2 und 3 beschrieben.
Auf diesen Rechnern wurde bereits eine Netzwerkinstallation durchgeführt.

Schritt 8:
Diesen Rechnern muss nun nur noch mitgeteilt werden, dass sie ab sofort die Datenbank unter dem neuen Laufwerksbuchstaben verwenden soll.

Fertig!

 

[Rihino]

Der vorgenannte Lösungsvorschlag hat den großen Vorteil, dass man nun von jedem (performanten) Rechner unabhängig ist.
Nirgendwo muss ein RAID eingebaut werden (Was auch gegen die Regel "Never Touch a running system" verstoßen würde).
Der nachträglich RAID-Einbau hätte immer noch den Nachteil, dass bei Ausfall des Rechners die WAWI nicht mehr nutzbar ist (so hatte ich es - wie oben beschrieben - leider erleben musste).

Hinweise:
NAS-Server, Notebook und die erwähnte zusätzliche Netzwerkfestplatte verursachen nur relativ geringe Kosten, erhöhen aber immens die Datensicherheit und Verfügbarkeit des Systems
Nachteil ist jedoch, der zeitliche Aufwand für die Neuinstallation der WAWI auf dem Notebook.
Auf den übrigen Rechnern dürfte die Umstellung nur wenige Minuten dauern.
Für die Verlegung der WAWI kommt es zu einer relativ kurzen Ausfallzeit, nämlich die es dauert die bak-Datei zu erstellen bis zur Wiederherstellung über das neue Notebook. Die Einzelnen Rechner können nun nach und nach umgestellt werden.

Bitte beachten:
Das ganze ist bisher nur ein Vorschlag bzw. eine Idee! Es bedeutet einen deutlich größeren Aufwand als ich mir ursprünglich erhofft habe. Vielleicht hat noch jemand einen anderen Vorschlag oder sinvolle Anmerkungen.
Am liebsten wäre mir ein Tool gewesen, mit dem die Datenbank auf das NAS-Laufwerk verschoben worden wäre.

 

[_simone_]

Hm, was ein Aufwand. Ich sehe das eher wie @SebiW :

Bei uns steht neben dem Wawi Server deshalb auch ein mittlerer i5 dessen einzige Aufgabe es ist im Falle einens Serverausfalles hochgefahren zu werden, die neuesten Backups gefüttert zu bekommen und dann die WAWI Verfügbarkeit für die Zeit des Ausfalles des Hauptsystemes sicherzustellen. Der ist zwar nicht so performant wie der dicke, war aber billiger als es rechnerisch ein halber Ausfalltag wäre...

So sieht es in etwa bei uns auch aus. Sollte der Server ernsthaft kaputt sein, wird ein Clientrechner mit MSSQL-Server im Schlummermodus, zum neuen temporären Server befördert. Backup drauf und weiter gehts.

 

[Rihino]

Die Lösung von SebiW und Simone sind natürlich gute und gangbare Wege.
Nachdem mir der Rechnerausfall wiederfahren war, hatte ich mir überlegt was für die Zukunft der beste Weg ist Ausfallzeiten und Pannenhäufigkeit nahezu gegen NULL zu setzen.
Ein mittlerer I5 oder Schlummerechner bedeutet im Falle eines Falles immer noch das es zu einem Ausfall der WaWi kommt und diese Bakup-Rechner zusätzlich immer noch zu pflegen sind (Z.B. durch UpDates). Außerdem müssen die Backup-Dateien ja auch an einem sicheren Ort abgelegt werden!
Kommt es bei der NAS-Server-Lösung z.B. zu einem Festplattenausfall kommt es zu keinerlei Verfügbarkeitsunterbrechung. Die defekte Festplatte wird einfach mit zwei Handgriffen ausgetaucht während die WaWi weiterhin ihren Dienst tut.
Im Falle der beschieben Lösungen mit BACKUP-Rechnern gibt es sehr wohl eine Unterbrechung: Denn zum austauschen der Festplatte muss der Rechner heruntergefahren, also abgeschaltet werden. Zudem ist es fraglich ob nach dem hochfahren dann wieder alles Reibungslos weiterfunktioniert. Im Lager und auch auf allen anderen Rechnern kommt es zu zahlreichen Fehlermeldungen.
Nach meiner Betrachtungsweise ist also die NAS-Server-Lösung die bessere wahl.
Alternativ kann natürlich auch ein reinrassiger Server verwendet werden, bei dem die Festplatten ebenfalls von außen und während des Betriebes gewechselt werden können. DIe Kosten für die Anschaffung, Softwareupdates und Festplatten dürften jedoch deutlich höher sein (Alleine die Preise für das ECC-Ram löst Staunen aus) .

 

[SebiW]

Rihino Du hast hier irgendwie eine etwas überzogene magische Vision von der Leistungsfähigkeit eines NAS.

1. Ein NAS ist, zumindest in der Einstiegsklasse, ein Datenträger für Inhalte und dient NICHT der ständigen hochperformanten Hochverfügbarkeit von Daten. Dafür musst Du dann schon deutlich tiefer in die Tasche greifen. Da liegt schonmal Hase 1 im Pfeffer: Natürlich kriegst Du den SQL irgendwie dazu seine Datenbank aufs NAS zu legen. Das wird aber so brechend langsam, dass Du dann auch gleich wieder einen Abakus verwenden kannst. Ein typisches NAS verfügt über 512 MB bis vielleicht 1 Gig RAM und einen langsamen ARM Prozessor, und wir sprechen hier schon über die gehobene Einsteigsklasse wie ein Synology DS216J. Dazu muss jede einzelne Aktion des SQL Servers über das LAN auf dem NAS ausgeführt werden, inklusive massiver zusätzlicher Latenz.

2. Der Betrieb der Wawi setzt einen SQL Server voraus. Der Server verwaltet die Datenbank, nicht die Wawi. Nun gibt es zwar mittlerweile von MS open Betas für den SQL Server auf Linux. Diese setzen aber noch deutlich mehr Nutzerwissen voraus und auch für diese gilt: beschießt Du sie mit nemm langsamen ARM und nemm Gig RAM kannst Du Dir die Mühe gleich sparen.

3. Die von Dir beschriebenen Vorteile eines NAS, also Hotswap bei Ausfall etc, sind problemlos mit einem Mittelklasserechner abzubilden.

4. Und nochmal: Mit Deinem Weg verringerst Du nicht das Ausfallrisiko sondern Du ERHÖHST es! Warum? Hast Du einen Rechner mit Raid 1 und externem Backup gibt es genau dieses eine Systeme das ausfallen kann. Dafür hält man einen günstigen Ersatz für Notfälle vor und fertig. Hast Du 2 Systeme, also einen externen Rechner auf dem der SQL Server läuft und ein NAS gibt es eben auch 2 Systeme die kaputt gehen können. Die Fehleranfälligkeit des NAS ADDIERT sich zur Fehleranfälligkeit des SQL Server Rechners. Denn wenn der Rechner auf dem der Server läuft abraucht musst Du ja dennoch einen zweiten Rechner mit SQL Server vorhalten. Gleiches gilt für das NAS die im Endeffekt auch nur spezialisierte Rechnerhardware sind und dadurch eben genauso einen Defekt aufweisen können. Wir hatten hier in den letzten Jahren da schon alles, von geschossenen LAN Ports bis zu durchgerauchten Netzteilen.

Dein Weg weist keinerlei Vorteile sondern nur immanente Nachteile auf.

 

[Maritimia]

Folgende Überlegung solte man anstellen: 1. Was kann ausfallen 2. was passiert dann.

Der einfachste Fall ist ein Plattenausfall. Dagegen hilft ein RAID. Der schlechtere Fall ist ein anderer Hardwareausfall z.B. ein Motherboard. Dagegen hilft nur Ersatzhardware. Das dümmste wäre jetzt, dass ein Server mit RAID in einem Gehäuse steckt und darauf SQL-Server und Datenbank läuft. Warum? Weil nur eine vollig identische Hardware das RAID wieder zum laufen bringt. Passiert der Fehler nach 2-3 Jahren gibts die Hardware vielleicht nicht mehr. Also lieber Einzelplatte und diese sichern. Dann bleibt alles lesbar.

Meine Lösung:
Schneller Rechner mit z.B. I7 möglichst viel RAM so 32 Gig. und einer schnellen SSD für die Temp-Datenbank und das Betriebssystem. Auf keinen Fall ein RAID für diesen Rechner! Darauf läuft eine virtuelle Maschine (z.B. mit VM-Ware), die den SQL Server bereit stellt. Diese Maschine wird nachts einmal gesichert und zwar auf ein NAS. Bei Ausfall kopier ich die Maschine auf irgend einen anderen Rechner starte sie mit dem VM-Player und weiter gehts (Alle IP`s sind richtig, alles geht sofort). Wohin mit der Bank? Auf ein NAS mit RAID 1 oder 5 oder 10. Die Bank auf dem NAS wird stündlich auf eine externe 08/15 USB 3.0 Platte gesichert (nicht einfach kopiert, sondern DB-Export). Warum diese Sicherung. Damit die Hardware vom NAS kaput gehen darf. Das NAS darf nicht so ein Hausfrauen Wohnzimmer NAS sein. Ich spreche hier vom Einstiegspreis 1.200,- incl. 3x 1TB Platten. UND: es muss mit einem Backbone von 1GBit auf einer eigenen Netzwerkbuchse am SQL Server hängen. Die zweite Buchse kann man gern für weitere Verbindungen ins Netz nutzen.

Wie bekommt man die Bank des Servers auf verschiedene Laufwerke? Das geht mit dem Datenbank-Manager, der beim SQL-Server dabei ist. Dort kann ich für jede Bank angeben, wo sie liegen soll. Die Wichtigsten sind die Temp.-Datenbank und die Hauptdatenbank. Temp. sollte lokal wegen Performance auf SSD liegen.

Bei uns läuft diese Kombi seit 2 Jahren problemlos und ist performant wie Roland. Entscheidend ist außerdem eine gute Kühlung der Server und ein mal im Jahr eine Entstaubung. Eine USV ist selbstverständlich.

Wer eine bessere Idee hat......

Wer es jetzt ganz sicher haben will, baut ein VPN zu einem zweiten Standort auf und nimmt statt der externen Platte am NAS eine Sicherung über die VPN-Verbindung zum externen Standort. Dann ist man auch noch sicher gegen einen Brand oder Raub der ganzen Anlage. ...das geht übrigens mit zwei Friz-Boxen und nein ich bin kein Sicherheitsfanatiker, ich habe Spaß an sowas....-

 

[Rihino]

Vielen Dank für die vielen guten Gedanken und nützlichen Informationen.
Vor allen Dingen die Frage nach dem was ausfallen und dann passieren kann ist Gut und Weise.
Ich sehe das so: Je intensiver die Datenbank genutzt wird - oder anders ausgedrückt: Je mehr Aufträge zu bearbeiten sind - umso mehr werde ich meine Lösung in Richtung Maritimias Lösung weiter entwickeln. Z.Zt. ist die Anzahl der bei mir eintreffenden Aufträge gerade noch überschaubar. Bei Maritimias Firma werden es wohl deutlich mehr sein.

 

[SebiW]

Hi Maritimia, hier scheiden sich die Geister.
Wir nutzen kein NAS sondern einen Hardware Raidcontroller samt mehreren Raid 1 für die einzelnen Mandanten. Dein Einwurf gegen Raid Systeme gilt natürlich nur gegen Onboard Consumer Software Raids. Um dem Problem zu entgehen verwendet man einen separaten Controller auf dem die Einstellungen des ersten bereits gespiegelt sind. Bei einem unwahrscheinlichen Ausfall dieser Komponente ist das Raid so verdammt schnell wieder live.
Aus dem gleichen Grund wie oben würde ich die Datenbank niemals auf ein zweites System legen (außer natürlich man hebt sie gleich in einen gehosteten Verbund oder hat selber die Mittel sowas zu realisieren): Habe ich 2 individuelle Systeme erhöht sich die Ausfalllzeit rein rechnerisch.
Unsere Backups, täglich 2 mal Full, alle 4 Std diferentiell und alle 15 Minuten Transactions Logs, laufen natürlich auf ein NAS und werden zudem alle 24 Std extern via VPN gesichert.

Zum Vergleich: Du hast 2 Komponenten von denen der Ausfall von jeweils einer zu einer Unterbrechung der Verfügbarkeit führt: Fällt der Rechner aus muss auf Ersatz umgestiegen werden. Fällt das NAS aus muss bis Ersatz da ist die Datenbank auf den Server wandern.
Du verwendest das NAS an dieser Stelle also auch nicht anders als als einen externen Raidcontroller. Mit dem Nachteil, dass das NAS deutlich zusätzliche Komplexität bringt weil neben dem Raidcontroller selbst beim NAS auch noch Komponenten wie der LAN Port, das Board oder das Netzteil ausfallen können.

Fällt unser Rechner aus, auf dem Server und Datenbank liegen, schalte ich das Backupsystem ein, spiele die Backups auf und weiter gehts. Fällt Dein Rechner aus schaltest Du den Backuprechner ein, mountest die Datenbank und weiter gehts. Ein Punkt für Dich, weil sicher etwas schneller. bewerkstelligt.

Fällt unser NAS aus habe ich immer noch eine redundante Sicherung durch das Raid 1 im Server. Fällt Dein NAS aus hast Du erstmal nur die Datenbank auf dem Rechner, ohne Sicherung. Du kannst dann zwar die externe Platte dranhängen und damit wieder anfangen zu sichern, hast hier aber keine hochaktuelle Datensicherung. Deutlicher Vorteil für uns.

Außerdem würde ich persönlich für den SQL Server ab einer gewissen Größe keinesfalls mehr ein Standardsystem einsetzen. Wir haben derzeit einen XEON mit 32 GB ECC RAM auf einem Supermicro Board samt passendem Hardware Raidcontroller mit 4x2 Raid 1 laufen. Je ein 2er Verbund für System und jeden einzelnen Mandanten.

Was mir aber gefällt und ich wohl auch noch so umsetzen werde ist der Ansatz den SQL Server zu virtualisieren. Damit kann man die Ausfallzeit gegenüber unserem jetzigen Ansatz sicher nochmal deutlich drücken. Danke für die Idee!

 

[meine-kleine-eisenbahn.de]

Man sollte auch überlegen wie wichtig die sofortige Verfügbarkeit der Datenbank und des Servers ist.
Es kommt sicher auf die Firmengröße an. Ich finde das Wichtigste ist die Sicherung der Datenbank.

Bei uns kommt ein Server mit Raid zum Einsatz, so mit sind wir schon mal gegen den Ausfall einer Platte gesichert.
Für den Fall das die Serverhardware versagt machen wir regelmäßige Backups auf ein NAS.

Wenn der Server ausfällt, wird aus einem Client mal schnell ein Server gemacht und das Backup eingespielt, fertig.
Dauert für mich als (fast) One-Man-Show auch nur ein paar Stunden.
Wenn die WAWI dann mal einen Tag nicht verfügbar ist, ist dass zwar nicht schön aber da kann ich mit Leben.
Es gehen ja keine Aufträge verloren, die werden ja später wieder mit Ebay, Amazon und Shop abgeglichen.

Wenn ich Mitarbeiter nach Hause schicken müsste wären dass dann andere Überlegungen.....

 

[Maritimia]

Hallo SebiW,

ja das mit dem gespeigelten Raid-Controller hatte ich auch ins Auge gefasst. Wir sind ungezogen und hatten zwei von den großen NAS Servern von Qnap und 3 Server mit XEON und 32GB. Leider waren die XEON Server in 2U Gehäusen, die gefühlt 1,50 lang waren. Nach dem Firmenumzug war der neue Serverschrank zu kurz und wir haben hinten die Tür offen gelassen. Das führte dann zur Lärmbelästigung, da der Serverraum genau neben dem Büro ist. Da habe ich die 3 XEON Server rausgeworfen und hab den einen mit dem I7 schnell zusammengestrickt. Da der nur onboard RAID hat, kam die Bank auf einen der NAS Server. Dieses NAS hat sich dann mit dem zweiten NAS syschronisiert. Damit konnte ein NAS ruhig ausfallen. Nach einiger Zeit habe ich festgestellt, dass die NAS Server sich mehr mit Synchronisation als mit Abgabe von Daten beschäftigen. Deshalb bin ich zurück auf Backup der Bank auf externe Platte und habe den 2. NAS Server bei mir zu Hause um die Daten Standort unabhängig noch einmal zu haben.

Sicher ist das nicht optimal die Datenbank nicht auf dem Server zu haben. Allerdings müsste ich dann auch zwei identische RAID Controller haben, die in einem Rechner stecken. Meiner Erfahrung nach sterben meist die Netzteile an den Servern zu erst, Platten mal außen vor gelassen. Wenn das Netzteil "positiv" stirbt dann kann man es austauschen und weiter gehts. Stirbt es "negativ" nimmt es das Board und evtl. noch mehr mit ins Grab. Dann sind die RAID-Controller auch weg. Deshalb erschien mir die Lösung mit der Bank auf dem NAS als nicht so unplausibel. Ja es sind zwei Geräte und die Ausfallwahrscheinlichkeit ist höher.

Was ich trotzdem empfehlen kann ist ein zweistufiges Backup. Mit zwei Stufen meine ich Backup des ersten Backups auf eine weitere Hardware oder ein Serververbund mit Synchronisation.
Und was auch genial ist, ist die Virtualisierung. Nichts geht schneller, als eine virtuelle Maschine auf einer anderen Hardware zu starten.

Wer das hier liest wird sicher denken. Was der da schreibt ist völliger Overkill. Ja das ist auch so! Realistisch gesehen sterben Server wirklich selten. Man kann es auch einfacher haben und genau einen Server nehmen und da ist alles drauf. Dazu kauft man eine externe Festplatte. Diese beiden Komponenten kauft man alle 3 Jahre neu. Die Ausfallwahrscheinlichkeit steigt nach ca. 3 Jahren recht deutlich an. Auf dem Server läuft eine Virtuelle Maschine mit SQL Server und Datenbank, die nachts auf die exteren Platte kopiert wird. Bei Ausfall des Ganzen ist max. ein Tag weg. und der Wiederanlauf ist mit finden irgend einer Hardware und aufspielen der virtuellen Maschine schnell getan. In dem Fall würde ich sogar das RAID weglassen, wenn man 24/7 fähige Platten oder SSD`s kauft.

 

[SebiW]

Hi @Maritimia

das hätte ich unter den Voraussetzungen sicher genauso gemacht. Sind wir mal ehrlich, das was wir hier machen ist im Endeffekt Nerdgepicke auf gehobenem Niveau
Deine Lösung ist sicher mindestens genauso gut wie unsere hier, durch die Virtualisierung imho sogar noch einen Schwupps besser.

Meine Abneigung gegen NAS Lösungen beruht wahrscheinlich auch darauf, dass uns hier in den letzten Jahren da so einige teure Hardware spontan über den Jordan ging, meist wegen Netzteil oder Controller Problemen. Einmal hat uns ein defekter Controller entspannt unser komplettes NAS Raid mit defekten Daten überschrieben bevor er sich genötigt sah uns auf einen potentiellen Fehler hinzuweisen. Das war ein Sch... Tag...

Wir setzen deshalb mittlerweile als NAS einen Linux Server ein, einfach weil wir da die einzelnen Komponenten im Notfall selbst relativ schnell und unkompliziert tauschen können.

Und auch beim Thema Backup sind wir uns absolut einig: Im Endeffekt kann man fast nicht zu viele Backups haben. Und Platten kosten ja mittlerweile wirklich nichts mehr.
Für unseren Server setzen wir Samsung SM863 SSDs in einem 1er Raid Verbund ein. Für die JTL Datenbanken genügen dabei locker die 128 Gb Varianten und die Performance stimmt. Kann ich nur empfehlen die Dinger

Viele Grüße,
SebiW

 

[Rico Giesler]

Wie @Maritimia und @SebiW schon richtig mit erfasst haben sollten die Backups auch nochmal extern (komplett außer Haus) gespeichert werden, denn NAS, externe Festplatten, Zweitrechner etc bringen nichts wenn du Wasserschaden, Brände oder Diebstahl die Hardware beschädigt oder verloren geht.