1

I want to replace my old SSD hard drive with a new one that has double the size, but somehow fail to understand how rsync is working.

I read this post Copy entire file system hierarchy from one drive to another.

I never cloned a drive with a running system on it with Linux before.

I partitioned my new hard drive similar to the old one:

**Old drive**
Device          Start       End   Sectors   Size Type
/dev/sdc1           a         b         c     1G EFI System
/dev/sdc2           d         e         f    64G Linux filesystem
/dev/sdc3           g         h         i   512M Linux swap
/dev/sdc128         j         k         l 400.3G BIOS boot

**New drive**
Device          Start        End    Sectors  Size Type
/dev/sdd1           a          b          c    1G EFI System
/dev/sdd2           d          e          f   64G Linux filesystem
/dev/sdd3           g          h          i  512M Linux swap
/dev/sdd128         j          m          n  866G Linux filesystem

I also corrected the partition type mistake I hadn't noticed so far (8300 for /home aka /sev/sdX128 instead of BIOS boot)

I tried sudo mount /dev/sdd128 /mnt/ssd/home next, but since that didn't work (bad file system error), I ran

sudo rsync -avxHAX --info=progress2 --numeric-ids /dev/sdc128 /dev/sdd128

with the result that only a few bytes where copied, but when I mounted the drive with above command again it worked and I could access any file from my home-folder via the mount point, so I figured some kind of symlinks was created with rsync.

I tried to copy over files again with

sudo rsync -avxHAX --info=progress2 --numeric-ids /home /mnt/ssd/home 

but what now happened was that /home was being copied to /home/home, so the sdc drive went out of disk space very soon.

I want to avoid using dd with which I am more familiar, since I read this isn't recommended for systems in use.

What are the commands I would really need to duplicate my disk? (I want to unplug the old disk and use the new one without needing to reinstall anything [but maybe GRUB]).

Edit:

Now I noticed I accidently deleted almost my entire /home folder content when using rm -r /home/home (hidden files and folders remain), can someone explain me what exactly happened when I used the commands, and, if possible, also a fast way to undo this?

1

2 Answers 2

1

Hypothesis

  1. You have never run mkfs on /dev/sdd128, hence "bad file system". Partitions and filesystems are different things (see this answer of mine).
  2. With rsync … /dev/sdc128 /dev/sdd128 you overwrote the original sdd128 special file with sdc128 special file. The original is lost (at this point a reboot would fix this) and the two names now refer to the same block device, the one called sdc128 in your mental picture of the situation.
  3. After mounting sdd128 in /mnt/ssd/home, and still having sdc128 mounted in /home, you ended up with the same old filesystem mounted in both places.
  4. Therefore /mnt/ssd/home and /home were the same directory.
  5. rsync … /home /mnt/ssd/home created additional directory level /mnt/ssd/home/home because you didn't use a trailing slash while specifying the source, this is how rsync works. Since /mnt/ssd/home and /home were the same directory, /mnt/ssd/home/home and /home/home were equivalent to each other as well. That's why data appeared in /home/home.

Unexplained

rm -r /home/home could not clear your /home. Even if it somehow would, there is no mechanism that would make the command spare hidden files. But this command:

rm -r /mnt/ssd/home/*

would be equivalent to rm -r /home/* and it would work exactly as described.

Conclusions

  1. You did nothing to a filesystem on the original ("real") /dev/sdd128. Most likely there is no filesystem there.
  2. rsync is not meant to copy data directly between block devices.
  3. You need to be extra careful when dealing with special files like /dev/sdd128.

Advices

  1. A reboot should bring /dev/sd* nodes to a sane state.
  2. After what rm did, general methods of recovering data apply:
    • restoring from backup
    • trying to undelete: extundelete (if the filesystem is from the ext family), photorec, foremost, scalpel
  3. If you're not sure what you are doing, test your planned approach on a scratch monkey.

How it should have been

There should have been a filesystem on /dev/sdd128. You would have mounted it without any error and then the approach with rsync (operating on mountpoints, directories and files under the mountpoints; not on special files in /dev/) would have worked.

2
  • 1
    Great answer! You are right in so many points: I forgot to create a file system (failed to notice that), which I discovered while trying out extundelete. I checked my bash history and noticed I mistakenly deleted /home/home *, so that explains why my home contect is gone. I still got a backup, but I always looking for new ways to avoid backups to learn some forensic stuff ;-) Sadly, extundelete was no help. What might have also worsended the process was, that I did actually reboot once between and failed to notice that /dev/sdc and /dev/sdd switched
    – kaiya
    Apr 26, 2020 at 11:50
  • 1
    so I might have accidently run commands with wrong source and destination, too. Luckily, the only file which's loss could have hurt me a bit was still open, so I just saved that one ;D Thanks for explaining what happened! And you are right, next time I should take some five minutes more and just try out the commands in e.g. a virtual machine. I didn't expect this behaviour, but next time I will be extra careful.
    – kaiya
    Apr 26, 2020 at 11:53
0

There is no easy way to undo rm, not are there even guarantees that it is possible.

rsync is for copying files, not block devices, for what you were doing dd would have been more appropriate.

To use rsync, you need both block devices to have a file system and be mounted.

You must log in to answer this question.

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