2

PURPOSE: determine if there are any negative risks associated with mounting a blank, encrypted, destination hdd, when using the following dd command: 

(sudo dd if=/dev/sdx bs=16M of=/dev/mapper/diskname)

I was told in another post that mounting a hdd when using the 'dd' command can lead to multiple problems, such as, 1, potentially overwriting "deleted" data during the dd process. This could be problematic if the point of using the 'dd' command is to recover data that was accidentally deleted.

My guess is that mounting the "host" hdd could be problematic in numerous ways, as written above, but am "guessing" that mounting an encrypted, data-empty hdd, that is the "destination" hdd, would be harmless. But maybe this is not correct = why I am asking.

UPDATE: The encrypted hdd had the data copied to it, the encryption is intact, and it does open using the 'cryptsetup' command.......... BUT it won't mount! Mounting error: "bad fs type, bad superblock on x, bad option, etc...". Tried mounting it to other directories, like media, but same result. 

sudo cryptsetup luksOpen /dev/sdx boo.boo
sudo mount /dev/mapper/boo.boo /mnt
Improve this question
5
  • Hmm? I find your question a bit unclear, what is it that you fear? Using a disk while dd is writing to it? (<-unlikely to be "useful" IMO). If you have a full copy of an already mounted disk and attempt to mount that copy while still having the original mounted - the duplicate ID's might possibly cause problems (same ID on two disks, never tried that).
    – Hannu
    Commented Oct 28, 2019 at 16:19
  • Well, my fear is that if I mount the destination hdd, that after the duplication process is over, the destination hdd will have some sort of problem. For example, the hdd won't mount. Ironically, now, the hdd won't mount.
    – topencrypt
    Commented Oct 29, 2019 at 4:32
  • In general, the only consequences you should have had is exactly duplicate IDs. Was an origin HDD unmountend and closed in cryptsetup during a whole dd run?
    – Nikita Kipriyanov
    Commented Oct 29, 2019 at 5:28
  • @NikitaKipriyanov I think you should read the answer below.
    – topencrypt
    Commented Oct 29, 2019 at 6:01
  • It seems I asked simultaneously with that answer. Yes, I am talking about the same thing.
    – Nikita Kipriyanov
    Commented Oct 29, 2019 at 6:10

1 Answer 1

Reset to default
0

Accessing something via filesystem and via raw blocks at the same time is a very bad idea.

  • using a mounted disk/partition means: accessing the disk/partition via file system operations only, that is: creating/writing/reading files.

  • Using dd with a disk/partition as a target means: writing/reading raw blocks. This is usually incompatible with accessing the same device at the same time via a different method.

  • (Using dd with a file as a targets would mean reading from/writing to a file, mounting would be prerequisite then, and dd operations cannot clash with file system operations in that case.)

So if you both mount a disk/partition and write to it with dd, you might end up with an undesired result, because

  • dd might overwrite critical file system structure (such as directory structure or arbitrary files), rendering the target unmountable for future operations,

  • file system operations (say, flushing caches) might overwrite blocks already assigned to files (e.g. cache flush), which were recently used by dd, thus rendering your dd block copy inconsistent.

In either case, you might end up with inconsistent data, unless your dd and file system operations happen to use a different set of blocks by chance - which sounds impossible to guarantee.

Improve this answer
6
  • at jvb. Thank you, well-explained. I learned a few new things today.
    – topencrypt
    Commented Oct 29, 2019 at 6:03
  • Please note that not only mounting, but having it open in cryptsetup, participating in RAID or LVM or in some kind of caching (bcache, flashcache) also in general impedes usage of dd. You have to cease absolutely any upper level activity of the device before accessing it directly with dd.
    – Nikita Kipriyanov
    Commented Oct 29, 2019 at 6:12
  • @NikitaKipriyanov Good to know, thank you!
    – topencrypt
    Commented Oct 29, 2019 at 6:40
  • at jvb (or anyone)... "So if you both mount a disk/partition and write to it with dd, you might end up with an undesired result" : The host partition was not mounted, only the destination, so "both mounted" would not apply here. As much as I won't do it in the future, I'm wondering if the process of (only) mounting the empty destination hdd was problematic. Thx.
    – topencrypt
    Commented Nov 1, 2019 at 8:01
  • @topencrypt To clarify - I meant "both" (a) mounting destination partitions file system and (b) writing to the block device containing the file system with dd while the destination is mounted. The partition isn't empty anymore when there is a filesystem on it. While it is mounted, the operating system might decide to write to undisclosed locations on it at any time (cached things, access times, internal housekeeping info, even an "correctly unmounted" stamp later when unmounting it), thus ruining your dd copy.
    – jvb
    Commented Nov 1, 2019 at 8:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .