Welcome, Guest. Please login or register.
Did you miss your activation email?
September 24, 2017, 09:39:57 AM
Home Help Search Login Register
News:

+  DIY DataRecovery.nl Support forum
|-+  Support
| |-+  iRecover (Moderators: Tom, Joep)
| | |-+  Slow autosave or analysis
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: Slow autosave or analysis  (Read 3482 times)
vanhorn
member

Posts: 8


« on: February 06, 2017, 10:51:32 AM »

RAID 5 in Dell server with PERC 4/SC RAID controller went south. Replaced the failing disk and everything disappeared.

Pulled the PERC 4 and connected the four-drive cage to an Adaptec non-RAID controller. Followed directions for RAID Recovery. Drives are SCSI 15K rpm 73 GB Maxtor Atlas.

Disk scan took about ten hours and completed smoothly. (On an earlier attempt it got to 51% and simply stopped trying, I restarted the Windows 2003 Server before this disk scan and it finished.) It went on to Volume Analysis and happily proceeded for 13m 27 s, correctly identified the filesystem as NTFS, and started to run an autosave. I went off and bought my serial number for the program, and that's where we're stuck. It's been an hour and a half now. I got my serial number in a minute and a half and I want to go use it!

For some reason this forum software won't allow anything but .zip files, so you can't actually see the screen capture too easily, but I have one in here.
Logged
Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1472


WWW
« Reply #1 on: February 06, 2017, 10:59:42 AM »

There are a few things you can try:
- Run the scan with autosave disabled (check in 'advanced config' and look at the 'general' tab)
- Use a newer version that's still being evaluated, link here:
http://www.diydatarecovery.nl/downloads/Demo/iRecover.zip
- See if you can copy the iRecover log (use copy, not move or edit when iRecover is still running) and send it to us zipped. Find the file in the iRecover program folder.
Logged

vanhorn
member

Posts: 8


« Reply #2 on: February 06, 2017, 11:42:06 AM »

Note that the program doesn't accept focus anymore, it can't be moved, and nothing responds. The Autosave log is empty and the log file crapped out about when everything froze.

When I forced it to quit, it updated the logfile timestamp, didn't help the autosave log.

Logfile is attached.

The original installer I downloaded was 1.0.0.612. The new one says it is 1.0.0.0 after extracting from the zip. It doesn't seem to be an installer, it runs as "Form1" instead of "iRecover". I get all kinds of unhandled exceptions so I think I should remove the original first.

That didn't work either. every click is either ignored or results in an unhandled exception. Where I come from, that means it isn't really worth investing any time into.

BTW, this is a Windows Server 2003, same hardware as before but a fresh OS install a few days ago.

I really need to get to sleep, but I'll check here as soon as I'm back up.

Van

Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1457


WWW
« Reply #3 on: February 06, 2017, 12:28:49 PM »

Hello,

Quote
Replaced the failing disk and everything disappeared.

Immediately?

Quote
The original installer I downloaded was 1.0.0.612. The new one says it is 1.0.0.0 after extracting from the zip. It doesn't seem to be an installer, it runs as "Form1" instead of "iRecover". I get all kinds of unhandled exceptions so I think I should remove the original first. That didn't work either. every click is either ignored or results in an unhandled exception. Where I come from, that means it isn't really worth investing any time into.

I have no idea what you're doing there. Never heard of it or seen it before. Is that the zipped version that Tom suggested? If so, what version of the .NET framework is installed?

Quote
BTW, this is a Windows Server 2003, same hardware as before but a fresh OS install a few days ago.

Yeah with only 2 GB memory, correct?

Okay, that's not a lot of RAM then. For a recovery that is. With little RAM it's not a good idea to set the read cache to 365MB because that's 365MB less we can use for working with. 2GB should be enough for a couple of 100.000 files, but that's without RAID analysis. Also, BAD sectors snoop away memory. We do see bad sectors on one of the disks.

Ok, so originally 4 disks? And what disks are we working with now? Were all 4 original disks selected for RAID analysis? Or 4 minus the failed one? How many were selected for RAID 5 recovery? If originally 4 disks, then at least 3 need to be available for analysis. The 4th can be derived from parity.

If that's the case, if that's what you did, then I'd do:

- Either add RAM or disable autosave
- Load latest autosave file which should be the RAID analysis > go through file system analysis again. Autosaves are in the folder AUTOSAVE in the directory where iRecover.exe is.
Logged

--
Kind regards,
Joep
vanhorn
member

Posts: 8


« Reply #4 on: February 06, 2017, 10:21:33 PM »

Immediately? Well, I replaced the bad disk (which was the first in the array) with another, made it part of the array, and left it to start rebuilding. A half hour later somebody asked if I was going to fix the server, because I clearly hadn't. So I don't know if it worked even for a second, but it didn't explode or anything like that.

If I right click on a file in Windows, one of my choices is Properties. The second tab is Version, and the first item in that window is what I quoted. The new file I was told to download does not appear to have a useful version number, as I said, iRecover.exe in that reports 1.0.0.0. reports

Yes, this is the zipped version that Tom suggested.

The only .NET item that Control Panel | Add or Remove Programs shows is Microsoft .NET Framework 2.0.

Yes, 2GB of RAM, haven't looked around to see if I have any other chips for this old machine. I would be happy if you told me that there was a way to scan smaller parts of the disk, only the first 20 GB partition is of any interest at all. I jacked up the read cache because the thing was going to take 20 hours and anything that looked like it would speed things up had to be a good thing.

Original array was three disks and a hot spare, I was working with disk 2 and 3, disk 0 had totally failed (no spin) and disk 1 was always the hot spare.

I would happily skip autosave, particularly if that would mean I could scan for shorter periods and see what I got.

Note that right now I can't do anything at all, the new version won't run and the old one has bee removed and doesn't want to go back in either.


Van



Logged
vanhorn
member

Posts: 8


« Reply #5 on: February 07, 2017, 04:11:49 AM »

I removed the original iRecover installation, removed and replaced .NET Framework 2.0 from the Add/Remove Windows Features control panel, and installed .NET Frameworks 2 Service Pack 2.

I found an SCA adapter and determined that disk 0 in the original array was not "no spin" as earlier thought, so I put it back in the rack. It had been the first disk in the array.

I have turned off Autosave, also switched to individual log per session. All other settings are the defaults, I think, at least I don't remember setting the Read cache to 92 MB and that's where it is right now. On the other hand, it seems to change itself from time to time, despite my efforts to reset it to 32MB.

I was rather concerned an hour or so ago when all the activity levels went to 0. CPU was at 0%, and disk activity was 0MB/sec, 0 seeks/sec. That lasted for at least a half hour.

RAID analysis in progress at 9%, hope springs eternal. Maybe I'll go looking for some more DDR2 RAM of a suitable speed to jack that up for the next run.
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1457


WWW
« Reply #6 on: February 07, 2017, 08:07:51 AM »

Aha, I see, a 3 disk array.

Well, the screenshot showed the read cache slider at a non default value. I am just trying to explain why that isn't a good idea. The autosave fail might very well be a memory issue.

Okay, let's sit this out then, but for my liking we're changing too many variables right now: different version of iRecover + the failed disk is back again?

As 6.1 version you used was almost there, I would have preferred to continue with that in the way I suggested:
- turn off autosave
- load already completed RAID analysis
- do file system analysis which took less that 15 minutes


Logged

--
Kind regards,
Joep
vanhorn
member

Posts: 8


« Reply #7 on: February 07, 2017, 08:24:47 AM »

We'll see how this one goes, it is at 49% now and I expect it will finish before I have to leave for my day of medical adventures in Seattle later today.

When I tried the more recent version, it was just as a raw executable rather than as an installer. If I try it again, should I just run it with the rest of the iRecover components already installed? Or should I remove the released version?

Now that I know that iRecover relies on .NET, I suspect that the original version of .NET 2.0 (part of that fresh WS2003 install, with no updates at all applied) might have been a factor. Whatever it was, the fact that it was spitting out error messages at every turn made me really wonder about letting it loose near these drives.

There are some files on this array that are truly critical to an important client, and they are eager to get them back. But if keeping the read cache setting at the low end means we need an extra hour or two but the recovery is more likely, that's a net gain. I ended up with it set at 48 MB because I couldn't get it back to 32 with the slider. I did end up swapping by the time the last scan completed. iRecover is using 894 MB of memory now, and the system is using 1.21 GB of its 2 gigs, so we may make it without dipping into virtual this time.
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1457


WWW
« Reply #8 on: February 07, 2017, 09:08:52 AM »

Hi,

Medical adventures ... doesn't sound good, hope it's nothing too serious. Good luck with that!

Yes, that new version is just the exe, no setup. It should be okay to run it with the 6.1 version installed. I think I have 5 versions installed.

Read cache should only make a difference on slow devices, like USB 2, and only if we're doing sequential reads.

Yes, let it run. keeping fingers crossed.
Logged

--
Kind regards,
Joep
vanhorn
member

Posts: 8


« Reply #9 on: February 07, 2017, 12:19:03 PM »

Well, several hours later I popped back over to the window on that machine and the iRecover session had simply gone away. The logfile had run to 16,884 KB, and ended as shown below.

I restarted the scan using the new version I downloaded, which now starts without complaint. I turned autosave off before starting the scan. I would have selected individual log files by session, but I couldn't find that option.

It will be most of a day before I can get back to this.

Van

Edit: log messed up the forum, put here: http://www.diydatarecovery.nl/downloads/log.txt
Logged
vanhorn
member

Posts: 8


« Reply #10 on: February 07, 2017, 04:33:18 PM »

A little worried here, the analysis shows four rows of disks instead of three, and it actually says "Scanning RAID5 with 4 disks, 44.9%" over the status bar. This isn't a four-disk array, it's a three disk array with a hot spare, and I am pretty sure I didn't include the hot spare when I identified the array.

The array members on the system are these, current disk and original assignment in the array on the PERC 4:
2     A-00-00
3     Hot spare
4     A-00-02
5     A-00-01

If this fails, how should I assign this for the next run.

Also, logfile.txt is only 470 KB and ends indicating that it stopped validation and shut down after encountering 16 bad sectors on disk 0102. But the software is still running despite that.

Van

Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1457


WWW
« Reply #11 on: February 07, 2017, 04:41:56 PM »

Hi,

Well, it indicates that the parity check failed. RAID 5 parity is based on simple XOR-ing. So you take 2 disks, and you know what should be on the 3rd disk. If that fails often enough, iRecover will assume we're missing a disk and add a 4th. Can very easily happen on a partially rebuilt RAID.

So, that's what I meant with changing too many variables. Better stick with the two disks used in the first attempt. The hanging save file load was the problem we ran into. Not the fact we scanned with 2 disks.
Logged

--
Kind regards,
Joep
vanhorn
member

Posts: 8


« Reply #12 on: February 08, 2017, 01:41:51 PM »

Despite the fact that I've seen only tiny issues with bad sectors, I was still a bit nervous about using the original array elements directly. Besides, I suspect that using images may be faster than working with the disks. So I'm creating images of the three disks, one each on three different SATA drives.

Two out of three are done, I'm going to eject the first three disks (two array members and the hot spare) before creating the third image and going to bed.

I also have read that ReclaiMe RAID Recovery is good at discovering the actual RAID parameters, so my next step will be to run that against the images and possibly get a better insight into the correct parameter when I return to iRecover to work from the images.

Van
Logged
Joep
Developer and Support Tech
Administrator
member
*****
Posts: 1457


WWW
« Reply #13 on: February 08, 2017, 10:28:33 PM »

Hi Van,

Yes, by all means try Reclaime Free RAID recovery. You can even feed the info it finds to iRecover.
Imaging the disks is always a good idea.
Logged

--
Kind regards,
Joep
Pages: [1] Go Up Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!