[RndTbl] shrink to smaller disk, offsite

[Adam Thompson]

I 100% agree about defensive use of trailing "/." in rsync... I just 
gave up trying to figure out what combination of magical trailing 
slashes and lack thereof caused which behaviour and *always* terminate 
with a final "/." now.

On most modern-ish systems with modern-ish versions of rsync, you may 
want to consider "-vaxHAXES".  Some of those options won't exist on 
older systems, adjust as necessary.  If you have sparse files and 
*don't* use -S you're in for a looooooooong copy session.

Generally "-x" makes dev, dev/pts, dev/shm, proc, sys, etc., etc., get 
handled correctly: the mountpoints should get copied but not traversed.  
And as the operator, you'll generally know if there are any really, 
really "special" directories that rsync can't detect, but --exclude 
shouldn't be needed nowadays.

I use this quite frequently to migrate systems; for some KVM setups, it 
can be *faster* than doing a live migration of an oversized 
raw-provisioned disk.  I've also used this to transition from thick- to 
thin-provisioned disks.

The much bigger, harder problem lies in convincing GRUB to install its 
bootloader correctly on the second volume (and point to the second 
volume for stage1, stage1.5, stage2, /boot, kernel, etc.).  I have 
*once* managed to do this successfully without using a rescue CD, and I 
sure wish I could figure out how I did it!
The one pointer I can provide is that physically removing the first disk 
before trying to reinstall GRUB from rescue media does make the job a 
heck of a lot easier!

Remember to pre-create the correct RAID layout with a "missing" disk 
*before* rsync'ing anything.  And then good luck convincing the system 
that that's really md0, not md1 or md127 or ...
Use LABEL= in your boot command lines and fstabs, not UUIDs or raw 
devices nodes for scenarios like this.  At least you can sanely control 
LABELs, and they're easy to change as needed.

As far as SELinux goes, I still refuse to waste my time creating custom 
SELinux policies to allow me to do what I consider to be fairly "normal" 
things, so on systems that only run RedHat-provided daemons, it's still 
enabled (because it doesn't break anything) and on every other system 
it's either disabled altogether, or that system just doesn't run 
RHEL/CentOS any more.

IMHO SELinux itself probably shouldn't be trusted, given what we now 
know about the NSA.  In any case, it's about as useful as systemd to me 
- yet another "improvement" forced on me as a sysadmin. *grumble*

-Adam




On 16-03-31 11:47 AM, Gilles Detillieux wrote:
> 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
>