Umzug David.fx auf andere HD bei gleichem Laufwerksbuchstaben

Hallo,

gibt es beim Umzug des David-Archivs von einem Serverlaufwerk auf ein anderes (größeres) Serverlaufwerk (gleicher Server), bei gleichzeitiger Laufwerksumbenennung, so dass der Laufwerksbuchstabe für den David-Server gleich bleibt, irgendetwas zu beachten? Soweit mir bekannt, müsste das einigermaßen reibungslos einschließlich der Zugriffsrechte laufen, aber falls doch Kinken zu erwarten sind, wäre ich für Tipps & Hinweise dankbar, worauf speziell zu achten ist.

CU

Danke für die Info.
Werde es mit xcopy und den entsprechenden Parametern angehen.

CU

Hallo,

nach erfolgtem Umzug hier noch ein paar zu beachtende Punkte nachgereicht:

Wie immer vor dem Beginn solcher Arbeiten: ist das Backup vom System valide und aktuell?

Wegen möglicher Reboots des Servers im Laufe der Arbeiten am bsten die Dienste vom David im Zuge der sowieso fälligen Beendigung vorübergehend auf "Deaktiviert" stellen, damit David nach einem Serverneustart nicht gleich automatisch mitstartet.

Im vorliegenden Fall war der Reboot im Zusammenhang mit der Neuzuweisung des Laufwerksbuchstabens erforderlich.

Mit der Änderung des Laufwerksbuchstabens hebt Windows die Freigaben auf. Falls die etwas umfangreicher eingerichtet sind, sollten die zuvor dokumentiert werden. Die ACL bleiben hingegen bei Neuzuweisung eines Laufwerksbuchstaben erhalten.

Falls eine AV-Lösung auf dem Server läuft, sollte die angehalten werden oder man erstellt vor dem Beginn der Kopieraktion eine weitere Ausnahme für das (temp) Zielverzeichnis. Die David-Archive sollten sowieso von jeglicher externer AV-Überwachung ausgenommen sein, aber hier ist das auch für die Kopiergeschwindigkeit nicht unerheblich (auf diesem Server etwa 50% schneller).

Statt mit robocopy bin ich es mit "xcopy m:\David q:\David /E /I /H /O" angegangen. Der Parameter /O sorgt dabei für die Übertragung der ACL. (Auf dem fraglichen Server war das W2K3 Ressource-KIT mit robocopy nicht installiert und der Aufwand dafür war mir zu groß, zumal zusätzlich noch eine GUI ganz hilfreich für robocopy wäre, was je nach dem z.B. auch noch eine .NET-Inst. erforderlich macht.)

Das hat recht gut funktioniert. Irgendwann ist der Job allerdings auf eine defekte Datei gelaufen und hat folglich die Ausführung abgebrochen. In dem Fall kann man noch die Parameter /D und /C ergänzen und erneut starten. Bedeutet dann aber auch, dass man sich hinterher mit den - warum auch immer - übersprungenen Dateien befassen muss. Für mich hat da Winmerge sehr gute Dienste geleistet (http://www.winmerge.org).

Auf diesem Server waren 2 Dateien von ca. 1.5 Mio derart beschädigt, das sie mit Bordmitteln von W2K3 nicht mehr greifbar waren. Zudem so alte Objekte, dass ich gerne auf weitere Untersuchung verzichtet habe.

Ein Knackpunkt lag in den Dateien des SQL-Server (\\server\David\code\Database\MSSQL.1\MSSQL\Data). In diesem Fall lag da nicht nur die Datenbank vom David, sondern auch noch von einer anderen Anwendung, die ebenfalls eine Instanz auf dem SQL führt. Man sollte also vor einem Umzug auch die MSSQL-Dienste stoppen (und nicht nur die David-Dienste), bevor der Kopiervorgang gestartet wird. (Entweder auf der Konsole mit "net stop MSSQLServer" oder "net stop MSSQL$SQLEXPRESS" je nach eingesetzter Edition ... oder über die Dienste-MMC.)

Nach dem Umzug und der Überprüfung, dass Quelle und Ziel wirklich identisch sind (Anzahl und Volumen) kann man die Dienste nach und nach wieder starten. Heißt, zunächst nur den Service-Layer und den TLD. Hier kam dann eine unerwartete Meldung: der David-Server meldet, das die Site-ID ungültig sei und man eine neue anfordern möge. Wohlgemerkt, eigentlich ist für den David alles so wie zuvor geblieben, insb. gleicher Laufwerksbuchstabe für den David-Server. Die Generierung der neuen Site-ID hat hier aber klaglos funktioniert.

CU