Many thanks (!!) to all who responded (no particular order: David Deaves, Alan Pae, NoUce "E", Terry Moore, Darren Dunham, Angelo Bonfieto Jr., Charles Rawls). The concensus was loud and clear, mount the (!&$#@@) thing with read-only mount option, and things should work more smoothly: mount -o ro /dev/dsk/bad-device /mount-point Failing that, if the device is still giving excessive grief, "DD" might be used to rip raw data directly from the device path and dump it to another local safe storage area. [Fortunately I didn't have to resort to this] Failing that, if the data missing is of great enough value, 3rd party services are happy to accept your $$ to make an attempt at recovery :-) In my case, read-only mount was adequate to rescue the *very few* (literally - 5 files total size of < 1 meg on a 1.4Tb raid5 array) files that had been modified since the last good backup done the night before. Certainly at times like this, one gains a greater appreciation for reliable backup systems :-) Thanks again to all, ---Tim Chipman ===ORIGINAL QUESTION=== A fun "hypothetical question" (apparently un-answered in google/list archives) Is it possible to force-mount a known corrupt volume (ie, it cannot finish FSCK and if mount is attempted it gives "fatal read errors") -- **purely** for the purpose of attempting to recover *some* small portion of data on the volume .. ? context, -failed blocks on too many disks in a raid5 array. One disk in particular failed totally. -the thing is in bad shape. Rebuild of array will be 4-5 days based on the first 24 hours of performance observed. Uncertain it will actually finish successfully. -recent backup renders this a not-disaster. -small amount of data .. not backed up but would be nice to recover if possible [Filesystems are UFS/Logging Solaris8 ] Any thoughts ? Many thanks! Tim Chipman _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Sep 22 10:20:41 2004
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:37 EST