monstermania

Na ja, es sind ja schon Lösungsmöglichkeiten genannt worden. z.B. mal den Hersteller der Lösung hinzuziehen. Evtl. ist es ja möglich das Backup in einen Zeitraum zu verlegen, in dem keine Anmeldung am Server erforderlich ist. Arbeitet Ihr wirklich 24/7? Ansonsten kann ich nur sagen, dass wir hier mit Veeam und mehreren SQL Server absolut keine Probleme haben. Sicherung läuft einwandfrei durch und es gibt auch keine merklichen Lags oder Abbrüche. Auf was für einem System läuft den der SQL Server (VM Host). Evtl. ist das Hostsystem einfach nicht performant genug und daher dauert die Erstellung der VSS-Kopie unverhältnismäßig lang. Im Übrigen würde ich auch wenn das Ganze einwandfrei laufen würde immer noch eine regelmäßige Sicherung auf SQL-Ebene machen! Gruß Dirk

Moin, um was für eine Anwendung handelt es sich denn? Das grundsätzliche Problem wirst Du immer haben. Veeam nutzt auch den VSS-Provider von Windows um die Datenbanken konsistent sichern zu können. Ein 'kurzes' Einfrieren ist daher ganz normal. Gruß Dirk

Moin, grundsätzlich ist eine Ausfallzeit von <= 4 Stunden schon mal ein sehr 'sportliches' Ziel! Selbst, wenn man einen Supportvertrag mit 4h-Mission-Critical-Staus hat, heißt das ja nur, dass die Hardware innerhalb von 4 Stunden wieder einsatzbereit wäre. Die Daten auf der Hardware können aber durchaus weg sein. Wie lange dauert es aber dann noch ggf. das Backup wieder einzuspielen? Da Hochverfügbarkeit bei Euch ja nicht unbedingt erforderlich zu sein scheint, würde ich meinen Schwerpunkt auf ein sauberes Backup/Restore-Konzept legen. Die Idee mit den beiden Hosts mit dediziertem Storage halte ich für unsinnig. Ich würde so etwas mit einem zentralen SAN realisieren. 2 VM Hosts, dazu ein Shared-Storage (2,5" SAN mit SAS-Anbindung). Dann ein Veeam Backup & Replikation Essentials auf einem extra Backupserver und ein entsprechendes iSCSI-NAS (z.B. QNAP x69Pro) als Speichermedium für die Backups / Replikate. Für Offline-Sicherungen dann noch das entsprechende Tape-Laufwerk. Das NAS muss natürlich eine entsprechende Kapazität haben um sowohl die Backups als auch die Replikate aufnehmen zu können! Wenn das Alles sauber eingerichtet ist hast Du damit mehrere Anforderungen abgehakt. Veeam macht das Backup und eine regelmäßige Replikation des SAN auf das NAS. Bei einem Totalausfall des SAN könnt Ihr zur Not das Replikat direkt vom NAS starten. Klar die Performance ist dann recht lahm, aber Eure Systeme sind quasi sofort wieder mit dem letzten Replikationsstand online. Gruß Dirk PS: Wieso kostet es Euch kein Geld, wenn die Systeme mal nicht zur Verfügung stehen?

Moin, willst Du den Server selbst bauen? Ich würde bei einem Serversystem grundsätzlich immer einen Markenserver kaufen (z.B. HP, DELL, IBM(Lenovo), FSC). Ob nun SATA- bzw. die im Serverbereich anzutreffenden NL-SAS-Platten in einen richtigen Server gehören lasse ich mal dahingestellt. Kann man aber machen. Ich habe in der Vergangenheit diverse kleine VMWare ESXi-Server bei Kunden stehen gehabt (RAID5 mit NL-SAS Platten und richtigen RAID-Controller). Auf diesen Server laufen so 2-3 VM's für 10-20 User. Hauptsächlich SBS2011 mit Premium Addon. Vollkommen ausreichend! Und mit 5 Jahren Vor-Ort-Service stimmt auch der Service. Auch ein Tandberg RDX kann man machen. Frage ist ja immer welche Backupstrategie verwendet wird und wie viele Mediensätze es nachher gibt. USB geht auch, sofern es sich um USB3 handelt. Ich verwende als Backuplaufwerk bei kleinen Installationen gerne eine kleine QNAP (NAS). Offline-Backups dann per externem USB-Laufwerk über Copy2USB der QNAP. Gruß Dirk

Und was verleitet Dich zur der Annahme, dass Du die MS Dreamspark-Lizenzen Privat nutzen darfst? IMHO sind die Dreamspark Lizenzen grundsätzlich zunächst mal für Forschung und Lehre und dürfen auch nur in diesem Zusammenhang genutzt werden. Glaube kaum, dass das die Nutzung für Familienmitglieder einschließt. Kommt natürlich im Einzelnen darauf an, was für einen speziellen Vertrag Eure Uni mit MS geschlossen hat.

Klar, gehostetes Exchange kostet Geld. Aber ist ja nicht so, dass man die MS Lizenzen (MS Server, MS Exchange, Windows CAL, Exchange CAL, oder ggf. SBS 2011+CAL) für zu Hause kostenlos bekommt! Kosten ja auch mal eben einige Hundert Euro. Dazu dann noch die Kosten für regelmäßiges Backup und die ständigen Stromkosten. Dazu noch der Aufwand! Schon sind die Kosten für gehostetes Exchange wieder relativ. Zumal man bei den meisten Angeboten ja auch noch MS Outlook oder sogar das komplette Office dazu bekommt. Kostet ja sonst auch wieder Geld.

Natürlich nur die 12 MA aus der Konstruktion. Verstehe die Frage aber nicht so wirklich. Wenn sich mehrere MA einen Rechner teilen, würde man sicherlich SQL-Device CAL kaufen. Dann können auch z.B. 100 Mitarbeiter von den 12 Devices aus auf den SQL Server zugreifen. Nur wie passt das jetzt zur Aussage vom Lizenzdoc "die zugreifen können"? Bzw. was bitteschön soll das lizenztechnisch bedeuten? Theoretisch kann jeder auf einen SQL Server zugreifen, sofern man einen Zugang hat. Einzig über die Administration legt man fest, wer sich im Endeffekt am SQL-Server bzw. an der den SQL Server nutzenden Applikation anmelden kann.

Moin, wie sieht es mit den Userdaten aus? Die sollen doch sicherlich auch auf den neuen Server übernommen werden? Sonstige Freigaben? Gruß Dirk

Klar RAM ist schön und gut. Ist aber nun mal so, dass ein Datenbanksystem u.a. die Transaktionen regelmäßig protokolliert. Dabei wird eben zwingend in eine Datei geschrieben. Ist eben b***d, wenn Entscheider glauben sich über die Meinung vom Fachpersonal hinwegsetzten zu können.

Sorry, dass ich hier mal Nachfrage. Was meinst Du mit dem 'zugreifen können'? Wir haben ein PLM System bei dem im Hintergrund ein SQL 2008R2 läuft. Dieses System wird von unseren 12 Usern der Konstruktion genutzt. Dementsprechend haben wir auch 12 SQL User CAL für den SQL2008R2. Natürlich arbeiten bei uns mehr Mitarbeiter als 12 User, die theoretisch auf den SQL 2008R2 zugreifen können. Nur sind eben nur die 12 User der Konstruktionsabteilung in der PLM Software als User angelegt. Gruß Dirk

Moin, die verlinkten Beiträge kenne ich natürlich auch. 1GB pro Instanz ist auch klar. Haben ja auch nur 1 Instanz SQL Express mit 7 Datenbanken am laufen. Ist schon klar, dass die sqlsrv.exe nicht nur 1GB groß werden kann, da natürlich immer ein gewisser Overhead für die Datenverwaltung entsteht. Auch jede Verbindung zum SQL Server muss ja irgendwie verwaltet werden. Aber bei knapp 3 GB wären das fast 2 GB Overhead. Finde ich jetzt schon ganz schön heftig. Stört mich aber auch nicht wirklich. War halt mehr aus Interesse die Frage. Gruß Dirk

Moin, hmm. Ich weiß nicht, ob ich mir für meine privaten Emails, Kontake und Termine einen Exchange hinstellen würde. Da wäre mir der Pflegeaufwand (Spam, AV, Datensicherung, usw.) einfach zu hoch. Wenn es denn unbedingt Exchange sein soll würde ich mir mal die Exchange-Online Angebote der diversen Anbieter ansehen. Just my 2 Cent Gruß Dirk

Moin, jo glaub ich gern, dass Du damit Probleme bekommst. Bei einem Raid 6 mit SATA-Platten und dann mehrere SQL-Server... :rolleyes: Du kannst Dir eine 30 Tage Testversion von Veeam ONE beim Hersteller herunterladen. 30 Tage 'Test' sollten mehr als ausreichen um aussagekräftige Performancewerte zu bekommen. Gruß Dirk

Moin, wir haben vor kurzem unseren SQL2005 Standard in Rente geschickt und durch einen SQL2012 Express ersetzt. Auf dem SQL laufen eh nur noch kleine Datenbanken, so dass der SQL-Express vollkommen ausreicht. Express unterstützt ja nur 1 GB RAM. Nur wie ist das zu verstehen mit den 1 GB? Mittlerweile ist die sqlsrv.exe auf dem Express rund 3GB groß. Eigentlich fast genauso, wie vorher mit dem alten SQL 2005 Standard. 1 GB RAM pro Datenbank oder wie? Gruß Dirk

Moin, richtig. Du muss den SQL Server + die entsprechende Anzahl von SQL CAL kaufen. Dabei natürlich auch nicht die 'normalen' Windows Lizenzen vergessen. Also die Lizenzen für Windows Server Betriebssystem und die normalen Windows CAL. Beim Lizenzerwerb kaufst Du die immer die derzeit aktuelle SQL-Server Version (SQL2014). Du hast dann ein Lizenz-Downgrade-Recht auf die Vorversionen. Die entsprechende Software kannst Du dann in Deinem MS Lizenzportal herunterladen. Bei den CAL gilt dasselbe. CAL für SQL2014 berechtigen immer zum Zugriff auf alle vorherigen SQL-Serverversionen. Zur Ermittlung der Datenbankgröße hat ja sunny61 bereits etwas geschrieben. Oder ist da noch etwas unklar? Natürlich bei SQL 2008R2 Express ist das Limit 10 GB pro Datenbank und nicht für alle Datenbanken zusammen! Das mit der Abwärtskompatibilität ist so eine Sache. Meist läuft eine Anwendung für SQL 2005/2008 problemlos auch auf SQL 2012/2014. Das Problem ist aber oft der Support des jeweiligen Programms seitens des Herstellers. Der Hersteller supportet meist nur bestimmte Installationen (Die Version x ist nur für SQL2008R2 freigegeben. Erst Version Y ist auch für SQL 2012 freigegeben). Den Spaß habe ich hier leider auch, da wir bestimmte Softwareprodukte über einen sehr langen Zeitraum einsetzen. Haben sogar Software, die Ursprünglich für SQL2000 war mittlerweile auf SQL2012 am Laufen. Wenn es eh keinen Support vom Hersteller mehr gibt, kann man es ruhig versuchen die Datenbanken umzuziehen. Gruß Dirk

Moin, ich glaube ich habe es verstanden. :) Ganz einfach gesagt. Werden x-beliebige Daten in eine SQL-Datenbank von Hand eingepflegt (durch einen Mitarbeiter) benötigt nur der entsprechende Mitarbeiter bzw. Arbeitsplatz eine SQL-CAL. Wir für das Erfassen der Daten jedoch irgendwie eine Hard- oder Software genutzt (siehe Zitat von Daniel) greift das Multiplexing. Und klar, das vCenter ist nun mal eine Software... Rein theoretisch braucht also jede unserer Dreh- und Fräsmaschinen genau wie ein Mitarbeiter/Arbeitsplatz auch eine SQL-Lizenz, da die PPS-Daten per Dienst in die ERP-Software importiert werden (Backend MS-SQL Server). War also die richtige Entscheidung sich 2013 für eine SQL Core Lizenzierung zu entscheiden. :D

Moin, Du verstehst noch so Einiges nicht richtig. Die Anzahl der Datenbanken ist für die Anzahl der CAL's irrelevant. Es wird der genreelle Zugriff auf den SQL lizenziert nicht auf einzelne Datenbanken. Es muss nur jeder tatsächliche Zugriff auf den SQL-Server lizenziert werden. Also, du hast im Unternehmen 250 Mitarbeiter. Es greifen aber nur 50 Mitarbeiter davon auf den SQL-Server zu. Dann brauchst Du auch nur 50 SQL CAL. Ob nun SQL User oder Device CAL günstiger ist, muss man halt ausrechnen. Man kann auch Device/USER CAL mischen. Wichtig ist nur, dass Du sauber dokumentierst wem eine entsprechende Lizenz zugewiesen wurde. Ach ja, irgendwann ist natürlich auch Core-Lizenzierung günstiger...

@Weingeist Ist eben absolut nicht einleuchtend! zahni hatte ja schon das Beispiel mit einer Monitoring-Software gebracht. Monitoring-Lösung hat im Backend einen MS-SQL. Braucht jetzt jeder Client eine SQL-CAL? Klar kann man eben so argumentieren, dass der Monitoring-Server die Clients aktiv abfragt. Ähnlich, wie ein realen Menschen, der z.B. seine Kunden anruft und die Daten seiner Kunden manuell einpflegt. Aber ist das lizenztechnisch das Selbe? Braucht das dann also keine SQL-CAL für jeden Client (Kunden)? Wo beginnt die Lizenzpflicht? Was machst Du dann aber, wenn der Agent auf den Clients aktive Warnmeldungen verschickt (z.B. SNMP-Traps)? Dann greift der Client ja sozusagen aktiv auf den MS-SQL zu (über die Monitoring-Lösung)! Brauchst Du dann auf einmal eine SQL-CAL? Im Prinzip ist es mit dem VCenter ja das Gleiche... Andererseits läuft die Umgebung prinzipiell auch ohne VCenter. Oder auch ohne Monitorung-Lösung. Aber ob das Auswirkungen auf eine evtl. Lizenzpflicht? Ich bin nur froh, dass ich mich damit nicht Auseinendersetzen muss, da SQL-Express. Ich kann aber beide Argumentationen nachvollziehen.

Ja und, wo ist das Problem? Genau das machen diverse andere Anwendungen auch. Die Clients solcher Anwendungen greifen per Applikationsserver indirekt auf den SQL-Server zu... Oder geht es Dir um die Richtung des Zugriffs bzw. den Initiator? Also, dass nicht die VM's aktiv auf den VCenter zugreifen, sondern der Applikatiosserver aktiv auf die VM's zugreift? Hmm, gute Frage...? Sollte aber lizenztechnisch eigentlich keine Rolle spielen wer den Zugriff auf die Datenbank auslöst. Tja, wo ist ein MS Lizenzspezi wenn man Ihn braucht?

Sorry, hatte ich überlesen... Ich stimme aber auch zu, dass bei dem obigen Nutzungszenario (VCenter) wohl in der Tat eine SQL Device CAL pro VM benötigt wird. Ist ja das gleiche wie eine beliebige andere Anwendung, die per Client/Server indirekt auf die Datenbank zugreift. Der VCenter stellt für die VM's den Zugriff auf den SQL Server sicher. Indirekter Zugriff. Müsst dann ja auch für unseren VCenter bei VMWare gelten! Nur gut, dass wir da auch nur SQL Express nutzen!

Moin, dafür gibt es dann ja die unterschiedlichen Lizenzmodelle für SQL. Kannst ja auch eine SQL Core-Lizenzierung machen. Dann brauchst Du keine SQL CAL's mehr. Muss man halt genau durchrechnen ab wie vielen Usern sich welches SQL Lizenzmodell rechnet. Wir haben z.B. 2013 SQL Core-Lizenzen (Runtime) für unser MS Nav gekauft, da dass die günstigste Option war (vorher hatten wir SQL 2005 Standard mit SQL User CAL). Den SQL 2005 haben wir kürzlich mit SQL2012 Express abgelöst. Die paar Datenbanken die da neben Navision noch drauf liefen, laufen auch ganz locker auf dem SQL 2012 Express. :)

Ja genau, die werden z.Zt. gar nicht gelöscht. ;) Wird wohl in vielen Unternehmen ähnlich aussehen. Eigentlich schade, da die DMS/Archivsysteme ja durchaus eine 'Lebensdauer' unterstützen. Man könnte also sehr wohl alle Dokumente deren 'Lebensdauer' überschritten wurde automatisch löschen lassen. Die Funktion nutzen wir aber ehrlicherweise auch nicht...

Jo, haben wir. - Archivierung aller Ein- und Ausgangsbelege inkl. Scannen von Papier (Eingang). - Mailarchiv - Archivierung von Fertigungslaufkarten, Materialzeugnissen, QS-Berichten - usw. Aus den Archiven werden keine Daten gelöscht (seit 1998). Löschen Können die meisten Mitarbeiter auch gar nicht. Nur einige Key-User haben das Recht dazu. Wenn etwas gelöscht wird, sind die Daten immer noch im Archivpapierkorb und können von da zurückgeholt werden. Bisher konnten wir das Anwachsen der Datenmenge immer gut mit der nächsten LTO-Generation abfangen. Löschen wäre auch problematisch, da einige Daten aus der Fertigung mindestens 20 Jahre aufgehoben werden müssen. Wer will da entscheiden, welche Daten gelöscht werden können!? Kommt immer mal wieder vor, dass bei Unfällen mit unseren Produkten der TÜV die Fertigungshistorie/QS-Berichte zu den Chargen sehen will auch wenn die Fertigung schon zig Jahre zurück liegt. Ja, z.B. muss jeder MA bei uns eine Erklärung unterzeichnen, dass er der Firma die Archivierung der Daten ausdrücklich erlaubt! Die Erklärung ist sowohl mit Betriebsrat/Gewerkschafft als auch mit dem Datenschutzbeauftragten abgestimmt um das auch rechtlich sauber abzubilden. Ob es jetzt eine gesetzlich bindende Verpflichtung zum Löschen von Daten gibt (30 Jahre)? Kommt mit Sicherheit auf die Art der Daten an. Also ob es sich um personenbezogene Daten handelt. Ich kenne eine Firma, die im Bereich Schiffsausrüstung tätig ist. Habe seinerzeit dort die Archivierung mit eingerichtet. Die haben die Datenblätter von Maschinen auf Schiffen vorliegen die über 50 Jahre alt sind! Die können heute noch lückenlos nachvollziehen, welches Monteursteam die Endmontage der Anlagen auf den Schiffen vorgenommen hat. Die habe sich sogar die Mühe gemacht alle Akten seit 1990 nachzuarchivieren damit die Informationen in Form einer elektronischer Akte vorliegen.

Hmmm, habe ich irgendwo geschrieben, dass unsere Lösung eine allgemeingültige Empfehlung darstellt? Und ja, unser Sicherungskonzept ist u.A. mit unserem (externen) IT-Sicherheitsbeauftragten abgestimmt. Und Du kannst mir Glauben, dass wir auch von anderen Stellen regelmäßig zertifiziert werden. Grundsätzlich sollte ein Backupkonzept sich immer an dem Unternehmen und den dortigen Gegebenheiten orientieren. Ein allgemeingültiges Backupkonzept gibt es nicht.

Moin, wieder mal viel heiße Luft... :D Na, auch dafür gibt es Werkzeuge. Wir haben dafür seinerzeit Subversion genutzt. Ist aber schon rund 10 Jahre her... Eben! Wie ich bereits in meinem ersten Post geschrieben hab ist Backup keine Archivierung! Und ja, die GF hat bei uns das 6 Monatsfenster abgesegnet. Und damit ist es für mich auch OK!