Change block tracking software?

[nasdude]

Kent iemand een tool welke bijhoud, welke files veranderd zijn en hoeveel data er dan ook echt veranderd is?

We zien veel veranderingen van data op de C schijf van een Windows server, file monitoring laat zien welke file veranderd is, maar dat gegeven is niet voldoede.

Voorbeeldje: een txt file van 100mb, verander 1 letter en in de eventlog zie ik dat deze file van 100mb is aangepast. in werkelijkheid is er maar 1byte aangepast op de disk zelf.

Is er software beschikbaar welke alleen laat zien wat er echt is aangepast ipv de file grote van de hele file?

[RobinF]

Wordt er niet meer aangepast ivm blockgrootte?

[Brahiewahiewa]

nasdude schreef op maandag 19 maart 2018 @ 16:32:
Kent iemand een tool welke bijhoud, welke files veranderd zijn en hoeveel data er dan ook echt veranderd is?

We zien veel veranderingen van data op de C schijf van een Windows server, file monitoring laat zien welke file veranderd is, maar dat gegeven is niet voldoede.

Voorbeeldje: een txt file van 100mb, verander 1 letter en in de eventlog zie ik dat deze file van 100mb is aangepast. in werkelijkheid is er maar 1byte aangepast op de disk zelf.

Is er software beschikbaar welke alleen laat zien wat er echt is aangepast ipv de file grote van de hele file?

Dat hangt van je text-editor af. De meesten lezen de textfile in het geheugen en op het moment dat er gesaved wordt, wordt de hele file overgedragen aan het filesystem. Dat filesystem gaat niet de moeite nemen om de oude en de nieuwe file te vergelijken; die plempt gewoon de nieuwe file ergens op een disk en past de indexen aan. Da's veeeel sneller

Maar ik krijg de indruk dat je niet precies weet welk process de betrokken files wijzigt. Heb je d'r al met processmonitor naar gekeken?

[Gomez12]

nasdude schreef op maandag 19 maart 2018 @ 16:32:
Voorbeeldje: een txt file van 100mb, verander 1 letter en in de eventlog zie ik dat deze file van 100mb is aangepast. in werkelijkheid is er maar 1byte aangepast op de disk zelf.

Zoals al gezegd, dan heb je wel een hele ingewikkelde editor als die dit doet, de gemiddelde editor zal gewoon 100mb wegschrijven.
Maar zelfs al heb je een hele ingewikkelde txt-editor (want bij andere files bijv dbases etc gaat het wel op) dan alsnog wordt er niet 1 byte weggeschreven, maar minimaal 1 block (waarbij de block-grootte weer afhankelijk is van wat je ingesteld hebt bij formatteren) en als je heel erg zeikerig bent dan wordt er ook nog wat in de FAT aangepast (wat wederom 1 block is) om de grootte en laatste wijzigingstijd etc aan te passen.

En om nog zeikeriger te zijn heb je weer RAID-arrays met battery backed write-caches waar niets geschreven wordt totdat of de write-cache vol is of het systeem stroom verliest (of de write-cache een time-out krijgt).

Daarnaast doet je OS meestal ook nog wel aan caching, oftewel die gaat er ook nog eens doorheen.

Eigenlijk zit ik me meer af te vragen waarom je dit nodig zou hebben? Want het is verduvelde ingewikkeld om te achterhalen wat er daadwerkelijk op disk aangepast wordt vanwege alle tussenlagen.
Ik denk dat er wel andere/betere wegen zijn om je doel te bereiken, alleen moet je dan wel even het doel schetsen.

[Equator]

nasdude schreef op maandag 19 maart 2018 @ 16:32:
Kent iemand een tool welke bijhoud, welke files veranderd zijn en hoeveel data er dan ook echt veranderd is?

We zien veel veranderingen van data op de C schijf van een Windows server, file monitoring laat zien welke file veranderd is, maar dat gegeven is niet voldoede.

Voorbeeldje: een txt file van 100mb, verander 1 letter en in de eventlog zie ik dat deze file van 100mb is aangepast. in werkelijkheid is er maar 1byte aangepast op de disk zelf.

Is er software beschikbaar welke alleen laat zien wat er echt is aangepast ipv de file grote van de hele file?

Ten eerste verplaats ik dit topic naar Serversoftware en Windows Servers. Ten tweede, waarom is het gegeven dat een file veranderd is niet voldoende. Wat wil je nu bereiken met deze software?

[nasdude]

Gomez12 schreef op dinsdag 20 maart 2018 @ 10:04:
[...]

Eigenlijk zit ik me meer af te vragen waarom je dit nodig zou hebben? Want het is verduvelde ingewikkeld om te achterhalen wat er daadwerkelijk op disk aangepast wordt vanwege alle tussenlagen.
Ik denk dat er wel andere/betere wegen zijn om je doel te bereiken, alleen moet je dan wel even het doel schetsen.

Brahiewahiewa schreef op maandag 19 maart 2018 @ 22:09:
[...]


Maar ik krijg de indruk dat je niet precies weet welk process de betrokken files wijzigt. Heb je d'r al met processmonitor naar gekeken?

Dat klopt, (ik ben ook bekend met de blockgroote van het filesystem als die van vmware) ik probeerde de vraag zo simpel mogelijk te stellen. Hier onder wat meer duiding.

We maken gebruik van Riverbed Edge servers, een cached datastore op de locatie, storage in een centraal datacenter. Op deze appliance draait VMWare, VMWare maakt via ISCSI gebruik van de Riverbed storage. SChrijf je iets weg naar de datastore dan worden die veranderingen lokaal weggeschreven en naar het datacenter gerepliceerd. Op de locatie draait een enkele file/print server, niet heel spannend verder


Als je data veranderd komt dat dus in een backlog te staan. Stel dat ik 1 file van 100MB iedere 5 minuten volledig overschrijf en dat gedurende 8 uur doe (12x per uur * 8 uur * 100mb) dan staat er dus totaal 9,6gb in de queue.

Met bovenstaande techniek in een normale backup heb je hier weinig last van, die ziet in de dagelijkse backup een file van 100mb staan en zal deze opslaan, de backup voor die file zal dus 100mb zijn ipv 10gb die wij nu zien.

Het probleem is dat ik een gigantische berg van data zie welke gerepliceerd moet worden richting het datacenter. Ik zie bijvoorbeeld dat er gister avond tussen 21:00 en 23:00 8gb aan data is weggeschreven naar de queue (en dat is dan alleen de C drive van een simpele fileserver waar in dat tijdsframe niemand op gewerkt heeft).

Als we de servers op een andere manier backuppen (direct file backup) dan zijn de incrementals maar een paar gig groot, het moet dus wel een proces zijn welke continu dezelfde file overschrijft.

We hebben dus geen enkel idee wat de oorzaak is van deze hoeveelheid data. (Riverbed kan ons geen duidelijkheid verschaffen wat het nu exact repliceert)

[Equator]

Als Riverbed je het niet kan vertellen.. Dan wordt het lastig natuurlijk. Maar goed, situatie is wat duidelijker nu. Vreemd dat RB die sync niet op basis van CBT doet.

En deze 8GB synchronisatie-verkeer is van slechts 1 virtuele File- / Printserver? Als je een tweede VM draait, genereert die dan net zoveel replicatieverkeer?

[Gomez12]

Is het niet iets heel simpels als een page-file die op de c-schijf aanstaat en uit had moeten staan? En daarom continue gerepliceerd wordt? Oftewel gewoon een windows onderdeel?

En kan je die queue niet pauzeren (/ via een Modemlijntje laten lopen) zodat die goed gevuld wordt.
Dan gooi je daarna op de target machine processmonitor etc aan en laat je de hele queue leeglopen. Dan heb je alle bestanden die geraakt zijn.

[ Voor 41% gewijzigd door Gomez12 op 20-03-2018 11:52 ]

[nasdude]

Gomez12 schreef op dinsdag 20 maart 2018 @ 11:49:
Is het niet iets heel simpels als een page-file die op de c-schijf aanstaat en uit had moeten staan? En daarom continue gerepliceerd wordt? Oftewel gewoon een windows onderdeel?

En kan je die queue niet pauzeren (/ via een Modemlijntje laten lopen) zodat die goed gevuld wordt.
Dan gooi je daarna op de target machine processmonitor etc aan en laat je de hele queue leeglopen. Dan heb je alle bestanden die geraakt zijn.

pagefile en eventlog staan op een ander LUN en worden niet mee gerepliceerd

Ik kan de queue pauzeren maar dat heeft niet zo veel zin. C:\ -> NTFS -> VMDK -> VMFS -> LUN
De lun wordt gerepliceerd, daar zie je alleen de changed blocks van het vmware filesytem op.

In het datacenter wordt vervolgens de LUN daar volgeschreven, die zien dus ook alleen de diverse bitjes. (zie het als een soort van raid1 array over een wan verbinding, waarbij disk1(locatie) en disk2(datacenter) verschillend zijn, de verschillen worden op de locatie gequeued totdat disk2 ze verwerkt heeft)

[ Voor 16% gewijzigd door nasdude op 20-03-2018 13:14 ]

[MAX3400]

nasdude schreef op dinsdag 20 maart 2018 @ 13:11:
[...]
...C:\ -> NTFS -> VMDK -> VMFS -> LUN

Maar nu draaien we toch in een cirkel?

De LUN kan alleen bijhouden wat in blocks wijzigt op VMFS. VMFS is een "container" voor VMDK. VMDK is een continuous boundary (lees de PowerCli commands er maar eens op na) en heeft dus geen eigen change-tracking. De VMDK biedt je aan als "raw disk" aan een virtueel OS, dan zet je er een filesystem op en nu vraag je "waar" de file/block-tracking moet achterhalen?

Binnen Windows dus want dat is de enige layer wat zichtbaar is voor Windows. Het lastige is dat je dit amper/niet realtime kan doen. Het enige handige/simpele alternatief: gooi je data direct naar iSCSI-LUNs en daar kan je dan wel je changes beter/netter inzichtelijker krijgen.

[Gomez12]

Wat je wel nog kan doen, aangezien je zegt dat het een FS is, is dat je kijkt naar het inkomende netwerkverkeer.

Dat moet minimaal 8Gb zijn (en te tracken) of je Fileserver genereert zelf verkeer.

2e optie is nog dat je je print-spool-files op die lun laat wegschrijven aangezien je zegt dat het ook een printserver is. print-spool-files willen nog wel eens gigantisch opgeblazen zijn.

[The Eagle]

Heb je toevallig een physical waar je mee kunt testen? Kun je de VMware lage uitsluiten (of pinpointen).
Verder verdachten onder windows: SearchIndexer? Stukje logging van monitoring agent(s)?