gewährleistet WHS Datenkonsistenz?

[pfaelzer]

Hallo Wissende,

angenommen, ich habe auf einem Client eine Excel-Datei erstellt mit Office 2003, alle Patches. Weiter angenommen, ich kopiere diese Datei einmal im Rahmen einer "Datensicherung mit einem Synctool" in das WHS-Share "Benutzer/Client/Datensicherung/..." und zeitnah (ohne Änderungen zwischendurch) in das WHS-Share "öffentlich". Dann könnte ich doch annehmen, ich habe zweimal eine identische Datei auf dem WHS?!?

Jetzt nehmen wir an, ich connecte den WHS über das Internet und greife auf beide WHS-Shares zu. Ich würde zweimal eine Datei sehen mit gleichem Namen und gleicher Größe. Richtig?

Nehmen wir weiter an, ich öffne beide Dateien mit einem Notebook (auch Office 2003) auch mit Excel und erhalte einmal eine Meldung "Datei ist beschädigt, Reparaturversuch war erfolglos", was sollte ich denken wollen?

Ich habe bisher oft "nehmen wir an" gesagt, da ich das Erlebte einfach nicht glauben will. Ich habe die gleiche Datei zweimal jeweils ohne Fehlermeldung auf meinen WHS kopiert, einmal kann ich sie öffnen, einmal nicht. "FC" (file compare) ergibt tatsächlich Unterschiede.

Wo kann ich ansetzen, bevor ich das Vertrauen zum WHS verliere? Wo kann der Fehler liegen? Was kann ich als "dummer Anwender" tun ausser "dumm gucken"?

Gruß Werner

[Martin]

Hallo Werner,

ich denke da hat dich der noch nicht behobene Fehler mit der Datenkonsistenz getroffen (http://support.microsoft.com/?scid=kb%3 ... &x=10&y=12). Dass dieser allerdings auch so auftritt ist schon heftig.

Aus Anwendersicht ist dein Vorgehen absolut in Ordnung. Einen Fehler auf deiner Seite würde ich ausschließen, solange Du die Datei nicht mit Excel selbst auf dem Netzwerk speicherst.

Nur aus Interesse: Welche Version ist defekt? Die mit dem Synctool kopierte in Benutzer oder die (manuell?) kopierte in Öffentlich? Und welcher der beiden Freigaben hat Folder Duplication aktiv?

Such doch mal ausgehend vom Dateinamen in den q_de.logs bzw. qsm.log ob es da einen Fehler gegeben hat.

Gruß
Martin

[pfaelzer]

Hallo Martin,

Dass dieser allerdings auch so auftritt ist schon heftig.

oh ja, insbesondere, weil ich noch eine weitere (auch) Excel Datei gefunden habe, die ich aus der Datensicherung nicht öffnen kann.

Nur aus Interesse: Welche Version ist defekt?

Defekt ist die Version, die mit dem Synctool in die Datensicherung kopiert wurde. Dort ist auch "Folder duplication" aktiv. Ein Fehler mit dem Synctool schliesse ich aus.

Such doch mal ausgehend vom Dateinamen

frühestens ab morgen abend.

Mal so direkt gefragt, ist der WHS "produktiv" einsetzbar?

Gruß Werner

[AliG]

Hi!
Benützt du SyncToy 2.0 ? Denn das steht auf der Liste der gefährdeten Programme: http://support.microsoft.com/kb/946676/en-us?spid=12624

oh ja, insbesondere, weil ich noch eine weitere (auch) Excel Datei gefunden habe, die ich aus der Datensicherung nicht öffnen kann.

Also das ist mir neu, bis jetzt betraf der Datenkorruptionsbug nur Dateien die in den Freigaben lagen, Backups waren sicher. Ich denke die Datei war schon bei der Sicherung defekt, denn ich kann mir nicht vorstellen dass gerade diese eine Datei in der Backupdatenbank defekt sein soll (aufgrund der Technik die dahintersteckt).

lg Alex

[pfaelzer]

Hallo Alex,

Benützt du SyncToy 2.0 ? Denn das steht auf der Liste der gefährdeten Programme

Nein, ein anderes, was nicht auf der Liste steht. Aber wer weiss, vielleicht nutzen unterschiedliche Programme zum Kopieren gleiche Schnittstellen?

Wie auch immer, ich muss doch sicher sein, einige zigtausend Dateien zu kopieren ohne jede einzelne zu überprüfen. Ich gehe sogar soweit zu behaupten, eine Datei konsistent auf ein freigegebenes Share zu kopieren ist Basisvoraussetzung, sich "Server" nennen zu dürfen.

bis jetzt betraf der Datenkorruptionsbug nur Dateien die in den Freigaben lagen, Backups waren sicher

upps, meine Schuld. Ich meinte nicht "Backups" in WHS-Terminologie, sondern ich sichere meine (wichtigen) Daten regelmäßig 1:1, da ich mit komplexeren Methoden der Datensicherung in der Vergangenheit "im Falle dass" dann doch Probleme hatte. Ich habe alle für mich wichtigen Dateien 1:1 an andere Stelle kopiert und sage "Datensicherung" dazu. Sorry, mein Fehler hier.

Konkrete Frage, sind meine Probleme gelöst, wenn ich auf Ordnerduplizierung verzichte?

Ob Backups in WHS-Terminologie betroffen sind, weiss ich nicht, möchte ich auch bei der Gesamtzahl meiner Dateien nicht einzeln überprüfen wollen.

Sorry, ich erwarte von einem Server auch der "Home-Zielgruppe", dass er nach erfolgter Kopie einer Datei ohne Fehlermeldung diese Datei unverändert wieder "hergibt". Und nein, bisher habe ich auf den WHS nur kopiert, ihn quasi nur als zusätzlichen Datenspeicher benutzt.

Soll ich meine Gedanken tatsächlich alle fallenlassen, einen Server einzurichten, mit vielleicht sogar Office zentral installiert, mindestens aber alle Vorlagen und Daten einmal zentral auf Server-Shares?

Gibt es eine MS-Aussage, wann der WHS servt? Ich finde keinen MS-Hinweis über meine(n) Fehler.

Gruß Werner

[Martin]

Hallo Werner,

ich setzte 2 WHS Systeme produktiv ein, einmal privat und einmal im Büro. Die Büromaschine aber primär fürs Backup.
Zum Synchronisieren benutzte ich ein per Taskplaner laufendes Robocopy.

Konkrete Frage, sind meine Probleme gelöst, wenn ich auf Ordnerduplizierung verzichte?

Nein, denn das Speicherprinzip ist das gleiche. Eventuell ist wegen der geringeren Datenmenge die verlagert wird, das Zeitfenster für eine Korruption kleiner und damit weniger anfällig.

Gibt es eine MS-Aussage, wann der WHS servt? Ich finde keinen MS-Hinweis über meine(n) Fehler.

Bisher heißt es bei MS, man arbeite mit Hochdruck an der Lösung. Ich vermute mal, dass dieser Fix in das Power Pack 1 mit rein soll. Und ich bin mir auch sicher, dass es weit mehr Programme und Konstellationen gibt, die dieses Problem hervorrufen. Wenn also deine spezielle Vorgehensweise nicht in dem KB Artikel beschrieben ist, heisst das nicht im Umkehrschluss dass es dann nicht auftreten kann.

Im US-Forum gibt es z.B. einen längeren Thread, wie mit einer simplen Batchdatei, die im Prinzip eine Datei erzeugt, löscht und wieder neu anlegt, das Problem provoziert werden kann.
http://forums.microsoft.com/WindowsHome ... &SiteID=50
Und jeden Tag gibt es dort inzwischen neue Meldungen zur Datenkorruption. Ich denke MS ist sich der Problematik bewusst.

Gruß
Martin

[maody]

Ich kann mich da mal anschliessen (und mach nicht extra nen weiteren (heul-)thread) dafür auf:

Heute morgen wollte ich übers Web auf einige Verzeichnisse im "Öffentlich" zugreifen. Ging nicht. Der IE zeigte die Verzeichnisse zwar an, wollte aber nicht "reingehen". Dacht ich mir: Da stimmt was mit den Rechten nicht. Remote Desktop auf den WHS. Im Explorer mal nachgschaut. Rechte stimmten alle.

Dabei hab ich entdeckt, dass in besagtem Unterordner das "Schreibschutzflag" auf ein Verzeichnis gesetzt war, was ich so aber nicht wollte. Weggeclickt, OK gedrückt und es macht pooof (mal rein symbolisch gesprochen).

Was war passiert? Das komplette Verzeichnis mit einigen hundert Dateien und Unterverzeichnissen ist einfach weg. Futsch. Nicht mehr auffindbar. Komplett weg vom Server.

Mag sein das sich das mit gefrickel wieder rekonstruieren lässt. Aber da hab ich keine Zeit für. Mein Vertrauen in den WHS als sichern Datenhort sinkt gerade auf unter Null Werte

[pfaelzer]

Hallo Martin,

der Form halber einen Zwischenstatus:

Such doch mal ausgehend vom Dateinamen in den q_de.logs bzw. qsm.log ob es da einen Fehler gegeben hat.

ja, beide (und noch viel mehr) Dateien sind in der q_de.log mit dem Fehler "failed to rename shadow" aufgeführt.

Und jetzt bin ich nicht nur "verwundert", sondern "stinkesauer". Wenn MS selbst feststellt, dass da was schief gelaufen ist, warum bekomme ich als dummer Anwender nicht einen Hinweis darauf? Oder ist der WHS derart fehlertolerant, dass er sich selbst alle Fehler verzeiht?

Gruß Werner

[whs_cb]

Hallo,
da wir hier gerade ueber Logfiles reden, gibt es irgendwo eine technische Referenz bzgl. der ganzen Logfiles vom WHS, ich bin gerade dabei, ein paar Scripte fuer den MS Logparser zu schreiben, um das floehen der Logfiles zu vereinfachen, aber ich tappe bei vielen Dingen mehr oder weniger im Dunkeln ...

Gruss, whs_cb

[Martin]

Mir ist keine bekannt.

Gruß
Martin

[Christoph]

Hallo,
da wir hier gerade ueber Logfiles reden, gibt es irgendwo eine technische Referenz bzgl. der ganzen Logfiles vom WHS, ich bin gerade dabei, ein paar Scripte fuer den MS Logparser zu schreiben, um das floehen der Logfiles zu vereinfachen, aber ich tappe bei vielen Dingen mehr oder weniger im Dunkeln ...

Gruss, whs_cb

Hi whs_cb,

sofern du das weiter bist, könnten wir eventuell einen Artikel machen wo andere Leute auch von der Log Parser Sache profitieren?

Danke

Christoph

[Martin]

@Werner,

ich habe gerade mal einen binären Vergleich über die Daten auf dem WHS gegen den SBS 2003 im Buro gemacht.
Hintergrund: Ich spiegle nachts um 01.00 Uhr per Taskplaner mein Projektverzeichnis mit robocopy auf den WHS.
Die Kommandozeile lautet:

Code: Alles auswählen

"C:\Programme\Windows Resource Kits\Tools\robocopy.exe" \\pe2600\projekte \\whsbackup\projekte /MIR /NP /ZB /NDL /LOG+:"D:\robocopy.log"

Das Volumen liegt bei 12,3GB verteilt auf:
77000 Dateien
10000 Ordnern

Der Vergleich ergab KEINE binären Differenzen. Von daher kann ich nur vermuten dass es an deinem Synctool liegt.

Gruß
Martin

[pfaelzer]

Hallo Martin,

danke, dass dich mein Problem weiter interessiert ...

Der Vergleich ergab KEINE binären Differenzen. Von daher kann ich nur vermuten dass es an deinem Synctool liegt

die einzig legitime Folgerung daraus ist, dass der Fehler bei dir nicht auftritt. Mein Synctool vergleicht Datum/ Uhrzeit und setzt dann einen ganz "normalen Copy" über die definierte Userschnittstelle ab.

Mittels Log und probieren glaube ich, die Ursache bei mir gefunden zu haben. Wenn ich auf einem Share viele Dateioperationen habe (viel kopieren, löschen, etc) und dieser Share hat "duplication" aktiviert, dann kann mein WHS nicht folgen, seinen Shadow zu aktualisieren. Er versucht dann z.B., den Shadow einer Datei anzulegen, die bereits wieder gelöscht wurde oder hat Shadows von Dateien, die es nicht mehr gibt.

Weiter trat bei mir das Problem auf, dass die Länge des Pfadnamens begrenzt ist (ich glaube auf 400). Wenn im Original der Pfadname "knapp ausreicht", überschreitet er im Shadow diese Grenze, da der Pfadname des Shadow "per Definition" einige Zeichen länger ist. Dies führt zu einer Inkonsistenz, der Server meldet, er ist nicht mehr "integer". Wenn man jetzt diese Datei löscht und mit verkürztem Pfadnamen erneut auf den WHS kopiert, streicht er die Segel und ergibt sich. Im q_de.log stehen dann entsprechende Hinweise, dass er reparsepoints hat von Dateien, die es mit diesem Pfadnamen nicht mehr gibt.

Gruß Werner

[Martin]

Das Problem mit den zu langen Dateinamen war bekannt. Da hätte ich dich darauf hinweisen müssen, dachte aber dass der WHS seit dem Update das selber erkennt.
Ich hatte am Anfang mal diese Liste hier erstellt:

- Readonly Dateien (sollte das Novenber-Update behoben haben)
- Dateien mit Alternate Data Streams (dito)
- Dateien die zum Zeitpunkt der Duplizierung in Bearbeitung waren (ist dann nur ein temporäres Problem)
- Zu lange Verzeichnispfade
- Dateinamen mit unzul. Sonderzeichen (meist auf Linuxsystemen entstandene Dateien)

Das andere beschriebene Problem ist genau das aus dem US Forum, das ich weiter oben schon zitiert hatte. Sind die Probleme mit den vielen Dateioperationen durch das Synctool aufgetreten oder waren das manuelle Aktionen?

Gruß
Martin

[whs_cb]

Hallo,
da wir hier gerade ueber Logfiles reden, gibt es irgendwo eine technische Referenz bzgl. der ganzen Logfiles vom WHS, ich bin gerade dabei, ein paar Scripte fuer den MS Logparser zu schreiben, um das floehen der Logfiles zu vereinfachen, aber ich tappe bei vielen Dingen mehr oder weniger im Dunkeln ...

Gruss, whs_cb

Hi whs_cb,

sofern du das weiter bist, könnten wir eventuell einen Artikel machen wo andere Leute auch von der Log Parser Sache profitieren?

Danke

Christoph

Hallo,
ja, sofern ich irgendwann mal zu wirklich verwertbaren Infos komme
Derzeit ist es eher Jugend forscht und recht muehselig.

Gruss, whs_cb