Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
nachdem ich schon eine Weile hier und im Rest des Internets gewühlt habe, bin ich immer noch auf keinen wirklich eindeutigen Nenner gekommen. Meine Frage lautet eigentlich einfach nur:
Macht es schon Sinn, ReFS auf einem Fileserver produktiv einzusetzen, oder ist NTFS noch die bessere Wahl?
Die größe des Servers wird im Bereich einiger TB liegen, sagen wir max. 16 bis 32 TB und Dedupe spielt nicht so die Rolle; tägliche Backups werden ebenfalls angefertigt.
Oder gibt es Best Practises, bei denen ich anhand einer Checkliste sagen kann, ReFS ja oder nein?
Auf Dedup sollte man nicht verzichten, man glaubt gar nicht, wie viele Dateien zig mal abgelegt sind.
ReFS kann kein Quota, falls das notwendig ist.
Ansonsten findest du hier von MS einen Vergleich: ReFS vs NTFS
Einfach die Features durchgehen und danach entscheiden.
ReFS ist ja etwas speziell und NTFS der "Standard". Ich persönlich würde es auf NTFS belassen bzw. aufsetzen.
Rest dann der Aussage des Vorredners befolgen.
Es kommt wie immer drauf an. ReFS kann viel besser mit Milliarden kleinen Dateien umgehen, das steht schon mal auf der Positivliste. Auf der anderen Seite hast du natürlich das Problem, dass nicht jede Datensicherungssoftware damit vernünftig umgehen kann und auch ein "chkdsk" funktioniert schlichtweg nicht. Die Selbstreparaturfunktion, ist eine tolle Sache, sie geht aber nur wenn du Storage Spaces mit Raid1 einsetzt.
Somit bleibt der wichtige Punkt, wenn auf dem Fileserver sehr sehr viele Dateien sollen, solltest du es erwägen, wenn nicht dann eher nicht.
Ergänzung ()
b1nb4sh schrieb:
Auf Dedup sollte man nicht verzichten, man glaubt gar nicht, wie viele Dateien zig mal abgelegt sind.
Dedup dedupliziert nicht gleiche Dateien (das war SIS), sondern Dateiblöcke. Du musst es dir mehr als Komprimierungssoftware vorstellen, die mit Trees arbeitet und mehrfach vorkommende Blöcke als Verweise speichert.
Das senkt die Kompatibilität zur Sicherungssoftware aber noch weiter herunter und verlangsamt natürlich auch die Zugriffe. Für ein Archivierungslaufwerk kann man es sich überlegen und für einige andere Anwendungsfälle auch, grundsätzlich würde ich aber nicht überall die Deduplikation "einfach so" einschalten.
Das ist alles richtig. NTFS reicht sicherlich noch aus. Allerdings zielt die Frage auch ein Stück weit darauf ab, ob man in Blick Richtung Zukunft nicht auch schon ReFS einsetzen kann; eben auch für einen normalen Fileserver. Die Vergleichstabelle von Microsoft gibt da nicht viel her. Die Meinung lautet irgendwie am Ende immer nur: Ja, es geht. - Aber ob es jetzt schon Sinn macht, oder erst in - sagen wir mal - 5 Jahren, darüber schweigt sich fast jede Quelle tot.
Dedup dedupliziert nicht gleiche Dateien (das war SIS), sondern Dateiblöcke. Du musst es dir mehr als Komprimierungssoftware vorstellen, die mit Trees arbeitet und mehrfach vorkommende Blöcke als Verweise speichert.
Mir ist bewusst wie Data Dedup funktioniert, es geht hier um einen Fileserver und und der TE hat nicht näher spezifiziert, was auf dem FS liegen soll, aber per se schon Dedup ausgeschlossen.
Ansonsten: MS Dedup
"Data Deduplication can effectively minimize the costs of a server application's data consumption by reducing the amount of disk space consumed by redundant data. Before enabling deduplication, it is important that you understand the characteristics of your workload to ensure that you get the maximum performance out of your storage. There are two classes of workloads to consider:"
Recommended workloads that have been proven to have both datasets that benefit highly from deduplication and have resource consumption patterns that are compatible with Data Deduplication's post-processing model. We recommend that you always enable Data Deduplication on these workloads:
General purpose file servers (GPFS) serving shares such as team shares, user home folders, work folders, and software development shares.
Workloads that might benefit from deduplication, but aren't always good candidates for deduplication. For example, the following workloads could work well with deduplication, but you should evaluate the benefits of deduplication first:
General purpose Hyper-V hosts
SQL servers
Line-of-business (LOB) servers
Wegen der Sicherungssoftware:
Veeam unterstützt ReFS
Acronis unterstützt ReFS
Urbackup kann es nicht
Weil keine Quelle deine Anforderungen erraten kann, ReFS ersetzt NTFS nicht, genauso wenig wie Btfrs ext4 ersetzen würde. Wenn du Einsatzfälle hast bei denen die Vorteile von ReFS überwiegen, stellt sich die Frage nicht.
Ich hatte zum ersten Mal von ReFS auf einer Windows-Server-Schulung 2016 gehört. Der Schulungsleiter pries das Ding als den Heiligen Gral an. In der Praxis war's zum damaligen Zeitpunkt wohl noch Alpha- oder Betastadium.
Hellstorm schrieb:
Die Vergleichstabelle von Microsoft gibt da nicht viel her. Die Meinung lautet irgendwie am Ende immer nur: Ja, es geht. - Aber ob es jetzt schon Sinn macht, oder erst in - sagen wir mal - 5 Jahren, darüber schweigt sich fast jede Quelle tot.
Verlass Dich nicht auf auf Microsoft-Quellen. Such Dir lieber Erfahrungsberichte von Leuten, die das schon produktiv einsetzen. Und wenn du da keine findest, wird das vermutlich einen Grund haben.
If you plan to restore files from a VM running Microsoft Windows ReFS, consider the following requirements for the Veeam Backup & Replication components involved in the restore process:
The machine on which a mount point is created (for example, the mount server) must run Microsoft Windows Server 2012 or later.
[ReFS 3.x] If you plan to restore files from a VM running Microsoft Windows ReFS 3.x, the machine on which mount point is created must run Microsoft Windows Server 2016 or later and the ReFS version must be supported on it.
The machine on which a mount point is created must run Microsoft Windows Server of the same version or newer than the guest OS of a VM from which you plan to restore files.
Was bedeutet das im Echtbetrieb? Während du bei Sicherungen von NTFS Datenträgern jederzeit und auf einem beliebigen System, eine Wiederherstellung einzelner Dateien initiieren kannst, muss bei ReFS der Server auf dem du diese Wiederherstellung durchführen willst, das gesicherte Volume unterstützen. Veeam kann wie praktisch alle anderen Systeme nichts mit ReFS anfangen, um auf die Daten zuzugreifen wird der Datenträger über das System gemountet.
Simples Beispiel gefällig? Auf deinem Sicherungsserver läuft noch Server 2016, gesichert wird ein Server 2022 mit aktueller ReFS Version. Willst du nun einzelne Dateien wiederherstellen, hast du Pech gehabt, dein Server 2016 kann mit der aktuellen ReFS Version gar nichts anfangen. Üblich ist auch, falls du zusätzlich noch die Deduplikation genutzt hast, muss den entsprechende Dienst ebenfalls auf dem Sicherungsserver vorhanden sein.
ReFS bringt neben den Vorteilen auch jede Menge Nachteile mit sich, die oft von einigen "Aushilfsadmins" auf den ersten Blick gar nicht erkannt werden. Beschädigtes Dateisystem? Kann manchmal über Jahre hinweg nicht auffallen und ein Checkdisk ist nicht vorgesehen. Da kann dir schon mal passieren, dass du nach ein paar Jahren feststellst, oha die Ordner lassen sich gar nicht mehr zugreifen, alles schon erlebt.
Für ReFS sprechen eigentlich nur genau drei Anwendungsfälle:
Es sollen >Millionen Dateien gespeichert werden.
Es sollen .vhdx Dateien drauf genutzt werden.
Es werden Storage Spaces genutzt.
Und selbst bei diesen drei Fällen würde ich noch ein aber....... hinzufügen.
Das "Problem" kann man nicht wirklich fixen, es gibt schlichtweg verschiedene ReFS Versionen. Einfaches Beispiel gefällig?
Du hast einen ReFS formatierten Datenträger mit Daten und ein Server mit Server 2019. Nun möchtest du Server 2022 ausprobieren, oder schließt diesen Datenträger aus welchen Gründen auch immer an so einen Server an. Windows aktualisiert ReFS dann ungefragt auf die neue Version, unter Server 2019 siehst du dann nur noch "RAW".
Simples Beispiel gefällig? Auf deinem Sicherungsserver läuft noch Server 2016, gesichert wird ein Server 2021 mit aktueller ReFS Version. Willst du nun einzelne Dateien wiederherstellen, hast du Pech gehabt, dein Server 2016 kann mit der aktuellen ReFS Version gar nichts anfangen.
Ich gehe mal davon aus, dass du den Mountserver meinst, dieser sollte sowieso immer die aktuellste Version haben, hier Windows Server 2021, das Backup Repo kann dann ruhig auf deinen 2016 liegen.
Das ist nicht überall möglich oder gewünscht und letztlich ging es um deine Aussage Veeam würde ReFS unterstützen, das tut es nicht. Bei Acronis sieht es übrigens ebenfalls schlecht aus.
Ich würde mal ins blaue einfach mal behaupten, kein noch so aktuelles Drittanbieterprogramm zum Sichern oder Bearbeiten von Datenträgern unterstützt ReFS. Bestenfalls gibt es eingeschränkte Unterstützung, indem man Dateisystemfilter vom unterliegenden System nutzt.
Das ist alles richtig. NTFS reicht sicherlich noch aus. Allerdings zielt die Frage auch ein Stück weit darauf ab, ob man in Blick Richtung Zukunft nicht auch schon ReFS einsetzen kann; eben auch für einen normalen Fileserver.
Das hat um ehrlich zu sein nur wenig mit "Reife" zu tun, ich glaube selbst in 10 Jahren wird sich an diesem Stand nichts verändern. ReFS wurde nicht entwickelt um NTFS zu ersetzen, sondern für diverse speziellen Einsatzzwecke. Wer davon profitieren kann und wem die Einschränkungen bekannt sind, kann ReFS gerne nutzen. Ich habe selbst >100 Server mit ReFS eingerichtet, von denen allerdings die meisten Hyper-V Hosts waren und durch Replikation abgesichert gewesen sind.
Das Dateisystem ist stabil und bietet diverse Vorteile, aber eben auch Nachteile von denen leider einige nur im "Kleingedruckten" zu lesen sind. Den größten Bock hat Microsoft mit dem System selbst geschossen, als es früher als das sich selbstreparierende Dateisystem beworben wurde. Die Abhängigkeit dieser Funktion vom Einsatz der Storage Spaces wurde wenn überhaupt nur im Nachgang erklärt.
Naja, ReFS ohne Storage Spaces ist halt nur die halbe Miete... leider.
Für mich(!) wären der fehlende Quotasupport konkret auf einem Fileserver und sekundär die fehlende Unterstützung von EA ein Fast-ganz-totschlagargument. Fehlendes EFS mag dazukommen.
Dedup dagegen würde ich auf nem Fileserver dann und nur dann einsetzen, wenn ich wirklich A "zuviel" RAM habe und ich B davon ausgehen muß daß jede Menge Duplikate auch in irgendeiner Form vorhanden sein werden (zB weil zu viele Personen da schreiben dürfen und es keine echte Kontrolle gibt).
Ansonsten erkauft man sich das Minus an Speicherbedarf mit einem Plus an RAM Bedarf und (wie ich finde) unverhältnismäßig mehr RAM als man an Plattenplatz spart. DER kostet im Vergleich nämlich fast nix.
Dann lieber die Datenkompression einschalten an den Stellen, wo es gut komprimiertere Daten auch wirklich gibt.
