Clone Linear Raid Array without empty space

Palme · Tux's lil' helper Joined: 31 May 2014 Posts: 92

Situation

eccerr0r · Posted: Thu Aug 01, 2019 2:59 pm Post subject:

Ouch, fortunately it is a linear raid so theoretically you can do this without damage, however it sounds like you want to move to the second disk in the linear.

If there was a good way I'd shrink the array to the first disk (if it's ext2fs there's a resize2fs command that should do it), then remove the second disk from the array. Do what you want to do with the second disk (repartition, mkfs) and copy first to second disk.

However I'd be wary about doing something like this without a backup. And you're using only 3.6GB at this point it's not too much data, can you find another two small disks to just copy onto (one for copy, one for backup)? This would be safest instead of dumping to itself which can be dangerous.

(I'm not sure what your intent is... eventually if you fill up more than a single disk, you can't put a "redundant backup" on the second disk of the array because the sum will be larger than a single disk. You're better off running the disks JBOD if you're worried about backup and just rsyncing the disks versus dealing with "R"AID. Actually since you're working disks like this you may have been better suited using LVM instead of MD as you can simply keep a pool of free space and add to either disk as you fill up, backup or main. Still have the same problem if data exceeds one disk's worth of space however.)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Palme · Tux's lil' helper Joined: 31 May 2014 Posts: 92

Hi

I thought about the following procedure

1. Boot from Live cd
2. Mount /dev/sdb1 to let's say /mnt/backup (as a temporary storage space)
3. backup /dev/md0 and /dev/sdb2 to /mnt/backup
4. Move the backup to my externel hdd
5. Delete all Backup files in /mnt/backup

NeddySeagoon · Posted: Fri Aug 02, 2019 5:38 pm Post subject:

Palme,

You probably can't mount /dev/sdb1 alone.
You don't know where in /dev/md0 your data is.

As it stands, /dev/sdb1 contains a piece of a filesystem that belongs to a raid set that includes /dev/sdb1
You cannot do anything with /dev/sdb1 unless you can remove it from the raid set first.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Palme · Tux's lil' helper Joined: 31 May 2014 Posts: 92

NeddySeagoon

I thought, with linear RAID, the chunks will be sequentially assigned from one drive to the next, only when the first drive is completely full.

thus all my data should be on dev/sda3 and / dev / sdb1 must be empty!
or do I misunderstand something?

eccerr0r · Posted: Sat Aug 03, 2019 1:24 pm Post subject:

It's not guaranteed to be at the beginning of the disk. The data can show up anywhere in the array - the filesystem typically selects extents to write and though a lot of the time is at the beginning of the array, large gaps are selected to reduce fragmentation. The gaps could extend the data into the second disk, though probably not likely at this point.

Definitely cannot mount a linear array's individual elements alone. You have to shrink the filesystem and then remove the extra disk if you want to do something special with that disk.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

NeddySeagoon · Posted: Sat Aug 03, 2019 2:40 pm Post subject:

Palme,

raid 0.9 puts the raid metadata an the end of the raid space.
It contains a single filesystem that describes all the space in the raid set, Its not two separate filesystems.

Your raid set is comripised of /dev/sda3 and /dev/sdb1 in linear mode. You don't know what the order is.
Attempting to mount one element will fail as the filesystem will be found but is bigger than the containing volume.
Mount won't like that.

Attempting to mount the other element will give you a filesystem not found error, that's correct too as there is no filesystem.
The filesystem metada is on the the other element.

Shrink the filesystem.
Shrink the raid, it must be bigger than the filesystem still.
You still won't know where your data is.

Than you can think about taking the raid set apart.

This shrinkage cannot be performed with the filesystem in use.

Its much lower risk to save the data somewhere else.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.