DavidServer Migration von Win2008R2 zu 2016

  • Klingt als solltest Du mal dringen vom David Administrator auf dem Server oben über das Menü Punkt Werkzeuge die "Zugriffsrechte zurücksetzen" auf alle David Archive lassen und dann anschließend die benötigten extra Zugriffsrechte neu vergeben, das aber idealer Weise immer über Eigenschaften / Zugang / Berechtigungen

    Hallo riawie,


    danke für die schnelle Antwort.

    habe es schon genau so, wie du es beschrieben hast, zurückgesetzt.

  • hmm, seltsam, dann solltest Du da vielleicht mal einen der erfahrenen Tobit Partner remote drauf schauen lassen.
    Sind ja einige hier im Forum die gerne ihre Dienste anbieten 😉

  • Wir versuchen auch gerade die Migration von Server 2008R2 -> 2016

    Das David Migrations Tool ist aber sehr lahm und dann nach 28 Std Laufzeit abgestürzt :(


    ( bei großen gepackten Archiven kommt es auf ca. 10 MByte/sec bei den kleinen Nachrichten dann nur noch 2-3 MByte/sec. Unsere Server sind mit 1GBit angebunden und zwischen den Switchen 10 GBit )

    Ich vermute mal, da Server 2008R2 noch das alte SMB2 Protokoll fährt und das David Migration Tool nur single-threaded arbeitet kommt das nicht auf höhere Geschwindigkeiten.


    Wie sind eure Erfahrungen mit Robocopy? Wie lange braucht man ca. für 1000 GB ?

    (Zielserver benutzt ein SSD-Raid, also schnell genug ist der .. )

  • KlausG das Problem des Migrationstools ist nicht das SMB2 Protokolls, es ist die Art der Migration an sich.

    Robocopy schafft je nach beteiligter Hardware ca 80% der langsamsten beteiligten Komponente zu saturieren, es kommt also drauf an von was Du wegkopierst, nicht so sehr wo hin Du kopierst ;)

    1 TB kann also binnen einer Stunde fertig sein, genauso gut auch mehrere Stunden dauern und im schlimmsten Fall auch länger...

    Aber es geht immer um ein vielfaches schneller als mit dem Migrationstool.
    Voraussetzung für den Gebrauch von Robocopy ist halt das man den neuen Server so benennen kann wie den alten und das die neue Installation die gleichen Pfadangaben nutzen kann wie auf dem alten Server, dann ist das aber wirklich fix erledigt.

  • 1 TB in einer Stunde, das sind 300 MB pro sec, das ist schon sportlich.

    Unsere SAS Platten mit RAID Controller im HP Server schaffen so ca. 100 MB/sec

    und dann kommen die kleinen Dateien und Windows wird so richtig langsam ...


    Ja leider möchte ich auch einen neuen Namen vergeben, weil wir von BareBone Hardware in einen VM-Ware Maschine umziehen..

  • KlausG und wegen des Umzugs in eine VM soll es unbedingt ein neuer Name sein?

    Das würde ich mir gut überlegen, denn das erhöht drastisch die Komplexität und damit die Zeitkosten eines solchen Umzugs, gerade wenn man Datenvolumina in der Größenordnung wie bei Euch mit umziehen möchte bzw. muss.

    Wir haben den Schritt übrigens mit dem vorletzten Umzug rückgängig gemacht, die Performance war uns einfach wichtiger, aber das nur am Rande.

    1TB in einer Stunde ist übrigens kein Ding wenn man NVMe als Massenspeicher einsetzt ;)
    von solchen Transferraten konnte ich beim letzten Umzug zwar nur träumen, aber den Umzug habe ich auch anders durchgeführt.

    Ich hatte zusätzlichen Massenspeicher im neuen System via iSCSI an das alte System exportiert, dort habe ich ihn dann dazu genutzt um ihn als Spiegellaufwerk dem alten Laufwerk hinzuzufügen, nach dem der Spiegel vollständig war und der Tag des Umzugs gekommen war hab ich dann den Spiegel aufgetrennt und am neuen System dann das ganze noch mal mit umgekehrtem Vorzeichen nachvollzogen.
    Mein Vorteil dabei war das ich unseren David Server schon vor vielen Jahren so konzipiert hatte das die David Installation auf einem eigenen Laufwerk liegt.

    Damit sind wir dann irgendwann von physisch auf virtuell und später wieder von virtuell auf physisch umgezogen.

    Alles kein Ding wenn man vorher einmal richtig plant wie man seine Systeme designed und sich dann im Zweifel immer für eine spätere Portierbarkeit, also auch für gleichbleibende Namen im Netz entscheidet.

  • nette Idee mit dem Spiegel über ISCSI. Bei uns liegt David auch auf einem eigenen Laufwerk, nur gab es für den HP Server nur max. 600 GB Platten und da sind wir ein bisschen rausgewachsen , so liegt jetzt ein Teil des David Archivs auf zusätzlichen Platten...


    Aber mal ne Frage zur Virtualisierung: an welcher Ecke gab es denn Performance-Probleme ??

  • KlausG die Virtualisierung hat vor allem alle IO messbar beeinträchtigt.

    Der Punkt ist schlicht das wir mal mit Virtualisierung gestartet sind um teure Serverhardware besser auszunutzen.
    Zwischenzeitlich ist Serverhardware sehr viel günstiger geworden und gleichzeitig sind die Anforderungen an die Systeme immer stärker gestiegen, da hat es am Ende keinen Sinn mehr gemacht einen David Server weiterhin zu virtualisieren wenn er am Ende doch einen ganzen Host für sich allein frisst.

    Außerdem ist der Umzug eines nackten Windows Servers direkt auf der Hardware einfacher von einem Stück Serverhardware zu einem neuen als der Umzug eines Virtualisierungshosts auf ein neues Stück Serverhardware.
    Bei 2 TB an Archiven zählt für weitere Umzüge am Ende schlicht alles was Datensicherung und Upgrades nennenswert beschleunigt.
    Außerdem stört jedes Stück zusätzlicher Komplexität.


  • Also sorry, das ist von vorne bis hinten _alles_ falsch.


    Nur ein Beispiel

    ! Es ist doch nicht komplexer eine VM umzuziehen, als ein Stück Hardware !

    Ganz im Gegenteil !


    Eine VM komplex? Oooook das erklärt's dann ...


    Auf den Rest gehe ich erst gar nicht ein.


    Gruß

    ****************
    Wohl bald ehemaliger "Tobit Partner" :cursing: 2001 - bald wären es 20 Jahre...<X So geht man nicht mit seinen Partnern um !! Stichwort _Provisionen_.
    ****************

  • Genesis typischer Marketing bla bla.

    Deine pauschalen Aussagen sind schlicht Unfug!
    Man muss die Frage von Sinnhaftigkeit einer Virtualisierungsumgebung immer im Einzelfall stellen und beurteilen.
    Da sind Verallgemeinerungen schlicht fehl am Platz!

    Fakt ist das eine Virtualisierungsumgebung zwischen einer Serverhardware und einem Windows Server Betriebssystem eine zusätzliche Ebene ist.

    Fakt: Wenn ich in einen Softwarestack eine weitere Ebene einziehe wird das Ergebnis komplexer als wenn ich das nicht mache.

    Das Du nicht in der Lage bist - mindestens - in der gleichen Zeit eine Microsoft Server Installation von einem Stück Server Hardware umzuziehen wie die Virtualisierungsumgebung samt der darauf laufenden virtuellen Microsoft Server Instanz besagt im übrigen auch genau nichts darüber das andere es nicht doch oder gar noch schneller können.

    Virtualisierung verbraucht immer Ressourcen für sich selbst, welche den virtualisierten Servern die darauf laufen nicht mehr zur Verfügung stehen.
    Wie viel es konkret ist hängt zwar von vielen Faktoren ab, aber diesen Overhead vollständig zu negieren "das ist von vorne bis hinten _alles_ falsch" zeugt schlicht von Unkenntnis und ignoranz!

    Ebenso benötigt eine Virtualisierungsumgebung immer eigene zusätzliche Wartung welche man nicht hat wenn man den jeweiligen Server direkt auf der Hardware laufen lässt.

    Unbestreitbar bringt Virtualisierung durchaus auch den einen oder anderen Vorteil wenn es um das Thema Point in Time Snapshots geht, da ist es jedoch schlicht eine Frage dessen ob man diese braucht oder ob man andere Möglichkeiten hat dieses abzubilden.
    Und über den Punkt hatte ich mich auch gar nicht ausgelassen, denn der war für unsere Entscheidung schlicht nicht relevant.

    Relevant war der erhöhte Pflegeaufwand bei gleichzeitigem Mehrverbrauch an Ressourcen sowohl auf Hardwareseite als auch in Form von Personalaufwand bei der Pflege des Gesamten Softwarestacks.

    Weiter will ich das Thema hier aber auch nicht mehr auswälzen, denn eigentlich geht es hier unten aktuell nur noch um KlausG seine aktuelle Migration und wäre es nicht er gewesen der meine Aussage hinterfragt hätte, so wäre die Nachfrage auch unbeantwortet geblieben.
    Ich will hier folglich keine Grundsatzdiskussion über das Thema Virtualisierung halten.

    Aber derart unflätiges Benehmen wie Dein Kommentar hier mag ich auch nicht unkommentiert stehen lassen.

    Einmal editiert, zuletzt von riawie ()

  • Muss auf dem neuen Server das Verzeichnis auf dem selben Laufwerksbuchstaben liegen?

    Radio Eriwan: Kommt drauf an. ;)


    Im Archivsystem selbst wird afaik immer auf den Freigabenamen referenziert, ebenso an den allermeisten Stellen im David selbst. Sprich: Wenn Server + Freigabe ( \\server\david ) wieder wie bei der alten Installation heißen, kann jene Freigabe auf einem beliebigen Laufwerk liegen, das muss nicht mit dem alten identisch sein.


    Wenn du aber wirklich ALLES umkopierst, also den kompletten David-Ordner, gibt es Ausnahmen von dieser Regel. Zum Beispiel das Verzeichnis CODE\DATABASE, in dem die Datenbanken des SQL-Server liegen. An der Stelle knirscht es, sobald der Laufwerksbuchstabe nicht mehr passt.


    Andere Stellen an denen es hakeln könnte, fallen mir gerade nicht ein. Ein Workaround könnte darin bestehen, einen "Dummy-Ordner" DAVID zu erstellen, der auf dem gleichen "alten" Laufwerksbuchstaben bleibt (z. B. D:), in dem aber nur der DATABASE-Ordner wohnt. Oder du löscht die SQL-Instanz und installierst manuell eine neue mit dem korrekten Pfad. Oder installiert auf dem neuen System SQL manuell vor der David-Einrichtung. Oder, oder...

  • Hallo Zusammen,

    ich bin jetzt am WE damit dran - von W2K8r2 auf W2k19... Was ich mich gerade frage, muss ich die SQL-Daten übernehmen oder kann ich einfach eine neue SQL-Version installieren, ohne dass ich da Daten mit übernehme??? Das würde mir viel Stress ersparen... Denn aktuell ist die Installation auf SQL Express 2008R2 und ich wollte mind. eine SQL Express 2016 hernehmen....


    Vielen Dank für Eure Hilfe

    VG Ingo

  • Der David Server nutzt den SQL Server zum einen für die Suche, zum anderen für die Chats.

    Die Suche ist unproblematisch, denn die kann man schlicht neu aufbauen lassen.

    Die Chats allerdings wären dann weg.

    Ich würde schlicht die Datenbanken sichern, auf dem neuen Server einen SQL Express in Version 2017 installieren (der 2017er wird erwiesener Maßen unterstützt, bei noch neueren weiß ich es nicht, die Datenbanken aus der Sicherung wieder einspielen und ansonsten den Umzug wie oben von mir beschrieben durchführen.

  • kettentechnik der neue muss in die Domäne bevor die Daten rüber kopiert werden, sonst passen nachher die ganzen SIDs nicht. Zu der Zeit spielt sein Name aber noch keine Rolle. Seinen korrekten Namen muss er erst bekommen bevor der David Server dort über die auf ihn kopierte Installation drüber installiert und dann das erste mal gestartet wird.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!