has anyone ever tried to recover an NTSF disk and only gotten back $MFT and its subfiles after 80 hours of processing? Using another product (GetDataBack) we got the whole thing back (all 600K files) but without names (so only numbers).We were hoping that iRecover would get us the filenames as well, but alas.
Also, does iRecover offer the possibility to only recover files with a particular time stamp? I.e. we have the most recent backup restored fully, and would only like to get the next days mutated disks off the crashed system.

Product you are using: iRecover

Operating system / Service Pack: W2K SP3

Size of subject harddisk: 128GB

Hello,

What happened to the disk? In other words, how was the data lost (re-format, virus, 'bad' disk etc.).

I am sorry, but you can't filter based on dates.

--
Kind regards,
Joep

Joep, I'd love to do this in Dutch, but OK, here goes! :-)
Logical Disk was part of a file server cluster running with Veritas to make the disks dynamic. The physical disks themselves are actually spread out over any of 108 disks in an IBM Shark, so no physical issues here. After we dynamically added capacity to the disk and did failover tests everything worked. As a final test, we rebooted one of the system nodes and suddenly it lost ALL of it's logical disks. We were able to get all of them back after removing and replacing them, but this volume will not come back.
This happened thursday evening (PRE BACKUP) and is actually a very normal change (has always gone correct before). But, this forced us to restore wednesdays tapes so thursdays work is missing. We got it all back (we think) with getdataback, but without structure or file names. We have allocated the resulting thursday files (about 300 of them) on user request but we would really like to have the official filenames and structure back! iRecover initially stuck at 33% in the anlysing phase on this disk, but it turned out we should have used thew advanced interface. When it completed, it would only recover $MFT etc. so the structure files only. This took 80 hours! It did find the 968500 NTFS pointers etc., so I dont understand what is going on!

BTW do you know there is a russian out there selling a copy of your product as ZAR? If we install that, it works with your license so I hope you have a deal with them!

Product you are using: iRecover

Operating system / Service Pack: W2K SP3

Size of subject harddisk: 128GB

Hallo,

Ja, de Rus kennen we! Da's in orde!

Die Dynamic disks, wat voor volumes waren daarop aangemaakt? Als het zo is dat volumes uit meerdere 'segmenten' en zelfs over verschillende disks verspreid staan (striping, mirroring etc.), dan kan iRecover er niets mee. iRecover benaderd de fysieke disk en zal zelf partitie tabellen etc. parsen.

GetDataBack kan dan nog op volume niveau werken (C:, D: etc.). Op dit niveau is het benaderen van volumes zelfs als ze over verschillende schijven verdeeld zijn wel mogelijk, m.a.w. waar een logisch volume zich fysiek bevindt is irrelevant.

Met de files zonder bestands namen die GetDataBack recovered neem ik aan dat generieke bestands namen worden toegekend (file0010.DOC ofzo). En dit betekent dat ook GetDataBack file systeem structuren niet herkent maar dat file headers voor de bestanden gevonden zijn.

Het feit dat GetDataBack de bestands namen niet kan achterhalen is een slecht teken. In feite is, hoewel NTFS complexer is dan FAT, het achterhalen van bestands namen en het koppelen van clusters aan bestandsnamen makkelijker dan bij FAT. Het feit dat GetDataBack hierin niet slaagt betekent waarschijnlijk dat deze informatie eenvoudig weg niet voorhanden is.

Dan nog m.b.t. de etijd die iRecover nodig heeft om de disk te scannen: 80 uur betekent dat of die disk gigantisch is, de disk 'bad' is (maar dat is volgens u niet zo begrijp ik) of, en dat hebben we een paar keer aan de hand gehad, het OS ondersteund de disk size niet.

Bijvoorbeeld, Win2000 kan native niet goed omgaan met disks of arrays > 128 Gb.

--
Joep

Hi Joep,

W2K is op orde qua large volume support, dus dat is m niet. De Shark is een striped array van 108 disks van 36.4Gb, dus er is geen specifieke physical disk. Alles is in feite verspreid over alle strings in de arrays; we zien zelfs geen physical disk maar alleen LUNs. Dat moet dus ook de verklaring zijn waarom ie zolang onderweg is! GDB komt inderdaad met eigen unieke nummers per subdir en file.
Jammer, wij hadden de stille hoop nog wat meer eenduidigheid te kunnen krijgen of we inderdaad alle belangrijke data te pakken hadden.
Ontrack beweert (uiteraard) dit wel te kunnen, maar voor tussen EUR 30 en 45.000,-. En je begrijpt wat wij daarvan vinden!

Maar als ik het goed begrijp kan ik net zo goed de nu lopende iRecover scan afbraken, vanwege de phys dsk limitatie?

Bedankt voor je hulp!

Product you are using: iRecover

Operating system / Service Pack: W2K SP3

Size of subject harddisk: 128GB

Hallo,

Nou, zolang iRecover een fysieke disk ziet (en dit moet wel als je al aan het scannen bent), en of dit nu echt een fysieke disk is of niet of dat iRecover 'gefopt wordt', dan zou het moeten gaan.

D.w.z. we kunnen dan de disk scannen. Bijvoorbeeld, een intacte hardware raid 5 wordt naar buiten toe, en ook aan iRecover als een fysieke disk.

Maar dit is 108 x 36 Gb??? Indien zo, op dergelijke grote schijven hebben we iRecover nooit kunnen testen ...

Echter, als op die fysieke disk dynamic volumes aangemaakt zijn die verder gaan dan 'simple volumes' dan kan iRecover niet vast stellen welke gebieden op de fysieke disk tezamen een volume vormen.

En om data te kunnen recoveren moet je weten welke fysike gebieden een volume zijn omdat offsets in bijvoorbeeld de $MFT file records relatief zijn t.o.v. het volume. Tenzij je, zoals GDB ook scant op file headers.

--
Met vriendelijke groet,
Joep

Joep, ik maak het nog wat ingewikkelder.
iRecover ziet de "virtuele" disk prima, hij telt dezelfde aantal NTFS records als GDB namelijk 968581 of zo. De disk is virtueel omdat hij logisch is geplaatst op een aantal defined volumes die gestriped zijn over de 108 (16 arrays van 8 disken)
die onze Shark rijk is. Windows ziet deze volume, die is opgebowud uit een stukje hier en een stukje daar, als 128GB. En volgens mij ziet iRecover dat ook. Maar, zoals gezegd, zijn we bij elkaar 80 uur aan het scannen geweest en kregen we alleen &MFT van 945mb en z'n associated files in het recover scherm.
Beats me! :-)

Product you are using: iRecover

Operating system / Service Pack: W2K SP3

Size of subject harddisk: 128GB

Hallo,

Het feit dat iRecover maar 128 Gb ziet (dat zou toch veel meer moeten zijn?) suggereert toch dat de 48 bit LBA support in Windows niet in orde is. Wat is in het scherm waar je de *fysieke* disk selecteerd in iRecover de grootte van de disk? En, komt dit overeen met de werkelijke grootte?

Voor W2K zou je EN het laatste SP (maar 4 minimaal) moeten hebben geistalleerd EN je zou aan de registry een key moeten toevoegen om 48 bit LBA support the activeren.

--
Joep

Joep, ik zou je het liever telefonisch uitleggen dan zo want het complex maar niet ingewikkeld. Op de Shark alloceren wij stukjes physical disk aan windows volumes en de Shark presenteert aan Windows als 1 disk. We hebben ze al van 195Gb en groter gehad. Op de Shark limiteren we welke Shark logical volumes door een specifieke machine gezien kunnen worden; vandaar dat iRecover precies de goede disk ziet. De disk is echter dynamisch dus er is geen end-track.
We zitten in Amsterdam, dus als je eens wilt spelen met zoiets (want zoveel grote systemen ken je waarschijnlijk niet) ben je van harte welkom! Binnenkort komt er een derde Shark en dan hebben we in totaal 21Tb capaciteit. Mail me anders je telefoonnummer op teun_van_essem@hotmail.com

Product you are using: iRecover

Operating system / Service Pack: W2K SP3

Size of subject harddisk: 128GB

Hallo,

Nou, dat zou erg leuk zijn. We zijn met z'n twee-en, ook geen probleem? Inderdaad is er een hoop, zelfs vrij courante, hardware die we niet kunnen aanschaffen of testen. Zoiets als dat systeem dat je beschrijft blijft zo iets vrij abstracts. Tot je het een keer ziet natuurlijk! Nu zal ik wel direct toegeven dat we ons natuurlijk ook wat meer thuis voelen in het 'normale' PC wereldje waar een schijf over het algemeen echt een schijf (hooguit een arraytje) is met een capaciteit waar je je nog iets bij kunt voorstellen. En waar je met een DOS diskettje nog kunt bijkomen (ik zie op de IBM site DOS niet bij de ondersteunde operating systems staat voor de storage servers).

Maar, dus dat systeem presenteert transparant zo gezegd, een fysieke eenheid naar het OS dat je kunt partitioneren, of inrichten als ik het goed begrijp. M.a.w. het OS weet niet beter of het heeft met een normale fysieke schijf te maken?

Enne ... hoe dynamisch is dynamisch? Wordt er zeg maar gaandeweg schijfruimte aan zo'n ik noem het maar even virtuele disk toegewezen? En indien ja, wordt er ook gaandeweg weer ruimte terug geclaimd? Want dat zou natuurlijk wel gevolgen hebben voor de recoverablity.

Ik mail mijn nummer!

--
groetjes,
Joep

nog geen nummer ontvangen! :-)

Product you are using: iRecover

Operating system / Service Pack: W2K SP3

Size of subject harddisk: 128GB