Win 2012 storage space - alle wijzigingen verloren???

[psy]

Ik heb toch iets raars meegemaakt gisteren.
Ik draai een Windows 2012 installatie met onder andere een viertal Samsung 2TB disks waarop een Storage Space draait. Deze heb ik ingedeeld in 2 virtual disks
1 simple (NTFS)
1 mirror (ReFS) te noemen schijf Z

Het mirror gedeelte is voor mijn private data, deze staat dus altijd op 1 andere disks. Hier heb ik eigenlijk nooit gedonder mee.

Het gaat nu om het simple gedeelte. Deze staat dus in feite als RAID0 verdeeld over de Samsung schijven.
Dit wordt alleen gebruikt voor films, series, enzo. Geen belangrijke data.
Wel draai ik elke avond een automatische backup naar een tweede machine hier in huis.

Ik heb gistermiddag een hele hoop series en films gedownload en deze ook verplaatst naar deze Z schijf.
Tegen 20:30 merkte dat de hele 2012 installatie nauwelijks meer reageerde, wel kon ik de shares nog benaderen maar verder kon ik geen bruikbare RDP sessie meer starten. Ik heb dus de hele (virtuele) 2012 machine gereset.

Wat bleek daarna, ALLE wijzigingen die ik die dag had aangebracht waren pleite. Het was alsof ik naar de situatie van zondagmorgen zat te kijken.

Hoe weet ik dat nou zo zeker?
Nou, de backup, die succesvol was afgerond
Start time: 9-6-2013 20:00:05
Completed : 9-6-2013 20:04:57
Short Results: 47 copied (18.3GB), 5 deleted

Op de backupmachine staat alles nu zoals het hoort. Maar de server zelf is weer terug in de staat daarvoor.

WTF?

Hoe kan dit nou?

[Verwijderd]

Geen idee, maar heb je de SMART al gecontroleerd van je schijven die NTFS draaien?

[psy]

Beide disks draaien allemaal op dezelfde (4) schijven, geen SMART errors.

[Verwijderd]

Kan geen kwaad om de SMART hier even te posten. Zo heb ik al vaker gehad dat mensen zeiden dat er geen errors waren, omdat ze keken naar de SMART health die 'GOOD' zegt ofzoiets, maar er wel degelijk bad sectors waren en dus juist een heel groot probleem. SMART is iets wat je zelf moet interpreteren, geen programma ter wereld wat de SMART juist kan interpreteren.

Ik raad CrystalDiskInfo aan.

[ Voor 4% gewijzigd door Verwijderd op 10-06-2013 13:20 ]

[psy]

Dat kan uiteraard:

[Verwijderd]

Dat ziet er inderdaad prima uit. Dan terug naar je probleem; je hebt als ik je verhaal goed begrijp last van een soort 'rollback' over een hele dag (hoeveel uur gaat het dan om?) nadat je op de resetknop had gedrukt. Mijn vraag is, gaat het daarbij alleen om het simpele volume of ook je ReFS-volume?

Storagespaces is verder een extra laag bovenop het filesystem, van die laag weet ik verder heel weinig (vrijwel niets). Ik kan dus niet uitsluiten dat daar je probleem cq. oorzaak ligt, maar dat lijkt me wel enigszins aannemelijk.

Als je op de resetknop drukt dan wordt met journaling je filesystem in het verleden teruggedraaid, dit heet een rollback. Maar dat zou nooit zover in het verleden mogen zijn in het bijzonder wanneer je veel veranderingen hebt doorgevoerd in die tijd. Dus het is voor mij ook gissen hoe zoiets zou kunnen.

[Uncle Mel]

Verwijderd

[ Voor 95% gewijzigd door Uncle Mel op 30-01-2014 21:37 ]

[psy]

Verwijderd schreef op maandag 10 juni 2013 @ 14:10:
Dat ziet er inderdaad prima uit. Dan terug naar je probleem; je hebt als ik je verhaal goed begrijp last van een soort 'rollback' over een hele dag (hoeveel uur gaat het dan om?) nadat je op de resetknop had gedrukt. Mijn vraag is, gaat het daarbij alleen om het simpele volume of ook je ReFS-volume?

Storagespaces is verder een extra laag bovenop het filesystem, van die laag weet ik verder heel weinig (vrijwel niets). Ik kan dus niet uitsluiten dat daar je probleem cq. oorzaak ligt, maar dat lijkt me wel enigszins aannemelijk.

Als je op de resetknop drukt dan wordt met journaling je filesystem in het verleden teruggedraaid, dit heet een rollback. Maar dat zou nooit zover in het verleden mogen zijn in het bijzonder wanneer je veel veranderingen hebt doorgevoerd in die tijd. Dus het is voor mij ook gissen hoe zoiets zou kunnen.

ReFS volume was toen niets aan gewijzigd.

Mutaties waren van 16:15
Backup was 20:00 tot 20:06
De reset was van 20:45 ongeveer

Ja het is een raar verhaal.

Uncle Mel schreef op maandag 10 juni 2013 @ 14:26:
Kan het zo zijn dat je VM in RAM draaide en bij Reset niet zijn metadata wegschreef naar de (fysieke) hard drive?

Dat zou verklaren waarom de backup wel lukte maar na een restart hij weer in zijn oude bestandsstructuur stond. Als dat zo is, kun je wel corruptie hebben in je bestanden en zul je je backup moeten terugschrijven.

Iets dergelijks zou het wel verklaren maar is dat uberhaupt mogelijk? Zijn gewoon hyper-v machines die op een aparte SSD draaien. De reset heb ik ook vanuit de hyper-v host uitgevoerd dus de SSD is gewoon door blijven draaien met alle andere hyper-v machines.

[ Voor 23% gewijzigd door psy op 10-06-2013 14:42 ]

[Wim-Bart]

Toevallig het vinkje "Turn off Windows write-cache buffer flushing on the device" aan staan op een disk? Want dan kan het voor komen dat er geen flush naar de disk is geweest voordat de drive opnieuw geïnitialiseerd is door de BIOS. Wanneer je geen "safe"-shutdown kan doen is dit dodelijk voor je data.