diff options
author | Danny Rawlins <monster.romster@gmail.com> | 2017-03-09 12:01:50 +1100 |
---|---|---|
committer | Danny Rawlins <monster.romster@gmail.com> | 2017-03-09 12:01:50 +1100 |
commit | 3baa96bf2647a608a02b812d2c1a4e0db588ebb5 (patch) | |
tree | fe9650d73e0d183846c8412aa1f7d41e79aac3b7 | |
parent | 213cf073f2c821fc8abcc42f60195edd14f95110 (diff) | |
download | contrib-3.2.tar.gz contrib-3.2.tar.xz |
ddrescue: add README about a possible security risk, and how to migrate that risk by writing zeros to the unfinished parts of the clone3.2
-rw-r--r-- | ddrescue/README | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/ddrescue/README b/ddrescue/README new file mode 100644 index 000000000..c5ccb36dd --- /dev/null +++ b/ddrescue/README @@ -0,0 +1,28 @@ +CAUTION: + +I would like to point that relates to an unfinished image. + +In any event, anything less than a 100% recovery will leave portions on +the target image/drive that have not been written to by ddrescue. + +If copying to a brand new hard drive, those areas are (hopefully) likely +to be zeros. But in any other case, those areas will contain whatever data +was there previously. For someone that uses their system for data recovery +on a regular basis, and is using image files or reusing hard drives, those +areas could contain data from a previous recovery! This could be a privacy +issue in some cases, but also could cause an issue with running any other +sort of repair/file recovery tools on the recovered image/drive. + +The unrecovered parts could contain "garbage" data that could affect +accurate recovery. In these cases I would recommend using the fill mode +of ddrescue to fill any unfinished/untried areas with zeros. + +Example command: + +ddrescue --fill-mode=?/*- /dev/zero recovered_image logfile + +This would write zeros to any portion of the recovery that was not +successfully read from the source. + +Reference: +https://lists.gnu.org/archive/html/bug-ddrescue/2013-11/msg00011.html |