LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   How to 'clone' to smaller drive? (https://www.linuxquestions.org/questions/linux-newbie-8/how-to-clone-to-smaller-drive-4175454094/)

Geoff_L 03-14-2013 03:19 PM

How to 'clone' to smaller drive?
 
Is it possible to directly clone a drive (500GB, 2 partitions [32GB swap with balance ext3 as sda1], 35GB of sda1 in use) to a smaller drive (160GB)?

Background: Debian Squeeze 64 bit ... I recently built a new server with a 500GB Seagate SATA drive as sda but that drive is now showing SMART errors and Disk Utility suggests the drive is about to fail. The people who sold me the drive have given me an RMA number, so I've got to replace the 500GB drive with the smaller one until I get the replacement for the duff drive. I can boot into Puppy Linux (can't remember offhand which version) and so have both drives available unmounted to copy files, MBR, etc. However, I'm not sure how to do this and so help would be most welcome.

If necessary, I suppose I can do a fresh install of Debian onto the new drive and then boot into Puppy Linux to copy the contents of the old drive onto the new one, but I'm not completely sure that would work (for example, would I need to do something about the partition IDs in fstab?)

All help gratefully received.

Geoff

mreff555 03-14-2013 03:49 PM

I'm sure there are some fancy backup utilities out there which would do it. but I think you could do it with parted or resize2fs and dd.

I could be wrong on this, but I think you have to shrink your partitions first if they are bigger than the destination since data isn't always written symmetrically. Maybe that is an un-necessary step, but here is how I would do it.

assuming your 160gb drive is sdb:


used fdisk or parted to create sdb1. Make it the same size as sda1
you can do what you the same with the swap but if thats your only other partition I don't think you really need to copy the swap.
I would run fsck on sda, before attempting any resizing. Make sure the machine was completely shut down and not hibernating.
use parted or resize2fs on sda1 to shrink the partition (check the man files for details)
use dd to copy the filesystem with the notrunc flag. Something like this
Code:

dd if=/dev/sda1 of=/dev/sdb1 conv=notrunc

Emerson 03-14-2013 03:53 PM

copy -a will do.

Geoff_L 03-14-2013 04:20 PM

Thanks guys!

Certainly a pointer in the right direction. I guess my safest 'easy' option would be to back up the old drive to an external USB HD (just in case!), then use resize2fs to shrink sda1 to fit the smaller drive, power down, add the new drive, then boot Puppy Linux to use dd to first copy over the MBR, then the ext3 filesystem to the new drive, then use gparted to create a new swap partition, move the disks to their final location on the machine, then cross fingers and power up the machine...

I've scheduled the work for this weekend!

Thanks again,

Geoff

TobiSGD 03-14-2013 04:34 PM

I would simply use cfdisk to partiton the smaller drive, use mount the partitons, copy everything to the smaller drive using rsync and chrrot into the smaller partiton to reinstall the boot-loader. No experimenting with resize2fs and dd needed.

n2studio 03-14-2013 11:54 PM

Clonezilla. This is the right tool for the job (not that there aren't others). But it's open source, easy to use, and not what I would call "fancy".

chrism01 03-15-2013 01:26 AM

See also mondorescue

bloody 03-15-2013 02:03 AM

I would not try to use a filesys-resizer on a disk with damaged sectors. Get all files off that disk ASAP by copying file-by-file. Corrupt sectors have that tendency to be contagious, i.e., the more you try to read in the damaged area, the more neighbor sectors become infected, too. You might even end up with a failure when trying a fs-resize because some write op's could fail due to the damaged state of the disk, resulting in even more trouble.

I suggest to follow TobiSGD's advice, partition the smaller harddisk, copy all files over, then re-install the bootloader on the other (smaller) harddisk. Simple, safe, smart.

bloody 03-15-2013 05:04 AM

Quote:

Originally Posted by Geoff_L (Post 4911700)
(for example, would I need to do something about the partition IDs in fstab?)

Yes, Grub needs re-installing and /etc/fstab needs correct uuids (or disk labels which is what i'm using). But that's not really so much work. A few other things include confirming SSH fingerprints on the new system once again, and stuff like that. Otherwise, moving a system isn't that difficult. Once u got the bootloader and /etc/fstab updated, the whole shebang should already boot quite smoothly.

Geoff_L 03-16-2013 03:44 AM

Thanks for the help, much appreciated.

That said, I must be missing something because every attempt to clone the drive ended up with an unbootable system. In the end, I did it the 'hard' way:

1. Do a fresh install of Debian Squeeze to the smaller HD.
2. Edit /etc/fstab by copying the 'tail' of the one from the old system to overwrite the 'tail' of the new. That way, I got to keep the new UUIDs that apply to the smaller HD.
3. Restore data to new installation from backup.
4. Install the required services and restore MySQL data from backup + create Samba accounts.

Hours later, and it's all looking good except that my second USB external hard drive won't automount. When I plug it in, I get the following error:
Code:

Error mounting: mount exited with exit code 1: helper failed with:
Error opening '/dev/sde1': Permission denied
Failed to mount '/dev/sde1': Permission denied
Please check '/dev/sde1' and the ntfs-3g binary permissions,
and the mounting user ID. More explanation is provided at
http://ntfs-3g.org/support.html#unprivileged

So I tried "sudo mount /dev/sde1 /media/usb0", which worked -- although the same command without 'sudo' doesn't. I temporarily chmod'd /media/usb0 to 777, but still couldn't mount the drive as a normal user. Here's my /etc/fstab:
Code:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>  <type>  <options>      <dump>  <pass>
proc            /proc          proc    defaults        0      0
# / was on /dev/sda1 during installation
UUID=31a8b5b0-8985-4d97-97e9-d695dc379eb0 /              ext3    errors=remount-ro 0      1
# swap was on /dev/sda5 during installation
UUID=e5d582b9-9cfd-4530-9171-e475609a2cb9 none            swap    sw              0      0
#
# New SATA drives
/dev/sdb1        /var/multimedia                ext3        defaults        0        0
/dev/sdc1        /var/share/install        ext3        defaults        0        0
#
# Mount LaCie backup drive on /media/LaCie
/dev/sdd1        /media/LaCie                auto        rw,user,noauto        0        0
#
# Now added two SATA drives and converted LaCie to ext3, the first 'other' USB drive is now on /dev/sde
/dev/sde1        /media/usb0                auto        rw,user,noauto        0        0

I'm confused, partly because this fstab worked fine with the failing HD: plug in the second external drive and it automounted -- so I suspect that I'm missing something else.

Can someone point me in the right direction?

brokenleg 03-01-2016 11:21 AM

Quote:

Originally Posted by bloody (Post 4912106)
Yes, Grub needs re-installing and /etc/fstab needs correct uuids (or disk labels which is what i'm using). But that's not really so much work. A few other things include confirming SSH fingerprints on the new system once again, and stuff like that. Otherwise, moving a system isn't that difficult. Once u got the bootloader and /etc/fstab updated, the whole shebang should already boot quite smoothly.

Clonezilla or mondorescue will adjust this automatically?


All times are GMT -5. The time now is 07:28 AM.