[RndTbl] shrink to smaller disk, offsite

[Gilles Detillieux]

It's been a while since I've had to do this, but I have successfully 
replicated a live root volume on a few occasions using rsync. It could 
be as simple as doing this:

   rsync  -aHXx /.  /mnt/newdisk/.

I've adopted the "/." at the end of both paths to rsync as a defensive 
measure because it can make some funky assumptions about where you want 
source directories put in the target directory otherwise. I've often 
ended up with the target having an extra level of directory when I tell 
rsync to copy one directory to another without the /. at the end. The 
advantage of using rsync is that you can rerun it again to more quickly 
update the target if you suspect the source changed during the first 
copy, which can happen even on a relatively quiet system. To make the 
subsequent update even quicker, you can just run it on directories that 
are likely to have changed, e.g. /etc.

I don't recall if I had to play around with --exclude options to avoid 
paths I didn't want traversed, or if the -x took care of all of these. I 
do recall that on a few occasions I played it safe by using a for loop 
to only copy specific subdirectories and avoid things like /sys and 
/proc altogether, but that was a bit more complicated and error-prone 
(easy to miss something important).

Note that if you're using SELinux on your system, you'll want to verify 
that the target's contexts are correctly set, and chcon any that aren't. 
rsync with the -X option should copy contexts accurately, but you may 
want to manually override the context for any mount points on the target 
volume, and make sure the volume's root directory is set to 
system_u:object_r:root_t. ls -Zld dir  is the way I examine contexts (in 
addition to modes & ownership).

Hope this helps.

Gilles

On 2016-03-30 20:56, Trevor Cordes wrote:
> I have an interesting problem.
>
> Linux box.
> /, /boot, swap on 3 RAID1 partitions
> 2 disks
>
> currently RAID is degraded, just using 1 750G disk.
> / (ext3) is 700G, only 200G used.
>
> No LVM.
>
> I added a 500G SSD.  I want that to be the new 2nd RAID1 disk.
>
> I need to shrink / to be ~450G before I can do this.
>
> resize2fs can only do shrink on unmounted.  That's a problem.  RAID1 can
> shrink the RAID block dev once I get the fs shrunk, so that's not a
> problem.
>
> I'm offsite and want to find a way to do this without going onsite and
> using single-user mode or a boot cd.
>
> Options?
>
> I guess I could make a new, smaller RAID1 / on the SSD, quiet down all
> services, and do a cp -a or cpio or something?  Then get the system to
> boot off the new / and ignore the old one, and reboot.  Besides in theory,
> has anyone actually do a whole cpio or cp -a of an entire *running* / and
> been successful?  Sample command lines?  I guess nowadays there would be
> zero dev files that need to be copied because udev recreates them all?  So
> it's literally just files, dirs, links and fifos that need copying?
>
> Any options using just ext3 and mdadm tools?  Surely there must be some
> way... unless the no-shrink-mounted makes that impossible.
>
> Maybe I'm missing something.
>
> Thanks!
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable

-- 
Gilles R. Detillieux              E-mail: <grdetil at scrc.umanitoba.ca>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (Canada)