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@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable