More btrfs fun: Moving a subvolume from one drive to another.

[oshunluvr]

Exactly that: change fstab and grub.cfg. Then once you are able to boot into the new install, running update-grub will use the proper UUIDs. I don't think there's anywhere else in the system that uses UUIDs.

The last time I did this (recently) I used sed to do a replace-in-place. It goes a lot faster than typing searching out those long UUIDs in kate or nano. The sed command looks like this:

sudo sed -i 's/<OLD UUID>/<NEW UUID>/' /mnt/new_subvol/etc/fstab

I assumed you mounted the target subvolume at /mnt/new_subvol and you would replace <OLD UUID> with the source UUID and <NEW UUID> is the new target UUID. Repeat the above for /mnt/new_subvol/boot/grub/grub.cfg and you should be ready to boot.

I wonder if you could move the subvolume and then change the UUID of the target filesystem to match the source? Of course, you'd have to change the UUID of the source too or Grub would fail.

It just occurred to me that you could use labels in both grub and fstab, but you'd still have to either re-set the labels in grub/fstab or change them anyway, so not really a solution.

EDIT: Apparently, the sed command will work on two or more files in one shot, like this:

sudo sed -i 's/<OLD UUID>/<NEW UUID>/' /mnt/new_subvol/etc/fstab /mnt/new_subvol/boot/grub/grub.cfg

but I haven't tried it. Testing...

...it does indeed. Test results:

$ echo 'hello mom' > test1
$ echo 'hello cruel world' > test2
$ cat test*
hello mom
hello cruel world
$ sed -i 's/hello/goodbye/' test1 test2
$ cat test*
goodbye mom
goodbye cruel world

Of course, in the fstab/grub.cfg case you would list both files separately but this also works where it applies:
$ sed -i 's/hello/goodbye/' test*

[NZJon]

Hi there. Many thanks for posting this thread. I have cribbed from it while I am moving my HDD over to my new SSD. I realise that this is a relatively old post (well, 7 months old...), but I just wanted to understand what you meant when you wrote:

The last change I need to make is to fix the UUIDs in the newly moved subvolume to match the new filesystem location.

Is that within just /etc/fstab, or in /boot/grub/grub.cfg, or somewhere else too...?

Cheers,
Jon

[SteveRiley]

All in all, I find that I can manually create named snapshots when I need them (before adding or removing software or making other changes), and as easily delete them when no longer needed, as easy as apt=-get-snapshot.

Agreed; manual control over this process is probably better.

[GreyGeek]

I had trouble figuring out how to delete the post-upgrade snapshot, too. sudo btrfs subvolume delete /@apt-snapshot-release-upgrade-utopic-datetime simply refused to work -- it kept throwing some form of "can't delete" error.

Eventually I realized that I could mount the filesystem (/dev/sda2 in my case) into /mnt. When I did that, then sudo btrfs subvolume delete /mnt/@apt-snapshot-release-upgrade-utopic-datetime worked.

---

This is why I always set HISTSIZE=-1 and HISTFILESIZE=-1 in ~/.bashrc! Having an infinite bash history to review is sure handy, especially when trying to remember something I typed months ago

Mounting the file system and working on it (while the btrfs system is still running live -- NEAT!) is how I solved the problems the apt-get-snapshot created. The app automatically created them on the sdX drive and without mounting the drive the btrfs snapshots wouldn't show anything. Also, the annoying nesting of snapshot/directory/snapshot/directory/snapshot .... was a PITA.

It had some nice features, like automatically creating a "Pre" snapshot before the actual app installations took place, and a "post" one afterwards. But, it was the automatic snapshots (hourly, daily, weekly. monthly and yearly), especially the hourly and daily ones, that began eating my drive space. Editing the config files for both @ and @/home and reducing them to more reasonable frequencies helped.

All in all, I find that I can manually create named snapshots when I need them (before adding or removing software or making other changes), and as easily delete them when no longer needed, as easy as apt=-get-snapshot.

[SteveRiley]

EDIT: remembered it wouldn't delete snapshots it didn't take and I couldn't get it snapshotting the way I wanted it to, so I dumped it.

I had trouble figuring out how to delete the post-upgrade snapshot, too. sudo btrfs subvolume delete /@apt-snapshot-release-upgrade-utopic-datetime simply refused to work -- it kept throwing some form of "can't delete" error.

Eventually I realized that I could mount the filesystem (/dev/sda2 in my case) into /mnt. When I did that, then sudo btrfs subvolume delete /mnt/@apt-snapshot-release-upgrade-utopic-datetime worked.

---

This is why I always set HISTSIZE=-1 and HISTFILESIZE=-1 in ~/.bashrc! Having an infinite bash history to review is sure handy, especially when trying to remember something I typed months ago

[oshunluvr]

Gerry ran into trouble with it a while back. If I recall correctly, it kept filling up his drive space. I tried to install it recently just to see if it had improved. I couldn't get it to work - I was getting some error message - but I didn't stick with it too long and I don't remember what the exact issue was. EDIT: remembered it wouldn't delete snapshots it didn't take and I couldn't get it snapshotting the way I wanted it to, so I dumped it.

I just use a cronjob to run a script weekly that takes snapshots of all the subvolumes on my main drive and manually clean up once in awhile. I'm going to add to it to have it do the cleanup automatically - like delete the oldest of four snaps when doing a new one - something like that. The thing to remember about snapshots is they take up no room initially so do them as often as you like. As they age, they grow until they eventually equal the original subvolume in size.

I think different subvolumes would have different snapshot requirements depending on their content. Like - a subvolume containing an OS should be snapshotted every time you install anything or edit the system before you install or edit. Then, if the edit or install goes bad, you can recover. Home or personal files could be snapshotted hourly, daily or weekly - whatever suits your fancy.

Now that I've used send/receive, once I get things cleaned up and rearranged, I'll add backup duties to the script via send/receive for a backup onto my data drive.

[SteveRiley]

Yep, I ran into that thing when I do-release-upgraded from 14.04 to 14.10. It automatically snapshotted / before running the upgrade.

[vinnywright]

call me late or call me cool ,,,,,,,,,,,have you guys seen this one .................

vinny@vinny-Bonobo-Extreme:~$ apt show apt-btrfs-snapshot
Package: apt-btrfs-snapshot
Priority: optional
Section: universe/admin
Installed-Size: 93.2 kB
Maintainer: Michael Vogt <michael.vogt@ubuntu.com>
Version: 0.3.4.2
Depends: python (>= 2.7), python (<< 2.8), python:any (>= 2.7.1-0ubuntu2), python3:any (>= 3.3.2-2~), python3, btrfs-tools
Download-Size: 7,272 B
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
Description: Automatically create snapshot on apt operations
 This will create a btrfs snapshot of the root filesystem each time
 that apt installs/removes/upgrades a software package.
 .
 A commandline tool called "apt-btrfs-snapshot" is also provided
 for easy access create/list/delete snapshots.

looks like more btrfs fun to me

link > https://www.howtoforge.com/rollback-...n-ubuntu-12.10

yes yes old ........but have you seen it .

VINNY

[oshunluvr]

Re. rEFind: That's my plan, but I'm still using this older BIOS machine for now. So I'm making an EFI partition to prepare, but not using it as of yet.

[SteveRiley]

If you're going to run your machines in UEFI mode, why not rid yourself of that abomination otherwise known as GRUB and instead use rEFInd?

rEFInd's boot loader is the only one that gets registered into a UEFI NVRAM variable. rEFInd becomes your boot manager and can automatically detect all Linux, Windows, and Mac OS kernels on all visible partitions during boot. rEFInd creates a menu containing a list of what it found; select the OS you want and you're off like a herd of turtles. Simpler than your existing (and rather elegant) GRUB of GRUBs.

[oshunluvr]

I agree, it's feels a little slower than a properly tuned ext4 system. However for me the plethora of extra features are worth it.

Currently - due to the same impending upgrade - I'm converting a whole-device, multi-disk, btrfs filesystem into a partition-based multi-disk filesystem. I'm migrating to GPT tables and planning on EFI so I want to prepare for that in advance. Currently, my two SSDs are wholly used by a single filesystem. I want to get everything except backups onto the SSDs including grub, swap, and EFI so I need a couple partitions for that. Luckily, once I purged backups and snapshots (and re-balanced the metadata to clear it's free space) I had enough room on a single SSD so I just "deleted" one of the devices. After re-partitioning it, I'll balance the data to the new partition AND I will be able to use the computer through the entire operation. Fricken' amazeballs!

[SteveRiley]

Btrfs is amazing. I'm using it on my laptop even though it has just one drive so that I can become familiar with it. I do hope that the developers can work out the performance issues at some point. Phoronix testing routinely shows Btrfs lagging other file systems, and anecdotally I can state that it "feels" slower than EXT4 did. But not enough to make me switch back. Btrfs is the future -- its integration with containers is quite cool.

[oshunluvr]

After several years, I'm still just scratching the surface of all the wonderful tools btrfs has in it's kit. Today, I'm re-arranging drive space due to an upcoming (hopefully ) system upgrade later this year. I'll skip the why-fors and get to the brass tacks:

I installed 15.04 to an HD. I want to move the entire install and it's home to my SSD. I'm going to use a feature set of btrfs called send and receive. The send command "sends" the subvolume and preserves all the links and such. The normal output of the btrfs send command outputs to stout so you can pipe it to a file for later use or directly to a new subvolume using btrfs receive. I will do the latter.

For reference: the two mounts in use are /mnt/red and /mnt/samsung, the source subvolume on /mnt/red is @Kubuntu_15.04. I actually did this on the @home subvolume also, but the commands are identical and don't need repeating. All these commands were done in root mode via sudo -i.

Preparation for this task requires that the source subvolume for the send command must be read only. This is to prevent writes during a send or receive operation causing corruption. Since this is an install subvolume, not a data backup, I must create a read-only copy before sending it. With btrfs this is simple and immediate:

subvolume snapshot -r /mnt/red/@Kubuntu_15.04 /mnt/red/@Kubuntu_15.04_snap

To ensure the snapshot is complete, issued a sync command (but I doubt it was needed).

btrfs filesystem sync /mnt/red

Now I sent the read-only subvolume snapshots from "red" to "samsung"

btrfs send /mnt/red/@Kubuntu_15.04_snap | btrfs receive /mnt/samsung

and in a few minutes, here's the listing from both filesystems:

root@office:/mnt/red# ll /mnt/red
total 16
drwxr-xr-x 1 root root   220 Feb 20 13:26 ./
drwxr-xr-x 1 root root    68 Feb  1 01:12 ../
drwxr-xr-x 1 root root   212 Feb 17 13:20 @Kubuntu_15.04/
drwxr-xr-x 1 root root    32 Feb 15 16:36 @Kubuntu_15.04_home/
drwxr-xr-x 1 root root    32 Feb 15 16:36 @Kubuntu_15.04_home_snap/
drwxr-xr-x 1 root root   212 Feb 17 13:20 @Kubuntu_15.04_snap/
drwxrwsr-x 1 root backup  34 Feb 18 13:35 @media_backup/
root@office:/mnt/red#

root@office:/mnt/red# ll /mnt/samsung/
total 4
drwxr-xr-x 1 root root  268 Jan 31 23:52 ./
drwxr-xr-x 1 root root   68 Feb  1 01:12 ../
drwxr-xr-x 1 root root  348 Feb 16 11:56 @Kubuntu_14_04/
drwxr-xr-x 1 root root   48 Jan 25 16:21 @Kubuntu_14_04_home/
drwxr-xr-x 1 root root  274 Jan 27 11:56 @Kubuntu_14_10_plasma5/
drwxr-xr-x 1 root root   32 Jan 25 16:21 @Kubuntu_14_10_plasma5_home/
drwxr-xr-x 1 root root   32 Feb 20 13:53 @Kubuntu_15.04_home_snap/
drwxr-xr-x 1 root root  212 Feb 20 13:34 @Kubuntu_15.04_snap/
drwxr-xr-x 1 root root 1168 Feb  4 14:09 snapshots/
root@office:/mnt/red#

Currently, there's no way available to change a read-only snapshot back to read-write. No biggie - make a new read-write snapshot of the read-only snapshot (and fix the name in the bargin!):

btrfs subvolume snapshot /mnt/samsung/@Kubuntu_15.04_snap /mnt/samsung/@Kubuntu_15.04

Now /mnt/samsung looks like:

root@office:/mnt/samsung# ll
total 4
drwxr-xr-x 1 root root  334 Feb 20 14:13 ./
drwxr-xr-x 1 root root   68 Feb  1 01:12 ../
drwxr-xr-x 1 root root  348 Feb 16 11:56 @Kubuntu_14_04/
drwxr-xr-x 1 root root   48 Jan 25 16:21 @Kubuntu_14_04_home/
drwxr-xr-x 1 root root  274 Jan 27 11:56 @Kubuntu_14_10_plasma5/
drwxr-xr-x 1 root root   32 Jan 25 16:21 @Kubuntu_14_10_plasma5_home/
drwxr-xr-x 1 root root  212 Feb 20 13:34 @Kubuntu_15.04/
drwxr-xr-x 1 root root   32 Feb 20 13:53 @Kubuntu_15.04_home/
drwxr-xr-x 1 root root   32 Feb 20 13:53 @Kubuntu_15.04_home_snap/
drwxr-xr-x 1 root root  212 Feb 20 13:34 @Kubuntu_15.04_snap/
drwxr-xr-x 1 root root 1168 Feb  4 14:09 snapshots/
root@office:/mnt/samsung#

Since the read-only snapshots are no longer needed - let's delete them:

root@office:/mnt/samsung# btrfs subvolume delete /mnt/samsung/@Kubuntu_15.04_home_snap /mnt/samsung/@Kubuntu_15.04_snap /mnt/red/@Kubuntu_15.04_snap /mnt/red/@Kubuntu_15.04_home_snap/

Done. Now a full usable, bootable copy of Kubuntu 15.04 and it's home reside on two drives on my system. The last change I need to make is to fix the UUIDs in the newly moved subvolume to match the new filesystem location. This whole operation took less than 15 minutes - and that includes typing this post!

The send/receive operation can be used to make a full backup of a subvolume and can even be done incrementally using the "parent" switch or over a NFS connection. The combination of snapshots and send/receive backups can all be scripted and combined to create a really data-safe system.