How to recover accidentaly deleted partition/files?

[grancharov]

I think that most if not all of the folders with the red X were deleted by me recently. Would you explain me exactly how to recover what I see in the left pane? You mean that I can do virtual reconstruction on the other drive - without to copy there your first sector - and to look for the differences? I'm not sure where in DMDE to look for the statistics about the folders and files on the partition.

Edited December 2, 2013 by grancharov

[jaclaz]

I think that most if not all of the folders with the red X were deleted by me recently. Would you explain me exactly how to recover what I see in the left pane? You mean that I can do virtual reconstruction on the other drive - without to copy there your first sector - and to look for the differences? I'm not sure where in DMDE to look for the statistics about the folders and files on the partition.

On the left pane select $Root.

Right click and choose "Recover files".

In the "Recover" popup window click on "List" button.

Save the filelist.txt (on another volume).

Click "Cancel" to close the popup Window.

Repeat with the "clone" and compare the two "filelist.txt" files, if they are the same, there is no need to re-image back.

You can try to recover (one by one) a few files from one or the other disk and compare the result also.

Double click (navigate) on the left pane until you see in the right pane a file that you wish to try recovering, right click on it and select "recover files", point to another volume path and click on the OK button.

Inspect the file and see if it is "good".

jaclaz

[grancharov]

I receive the message "Free Edition recovers up to 4000 files from the current panel only". Is it time to go for the Express version?

[jaclaz]

The Free edition should allow you to create the lists alright.

If you want to actually attempt the recovery "en masse" you will need to get a license either the Home or Express version, but also remember that you will need *enough* space on an accessible volume where to save the recovered files.

jaclaz

[grancharov]

I think this is enough for today. You mean that I have to recover to other drive and not to the same one? Tomorrow I will get one 4 TB hdd. Buying of DMDE can be more tricky because they require verification.

[jaclaz]

You mean that I have to recover to other drive and not to the same one?

Yep , the idea is that until one has the whole amount of data (hopefully) recovered or decides to give up , there should always be a "working" drive, a "clone" (or image) one ready to restore the first if needed and another "target" drive where to store the recovered data.

Tomorrow I will get one 4 TB hdd.

Good , that will do nicely.

jaclaz

[grancharov]

Hello again, jaclaz!

I copied/recovered the folders from WD20EARS to the new hdd. Now I want to ask - can I recover the folders/files on the same hdd by recreating the file index or something like... In DMDE I see NTFS tools - Repair Directory INDX-Records. There is also Recover the Object and Reconstruct File System in the context menu - what I should use? The idea is that I want to spare myself another copy of 1.8 TB in the reverse direction. The files actually exist there and now I have them on two other places - on the hdd-clone WD20EARZ and on the new hdd.

Thank you for the help!

[jaclaz]

I am missing something.

You should have now TWO "sources" one (the original disk) on which CHKDSK was attempted to run - but failed) and one which is a clone of the original disk NOT being affected by the CHKDSK run.

Assuming that you recovered on the third hard disk ALL the files you were interested in, your next step would be to (virtually) go back to the same as before the issue, i.e. with the "original disk" containing a partition (this time either Primary or NOT aligned to Mb - if XP will be used on that disk) with all the files in it.

No matter how well a filesystem can be reconstructed or fixed, and particularly when it is only a "data" disk, it makes little sense to run a "repaired filesystem" (provided that DMDE can actually "fully" repair it).

I mean, if I were you I would:

1. (optionally) wipe the "original" disk with a single 00 pass (and it will take time)
2. create a new (this time either primary or cylinder aligned) partition/volume on it (you can use the MBR I posted, which has a second partition Mb aligned BUT Primary in it's partition table or recreate just one partition still Mb aligned and Primary under 7)
3. copy the files/directories from the "third" disk to this volume
4. (optionally) and only once you have triple checked no more files can be (or you want to) recover are needed on the "clone", wipe it also with a single 00 pass (and it will also take time)
5. Finally re-format (under Windows 7, without the "quick" or /Q switch) the partition on the "third" disk that hosted temporarily the recovered files

I tend personally to never suggest the wiping of a disk unless needed, but in cases such as this it represents the best choice IMHO.

The "risk" with NOT wiping the disk before recreating the partitions/volumes would be "marginal" in the sense that should in the future another "hiccup" such as the one that just happened on that disk, data recovery might be more complex because artifacts of the "previous" filesystem and of the rebuilt/repaired one may "confuse" the software.

Same goes for the disk that currently is the "clone", I presume you want to put it back into "service", and starting from a freshly 00ed disk gives more probabilities in the unlucky event that something goes wrong with it in the future that data recovery will be possible, and same goes for the new "third" disk that I presume you will also put into service.

As a side note (sorry but I have to say this), if you actually implemented a suitable backup policy before you wouldn't have had any need to perform the data recovery, and maybe this could be used as a "lesson": always have a backup (better if two) of any meaningful data.

jaclaz

[grancharov]

You are right.

Just my case is a bit complex. I have serious quantity of hdd's. I understand that large hdd and XP is not good combination, but I`m not ready yet to install 7 on my main PC. I still have some things to do under XP(like to backup some browser links and sessions from Cometbird and Opera) and yes - I would want to put back "in service" the "original hdd", but I would consider different way... At least now I won't reserve empty space at the start of the disk.

Actually I started something like backup after I bought my third hdd, but I wanted also to "sort" the things and this takes much more time. So I have files here and there and there and I fight with the disorder.

Edited December 5, 2013 by grancharov

[jaclaz]

Well the "known" issue that seemingly bit you was due to THREE concurring things:

1. a volume Mb aligned
2. a volume inside Extended
3. use of XP Disk Manager

As long as you take any of the three out of the equation, everything should be fine and dandy.

As said personally I would go for "cylinder aligned" (no matter if primary partition or volume inside extended) because that is the convention used by the MS guys (and by anyone else) until Vista came out, but a volume Mb aligned BUT primary AND use of XP Disk Manager is as well fine.

Partitioning/formatting under XP and then using other tools to re-align partition to Mb has already failed for you (cannot say if it was your original choice/decision to have the second partition a volume inside extended or if the software induced you to make it in such a way).

jaclaz

Edited December 5, 2013 by jaclaz

[grancharov]

One explanation, please - Mb aligned means Master Boot Record aligned? And this means to format under XP and leave it as it is instead of using the Acronis or other align tool? There I read that:

"WD Align is only necessary for users who have:
Installed Windows XP to a WD AFD
Cloned a source bootable hard drive with any Windows OS to a target AFD
Created single or multiple partitions on an AFD using Windows XP".

So my "original" hdd now is hooked(and also the new 4 TB hdd) to the secondary PC, running "7" 64 bit(the picture is not very nice ). I think first to try those DMDE commands - just to see what I would get - after all I paid for the program. After that I have to full format the hdd under Win7 and copy back what I need.

.....

This is strange. I just rebooted the secondary PC - it was "sleep" or something like that(I still learn about Win7) and this time I let the system to run CHKDSK before Windows to load. And the folders appeared again! Maybe there is something different when running CHKDSK under OS loaded or during the boot process. Or maybe CHKDSK in Win7 works better(with large volumes) than in XP.

So it looks that I didn't need to buy the Express DMDE - rather I paid for that I'm stuck with XP for so long time. I remember that people around me were using XP for a long time already and I was still on Win98 - then I didn't had internet either...

Thank you again!

[jaclaz]

It is entirely possible that given the "huge" size of the disk CHKDSK from XP failed for you (but it worked alright for me with the very "partial" - please read as much smaller $MFT - image I rebuilt) and that Windows 7's CHKDSK is "better" for this scope.

That would be a nice explanation on why it worked "here" and did not "there".

The issue with partitioning is, as it is explained in the thread I provided a link to (and that evidently you completely failed to read ):

http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/

essentially the following.

ALL MS Operating Systems up to and including XP/2003 adopted a convention that said that each and every partition and/or volume MUST start on a head boundary and end on a cylinder boundary..

In the case of the most common 255/63 geometry that equates to EACH partition and volume starting on m/a/1 and ending on x/254/63 (as seen in a MBR or EPBR, where cylinders and heads are numbered starting from 0 and sectors are numbered starting from 1), where a can is usually 0 or 1.

As an example, the first (primary) partition on any disk partitioned on any OS up to XP/Server 2003 would begin on 0/1/1 (first cylinder, second head, first sector) and thus at LBA 63 (and the hidden sectors, including the MBR are 63), since the partition will always end on x/254/63 (i.e. on last head, last sector of a cylinder), any subsequent partition (including the Extended one, if not the first) would begin on m/0/1 i.e. on the mth+1 cylinder, first head, first sector).

Any volume inside extended will also respect this head boundary, i.e. given that an extended partition starts at m/0/1, the first volume in it will start at m/1/1, i.e. there are always 63 "hidden" sectors (including the EPBR).

If you prefer, and this is evident in Disk Manager or better in one of the "orthodox" partitioning tool that have a "slider" to choose the size of a partition, the slider movement is not "fluid", but goes in steps which are around 8 Mb, more exactly 1*255*63*512=8,225,280 bytes.

Vista broke this "tradition" or "convention" and aligns by default to a Megabyte.

A typical first Primary partition created under Vista or later will begin at 0/32/33 or LBA 2048 (consider how 32*63+33=2049 and how 2048*512=1,048,576, il.e. exactly 1 Mb).

Any subsequent partition will also use this alignment i.e. each partition or volume start will be a multiple of 2048 sectors (or of 1 Mb).

In your case, as I tried telling you on post #11:

http://www.msfn.org/board/topic/170392-how-to-recover-accidentaly-deleted-partitionfiles/#entry1061133

16373760 is divisible by 2048 = 7995 i.e. is "Mb aligned".

The "bug" is in the XP Disk Manager that not only does not "understand" properly this "new" convention, but - in the case of logical volumes only - tries to "fix" these data it finds "wrong" creating the havoc you just came out of, i.e. deleting the correct partition data in the MBR, creating a new EPBR on the nearest cylinder/head boundary and additionally creating a bootsector for the volume in the "wrong place".

Now, aligning a partition/volume to the Mb (as opposed to cylinder/head) is said to provide some better access/transfer time.

This is mostly nonsense, in the sense that on a high speed bus (such as SATA) and with decently fastish disks (and with largish caches) this advantage is not noticeable and actually - when measured - pertaining only to some of the typical usage of the disk (again do READ the given thread).

With the advent of larger and larger disks (and with the most common OS becoming increasingly a Vista or post-Vista OS) hard disk manufacturers have started to optimize the disk firmware for "Mb aligned partitions" (which BTW only apply to NTFS filesystem and not to any FAT16/32), so that possibly (but I am unaware of any "serious" benchmark in this respect ) having a "Mb aligned" partition/volume does provide some advantage, though in the case of a disk dedicated to data only and mounted ot a NAS (and thus accessed mainly if not exclusively through the much slower LAN/Ethernet) such theoretical improvement in speed will be in practice totally vanified by the slow speed of the network.

The bug in the XP Disk Manager, as said ONLY affects logical volumes inside Extended and/or Extended partitions and DOES NOT affect Primary partitions/volumes.

So, your choice is between forgetting what the good WD guys say and do not align the partitions and keep using an Extended partition and logical volumes in it (which would be silly, since you have no *need* whatever to use Extended partition and logical volumes as you can have as much as 4 primaries, and have them aligned to "Mb") or align the partitions/volumes to the Mb BUT be limited to have a maximum of 4 volumes (four primary partitions) on the disk.

Of the two, the second allows to be compliant to the suggestion the WD guys make (no matter if *needed* or *useful*) while being sure that the XP Disk Manager won't by mistake mess with the volumes.

jaclaz