Questions on restoring to a failed boot drive.

[jfabernathy]

I've been studying the Sticky topic https://www.kubuntuforums.net/forum/...guide-to-btrfs

It's quite good. I started understanding it on the 4th read and after I did some of the examples.

I'd like to confirm some of the things I suspect from my playing around.

1. If I mount /dev/disk-that contains @ subvolume and @home at /mnt I see using the "ls -l" command @ and @home. Those are the subvolumes I also see if I do sudo btrfs su list /

2. If I do a mkdir /mnt/snapshot it not only creates a directory, but now the btrfs su list / shows it as a subvolume with and ID. What's the difference between just making the directory and using the btrfs -su create command?

3. I did the example from the Guide of doing a snapshot before installing a lot of code like libreoffice and then restoring @ and @home back to the previous snapshot and that worked great as expected. But what about the case where your SSD that contained @ and @home dies and all you have is the snapshot backups you created via btrfs send/receive on another hard drive in your system. In my case /dev/sda is the boot ssd and /dev/sdb is the btrfs partition-less drive where all the @ and @home snapshots are sent. So they contain all the files needed to rebuild a new /dev/sda, but how is this done?

[oshunluvr]

1. Correct

2. For technical correctness, I assume you meant "btrfs su create" (no dash). "mkdir" just makes a directory. A subvolume is not a directory per se, but can be accessed like one if the higher level file system is mounted. The difference is a subvolume can be mounted on its own, you can take snapshots of it, make a backup or copy of it by using "send", etc. A directory is just a directly. A btrfs file system supports using both folders and subvolumes.

3. When you "send|receive" a snapshot to another file system, it makes a complete copy of all the metadata and file data on the receiving file system. It is literally a complete copy of the subvolume. Once you "send" it, they are no longer connected to each other. You could say it ceases to be a snapshot and instead becomes a full copy. There's no "rebuilding" of data needed in this case because it's a true and full copy. Snapshots are the primary advantage of a subvolume over just a directory.

A btrfs "snapshot" is initially only a copy of the metadata. At creation it does not occupy any data space. If you modify the source subvolume, the snapshot then begins to occupy data space because it preserves all the original data. I.e. subvolume @test is created, you add 10 files to it, then you make a snapshot of it as @test_snap. Now delete 5 of the files from @test. Your drive free space stays the same. The files aren't actually deleted at this point because they still exist in @test_snap. If you were to also delete the same files from @test_snap, then your data space would increase again. Because of this relationship, a snapshot must exists on the same file system as the source subvolume. Once you "send' it to another file system, this sharing of data no longer occurs - the snapshot is no longer sharing space with the source subvolume.

As far as how would you recover from a drive failure: Using your example - snapshots of @ and @home have been "send|receive" from /dev/sda1 to /dev/sdb. You would need to replace sda so you could boot again, then once up and running, you would "send|receive" the subvolumes from sdb back to sda. Remember the subvolumes only contain the data, not all the boot info needed. The drive boot record and partition table contain boot info. You can also make a backup of the boot sectors and partition table, but that's not a btrfs function.

Per our earlier discuss about partition-less btrfs: There is a case to be made for using a partition table on the drives. Last time I checked, grub can't boot to a multi-device btrfs file system and can't boot from a partition-less drive. IDK if either of those boundries have changed or not. Having a liveUSB handy is always a good idea if only one drive is bootable on your system.