Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

BTRFS: moving striped data to larger drives

Ask for help with issues regarding the Installations of the Debian O/S.
Post Reply
Message
Author
colin_e
Posts: 3
Joined: 2014-10-20 20:15

BTRFS: moving striped data to larger drives

#1 Post by colin_e »

Note to mods- If "installation" is not the appropriate place for this question, please move it to the appropriate place.

I am setting up a Debian Jessie 8.5 machine as a home server.

I've been running the machine initially with a 2.5" system disk (for boot, root, swap, user, var) and a pair of 3.5" 1TB disks in RAID 1 (data and metadata) for the bulk data shares for /home and media (photos, music etc.). The two big disks are set up as a BTRFS volume on the raw devices (no partitions) with a subvolume for each share.

I want to swap the 1TB disks for some bigger drives before I pension off my old NAS and make this the primary home server. This is a pure migration, I want to copy the data in full to the new disks and remove the old ones.

From what I have read so far I have 3 main options on how to do this, listed below with pluses + minuses:

Option 1
  1. Install the new disks to the system
  2. Clone each old disk (using dd) to its new replacement disk
  3. Disconnect/remove the old drives from the system
  4. Reboot the machine with (hopefully) no config changes required (fstab uses UUIDs, but these will be cloned by dd)
  5. Expand the filesystem to occupy the full capacity of the new disks
Advantages: Simple, fast (probably?), no fstab changes required.
Disadvantages: Must not reboot machine with all 4 disks installed after the copy, or risk corruption caused by duplicate UUIDs

Option 2
  1. Install new disks
  2. Add the new disks to the RAID 1 array
  3. Remove first one old disk from the array, then the other. This will automatically(?) rebalance the data across the remaining disks
  4. Once the second rebalance completes. Physically remove the old disks from the machine.
Advantages: Machine remains in a safe bootable state throughout (e.g. if a power fail happens halfway through), no fstab changes required.
Disadvantages: Slower, due to multiple rebalances. Feels like a one-way trip, if a rebalance screws up I might have 4 disks without a good filesystem across any of them.

Option 3
  1. Install new disks
  2. Create a new BTRFS RAID1 filesystem on the new disks
  3. Copy the data using BTRFS send/receive (will this create the right subvolumes automatically?).
  4. Edit fstab to use new UUIDs
Advantages: Machine remains in a safe bootable state throughout (e.g. if a power fail happens halfway through). Can test the new array and revert to the old disks if something goes wrong with the copy.
Disadvantages: Requires fstab changes

Questions-
  • Have I correctly understood my main options here?
  • Does anyone have experience of trying any of these procedures (or something like them) and have any warnings / war stories to share?

colin_e
Posts: 3
Joined: 2014-10-20 20:15

Re: BTRFS: moving striped data to larger drives

#2 Post by colin_e »

As an update-

I undertook (roughly) my Option 1 above, the only different being I used partclone.btrfs to duplicate each disk to its replacement. Partclone claims to be btrfs-aware, but I'm not convinced.

Procedure
  1. Install the new disks to the system in addition to the existing disks
  2. Clone each old disk (using partclone-btrfs -b) to its new replacement disk (in parallel)
  3. Disconnect the old drives from the system
  4. Reboot the machine with no config changes required (my fstab uses UUIDs, but these are cloned by dd)
The good news was the machine rebooted and found the btrfs volume with all its subvolumes intact.

However, when I ran a btrfs scrub on the mount point I found a vast number of correctable errors. I found one other example of somebody who had the same issue with a single-disk transfer with partclone-btrfs here: http://superuser.com/questions/934042/p ... sum-errors, which is what makes me think partclone's "btrfs awareness" may not be that great at the moment.

After completing the scrub (which took many hours), I expanded the volume to occupy the full space on the new disks. I'm currently running another scrub but my impression is that the errors are now resolved.

So, the procedure is possible, but it's a bit nerve-wracking at times. Were I to try to do the same thing again I might try option 3, if I can find some better examples for btrfs send+receive.

Post Reply