VMware-Forum

https://www.frankysweb.de/vmware-view-d ... eschlagen/

Franky hat geschrieben:Der Fehler tritt auf da die NTUser.dat Datei innerhalb des Benutzerprofiles korrupt ist. Meist zu erkennen an der Größe von genau 256KB. Das löschen der NTUser.dat hilft zwar, damit sich der Benutzer wieder anmelden kann, behebt aber nicht die Ursache.

Der Fehler tritt auf wenn folgende Situation zutrifft: Die View Profile der Benutzer liegen auf einem Fileserver mit Windows Server 2012 als Betriebssystem und aktivierter Deduplizierung.

Ursache des Problems ist das Windows 2012 Feature „Deduplizierung“, welches die Probleme mit der NTUser.dat verursacht. Hier hilft scheinbar nur abschalten und „entdeduplizieren“.

Soweit mir bekannt ist, kann man neben der Dateigrösse auch Dateien von der Deduplizierung ausnehmen. Von daher erscheint mir die Dedup-Abschaltung für das gesamte Volume als etwas übertrieben.

Stimmt, da hast du recht. Aber das weckt trotzdem nicht das Vertrauen in die MS Dedup Technik. Da sollte auf die datenintegrität eigentlich immer Verlass sein.

Vertrauen würde ich da eh nicht haben. Sieh dir mal an, in welchem Win-Ordner der Dedup landet. Wenn irgendetwas mit diesem Ordner oder auch Teilen seines Inhaltes passiert, betrifft das sofort alle damit deduplizierten Daten. Winzigweich hat da überhaupt keine weitere Sicherung eingebaut.

Von der Warte und vor allem im Hinblick auf die mittlererweile verfügbaren Datenträgergrössen bin ich mir sowieso uneins, ob Dedup da überhaupt notwendig bzw sinnvoll ist. Zumal M$s Dedup-Implementierung nicht Live sondern nach Ablauf einer einstellbaren Frist als Task im Taskplaner während geringer Systemlast durchläuft.

Dayworker hat geschrieben:Vertrauen würde ich da eh nicht haben. Sieh dir mal an, in welchem Win-Ordner der Dedup landet. Wenn irgendetwas mit diesem Ordner oder auch Teilen seines Inhaltes passiert, betrifft das sofort alle damit deduplizierten Daten. Winzigweich hat da überhaupt keine weitere Sicherung eingebaut.

Von der Warte und vor allem im Hinblick auf die mittlererweile verfügbaren Datenträgergrössen bin ich mir sowieso uneins, ob Dedup da überhaupt notwendig bzw sinnvoll ist. Zumal M$s Dedup-Implementierung nicht Live sondern nach Ablauf einer einstellbaren Frist als Task im Taskplaner während geringer Systemlast durchläuft.

Hallo,
nach meinem Stand ist dedupe auch nicht unbedingt für aktive Systeme gedacht sondern eher für Datengräber bei denen sich die Daten nicht ständig dynamisch ändern.
Mag bei High-End-Systemen anders sein aber wer fährt die schon.

Gruss

Mich würde da brennend interessieren wie das eingerichtet wurde. Auf dem Systemlaufwerk innerhalb eines OS ist Dedup meines Wissens nach wie vor nicht supported.

Des weiteren ist Dedupe jeglicher Art grundsätzlich ein potentielles Risiko für Datenverlust wenn der Zusammenzug der Daten oder das Verwaltungssystem hops geht. Da ist es aber total egal welcher Hersteller das betrifft. Wird Datensicherung auf ein Dedupe-Volume betrieben, sind unter Umständen und je nach Design sämtliche Sicherungen am Arsch wenn ein paar Blöcke kaputt gehen.


Ansonsten sehe ich das Potential von Dedupe auf OS-Disk Ebene eher darin mehrere virtuelle OS-Disks von verschiedenen VM's innerhalb eines Datastores zu deduplizieren. Das macht irgendwo Sinn. Das Systemlaufwerk sonst sehe ich jetzt ned wirklich einen grossen Sinn darin.

Vorteil von Dedupe ist ja nicht nur der reine Platzersparnis sondern auch fördern von Cache-Mechanismen. Sei es auf OS-Ebene mit nem Cluster (Quasi beliebig grosser RAM-ReadCache) oder eben auf Hardwareebene durch das Storage. Jeder Block muss nur einmal in den Cache nicht X-mal.


Ich habe zumindest schon einige Umgebungen erstellt und im Unterhalt wo ich Windows als Storage-VM hernehme und den Datastore der OS-Disks dedupliziere. Das geht wunderbar, performant und ohne jegliche Probleme.

Bin da eigentlich der Meinung, dass es genau am richtigen Ort abgelegt wird. Da wo niemand direkt Zugriff hat.

Moin,
wir haben jetzt seid April unseren 2012'er Fileserver mit Deduplizierung im Echtbetrieb.
Ein wirkliches Ärgernis bzw. Aha-Erlebnis hatten wir mit dem Search Serverdienst auf dem Server. Der funktioniert nämlich bei Partitionen mit aktivierter Deduplizierung nicht!

In der Praxis führte das dann zu tollen Effekten bei Dateisuchen auf den gemapten Laufwerken der User!
Leider kommuniziert MS nicht gerade sehr offen, dass der Search Serverdienst bei Deduplizierung nicht funktioniert bzw. Probleme bei deduplizierte Dateien macht.

Das Problem stellt sich wie folgt dar:
1. Es werden diverse Dokumente (z.B. PDF's) in einem VZ abgelegt, dass auf einer Deduplizierten Partition liegt. Diese Dokumente werden zunächst durch den Search Serverdienst indexiert, da Dedup ja erst nach 5 Tagen läuft (Standardeinstellung).
2. Ein User sucht nach 14 Tagen nach PDF's auf dem Server im obigen VZ. Es werden auch alle PDF's in der Suche angezeigt...
3. Der User öffnet einige der der PDF's mit Acrobat Reader
4. Search Server registriert, dass die PDF's geöffnet wurden und indexiert neu... PDF's sind inzwischen dedupliziert und fliegen aus dem Index...
5. User sucht wieder nach PDF's und findet jetzt die obigen PDF's nicht mehr.
usw.

Stellt sich mir die Frage, warum MS überhaupt zulässt, dass der Search Serverdienst sich bei aktivierter Deduplizierung überhaupt aktivieren lässt!

Aber immerhin sparen wir fast 50% Space auf unserem Fileserver...

Gruß
Dirk

Gerade im Hinblick auf Datengräber erscheint mir Dedup als besonders risikoreich, da die Daten ja nur selten angefaßt werden und ein Backup ggf einen unbemerkten Bitfehler nur weiterverschleppt, bis die vielleicht einzige fehlerfreie Version aus dem Backup fällt.

Also Fehler enden bei Windows im löschen der Files... insofern wird kaum falsches gesichert

MS hat da aber einige Sicherheiten eingebaut damit das auch zuverlässig und betriebssicher tut. Spätestens wenn es für die StorageSpaces freigeben wird, dürfte die Datenssicherheit nochmals deutlich gesteigert werden durch mehrfachspeicherung etc. Aktuell wird da wohl einfach mit dem Superrobusten NTFS Erfahrungen gesammelt.

Probleme wie der Indexdienst dürften kaum so einfach lösbar sein, wenn der Index direkt auf der untersten Ebene ausliest. Da sieht er dann nur noch unsinnige Blöcke. Denke das wird ein eher grober Eingriff von MS für NTFS. Könnte mir gut vorstellen, das MS das Problem gar nicht mehr löst, sondern erst für ReFs.
Mit solche Nichtigkeiten schlägt man sich bei MS seit dem neuesten Management doch nicht mehr herum. Da werden lieber Preise erhöht, Lizenzbedingungen verschlechtert und der Support abgebaut. Richtiger Konzern ohne Patron eben.


NTFS hat es meiner Meinung nach gezeigt, dass MS mit wenn nicht das robusteste Filesystem hat. Ich traue denen diesbezüglich wesentlich mehr über den Weg als jedem anderen Unternehmen, dass Daten dedupliziert.


Nichts desto trotz, ein zusammenzug von Daten bleibt ein Zusammenzug von Daten. Völlig egal welcher Anbieter. Wurscht wie er erreicht wurde. Sei es durch Kompression oder Deduplikation. Gemeinsame Blöcke (EDIT: sowie die VerwaltungsDB/Register) haben also nicht auf eine Datei sondern immer auf alle Dateien einen Einfluss. Das muss man einfach bedenken und nicht verharmlosen bzw. eben meiner Meinung nach auch mit zwei verschiedenen Backupstrategien absichern.

Dayworker hat geschrieben:Gerade im Hinblick auf Datengräber erscheint mir Dedup als besonders risikoreich, da die Daten ja nur selten angefaßt werden und ein Backup ggf einen unbemerkten Bitfehler nur weiterverschleppt, bis die vielleicht einzige fehlerfreie Version aus dem Backup fällt.

Dafür gibt es doch dann Bandsicherungen im Banksafe über eine ausreichende Anzahl Jahre.

Gruss

rprengel hat geschrieben:

Dayworker hat geschrieben:Gerade im Hinblick auf Datengräber erscheint mir Dedup als besonders risikoreich, da die Daten ja nur selten angefaßt werden und ein Backup ggf einen unbemerkten Bitfehler nur weiterverschleppt, bis die vielleicht einzige fehlerfreie Version aus dem Backup fällt.

Dafür gibt es doch dann Bandsicherungen im Banksafe über eine ausreichende Anzahl Jahre.

Gruss

Naja, davon kommen ja immer mehr Leute weg. Disk genügt ja. *hust*
Kommt dazu, dass man den kram ja oft noch ned mal mehr gscheit einbinden kann in moderne Backuplösungen/Umgebungen...