dd question on bitcopy of hard drives

[gurutech]

A couple weeks ago I was able to use "dd" to bitcopy an 80gb hard drive to a 500gb drive. The only "issue" I ran into was that the new 500gb drive now had an 80gb partition and the rest was free space. I was able to correct this simply by extending the partition.

Just wondering what would happen if I had gone the other way, from a 500gb drive to an 80gb drive. Obviously the 80gb drive can't handle a 500gb partition. Would it just max itself out at the 80gb, or would I get an error saying it couldn't be done?

Should I go from the 500gb drive to an ISO, then from the ISO to the 80gb drive?

[george_toolan]

It doesn't fit. Try to shrink the partition first.

[jpollard]

Not exactly efficient - even shrinking the partition (though it will fit) will still leave the filesystem metadata configured for the larger drive.

[Gareth Jones]

dd will copy up to the point it runs out of space, then display a warning message that it did so.

You can shrink the partition, but you'll need to resize the file-system first to something smaller than the intended partition size, then expand the file-system to fill the partition after it's resized. See the resize2fs manual page if you're using ext2/3/4.

Or create a new partition and new file-system on the drive and use "cp -a" to copy the files. You'll probably need to "touch /.autorelabel" so that SELinux metadata is recreated on the next boot. Then you won't waste time copying unused blocks across.

If you just want to back-up onto the smaller drive, consider (compressed) tar instead.

[gurutech]

I'd actually be copying an NTFS partition. I have the 500gb drive with about 50-60gb of data on it now, so I know it would fit on the 80gb drive.

[Gareth Jones]

Then I'd definitely go with formatting the 80 GiB as a new NTFS (if you really must use that...) and using "cp -a" – SELinux attributes won't be an issue for NTFS, as it doesn't support them anyway, and shrinking file-systems is potentially more problematic than enlarging them, especially for reverse-engineered non-native file-systems like NTFS.

[gurutech]

will the cp -a copy all of the "hidden" NTFS files (like $MFT, etc...) and allow it to boot from the drive once it's been copied?

[Gareth Jones]

Originally Posted by gurutech

will the cp -a copy all of the "hidden" NTFS files (like $MFT, etc...) and allow it to boot from the drive once it's been copied?

I'm afraid I don't know about that. If it's an installed Windows system partition, I'd use Windows tools to resize it rather than Linux, unless you have space to back-up the whole partition image before resizing it.

[stoat]

Originally Posted by gurutech

will the cp -a copy all of the "hidden" NTFS files (like $MFT, etc...) and allow it to boot from the drive once it's been copied?

So this has been about a partition with a Windows operating system. I tried that once with tar. Maybe you'll have a different and better experience than me with methods that copy files (e.g., cp, tar, rsync, etc). But like you speculated, all those normally hidden files such as desktop.ini and whatnot (zillions of them all over the place) were not hidden after "cloning" with tar (something I do routinely with Linux systems). The cloned system actually booted up, but I didn't want to deal with those messed up file attributes everywhere. So for cloning Windows I went back to imaging their partitions with Acronis TrueImage.