Safecopy is a data recovery tool which tries to extract as much data as possible from a problematic (i.e. damaged sectors) source - like floppy drives, hard disk partitions, CDs, tape devices, ..., where other tools like dd would fail due to I/O errors.
Safecopy includes a low level IO layer to read CDROM disks in raw mode, and issue device resets and other helpful low level operations on a number of other device classes.
The project also includes a device simulator which can be used to simulate bad media for testing and benchmarking safecopy as well as other data rescue tools. This article (Statistical analysis of damaged data storage media read timings) (pdf version)covers the theoretical background and methods for gathering statistics on to be simulated media.
Project @ Sourceforge
All POSIX (Linux/BSD/UNIX-like OSes) downloads: at SourceForge.net
SafeCopy Data Recovery 1.6
Started By
Chachazz
, Feb 07 2009 07:48 PM
2 replies to this topic
#2
Chachazz
-
- General Admin
-
- 36,503 posts
Is GSF inventory
Posted 30 May 2011 - 03:31 AM
Safecopy-1.5
2009-07-28:
Safecopy now supports generic direct hardware access with O_DIRECT, as well as reading from /dev/raw devices. Direct IO is enabled with the --sync option. For this it was necessary to align the main read buffer with the blocksize address boundary, so DMA transfers to the read buffer are possible, bypassing CPU-based in-memory copying by the kernel.
The --debug switch, present since about safecopy 1.3, has now been documented, and a new switch -T <timingfile> will generate a statistics file with the read timing information in microseconds for each read block. This is useful for statistical analysis of bad hardware behaviour and finding strategies to speed up recovery tools like safecopy, ddrescue and the like.
Read Statistical analysis of damaged data storage media read timings for more information about what this is good for.
2009-07-28:
Safecopy now supports generic direct hardware access with O_DIRECT, as well as reading from /dev/raw devices. Direct IO is enabled with the --sync option. For this it was necessary to align the main read buffer with the blocksize address boundary, so DMA transfers to the read buffer are possible, bypassing CPU-based in-memory copying by the kernel.
The --debug switch, present since about safecopy 1.3, has now been documented, and a new switch -T <timingfile> will generate a statistics file with the read timing information in microseconds for each read block. This is useful for statistical analysis of bad hardware behaviour and finding strategies to speed up recovery tools like safecopy, ddrescue and the like.
Read Statistical analysis of damaged data storage media read timings for more information about what this is good for.
#3
Chachazz
-
- General Admin
-
- 36,503 posts
Is GSF inventory
Posted 30 May 2011 - 03:34 AM
Safecopy-1.6
Bugfix:
safecopy-1.5 and prior had a bug concerning badblock include files. With
enabled badblock marking the pointer to the current include block was set
beyond the next to be read block during badblock marking, since the badblock
marking code checks for include blocks to not overwrite good data with badblock
markers. However this constellation was not checked for correctly, when
advancing the main source file pointer, resulting in data to be copied despite
it was not listed in the include file.
safecopy-1.6 fixes this bug (ID 2854324 )
http://sourceforge.n...y/safecopy-1.6/
Bugfix:
safecopy-1.5 and prior had a bug concerning badblock include files. With
enabled badblock marking the pointer to the current include block was set
beyond the next to be read block during badblock marking, since the badblock
marking code checks for include blocks to not overwrite good data with badblock
markers. However this constellation was not checked for correctly, when
advancing the main source file pointer, resulting in data to be copied despite
it was not listed in the include file.
safecopy-1.6 fixes this bug (ID 2854324 )
http://sourceforge.n...y/safecopy-1.6/
