[2008 R2] Ik mis plots diskruimte op dataschijf

[mbr99]

Ik heb een Windows 2008 R2 server recentelijk in gebruik genomen. Er zitten 4 disks in. De C: staat in een array evenals de D: (mirrors). De totale capaciteit van D: is 146 GB. Gisteren stond daar op een datashare waar ongeveer 40 Gb in zit. Daarnaast een WindowsImageBackup folder van 20GB welke een dagelijks image is van de C: disk.

Disk D: bevat ook schadowkopieen. De limiet is echter ingesteld op het minimale van 500MB.

Het probleem is dat ik ruimte mis. Windows geeft aan dat er 117GB in gebruik is.Ik mis dus ruim 55GB. Er staat ook een System Volume Information folder op waarvan ik niet weet hoe groot die is. Mijzelf rechten toekennen gaat niet vlekkeloos. Als ik met vssadmin list shadowstorage kijk zie ik dat er op de D: disk 1,6 Gb in gebruik is voor VSC.

Zit er nog meer onbekende GB's in die map? Ik heb geen idee. Meer toegankelijke data staat er niet op. Het opslokken van de ruimte is vannacht gebeurd omdat er gisteren meer vrij was. Exacte GB's weet ik niet. Ik weet dat hij voor 3/4e vol stond, het langzaam opslokken zal dus wel eerder gestart zijn.

Ik heb geen idee waar ik nou moet kijken waar die ruimte zit. Nog even en die schijf zit vol.

Iemand enig idee?

[redfoxert]

SystemVolumeInformation is een systeem map waar je als user of admin niet in kan en ook niet in hoeft te zijn. In principe zou daar alleen info over de partities van die disk en andere disks in worden opgeslagen. Geen mega grote dingen dus.

Heb je al eens met een tool gekeken welke folders er allemaal zijn en hoeveel data er in zit? TreeSize of Spacemonger (http://www.sixty-five.cc/sm/v1x.php) bijvoorbeeld

[ Voor 10% gewijzigd door redfoxert op 12-08-2010 09:46 ]

[FireDrunk]

TreeSize Free of TreeSize Pro
Pro is makkelijk als je alle files van 1 soort gelijk wil verwijderen. Je kan alle .tmp files in 1 keer verwijderen.

Verder wil SVI nog wel eens wat nutteloze data bevatten.
Heb je Schaduwkopielimiet niet op 500MB per folder ofzo ingesteld?

[mbr99]

Ik ben met de Free versie van Treesize evenals WinDirStat aan de gang geweest. Die geven puur de aantallen weer die ik met het blote oog ook zie.

Ik had overigens ook de VSC uitgezet (tijdelijk) om te kijken wat de winst is maar dat is bijna niets. De limiet staat momenteel op 500MB.

[FireDrunk]

Als je VSC uitzet, word nog niet gelijk alle diskruimte vrijgegeven hoor... Dat duurt wel even...
Of je moet een cleaning tool gebruiken, maar dat raad ik af op servers.. (er kan vanalles kapot gaan).

Wat zegt TreeSize precies (post anders een screenshot)

[TheRookie]

Al gezocht naar files die gisteren of vandaag gemodified zijn, misschien kan dat je in de juiste richting sturen ?

[mbr99]

Er hebben alleen wat wijzigingen in Exchange plaatsgevonden (boxen erbij) met een totale ruimte van 1,5 GB (import). Meer niet. Dan nog waar zit die ruimte dan? Kan alleen in het image zitten en die ruimte zie ik (20GB).

TheRookie schreef op donderdag 12 augustus 2010 @ 10:08:
Al gezocht naar files die gisteren of vandaag gemodified zijn, misschien kan dat je in de juiste richting sturen ?

[mbr99]

OK. Met Windows 2003 was ik dat wel gewend na opschoning. Wat mij trouwens bij Treesize opvalt is dat hij aangeeft dat de disk slechts 59GB groot is.

Ik kan geen afbeelding op internet plaatsen. Hij geeft aan:

39,188 MB Data
20.428 MB WindowsImageBackup
320 MB System Volume Information
0,9 MB [Files]
0,0 MB $Recycle.BIN

FireDrunk schreef op donderdag 12 augustus 2010 @ 09:58:
Als je VSC uitzet, word nog niet gelijk alle diskruimte vrijgegeven hoor... Dat duurt wel even...
Of je moet een cleaning tool gebruiken, maar dat raad ik af op servers.. (er kan vanalles kapot gaan).

Wat zegt TreeSize precies (post anders een screenshot)

[FireDrunk]

Is het een Dynamische schijf?

[mbr99]

Nee.

FireDrunk schreef op donderdag 12 augustus 2010 @ 10:30:
Is het een Dynamische schijf?

[mbr99]

Kan Indexing een oorzaak zijn?

[TheRookie]

Die moet je a) zelf geïnstalleerd hebben en b) zou je terug moeten zien op de locatie waar je de catalog hebt opgeslagen, ipv dat de gebruikte ruimte niet gerapporteerd wordt

[mbr99]

Ik zag een vinkoptie staan bij de eigenschappen van de disk dat Indexing gebruikt mag worden. Echter bij de functies van de server staat Index uitgevinkt.

TheRookie schreef op donderdag 12 augustus 2010 @ 11:11:
Die moet je a) zelf geïnstalleerd hebben en b) zou je terug moeten zien op de locatie waar je de catalog hebt opgeslagen, ipv dat de gebruikte ruimte niet gerapporteerd wordt

[mbr99]

Ik tref veel berichten aan in forums dat Windows 2008 een foutief beeld na enkele dagen kan geven wat betreft de aangegeven vrije ruimte. Na een herstart van de server zou het correcte getal moeten worden weergegeven. Een oplossing ervoor vind ik niet. Ik ga eerst de server eens herstarten. Ik zie deze ochtend ook de vrije GB's op en neer gaan. Bevreemd me.

[Verwijderd]

mbr99, als je de laatste bent die in het topic reageert, zou je dan je post willen editten ipv een nieuwe te maken?

[mbr99]

OK.

Verwijderd schreef op donderdag 12 augustus 2010 @ 14:52:
mbr99, als je de laatste bent die in het topic reageert, zou je dan je post willen editten ipv een nieuwe te maken?

[mbr99]

Intussen na enkele reboots (die niet helpen) op de server lijkt het probleem alsmaar erger te worden. Volgens de eigenschappen van de mappen zou er 60 GB in gebruik zijn. Het overzicht van Windows zelf geef maar liefs 136Gb in gebruik aan. VSC staat slechts op 338MB. De vrije opgegeven ruimte is nu onder de 10GB gedoken. We hebben een nieuwe disk in bestelling staan maar snappen doe ik het probleem echt niet.

Ik heb de tool WinDirStat gebruikt en daar de optie aangezet om ombekend ruimte aan te geven. Deze onbekende ruimte geeft ruim 65GB aan. Hier zit dus mijn probleem.

Iemand enig idee?

[ Voor 16% gewijzigd door mbr99 op 19-08-2010 09:13 ]

[CertLog]

Kun je eens de output van "chkdsk" posten?

[mbr99]

Ik heb intussen het image van WSB verplaatst waardoor ik 23 Gb 'adem' heb gekregen. Chkdsk heeft eenzelfde uitkomst als de verkenner. Die 107036484 kB is dan inclusief de vermiste 65GB.

D:\>chkdsk
Het type bestandssysteem is NTFS.
Volumenaam is Data.

Bestanden controleren (stap 1 van 3)...
141568 bestandsrecords verwerkt.
De bestandscontrole is voltooid.
1 records met grote bestanden verwerkt.
0 records met beschadigde bestanden verwerkt.
0 EA-records verwerkt.
0 reparserecords verwerkt.
Indices controleren (stap 2 van 3)...
166684 indexvermeldingen verwerkt.
De indexcontrole voltooid.
0 niet-geïndexeerde bestanden gecontroleerd.
0 niet-geïndexeerde bestanden hersteld.
CHKDSK controleert de security descriptors (stap 3 van 3)...
141568 bestands-SD's/-SID's verwerkt.
De controle van security descriptors is voltooid.
12558 gegevensbestanden verwerkt.
Het bestandssysteem is gecontroleerd. Er zijn geen problemen vastgesteld.

143336447 kB totale schijfruimte.
107036484 kB in 121527 bestanden.
36956 kB in 12560 indexen.
0 kB in beschadigde sectoren.
211955 kB in gebruik door het systeem.
Het logboekbestand neemt 65536 kB in beslag.
36051052 kB beschikbaar op schijf.

4096 bytes per cluster
35834111 clusters in totaal op schijf
9012763 clusters beschikbaar op schijf

D:\>

Misschien heb je hier ook iets aan hoewel het nu uit staat (VSC):

Opslagkoppeling voor schaduwkopieën
Voor volume: (D:)
Opslagvolume voor schaduwkopieën: (D:)
Gebruikte opslagruimte voor schaduwkopieën: 126.938 MB (0%)
Toegewezen opslagruimte voor schaduwkopieën: 444.594 MB (0%)
Maximale opslagruimte voor schaduwkopieën:500 MB (0%)

CertLog schreef op donderdag 19 augustus 2010 @ 11:17:
Kun je eens de output van "chkdsk" posten?

[DiedX]

Ik heb dit eerder meegemaakt met een gehackte server. Hierbij werd met een RootKit een e: volgeplempt met allerlei meuk.

Ik maakte gebruik van BlackLight om hier achter te komen. Wellicht geen gek idee?

[mbr99]

Dank voor je gedachte. De server is vanaf dag 1 voorzien van virusbeveiliging en spywarebeveiliging van McAfee. Deze meld niets. Nou vermeld die pagina dat trad. AV's mogelijk geen rootkits vinden, en Blacklight is slechts een technologie. Waarin zit dit verwerkt? In healthcheck?

DiedX schreef op donderdag 19 augustus 2010 @ 11:27:
Ik heb dit eerder meegemaakt met een gehackte server. Hierbij werd met een RootKit een e: volgeplempt met allerlei meuk.

Ik maakte gebruik van BlackLight om hier achter te komen. Wellicht geen gek idee?

[DiedX]

mbr99 schreef op donderdag 19 augustus 2010 @ 11:56:
Dank voor je gedachte. De server is vanaf dag 1 voorzien van virusbeveiliging en spywarebeveiliging van McAfee. Deze meld niets. Nou vermeld die pagina dat trad. AV's mogelijk geen rootkits vinden, en Blacklight is slechts een technologie. Waarin zit dit verwerkt? In healthcheck?


[...]

Als je mijn link volgt kom je bij dat product uit!

[alt-92]

Je kan ook Treesize via een scheduled task een scan laten doen onder het SYSTEM account, dan kun je gelijk zien hoe groot die SVI superhidden folder is.

[CertLog]

chkdsk laat inderdaad niets raars zien.
Ik begin inderdaad ook te vermoeden dat je server wel eens een rootkit
zou kunnen hebben.
Vaak worden dan allerlei bestanden verborgen door gebruik te maken van alternate
data streams.
Je zou eens deze tool kunnen gebruiken om te kijken of dit zo is:
http://www.heysoft.de/de/software/lads.php
(weet alleen niet zeker of deze werkt op 2008R2)

[mbr99]

Even een update.

Blacklight schijnt niet meer bijgewerkt te worden dus ben ik aan de slag gegaan met de Sophos rootkit scanner. Die heeft niets gevonden. Ook nog Malwarebytes er tegenaan gehouden.

Ook LADS gebruikt op puur de SVI map maar daar wordt ook niets bijzonders in gemeld.

Inmiddels er een disk bijgeplaatst. Hierop wordt nu even alleen de Windows System Backup in opgeslagen. Op deze disk doet zich het probleem niet voor. Ook de system disk C: heeft dit issue niet.

Op de bijna volgelopen disk is volgens WinDirStat de 'onbekende' data gegroeid naar 74 GB.

[Craven]

misschien wel een beetje "ruwe" methode. Maar ehh het gaat hier dus om 60gb aan data op de probleem partitie? Waarom niet gewoon die 60gb wegschrijven (desnoods 's avonds als niemand aan het werk is). of zelfs 2 keer wegschrijven voor de zekerheid. Partitie formatteren en/of verwijderen en opnieuw aanmaken. Daarna weer terugzetten.

[Dirkxke]

Craven87 schreef op dinsdag 24 augustus 2010 @ 10:12:
misschien wel een beetje "ruwe" methode. Maar ehh het gaat hier dus om 60gb aan data op de probleem partitie? Waarom niet gewoon die 60gb wegschrijven (desnoods 's avonds als niemand aan het werk is). of zelfs 2 keer wegschrijven voor de zekerheid. Partitie formatteren en/of verwijderen en opnieuw aanmaken. Daarna weer terugzetten.

Dit gedacht had ik ook. het is eventjes wat avondwerk, maar het kan alweer een aantal zaken elimineren.

[DigiK-oz]

mbr99 schreef op dinsdag 24 augustus 2010 @ 10:07:

Ook LADS gebruikt op puur de SVI map maar daar wordt ook niets bijzonders in gemeld.

En LADS gewoon over de hele disk? Geen idee of treesize en dat soort tools ook alternate datastreams tellen, maar zo niet kan je verloren ruimte natuurlijk ook buiten de SVI map zitten.

[mbr99]

Ik heb idd de data eraf gehaald en naar de andere verplaatst, format, terug, en klaar. Helaas oorzaak onbekend maar gaat nu paar dagen goed.