0

I have an ext3 fs on an mdadm array of 1TB disks on an openSUSE system, and I want to move the fs to a new array of (the same number of) 3TB disks. I can have the system running with this fs unmounted, and with all of the disks in both arrays connected. I want to avoid having to boot to a self-booting tool to make the transition.

It's easy to find self-booting tools that will in one step copy and grow and ext3/4 fs from one (non-RAID) disk to a bigger one, but using an installed OS seems to require two steps (either create a new fs and copy the directory structure, or copy the fs as-is and resize the copy).

Is there a way to do this in one step from an installed OS? If not, is there a self-booting tool that supports mdadm volumes?

ShadSterling
  • 143
  • 9
  • I'm going to go ahead and copy then resize, but it seems absurd that better tools are available that self-boot than are available in an installed OS. Is that really the case? – ShadSterling Jan 26 '15 at 05:02

2 Answers2

0

I assume you have RAID5. If yes, then my guess is that you can replace the disks one by one and let it rebuild on the new one, then see if you can extend it.

One of the reasons why I would always use LVM.

Florin Asăvoaie
  • 7,057
  • 23
  • 35
  • I don't see how this answers the question, unless you mean to say that no, there isn't a way to do what the self-booting tools do from within an installed OS. Rebuilding the array for each disk is worse than copying to a new array because it doesn't leave the current state intact to serve as a backup in case the resize fails. I don't see how this is a reason to use LVM, or how that's relevant, but I don't trust LVM since http://superuser.com/questions/509872 – ShadSterling Jan 26 '15 at 04:57
  • There is always a risk involved and there are a bunch of reasons why you should not use RAID for backup. It is a safe guard but it is not a backup solution! Not using LVM is your choice, subject to your own fears. I am just telling you that it provides a much higher amount of flexibility in such cases (yopu would be able to create PVs on the new disks and migrate the VG replicas to them, live). – Florin Asăvoaie Jan 26 '15 at 13:27
0

I don't know why one step is important. You can just plug in your new array, use dd to sync the FS into the new md device (like dd if=/dev/md1 of=/dev/md2 bs=4k (4k is important for speed) and then do e2fsck -f /dev/md2 && resize2fs /dev/md2.

If you have RAID1, you can do it easier, BTW. You can remove one disk and replace with a bigger one. Then do that with the other, grow the partition table, grow the md device, grow the fs.

Halfgaar
  • 8,084
  • 6
  • 45
  • 86
  • I don't see how this answers the question, unless you mean to say that no, there isn't a way to do what the self-booting tools do from within an installed OS. One step isn't really important, just preferred, and it seems absurd that better tools are available that self-boot than are available in an installed OS. Rebuilding the array for each disk is worse than copying to a new array because it doesn't leave the current state intact to serve as a backup in case the resize fails. – ShadSterling Jan 26 '15 at 04:59
  • Then I think I don't understand your question. Perhaps you can edit to clarify. – Halfgaar Jan 26 '15 at 14:24