0

Source harddisk: Size 500G. 210G of data. Used hexdump to check beyond 280G are all zeroes.

hexdump -C /dev/sdd2 --skip 280G --length 10G    # all zeroes

Destination harddisk: Size 600G. Used hexdump to check beyond 250G are all zeroes (or useless data).

hexdump -C /dev/sdc3 --skip 250G --length 10G    # all zeroes

I would like to copy all data from /dev/sdd2 to /dev/sdc3 with 250G offset in destination.

FYI: After mount, it is showing no files in destination. But I do not want to overwrite the first 250G, such that I might be possible to recover some files from there.

dd if=/dev/sdd2 of=/dev/sdc3 skip=0G seek=250K bs=1M count=280K status=progress

I tried using the dd command above. It should have done the job. But, after mount, no files in shown in the destination drive. I guess it is because the copied "file index table" is messing up with the original "file index table".

midnite
  • 571
  • I am not following .. you can not expect to dump 250GB worth of sectors in according to you unused space and the file system to know about it while bypassing that file system. – Joep van Steen Nov 22 '22 at 12:35
  • @JoepvanSteen - Thank you for reply. That is why I am asking. I read another post that make use of find to enable dd to copy multiple files. But it does not handle directories. dd is good because it has skip and seek. How to skip and seek by using cp or rsync? – midnite Nov 22 '22 at 12:43
  • 1
    That's quite a weird thing to do. Why do you want to do this? What do you want to achieve? (XY problem) – gronostaj Nov 22 '22 at 13:43

2 Answers2

1

The content of a partition with a filesystem is... well, the filesystem. In general you cannot take a part of a filesystem, place it in another partition at random offset and expect it to mount when you pass the target partition to the mount command.

Note: I assume your "G" means "GiB".

The right way is like:

  1. Shrink the source filesystem on /dev/sdd2 to 280 GiB or less. Use a tool proper to the filesystem.

  2. Move the start of /dev/sdc3 (the partition, not the filesystem therein if any) 250 GiB to the right. This can be done by deleting the partition table entry and creating a new entry with recomputed start sector and the same end sector.

  3. Copy the content of /dev/sdd2 to the new /dev/sdc3 (with dd, or whatever). I assume the new partition is large enough for the (shrunk) filesystem.

    Alternatively create a new filesystem on the new /dev/sdc3, mount both filesystems and copy files from one filesystem to the other (e.g. with cp -a or rsync).

The data will be put 250 GiB after the start of the original /dev/sdc3, but within the new /dev/sdc3 it will be where the filesystem should be with respect to the beginning of the current partition. So now it should be mountable.

There will be unallocated space before /dev/sdc3 and this is where data you hope to recover is (according to you).

r2d3
  • 3,554
Kamil Maciorowski
  • 74,068
  • +1 but… 0. Make absolutely sure you are working on an old spinny rust HD & not an SSD ;) – Tetsujin Nov 22 '22 at 12:58
  • Thank you. I thought about similar methods that resizing the partitions. But that requires more steps and calculations. If dd or cp could do, I prefer simpler handy ways. But there seems none. BTW I can mount the partitions with no problems. I am dd-ing data into the middle of the destination partition. It mounts ok. Old files inside read ok. Just the newly copied files are not showing while ls. – midnite Nov 22 '22 at 12:58
  • 1
    @midnite So there is a filesystem inside /dev/sdc3 now? And you want to keep it? You don't copy files by overwriting a part of the filesystem with a part of a different filesystem. – Kamil Maciorowski Nov 22 '22 at 13:01
  • 1
    @Tetsujin What difference does SSD make in the context of the question? – Kamil Maciorowski Nov 22 '22 at 13:02
  • SSDs don't run in 'bands' so avoiding any specific area is pointless. – Tetsujin Nov 22 '22 at 13:04
  • @KamilMaciorowski - Yes there was a fs inside /dev/sdc3. From start until 250G, there are bytes of deleted files. I do not want to overwrite them. I would like to copy files (from /dev/sdd2) and write them from 250G and after. After I did the dd command in the question, /dev/sdc3 stills mounts without problems. First 250G bytes are intact. The data from /dev/sdd2 is successfully copied to offset 250G and after. But the only problem is, after mount /dev/sdc3, I cannot see the copied files by ls. – midnite Nov 22 '22 at 13:08
  • 2
    @Tetsujin I differ. Regardless of what logical sectors the SSD maps to what block, it has to return the written data when the OS requests these sectors. It may forget the data when the sectors are overwritten or TRIMmed, but no earlier. Not writing to and not trimming these sectors is enough to keep the data within intact. – Kamil Maciorowski Nov 22 '22 at 13:14
  • As you mentioned the shrink partition method. It reminds me that, while shrinking the partition, it is actually coping files from the latter part of the partition to the earlier designated parts. This operation is very similar to what I am asking. – midnite Nov 22 '22 at 13:14
  • @midnite You want to create a franken-filesystem in a way that cannot succeed. If you want the current filesystem on the current /dev/sdc3 to remain and remain mountable then you should state this in the question because it potentially complicates things greatly. Your tests for zeros tested 10 GiB each. Without any evidence you assumed later parts contain all zeros. – Kamil Maciorowski Nov 22 '22 at 13:20
  • @KamilMaciorowski - I am not creating any fs. After my dd, it is still mountable. The only problem is, after mounted /dev/sdc3, I cannot see the copied files by ls. For the zeroes, you may assume that I have checked all the rest parts (or I will take the risk). – midnite Nov 22 '22 at 14:02
  • @KamilMaciorowski - I think I will use the shrink partition approach. However I still believe coping files into specific part of a hard drive is possible. It is because, the partition resize/shrink program is doing exactly the same operations under the hood. – midnite Nov 22 '22 at 14:04
  • 1
    @midnite: Technically it is, but it is also altering the filesystem metadata accordingly (updating the file's extent list), which is much harder to do with just dd. If you just dump data into a sector without that sector being referenced by some file, it's useless – it won't make a file spring into existence. – u1686_grawity Nov 22 '22 at 15:02
  • @midnite Note your question does not request preservation of the entire filesystem living in the current /dev/sdc3 and my answer does not try to do this. Your dd command could have damaged the filesystem already. – Kamil Maciorowski Nov 22 '22 at 15:06
0

You can't do it that way.

On disk 2 create a 249gb partition of any kind at the front of the drive.

Now it would be better to use a tool like gparted. Copy and paste the desired partition from drive 1 to drive 2.

Hit apply

Wait till its done. Delete the bogus partition we created earlier.

cybernard
  • 14,007