Buster/debian-

Purpose: determine if the copied image is an exact replica of the dd image.

If I recall correctly, I used the command:
I used the dd command to copy an entire flash drive over, block by block, which produced a 900Mb "image" which was originally saved on hdd 1.

I am going to copy and paste the 900Mb image to a 2nd hdd.

Will the 2 images on hdd1 & hdd2 be identical from a "block-by-block, bit-by-bit" standpoint?

Thanks.

You have answered it for yourself, a block by block copy will be duplicated by copying it to another folder/drive/pendrive.

2 members found this post helpful.

I agree. The answer is "Yep!"

After all, what does 'dd' do? Suggest you review the man page on the 'dd' command to understand what "-if" and "-of" are designated to mean.

Better yet, do the copy and use diff tools with the binary switch enabled, to confirm.

1 members found this post helpful.

I don't really know what kind of copy&paste is it, theoretically the result may depend on the software you use, although [usually] the copy will be [most probably] identical to the original file. This is the nature of copy&paste.
If you are unsure you can use md5sum or other checksum utility to verify.

2 members found this post helpful.

The answer by pan64 makes me sort of realize that the original question was about copying an image, thus possibly meaning an image file.

I sort of feel that the 'cp' command will work fine. And you can verify that via 'diff' or even further with md5sum.

What's the whole formality of desiring to use 'dd'? Or did I misconstrue 'image' meaning that to be a file? I guess if you're using image to mean a partition, then all is fine and I remove my complication.

By the way, the 'dd' command is extremely powerful, for instance you can specify offsets from the start and block sizes, as well as count of blocks to copy. Ergo you can have a disk, partition, or file where you wish to skip something like the first 12 bytes, and start your copy there, and then specify only to copy some number of blocks, where also you can specify the size of a block. I've once or twice actually performed this, one gets really concerned (squeamish) about including something like that in a regular process. But there you are, it is an available capability.

Sorry for the lengthy prose, my concerns here are:
(1) you may be over using a tool you don't need, or
(2) perhaps you do need dd, but you perhaps should be aware of the flexibility that it permits.

1 members found this post helpful.

Flexibility == opportunity for errors. That's just an inevitable consequence. I too question the necessity for dd, but if it's already done, and what the OP has is an image file produced by dd, he might have to work with it. Either tar or rsync is a better tool, but sometimes we can't use the best tool, just what is readily at hand.

1 members found this post helpful.

Thanks.

Yes, the 'dd' command was necessary and likely the correct command to use given my needs.

Yes, an 'image file' was created ~1TB size.

Based on what you all stated, sounds like the image file was "copied & pasted" thereby making an exact replica of the original image file created. Therefore, both image file copies are "block-by-block" of the original.

Used dd to capture the deleted files, not just the available files. This way when I try to get my deleted files back, if something goes wrong, I still have an exact replica backup.

QUESTION: How do I verify the 2 images using 'diff' - whatever this is, or 'md5checksum' ?

Thanks.

md5sum returns a string of alphanumeric characters. To compare two files, run md5sum against both, and compare the strings. They should be identical.
Running will give you more information. You can do that with any app.

1 members found this post helpful.

Why not obtain a checksum for both images and convince yourself? Use md5sum or sha[256|384|512]sum (pick one) on each image and see what you get.

HTH...

1 members found this post helpful.

So, this isn't just a copy or backup copy. It is a 'clone' of the disk content, to be a backup for the case something goes wrong in the recovery operations.
I think dd was the right tool to use for this. dd works on the raw device content, not at the filesystem level, so you can get everything, deleted blocks, damaged partition borders etc. The output file can be written on an existing partition of a new drive or directly on the raw space of another drive.

A potential problem is bad blocks or other hardware-related issues. In this case, dd normally fails. You can instruct it by special command line parameters how to proceed in such cases (man page gives details on this). The checksum values then aren't accurate, and this perhaps makes data recovery even harder. If your original device is failing, it would be safer to work on a clone. Recovery operations could stress too much the drive's hardware, accelerating its definitive failure.

Be sure that you use your copied file as binary.

1 members found this post helpful.

If you think that you may have bad blocks, perhaps use dd-rescue instead.

How did this turn into a perception that the OP has an actual problem? Or maybe these are just extended answers for the "just in case" types of situations.

They asked whether or not they have made an exact clone/copy of the original by using the dd command. And: "in the event that they encounter possible future data corruption, they have this identical backup". I feel the answer to their original question was: "Yes".

dd is a binary copy, or rather it is a bit-by-bit copy.

Their follow-up question was the correct way(s) to confirm that each copy is identical, for which there were several suggestions, including md5 or other checksum functions.

1 members found this post helpful.

Thank you for your remarks, rtmistler.

Using the dd command in the form posted in the initial post,
Without any other command line parameters, dd would fail with "i/o error" message in case of bad sector, or even a bad connector contact. So, I guess that the original medium didn't have any error. In the first part of my reply I wrote about the selection of the dd tool for the copy, instead of other tools. Please take into account that OP didn't write about recovery/undelete operations, just copy. Of course, copying regular files from a healthy filesystem to another can be successfully and easily done by various tools, less "risky" to use compared to dd.

The second paragraph, about potential bad blocks, was in fact an "extended answer", as you point out. You can find this problem often in discussions in the GParted support forum, where people report failing operations with "i/o error" and can't understand why this happened and what this means.

I understand (re-reading everything) that OP's problem/concern is how to be sure that further copies he plans to do after the first one are identical to the first copy.
For this, I would answer that dd from hdd 1 to hdd 2 will give a block by block identical copy.
A detail I'd like to discuss is the following: dd makes a binary copy from a data ensemble to another. The copy can be written directly on a raw hard drive without any partitioning, or in a partition already formatted with a filesystem. /dev/sdx in the command means the entire drive space, including partition table, MBR or GPT. If we dd-copy it to another hdd with an output path of, say, /dev/sdy, the result will be a hard drive y that is an exact cloned copy of the drive x.
If we use a path not to the entire hard drive device /dev/sdy but rather something like "/dev/sdy1/new.filename", this will create a file named "new.filename" that is located in the partition "/dev/sdy1" of the hard drive /dev/sdy. That isn't the same thing. In the first case the cloned drive can replace the original one (given they have both the same connection type), in the second case this can't be done. The content will be the same but we need to make an inverse dd copy to get a working clone of the original.
OP gives the generic command form he used, not the exact one.
One thing I don't know is if the various proposed copy/checksum tools (other than dd) can work at the raw hard drive device level or just at the filesystem level.

Excuse me to be so long in my reply.

1 members found this post helpful.

Thanks. I will have to look at these answers in more depth before making a good reply. Will reply shortly.

As far as I know, there are no mechanical problems with any of the drives (hdd/usb).

In the past I have "dd" both a flash drive/ usb and an entire hdd. In this case, I am referring to the source drive as the flash drive and the target drive as "a partition on" the hdd, but, if I recall correctly, NOT the entire partition; rather, just a "filename" that got added to other files on a working partition. I didn't state that originally, my fault.

MASTERCLASSIC makes a very good point (as do other posts):
The "target hdd" was NOT an ENTIRE drive destination, but just an image file on part of the hdd; yes, the dd command included "/dev/sdy1/new.filename".

According to MC, this can't be done correctly, which no one has ever stated in the past. If MC, or anyone else, can elaborate, that would be great.

B/c it is an image file, I think MC is saying I have to convert it back to a non-image file to have a working clone, and this makes sense. What command would I use to do this, and I imagine it would need to go to a full device (usb/hdd).

Appreciate all the input and other useful comments above.