Btrfs, Snapper and apt-btrfs-snapshot

[GreyGeek]

The only point GG made above I would differ slightly with is the utility of btrfs on a single disk.

Thus my "escape clause":

... unless that HD or partition is TWICE OR 3X as big as the maximum size of your anticipated storage needs

IMO, btrfs has many benefits for smaller single-drive users but snapshots is not one of them. For example, if you have a small drive but want to multi-boot, you are stuck splitting your drive up into multiple partitions and thus waste a tremendous amount of space. With btrfs in the same scenario, you would need only a single file system and all your free space would be available to all your installs and your home all the time without managing partition sizes.

I have a thick skull. You'll need to explain a little more how you can get btrfs to give you multiple boots and homes on a single drive (or partition?).

Regardless of filesystem size, snapshots require paying close attention to their maintenance. Snapshots are not a set-it-and-forget-it function as GG learned with his experiments. Under certain conditions; one-off upgrades like me or risky things like compiling from an little-known source, the ability is awesome. But you must return to the snapshot and remove it as soon as it is no longer needed. In theory, over time a snapshot could grow to the same size as the subvolume it was made from. Take 4 snapshots and you have the potential to use a lot of filesystem space! With a larger amount of free space and a heavier work load, a scheduled series of snapshots - with included removal of same as they age - is a very large benefit.

Indeed. From what I've observed just creating two subvolumes (.snapshots) and then creating one snapshot each for @ and @home could, eventually, eat your entire partition or drive whereas in an EXT4 system your files and data build up may eat only half your storage.

A snapshot is not a backup and should not be used to replace one. Rather, it's a "photograph" of your system that can be used to "remember" it previous state. Once that remembrance is no longer needed, chuck that snapshot like you would pictures of your ex-girlfriend.

That's one of the three most useful reasons to use btrfs. The second is the ability to add or remove storage space easily. The third is the use of btrfs's "send" and "receive" to move one or more subvolues to a remote btrfs system, as described here:

Let's say you've got another computer with a btrfs filesystem and you want to back up your home directory from this computer to the other one. We'll use btrfs' built-in asynchronous replication for this. First, let's create a new subvolume underneath /home to contain the snapshots:
me@virtual-machine:~$ sudo btrfs sub create /home/.snapshots
Create subvolume '/home/.snapshots' Now, let's take our first snapshot:
me@virtual-machine:~$ sudo btrfs sub snapshot -r /home /home/.snapshots/myfirstsnapshot
Create a readonly snapshot of '/home' in '/home/.snapshots/myfirstsnapshot' We can see the new structure with another btrfs subvolume list:

me@virtual-machine:~$ sudo btrfs sub list /
ID 256 gen 199294 top level 5 path @
ID 257 gen 199294 top level 5 path @home
ID 849 gen 199310 top level 5 path @home/.snapshots
ID 850 gen 199311 top level 5 path @home/.snapshots/myfirstsnapshot

Now, let's replicate the snapshot to our second machine, which has convenient subvolumes named /backup and /backup/home and /backup/home/.snapshots.

me@virtual-machine:~$ sudo btrfs send /home/.snapshots/myfirstsnapshot | ssh second-machine sudo btrfs receive /backup/home/.snapshots

In its simplest possible form, this demonstrates sending the snapshot—which contains the entire /home subvolume at the time it was taken, remember—and tunneling it through ssh to the btrfs filesystem on the other end. There's nothing too special about this yet. Sure, you're replicating the entire subvolume all at once, which is kind of neat, but you could accomplish this in all kinds of ways. Where this gets cool is when we take and send a second snapshot:

me@virtual-machine: sudo btrfs sub snapshot -r /home /home/.snapshots/mysecondsnapshot
me@virtual-machine: sudo btrfs send -p /home/.snapshots/myfirstsnapshot /home/.snapshots/mysecondsnapshot | ssh second-machine btrfs receive /backup/home/.snapshots

What we did here was send only the data that has changed on-disk between "myfirstsnapshot" and "mysecondsnapshot." What's especially awesome about this is that the system doesn't have to laboriously scan the disks to find things that have changed. It already knows what has or hasn't changed, so it can just immediately start spitting data out to the receive process on the other end. If you have a few text files to replicate, this might not matter. But if you have a terabyte or five of database binaries or virtual machine storage, this is a huge deal. Backups that would have taken hours or days and generated a tremendous amount of system load with older technologies can now complete in minutes with little or no extra load.

I have systems that routinely replicate a terabyte or more of data across cheap 3Mbps and slower Internet connections using this technology... sometimes, replicating several times per day. There is literally no other technology that can accomplish this. If you have a six-figure SAN that replicates off-site several times a day, incremental snapshot replication is how it does it.

That is neat!

[oshunluvr]

I haven't yet ventured into "send" and "receive" territory, but they're definitely on my short list.

[COLOR=#333333]I have a thick skull. You'll need to explain a little more how you can get btrfs to give you multiple boots and homes on a single drive (or partition?). [/COLOR]

While I totally disagree with the former portion of that statement, to the latter I have a post here outling how I did that. But here's an abridged version:

Create a btrfs filesystem.
Install Kubuntu to it.
Rename the @ (root) and @home (/home) subvolumes to unique names; i.e. @Kubuntu_12.04 and @Kubuntu_12.04_home.
Edit fstab entries to match the new subvolumes and run update-grub.

You now have a single Kubuntu installed to a single filesystem. Now install 13.04 to the same file system (obviously without formatting!).

Rename the @ (root) and @home (/home) subvolumes to unique names; i.e. @Kubuntu_13.04 and @Kubuntu_13.04_home.
Edit fstab entries to match the new subvolumes and run update-grub.

You now have two version of Kubuntu on the same filesystem!

repeat ad nauseum.

Here's my subvolume list:

stuart@office:~$ sudo btrfs su li /
ID 258 gen 683679 top level 5 path @grub
ID 261 gen 690090 top level 5 path @Kubuntu_12_10_home
ID 262 gen 683625 top level 5 path @Kubuntu_12_10
ID 306 gen 691245 top level 5 path @Kubuntu_14_04
ID 307 gen 691245 top level 5 path @Kubuntu_14_04_home
ID 400 gen 683562 top level 5 path @Neptune_31_home
ID 401 gen 683589 top level 5 path @Neptune_31
ID 484 gen 685217 top level 5 path @Kubuntu_13_04_home_140120105600
ID 485 gen 683625 top level 5 path @Kubuntu_13_04_140120105600
stuart@office:~/Downloads$

All of this fit on a single 256GB drive.

[GreyGeek]

I thought I needed to add one more detail to this rambling prose: How to roll back, after some bad event, to a specific snapshot.

This is taken from a document in one of Ubuntu's "AksUbuntu" pages, but I don't remember which. Also note that it is a btrfs system that also contains its own /boot subdirectory, so btrfs contains all the stuff under /boot. And, I am merely acting as an aggregator of info. I have not yet done a roll back.

How to work with snaphots in Ubuntu's layout

In order to work with snapshots of / or /home in the Ubuntu layout mount the btrfs filesystem at a separate location, and work from the top of the btrfs tree, rather than from the mounted subvolumes you are running on.

First, mount the btrfs system you are currently on to the /mnt device
sudo mount /dev/sdX# /mnt

It seemed strange to me to mount the filesystem I was currently on and running AGAIN, to the very partition I was on, in my case sda4, which contained my entire kubuntu 14.04 system under btrfs.

To create a snapshot use this syntax:
sudo btrfs subvolume snapshot /mnt/@ /mnt/@_snapshot
Notice that when refering to @ or @home while running in the systm you use "/" and "/home", but when mounted separately you use "@" and "@home".


This will create a snapshot, created this way, of the @ subvolume named @_snapshot located also in the top of the btrfs tree. Since it is in the top of the tree, it will not show up when listing subvolumes in the subvolume you are currently running in.

To roll back to a snapshot, you simply need to change its name to the name that ubuntu mounts and reboot.

  [FONT=courier new]sudo mv /mnt/@   /mnt/@_badroot[/FONT]

[FONT=courier new]
[B]sudo mv /mnt/@_snapshot   /mnt/@[/B][/FONT]

then reboot!

To delete a snapshot while /mnt is mounted use:

  [FONT=courier new][B]sudo btrfs subvolume delete /mnt/@_badroot[/B][/FONT]

btrfs snapshots are subvolumes in themselves, and self-contained, deleting the old @ subvolume like this is fine, provided we have a replacement.

NOTE: The btrfs-tools command ''set-default'' will break Ubuntu's layout. Don't use it!

It is entirely possible to create a snapshot of "/" or "/home" without mounting your btrfs filesystem on /mnt and working there.
One could create a hidden subvolume called ".snapshots" in both the "/" and the "/home" subvolumes:
sudo btrfs subvolume create /.snapshots
sudo btrfs subvolume create /home/.snapshots
and then create snapshots and save them under those subvolumes:
sudo btrfs subvolume snapshot / /.snapshots/snapYYYYMMDDHHMM
sudo btrfs subvolume snapshot / /home/.snapshots/snapYYYYMMDDHHMM

Since these snapshots are created from within the working system they can be listed. Those snapshots created on a mounted /mnt cannot be seen from within the system, exceept for @ and @home, which are bound to "/" and "/home" in /etc/fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda4 during installation
UUID=ddf94bee-0a35-4c66-87b7-857db8d21a0c [B]/  [/B]             btrfs   defaults,[B]subvol=@[/B] 0       1
# /home was on /dev/sda4 during installation
UUID=ddf94bee-0a35-4c66-87b7-857db8d21a0c[B] /home[/B]           btrfs   defaults,[B]subvol=@home[/B] 0       2

In order to roll back "/" or "/home" one must mount the device to /mnt (or some other mounting point) and use mv command and then reboot.

[GreyGeek]

.....

You now have two version of Kubuntu on the same filesystem!

repeat ad nauseum.

Here's my subvolume list:

stuart@office:~$ sudo btrfs su li /
ID 258 gen 683679 top level 5 path @grub
ID 261 gen 690090 top level 5 path @Kubuntu_12_10_home
ID 262 gen 683625 top level 5 path @Kubuntu_12_10
ID 306 gen 691245 top level 5 path @Kubuntu_14_04
ID 307 gen 691245 top level 5 path @Kubuntu_14_04_home
ID 400 gen 683562 top level 5 path @Neptune_31_home
ID 401 gen 683589 top level 5 path @Neptune_31
ID 484 gen 685217 top level 5 path @Kubuntu_13_04_home_140120105600
ID 485 gen 683625 top level 5 path @Kubuntu_13_04_140120105600
stuart@office:~/Downloads$

All of this fit on a single 256GB drive.

So, IF I follow you correctly, you choose the version of Kubuntu you will boot into on the grub menu during bootup, BUT, you have access to all of the volumes regardless of which version you boot into?

[oshunluvr]

If I understand your question correctly, the answer is no. When I boot to @Kubuntu_12_10, that subvolume is mounted in fstab as root. Thus all other subvolumes are not accessible. I can (and often do) mount the root device somewhere and then access all the above.

I manage my grub menus a little differently than standard also. On startup, I boot the the @grub install. The grub menu there has os_prober turned off (as do all my grubs) and I have a 40_custom that points to the grub menus for each install, like this:

menuentry 'Kubuntu 13.04' {
insmod gzio
insmod btrfs
search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
configfile /@Kubuntu_13_04_140120105600/boot/grub/grub.cfg
}


menuentry 'Kubuntu 14.04' {
insmod gzio
insmod btrfs
search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
configfile /@Kubuntu_14_04/boot/grub/grub.cfg
}

That's just part of it, but you get the idea. Then each install manages it's own grub menu and none of them effect the "master" grub menu. This way I can add and delete installs without risking removing the grub host install - the main boot menu always survives. All I have to do is edit the 40_custom once in awhile. If I was smart, I would just use generic names like; Linux1, Linux2, Linux3, etc. Then I wouldn't even have to edit 40_custom. Another neat feature of doing it this way is the grub menus are automatically nested. If I select a submenu and change my mind, a simple ESC puts me right back to the main grub menu. I set the timeouts at 3 secs and have my current "daily" install set as the default so I can boot up unattended.

[GreyGeek]

So, when you install a new version you select the btrfs partition and install without formatting. The install then installs @ and @home, which you rename after the install to @KubuntuXX_YY and @KubuntuXX_YY_home, or something like that, and then edit the grub.conf and fstab so they point to the right subvolume?

[oshunluvr]

Exactly!

Each install has grub pointing to a disk other than my actual boot disk. That way each install has grub and all it's files, but they don't take over my main MBR.

[GreyGeek]

Exactly!

Each install has grub pointing to a disk other than my actual boot disk. That way each install has grub and all it's files, but they don't take over my main MBR.

Then I am in luck. Here are my partitions. As you can see, my boot disk is the 100MB Windows partition:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048    33556479    16777216   27  Hidden NTFS WinRE
/dev/sda2   *    33556480    33761279      102400    7  HPFS/NTFS/exFAT
/dev/sda3        33761280   759126015   362682368    7  HPFS/NTFS/exFAT
/dev/sda4       759126016  1465147391   353010688   83  Linux

I have 336GB on my sda4 partition so I can employ the same scheme you are using!

[GreyGeek]

The saga continues: The "btrfs device add" command.

My main partition, on which I have installed Kubuntu 14.04 with the btrfs FS, is on /dev/sda

I inserted an 8GB flash drive and attempted to format it with kparted. However, kparted did NOT have the btrfs as an option. XFS was there, but not btrfs.
So, I resorted to the CLI and mkfs.btrfs to format the 8GB stick. The "-f" switch was needed to forced the overwrite of the 500MB Verbatin_Store'n_GO partition, the first time I did it. After that, I did not have to.

:~$ sudo mkfs.btrfs /dev/sdb
WARNING! - Btrfs v3.12 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

Turning ON incompat feature 'extref': increased hardlink limit per file to 65536
fs created label (null) on /dev/sdb
        nodesize 16384 leafsize 16384 sectorsize 4096 size 7.46GiB

I mounted it using

sudo mount /dev/sdb /mnt

and was able to copy files to it using Dolphin, but they were stored with root ownership.
I umounted and mounted and umounted several times to see that the files I copied on it remained.

[FONT=courier new]:~$ sudo mount /dev/sdb /mnt[/FONT]
:~$ [FONT=courier new]vdir /mnt[/FONT]
total 0

and copies some files to it using Dolphin. The results are:

:~$ [FONT=courier new]vdir /mnt[/FONT]
total 64
-rw-rw-r-- 1 root root  1312 Jan 24 12:08 brtfs-find-root.txt
-rw-rw-r-- 1 root root  2268 Jan 24 12:11 brtfs-image.txt
-rw-rw-r-- 1 root root  1339 Jan 24 12:12 brtfs-map-logical.txt
-rw-rw-r-- 1 root root  1358 Jan 24 12:16 btrfsck-dont-use.txt
-rw-rw-r-- 1 root root  1431 Jan 24 12:07 btrfs-convert.txt
-rw-rw-r-- 1 root root  1104 Jan 24 14:10 btrfs-create.txt
-rw-rw-r-- 1 root root  1414 Jan 24 12:13 btrfs-show-super.txt
-rw-rw-r-- 1 root root  1217 Jan 24 12:16 btrfstune.txt
-rw-rw-r-- 1 root root 24800 Jan 24 12:04 btrfs.txt
-rw-rw-r-- 1 root root  1119 Jan 24 12:14 btrfs-zero-log.txt

:~$[FONT=courier new] sudo umount /mnt[/FONT]
:~$ [FONT=courier new]sudo mount /dev/sdb /mnt[/FONT]
:~$[FONT=courier new] vdir /mnt[/FONT]
total 64
-rw-rw-r-- 1 root root  1312 Jan 24 12:08 brtfs-find-root.txt
-rw-rw-r-- 1 root root  2268 Jan 24 12:11 brtfs-image.txt
-rw-rw-r-- 1 root root  1339 Jan 24 12:12 brtfs-map-logical.txt
-rw-rw-r-- 1 root root  1358 Jan 24 12:16 btrfsck-dont-use.txt
-rw-rw-r-- 1 root root  1431 Jan 24 12:07 btrfs-convert.txt
-rw-rw-r-- 1 root root  1104 Jan 24 14:10 btrfs-create.txt
-rw-rw-r-- 1 root root  1414 Jan 24 12:13 btrfs-show-super.txt
-rw-rw-r-- 1 root root  1217 Jan 24 12:16 btrfstune.txt
-rw-rw-r-- 1 root root 24800 Jan 24 12:04 btrfs.txt
-rw-rw-r-- 1 root root  1119 Jan 24 12:14 btrfs-zero-log.txt
:~$ sudo umount /mnt

However, I believe that the files were being saved in that 500MB XFAT Verbatin_Store'N Go partiton, as you'll see later.
So, don't expect to use btrfs on a flash drive the way you would EXT4.


Then I started exploring the "btrfs device add" command, which complained of an existing filesystem. Adding the "-f" switch forced the process.

:~$ sudo  btrfs device add /dev/sdb /home -f

Two devices were now shown:

:~$ sudo btrfs fi show /
Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
        Total devices 2 FS bytes used 90.90GiB
        devid    1 size 336.66GiB used 129.06GiB path /dev/sda4
        devid    2 size 7.46GiB used 0.00 path /dev/sdb

The show command does not total the size of the devid's.

I didn't want to run a balance operation because I didn't want to take the time.
When I mounted /dev/sdb I saw the two standard subvolumes, @ and @home:

:~$ [FONT=courier new]sudo mount  /dev/sdb /mnt[/FONT]
jerry@jerry-Aspire-V3-771:~$ vdir /mnt
total 0
drwxr-xr-x 1 root root 262 Feb  1 08:49 @
drwxr-xr-x 1 root root  66 Feb  4 14:43 @home

When I look into /mnt/@ and /mnt/@home I saw my entire filesystem!

The btrfs space and usage command showed:

:~$[FONT=courier new] sudo btrfs fi df /[/FONT]
Data, single: total=121.00GiB, used=90.50GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=4.00GiB, used=411.53MiB

and the subvolume list command showed:

:~$[FONT=courier new] sudo btrfs subvolume list /[/FONT]
ID 257 gen 25251 top level 5 path @
ID 258 gen 25251 top level 5 path @home
ID 1021 gen 21638 top level 257 path .snapshots
ID 1022 gen 25177 top level 5 path @home/.snapshots

:~$ sudo btrfs subvolume list /home
ID 257 gen 25251 top level 5 path @
ID 258 gen 25251 top level 5 path @home
ID 1021 gen 21638 top level 5 path @/.snapshots
ID 1022 gen 25177 top level 258 path .snapshots

My assumption is that the addtional 8GB of flash drive was added to the /home space.

The fi show command still showed the same devid's.

:~$ [FONT=courier new]sudo btrfs fi show /[/FONT]
Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
        Total devices 2 FS bytes used 90.90GiB
        devid    1 size 336.66GiB used 129.06GiB path /dev/sda4
        devid    2 size 7.46GiB used 0.00 path /dev/sdb

Btrfs v3.12

:~$ [FONT=courier new]sudo btrfs fi show /home[/FONT]
Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
        Total devices 2 FS bytes used 90.90GiB
        devid    1 size 336.66GiB used 129.06GiB path /dev/sda4
        devid    2 size 7.46GiB used 0.00 path /dev/sdb

Btrfs v3.12

I used the device delete command and the second device is gone:

:~$ [FONT=courier new]sudo  btrfs device delete /dev/sdb /home[/FONT]
:~$ [FONT=courier new]sudo btrfs fi show /home[/FONT]
Label: none  uuid: ddf94bee-0a35-4c66-87b7-857db8d21a0c
        Total devices 1 FS bytes used 90.90GiB
        devid    1 size 336.66GiB used 129.06GiB path /dev/sda4

The device add command destroys the existing device formatting and replaces it. The device delete command removes the formatting:

:~$[FONT=courier new] sudo mount /dev/sdb /mnt[/FONT]
NTFS signature is missing.
Failed to mount '/dev/sdb': Invalid argument
The device '/dev/sdb' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

The files I had saved in that 500MB partiton are gone.

I have a 7 port active USB device that could hold SEVEN 128GB flash drives!
Or, I have a 350GB USB HD that hasn't been used in a while.... mmmm ....

[GreyGeek]

Have you ever noticed the time delay between when you flip a switch and when the flouresencent bulb actually lights up? My brain works that way. I hear an explanation but it may take awhile for the eaning to soke in. Snapshots and backups on a btrfs system is my latest delayed reaction.

One can mount an external EXT4 formatted HD and copy files from one's computer onto the external drive, then umount it. IF the computer HD goes down the it can be replaced and files restored from the external backup HD.

Btrfs snapshots on non-raid systems do not allow that. If one makes a snapshot of /, for example, that snapshot is still on the primary btrfs system. If the HD goes down so does the backup. Disaster.

Attaching a second btrfs device, say /dev/sdb,
mkfs.btrfs -f /dev/sdb1
btrfs device add [-Kf] /dev/sdb1 /somepath
and creating a snapshot of / on it
sudo mkdir /somepath/.snapshots
btrfs subvolume snapshot / /somepath/.snapshots/snapshotname
only creates links to the files on the primary HD.

No actual data is written to snapshotname, only links to the original data. Copy on Write dictates that when a file changes on the primary system the original file, before the change was made, is copied to the snapshot. If all the files on the primary device, say /dev/sda, changes then eventually the snapshot will contain a complete copy of the original files on the primary system before any changes were made. This is why a btrfs system can eat twice the HD space of an EXT4 system. More snapshots eats up more space. IF, after creating a snapshot on /dev/sdb, that device is umounted, the links to the files on the primary system areno longer active. Any original copies of any changed files on the primary system are not copied to the snapshot. No ability to rollback exists.

This still leaves the old fashon method of just copying the original files to an EXT4 external HD, or even a btrfs external HD, and then copying them back if necessity requires it. But, this method isn't really entirely sastisfactory because one usually does not copy all the files, just the data files and important config files.

Enter the RAID system. We can use RAID0 (striping mode), RAID1 (mirror mode) or RAID10 (stripping and mirroring mode). I want RAID1.
I have not done any of the followiing. I'm sort of "thinking out loud".

I have a 350GB external USB HD and I have a seven port USB2.0 active hub, into which I can plug several flash drives, either 64GB or 128GB.
But, can I convert my brtfs single drive to a RAID1 in conjuction with an external drive?

First, mount my active btrfs system:
sudo mount /dev/sda4 /mnt
Convert it to a RAID1 system
btrfs fi balance start -dconvert=raid1 -mconvert=raid1 /mntbut this won't work because there isn't a second device that has already been spanned, which would have happened if we did this:
mkfs.btrfs /dev/sda4 /dev/sdb1
in other words, if multiple devices are specified, btrfs is created spanning across the specified devices. The balance command above merely converts both the data (-d) and the metadata (-m) to RAID1, which would mirror /dev/sda4 on /dev/sdb1, assuming /dev/sdb1 is as big or bigger than /dev/sda4.

If I use
sudo btrfs device add /dev/sdb1 /somepath
I haven't done anything except to add space to my existing btrfs filesystem.

So, at this point, I am assuming there are no btrfs tricks to convert my single btrfs system into a RAID1 by adding a second device.

I think I could reinstall Trusty Tahr, and from a LiveCD format both my /dev/sda4 and an external HD (/dev/sdb1) together and convert them to RAID1, and then install Trusty on /dev/sda4, which would mirror it to /dev/sdb1. Yes? No?

[oshunluvr]

Snapshots aren't really backups. You can do a btrfs --send to copy a filesystem to another drive, but it's a new feature and I've not messed with it. I usually do full backups the old-fashioned way. Alternately, RAID1 or RAID10 are also available if you have enough devices.

Only downside to the RAID1 with an external drive; if you remove the external (or it doesn't attach at boot time) you have to mount in degraded mode and "fix" the issue.

Yes, you can migrate your current install to another drive. You add the new device (not as RAID, just as additional space, aka "single"), delete the old device, and the files move to the new drive automatically. When the move ("balance" in btrfs lingo) is done, the old drive is removed from the file system. I know this works because I've done it. btrfs fi sh will show the progress - as the files move, the available space will change and eventually the "deleted" device will disappear from the device list. I did have to re-mkfs.btrfs the old device to generate a new UUID. The software expects you will pull the old device, and so it might re-appear in the device list eventually if you don't.

Converting a single device to RAID1 is simple. Add the second device first, then run the balance command using -dconvert. Meta will default to raid1.

[GreyGeek]

Ah, I forgot about the "-send" feature. So, would something like this work if I use a pipe and mount the external drive, previously formatted with btrfs and mounted as /mnt?
sudo btrfs send / | btrfs recieve /mnt
sudo btrfs send /home | btrfs receive /mnt/home
Then umount /mnt.

[oshunluvr]

I believe that is how it's supposed to work. I don't know if you have to send /home separately since your source is the mounted /. I think it's possible that since /home is mounted under / that it might send it all with the first command. It would be an interesting experiment.

http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html

[dibl]

Enter the RAID system. We can use RAID0 (striping mode), RAID1 (mirror mode) or RAID10 (stripping and mirroring mode). I want RAID1.I have not done any of the followiing. I'm sort of "thinking out loud".

I would invite you to reconsider -- this is not an "either / or" decision. The default BTRFS configuration for multi-device filesystem provides BOTH RAID 1 striping (of the data) and Raid 2 mirroring (of the metadata). That's what I have on my system, for my user data.

https://btrfs.wiki.kernel.org/index....ltiple_Devices

[GreyGeek]

I believe that is how it's supposed to work. I don't know if you have to send /home separately since your source is the mounted /. I think it's possible that since /home is mounted under / that it might send it all with the first command. It would be an interesting experiment.

http://docs.oracle.com/cd/E37670_01/E37355/html/ol_sendrecv_btrfs.html

Aren't "/" and "/home" (@ & @HOME) separate subvolumes? Otherwise, wouldn't a snapshot of / also include /home? When I made a snapshot of "/" I checked specfiically to see if it included /home. It did not.

I was thinking about this "send" situation while my wife and I were taking our walk ... mounting /dev/sda4 to /mnt and then doing a send of / and /home to /mnt, which is under /. It seems to me that this would create an infinite loop. However, "send" doesn't have any parameters to exclude /mnt, or any other part of /, and the examples you gave don't indicate any looping occurs. Looks like I'll be doing some experimenting.