Now I'm finally able to get out data from the corrupted HD. This is short help for those who will face the same problem in the future unless backups are in order.
To make sure that nothing happens to working HD(s) disconnect it/them and use live distros (this is probably not mandatory but to be on the safe side I disconnected other HDs). I used Mandriva 2008 which was easy to quite nice for the task. Easy to use, easy to get NFS mount for network drive and worked pretty well in general (only problem was gfx card - resolution was not possible to change).
1) Do not mount the broken HD as read-write! Each access to the file (even copy) causes write operation to the HD which further breaks the HD. If the HD is recognized by the distro in the boot it will be mounted as read-write. Remount it to read-only or simply unmount it. Drive don't have to be mounted. It just needs to be present at e.g. /dev/hda.
2) If it is possible to mount then take the partition table information from the HD are save it for later usage. If not then don't panic :-)
3) If the drive is in bad condition and does not allow booting of Linux then try connecting the HD during booting. Let the distro boot up many of the initialization parts and services and by the time it reaches HAL daemon plug the power supply to the HD. This way the HD is used quite little during the boot up.
4) dd might be sufficient for the task but in my case it turned out not to be. In case of HD which is in bad condition i.e. producing a lot of read errors (bad HW blocks etc.) the HD changes the operation (may depend on the HD manufacturer - in my case it was Seagate 250GB IDE drive) at some point of reading. This change results heads to go to park position and every command sent to the drive is acknowledged as an error. Further data cannot be read from the drive unless it has been powered down first (remounting does not help because this operation is done at very low level in the drive's software).
Very good tool for the task turned out to be ddrescue (v1.7 was used in this case):
http://www.gnu.org/software/ddrescue/ddrescue.html. It has advanced functionalities to get most of the data from the HD. It contains log-functionality which allows resuming of the operation after HD changes its operation and computer has to be rebooted. It can also split the damaged areas into smaller blocks thus get all the valid data leaving only small fraction broken. There are many other features in this tool so I suggest to read the documentation before usage.
If there are multiple partitions in the disc then try to get only the specific partition to the image unless you want to write the image to other HD or mount it using Windows tools. Multiple partitions where there are data corruptions present can be impossible to mount under Linux. I simply recovered full image including /boot, swap and / partitions and this caused a lot of problems regarding the mounting of the image.
In my case the operation to get the image of the HD tool around a week. I made a mistake in a beginning by mounting the HD as read-write which caused a lot of problems. Also, all the time when the image was further updated with more valid data the HD got into worse and worse condition. Now it is in so poor condition that it is no longer recognized if it is connected after HAL daemon. It is not always recognized either when it is connected from the beginning of the boot (which takes a long time when broken HD is connected).
5) After ddrescue the image is fine for further usage. It does not matter if the image does not contain all the data. Most like it contains enough data to get something out. Usually there are more than a single partition on the drive thus direct mounting cannot be done. In case of single partition then the image can be mounted directly via loopback device (-o loop). First it might be a good idea to run e2fsck to the image.
If there are multiple partitions the partition needs to be mounted using an offset. For this the partition table info is needed. If you managed to get at the beginning then calculate the byte offset (sector size * partition's start sector) and mount the partition.
If the partition table was not obtained or was not possible to get then try using testdisk tool (can be found at least in Open SuSe 10.3 distro). With this tool it is possible to get the partition table from the image. It can also fetch superblock positions which is vital information to get the image mounted.
For further information about the mounting see excellent info from
http://edseek.com/~jasonb/articles/linux_loopback.html.
6) If there are problems with the superblock then it may not be possible to mount the image under Linux as the mount tool does not support (or I'm blind) both offset setting and backup superblock usage (using direct position for backup superblock). e2fsck tool don't support offset setting which makes it no possible to check the image if there are multiple partitions. It is therefore advicable to rescue partition by partition from the broken HD (this I learned after full image was rescued). However, if the HD is in bad shape it might be necessary to simply get everything out and check the image out later.
To mount HD image which has broken superblocks I had to turn to Windows tools. For this I used Mount Image Pro. Trial version is fully functional for 30 days which probably is sufficient. This allows to mount dd-images which is also the format what ddrescue uses. Naturally mounting the image is not sufficient as windows have no idea what to do with the ext2/ext3 partition. It actually suggest to format the partition when you try to open the mounted disk drive.
For recovering files from the mounted image I used Stellar Phoenix Linux tool. This is commercial tool but does not cost that much - especially if there is important data on the broken HD. This is able to seek the mounted image and show not only the directory tree but correct filenames, dates etc. It can take a long time to get the file structure out from the image (in my case 187GB of data, 498 000+ files and 68 000+ directories) so I recommend to save the scan information so that it can be used later to speed up the opening of the image. The reason for reopening the image is the instability of the tool-set. I'm not sure where the problem is or what causes it but I had several blue screens during the recovery of files - even at the scanning of the directory tree (I had to close tree structure nodes on the fly to avoid blue screen which indicates some graphics card driver issues but this is a long shot). The crash might come from the broken image also but I'm not sure.
By the time of writing this I still have over 100GB data to recover but I'm confident that most (if not all) of that can be fully recovered. At least several hundred MBs of data got corrupted but luckily nothing important. But several hundred MBs is nothing compared to total of 187GB of data.
Lastly I'd like to thank kilgoretrout for the help! Even those tips did not provide final solution they helped me to get to correct tracks to reach final solution.
Hopefully this short guide can help someone in similar problem. Above information can also be used for other formats than ext2/ext3. ddrescue don't care about the format of the HD/partition thus any HD should be possible to rescue to image.
A8V + PATA + SATA: data corruption and unstable!
