Question one: Not sure, this doesn’t look right.
Can you post your /etc/fstab ?
As far as the second question is concerned I am not sure what the best way is but I can surely explain my best practice with a bit of additional detail to clarify why I do what I do 
I also like to point out that at the core this is based on some excellent advice I received on the Kubuntu forum a while back. Praise to whom praise is due
So here we go:
(My) Btrfs best practice
Some context
The thing which confused me the most with btrfs was that I couldn’t figure out how these odd @ and @home folders/subvolumes/whatever which everyone seems to be talking about related to my traditional understanding of hierarchical file systems. Where do they come from, what are they, etc.?
Well, the important point to understand is that like any other hierarchical file system btrfs has got a root! But what you see when you do a ls / running btrfs isn’t the real root of your file system but rather a subvolume called @, created during installation of the OS.
The preceding @ is just a naming convention which people adhered to, you can call your subvolumes whatever you like.
During installation the OS installer automatically creates two subvolumes (one for “/” called @, and one for /home, called @home) and mounts these two subvolumes as / and /home via fstab.
Post installation your fstab will look like similar to below, please note the subvol=@ parameter which tells the OS to not mount the uuid but rather the subvolumes inside this uuid with the names @ and @home.
/dev/e74269dd-8612-4b09-b59b-3145959fc5bd / btrfs subvol=@,defaults,ssd,noatime,space_cache,autodefrag 0 1
/dev/e74269dd-8612-4b09-b59b-3145959fc5bd /home btrfs subvol=@home,defaults,ssd,noatime,space_cache,autodefrag 0 2
Without the changes explained further down the consequence is that you will never get to see the real root of btrfs, but rather stay inside the respective subvolumes!
Complicated? Not really, and it comes with significant benefits!
To bring the benefits of btrfs to live I mount the real root of btrfs to /mnt. Real root means, I mount the partition uuid instead of the snapshot of "/" created during installation.
This means you move yourself a level higher to what you get with ls /
I do this again through fstab, but this time without the subvol parameter:
/dev/e74269dd-8612-4b09-b59b-3145959fc5bd /mnt btrfs defaults,ssd,noatime 0 2
When you now run ls /mnt you should see this:
~$ ls /mnt
@ @home
And when you dig into @ via ls /mnt/@ you will find that this the same as what you get with ls /. With ls /mnt/@ you are basically looking at your root from outside in. Same with @home
Now, the cool thing about this is that you can now very easily create a snapshot of your / and /home with these two simple commands:
sudo btrfs subvolume snapshot -r /mnt/@ /mnt/snapshots/@$(date +%Y-%m-%d)
sudo btrfs subvolume snapshot -r /mnt/@home /mnt/snapshots/@home$(date +%Y-%m-%d)
You can call your snapshots whatever you want and put them wherever you want, but I use the name of the source subvolume (@, @home) and add the current date as reference which is this $(date +%Y-%m-%d) variable. I also created a new folder "snapshots" in /mnt to keep things clean.
Your real / file system (ls /mnt) will now look like this:
/
/@
/@home
/snapshots
Why would you want to do this?
Here are my prime scenarios:
- 1 GB of new OS updates, cool! Let’s install and cross fingers…
- Need to install this brandnew app which may break things…
With btrfs you run the two commands above to take a snapshot of your OS (…which will take less than a second) , before you take an action which may break you system (Put the command into bash script if it’s too much typing).
If you don’t like the update you simply go to /mnt, mv @ to let’s say @old, mv the snapshot you just took to @, reboot and you are back in business. Same for @home.
Full backup and restore of / and /home in less than 5 minutes!
Snapshots are usually read only which means that the full set of commands for a complete system restore looks like this:
#Move the broken stuff aside
mv /mnt/@ /mnt/@old
mv /mnt/@home /mnt/@homeold#Make the snapshot rw
btrfs property set -ts /mnt/snapshots/@_yourname ro false
btrfs property set -ts /mnt/snapshots/@home_yourname ro false#Replace the current @ with your snapshots
mv snapshots/@_yoursnapshot /mnt/@
mv snapshots/@home_yoursnapshot /mnt/@home
reboot now
By the way, from my experience it’s only desktop OS installers (Calamares?) which will automatically create the @ and @home subvolumes. I know Kubuntu and Manjaro do.
Arch (obviously) and my Ubuntu server did not, which confused the hell out of me until I finally understood what was going on. If @ and @home are not created during installation you can create them manually.
Important! Snapshots are not a backup! If your drive dies your snapshots die with it! Hence to turn a snapshot into a backup you need to send them off to a different drive via btrfs send/receive. I can write up something in this respect as well if there’s interest.
Quite a long chunk of text but I hope this all makes sense…