Jump to content

Empfohlene Beiträge

Hallo Community,

ich habe einen Windows Server 2008, den ich als Fileserver nutze und unter VMware 6.5 betreibe.

Diesen Fileserver muss ich auf einen neuen Server migrieren und dazu benötige ich ein paar Anregungen.

Der Fileserver besitzt insgesamt 4 Festplatten (zusammen ca. 2 TB), wobei die erste für das OS ist und die anderen 3 für als Datenfreigabe genutzt werden.


Alle Platten sind als Typ Thick-Provision Lazy-Zeroed.


Ich muss diesen Server 2008  laut vorgaben auf einen Server 2012R2 migrieren (ja, 2012R2 obwohl 2019 schon raus ist).
Meine Idee ist es, einen 2012R2 Server neu zu installieren und die vorhanden Festplatten, welche auf mehrere Datastores verteilt sind, an den neuen Server „dranzuhängen“ und die Freigaben des alten Servers, welche unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares  zu finden sind, vom 2008er zu exportieren und beim 2012R2 zu importieren.

Anschließend will ich den alten Server herunterfahren und den neuen 2012er mit der IP-Adresse und den Servernamen des alten versehen.

Ist das so möglich?
Wie kann ich am besten die vorhanden Festplatten  (xxx.vdmk) an den neuen Server dranhängen?

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi,

 

vor 6 Minuten schrieb Dabinam:

Anschließend will ich den alten Server herunterfahren und den neuen 2012er mit der IP-Adresse und den Servernamen des alten versehen.

 

Ist das so möglich?

ja das kann man so machen.

 

vor 6 Minuten schrieb Dabinam:

Wie kann ich am besten die vorhanden Festplatten  (xxx.vdmk) an den neuen Server dranhängen?

Im vSphere Client die Festplatten vom alten Server abhängen (nicht löschen!) und beim neuen Server anhängen (VM auswählen -> Konfigurieren -> Bearbeiten -> Neues Gerät: Vorhandene Festplatte).

 

Gruß

Jan

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

chkdsk ist nicht notwendig. Ich habe den vom TE skizzierten Weg schon mehrere Dutzend Male, auch bei deutlich größeren FS und mehr Festplatten, durchgeführt. ***ensicher.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Der Sprung in der internen NTFS-Version ist beachtlich. Ich kann nur wiederholt das Chkdsk /f  empfehlen. Schon um "alte" Fehler gleich mitzubeheben, die alte Chkdsk-Versionen u.U. nicht beheben konnten.

 

Ach ja: Und vorher alle Snapshot löschen, falls es welche gibt (die sollte man in der Produktion eh nicht haben).

bearbeitet von zahni

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

GGF. hinterher ein storage vmotion machen um alle HDD in einen gemeinsamen VMware-Ordner zu haben.

vor 14 Stunden schrieb zahni:

Der Sprung in der internen NTFS-Version ist beachtlich. Ich kann nur wiederholt das Chkdsk /f  empfehlen. Schon um "alte" Fehler gleich mitzubeheben, die alte Chkdsk-Versionen u.U. nicht beheben konnten.

 

 

Da kann ich dir nur recht geben. Das Feature neuerer chkdsk-Versionen habe ich in der Vergangenheit gern genutzt um Fileserver-Systeme zu reparieren.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

ja, aber die vorgeschlagene Lösung kommt mit viel weniger Downtime aus und führt zu einem "sauberer" eingerichteten Betriebssystem.

 

Gruß, Nils

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

Werbepartner:


×