My RHEL7 system is configured like this:

Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root    50G   18G   33G  36% /
/dev/mapper/rhel-home   504G  147G  357G  30% /home
/dev/sda1               497M  256M  242M  52% /boot
/dev/mapper/tomato-data 8.8T  5.6T  2.9T  67% /data

The rhel volume group is all on one physical drive, along with /boot. The tomato volume group is made up of many drives.

rhel-root, rhel-home, and sda1 are all xfs and tomato-data is ext4. I'd like for everything to be ext4.

I realize you can't (safely) convert from xfs to ext4 in place, so the basic plan would be to add a new drive, copy everything to it, reformat old drive, move everything back. Or, really, leave everything on the new drive. That'd be fine too.

My major fear is how to copy the data from / and /boot to the other drive without breaking all the special files, losing the date and privilege info, etc. I've seen xfsdump recommended, but obviously that won't work because I won't be dumping INTO an xfs partition.

I do have everything backed up right now, but currently as xfsdumps, so pretty useless for this purpose.

What would be the recommendation? rsync?

I'm not too worried about moving over /home, it's just regular data, but / and /boot worry me because RHEL is not my brand, and I haven't been using it long enough to learn all its quirks.

I'm also still a bit hazy on the whole volume group/logical volume thing. The only abstraction I'd concerned myself with before was RAID. (These physical drives are all simple RAID1 mirrored, by the way.)

What pitfalls would you see in terms of making stupid mistakes with /etc/fstab, getting myself into an unbootable state, etc.?

What path would you take? Do it all at once or move partitions over one at a time?

I recently replaced a smaller drive in /tomato-data with a larger one and took advantage of the magic of pvmove.

I momentarily thought I could extend rhel to include an ext4 drive and pvmove all the data off the existing xfs drive onto the ext4 drive, then just vgreduce the old physical volume, but I'm pretty sure that's nonsense that only highlights how much I am not processing this volume thing.

But my point is, I am open to tricks like that.


How do I determine if I need to reinstall grub? I wasn't sure I even had it, but I see a /boot/grub2 directory on the server, so probably(?).

So, it goes...

1. install and configure new drive
2. rsync files to new drive
3. edit fstab
4. (maybe) reinstall grub
5. shutdown system down
6. remove old physical drive
7. power up system
8. pray

Sound right?


Take a new disk and create your partitions on it as you like (by the way, XFS is fine, why do you want to change?)

Then rsync things using rsync -aH, this will keep owner, timestamp and all, and -H will preserve hardlinks.

Depending how your boot is configured, you will maybe need to reinstall grub. Replace then the old disk with the new one and boot your machine. If anything goes wrong, you can always put back the old disk.

About your fstab, if your disks are declared in there with UUID, you will have to update your file with the new ids.

  • You also the -A (preserve ACLs) and -X (preserve extended attribute) options to rsync for a fully comprehensive copy. – Timothy Baldwin May 11 '19 at 11:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.