summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDanny Rawlins <monster.romster@gmail.com>2017-03-09 12:01:50 +1100
committerDanny Rawlins <monster.romster@gmail.com>2017-03-09 12:01:50 +1100
commit3baa96bf2647a608a02b812d2c1a4e0db588ebb5 (patch)
treefe9650d73e0d183846c8412aa1f7d41e79aac3b7
parent213cf073f2c821fc8abcc42f60195edd14f95110 (diff)
downloadcontrib-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/README28
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

Generated by cgit