ReFS unter Server 2012 und später Server 2019

[Garant 3]

Guten Morgen,

 

ich würde gerne auf einem vorhandenen Server 2012 eine ReFS-Storage anlegen.

Dieses ReFS-Storage soll später (nur) noch unter einem Server 2019/Server 2022 betrieben werden.

 

Gibt es hier irgendwelche Einschränkungen/Komplikationen oder kann der Weg gegangen werden?

[testperson 1.534]

Hi,

 

du willst jetzt - also ca. einen Monat vor Support Ende - noch etwas Neues auf einem Windows Server 2012 bereitstellen und es im Nachgang auf Server 2019 / 2022 migrieren? Wieso nicht direkt mit Windows Server 2019 / 2022 starten?

 

Eine andere Frage wäre, was du unter

vor 2 Minuten schrieb Garant:

eine ReFS-Storage anlegen

verstehst? Was soll denn später auf / mit dem bereitgestellten Storage passieren?

 

Gruß

Jan

[NilsK 2.785]

Moin,

 

so pauschal betrachtet, kann man das durchaus machen. Die Frage ist, welches Ziel du damit verfolgst.

 

Allgemein hat sich ReFS nicht in dem Maß zu einer besseren Alternative zu NTFS entwickelt, wie das mal gedacht war.

 

Gruß, Nils

 

[Garant 3]

alter Backupserver (Server 2012R2) mit lokalem Speicher, wo die Backups (ca. 50TB) enthalten sind.

neuer Backupserver (Server 2019+) ohne lokalem Speicher, wird ins SAN eingebunden.

 

Da das vorhandene Backup sehr groß ist, war die Überlegung den neuen SAN-Speicher den alten Backupserver bekannt zu machen, die vorhandenen Backups darauf zu moven und später unter dem neuen Backupserver weiterzunutzen (VEEAM Umgebung).

[mwiederkehr 351]

Veeam ist wohl der Anwendungsfall, in welchem ReFS am meisten Vorteile bringt. Nur ReFS kann man Fast Clone nutzen und bei Synthetic Fullbackups viel Datenträger-Auslastung und Speicherplatz sparen. Deshalb würde ich auf jeden Fall ReFS verwenden. Aber eben, nur in solchen Spezialfällen und nicht generell. (Habe letzte Woche wieder einen Hyper-V-Cluster gesehen, dessen Volumes mit ReFS formatiert waren, weil das "ja neuer ist"...)

[NilsK 2.785]

Moin,

 

ja, drum die Frage. Dann geht es jetzt also im Wesentlichen darum, ob ein ReFS-Volume von einem 2012-Host an einen 2019/2022-Host umgehängt werden kann. Dazu habe ich leider keine Erfahrung.

 

Gruß, Nils

 

[Dukel 436]

Bevor du hiermit anfängst solltest du überlegen einen Veeam Linux Datastore zu nutzen. Damit sind Immutable Backups Möglich. Hilfe gegen Ransomware.

https://www.veeam.com/blog/immutable-backup-solutions-linux-hardened-repository.html

[cj_berlin 1.138]

Du kannst die Volumes mit ziemlicher Sicherheit mounten. Allerdings sind reichlich Versionen, Bugfixes und Features dazwischen, so dass ich es lieber lassen würde. 

[mwiederkehr 351]

vor 39 Minuten schrieb cj_berlin:

Du kannst die Volumes mit ziemlicher Sicherheit mounten. Allerdings sind reichlich Versionen, Bugfixes und Features dazwischen, so dass ich es lieber lassen würde.

Sehr guter Einwand! Bei ReFS ist viel mehr gegangen, als ich mir gedacht habe und es geht immer noch was.

 

Die Tabelle auf https://gist.github.com/0xbadfca11/da0598e47dd643d933dc zeigt, dass 2012 ReFS 1.2 unterstützt. Danach ging es mit 2016 direkt zu Version 3.1. Bei 2022 läuft 3.7.

 

Da 3.x nicht kompatibel ist mit 2012, kann man das Volume nicht einfach auf dem 2022er-Server formatieren und dann umhängen. Es gibt auch keinen Upgrade-Pfad von 1.x auf 3.x. Innerhalb von 3.x werden Volumes aber automatisch beim ersten Write-Mount aktualisiert.

 

Fazit: Besser den Speicher am neuen Server anhängen und formatieren und die bestehenden Sicherungen per SMB kopieren.

[cj_berlin 1.138]

vor 13 Minuten schrieb mwiederkehr:

Fazit: Besser den Speicher am neuen Server anhängen und formatieren und die bestehenden Sicherungen per SMB kopieren.

Ich würde eher sagen, wenn das SAN das hergibt, einmal ein Volume an den 2012er präsentieren, Backup verschieben, dann dieses Volume UND ein neues Volume an den neuen Server präsentieren und lokal kopieren.

[Squire 211]

Wenn Du Veeam einsetzt, dann kannst Du das Backup mit Veeam selbst moven. Hab ich grad mit unseren beiden DataDomains hinter mir.

Das ist eine neue Funktion der V12. Job editieren und neues Repository auswählen. Veeam frägt Dich dann, ob Du neues Backup haben willst, oder die vorhandenen verschoben werden sollen. Ich würde den neuen Server einrichten. am alten als Repository bekannt machen und Veeam seine Arbeit machen lassen. Wenn alles verschoben ist kannst ja schwenken.

Aber Achtung 50TB brauchen bis die gemoved sind - so lange ist der Backup Job deaktiviert

 

bearbeitet 18. September 2023 von Squire

[NilsK 2.785]

Moin,

 

+1. In solchen Situationen bin ich auch Freund davon, den Job von der Komponente machen zu lassen, die dafür gebaut ist.

 

Gruß, Nils

 

[mwiederkehr 351]

vor 2 Stunden schrieb Squire:

Wenn Du Veeam einsetzt, dann kannst Du das Backup mit Veeam selbst moven.

+1 auch von mir. Ich habe noch zu wenig Routine mit V12, deshalb war mir das Feature nicht präsent.

 

Falls noch kein V12 im Einsatz ist, würde ich einen Neuaufbau der Backups prüfen, um die neuen Features nutzen zu können.

[Garant 3]

vor 2 Stunden schrieb Squire:

Wenn Du Veeam einsetzt, dann kannst Du das Backup mit Veeam selbst moven. Hab ich grad mit unseren beiden DataDomains hinter mir.

Das ist eine neue Funktion der V12. Job editieren und neues Repository auswählen. Veeam frägt Dich dann, ob Du neues Backup haben willst, oder die vorhandenen verschoben werden sollen. Ich würde den neuen Server einrichten. am alten als Repository bekannt machen und Veeam seine Arbeit machen lassen. Wenn alles verschoben ist kannst ja schwenken.

Aber Achtung 50TB brauchen bis die gemoved sind - so lange ist der Backup Job deaktiviert

 

 

Hallo Squire,

 

das ist ja genau mein Problem - ich kann dem neuen Server das alte Repo nicht bekannt machen, da es ein "lokales" Repo auf dem alten Backupserver ist. Also nichts was irgendwo im SAN liegt.. :|. 

Wir setzen auch noch V11 von VEEAM ein und das nachgelagerte Thema mit DataDomain ist auch mein "Kopfschmerz", da ich ungern möchte, dass der CopyJob von vorn beginnen muss.

[Nobbyaushb 1.359]

vor einer Stunde schrieb Garant:

Wir setzen auch noch V11 von VEEAM ein und das nachgelagerte Thema mit DataDomain ist auch mein "Kopfschmerz", da ich ungern möchte, dass der CopyJob von vorn beginnen muss.

Moin,

du kannst ein Inplace-Update auf die V12 machen - alle Jobs etc. bleiben erhalten

Und dann geht das wie oben beschrieben zu verschieben, hat gerade ein Kunde von mir gemacht

Auch auf dem "alten" Veeam war das Storage lokal, auf dem Neuen via iSCSI Target angebunden