I'm not an expert by any means, but I did a migration like this a few weeks ago.
The most consistent recommendation on this mailing list is to use the newest kernels and btrfs-progs feasible. I did my migration using Fedora 24 live media, which at the time was kernel ~4.3. I see your btrfs-progs is a little old. Maybe the kernel is as well and has a bug. I know you tried a bunch of variations, but it would be helpful if you posted the commands you've tried. Perhaps the most obvious problem that could be occurring is trying to send a RW subvol, which is illegal. I can't tell if you made a RO snapshot first, but your success with ROOT indicates you're aware of this limitation. I'm guessing that there's some problem with the destination path that you're providing. The path should be the containing subvol where you want it to go, not the destination name (i.e. btrfs receive /var/media/backups/ not btrfs receive /var/media/backups/HOME). Here's some send/receive commands that I've successfully used recently. Maybe they'll point you in the right direction: pull a RO snapshot from a remote system: cd ~/ksp/backups ssh 192.168.0.122 "sudo btrfs send /home/justin/ksp/backups/2016-03-15-17:24" | sudo btrfs receive . mv 2016-03-15-17:24 ../current Note how I received into the backups directory and have no control over the initial subvol name. I mv it to the proper location and name afterwards. move a RO snapshot between local file system: cd /tmp/old-btrfs/ sudo btrfs subvol snap -r home home-snap cd /tmp/new-btrfs/ sudo btrfs send /tmp/old-btrfs/home-snap | sudo btrfs receive . sudo btrfs subvol snapshot home-snap home sudo btrfs subvol delete home-snap Fedora names it's /home subvol "home." You *shouldn't* need to mess around with advanced mounting options to get this to work. On Sun, Mar 20, 2016 at 11:52 AM, Ryan Erato <rer...@gmail.com> wrote: > I do plan on physically replacing the current drive with the new one > and my fstab/boot comands use device. I never could get UUID or labels > to work, but that's another project. > > However, this still leaves me unable to take advantage of btrfs > features for implementing an incremental backup solution to another > disk. > Ryan Erato > C. 414.630.5295 > rer...@gmail.com > http://www.linkedin.com/in/ryanerato > > > On Sun, Mar 20, 2016 at 1:55 AM, Phantom Guy <no.real.per...@gmail.com> wrote: >> You tried to hard. >> >> Build the new media If you need encryption or meets devices. >> >> >> Then add the new media to the whole filesystem. >> >> >> Then remove the old media from the filesystem. >> >> >> # btrfs device add /dev/sdb1 /mountpoint >> >> # btrfs device del /dev/sda1 /mountpoint >> >> Then sync the filesystem and wait. >> >> Once the old device ID no longer part of the filesystem it's done. >> >> When the sync finishes, the /dev/sda1 device is nill. >> >> If you've designed your fstsb and boot commands correctly the label or UUID >> has migrated so as long as you've prepped the disk with grub of whatever >> then you can move the disks with impunity. >> >> You don't even need to be in any sort of maintenance mode. >> >> >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
