Another +1 for btrfs in my book.
The current implementation includes "send-receive" functionality that allows you to send an entire subvolume from one disk to another - even over a network - or to a file. This is an amazing tool and real time saver.
In the process of re-building my server (new hardware and re-configuring the drives), I used an older, small SSD. I immediately began having boot and space available problems on this drive (it wasn't full). Seeing the writing on the wall, before my last reboot, I did the send-receive from the SSD to one of the hard drives. I had both the Ubuntu server 14.04 and Kubuntu 15.10 installed to this drive (same btrfs partition, different subvolumes). I then prepared both of these new, received, subvolumes for booting: Which means I mounted them, edited the grub.cfg's and fstab's to change the UUIDs to the destination partition's UUID. Finally, I installed grub to the hard drive.
All of the above took a few minutes (the send-receive not included - that takes some time). The nice thing is I now had a complete bootable copy of two installs and I didn't have to go through all the hoops of other methods to replicate an install. Well, as luck would have it, the very next reboot the SSD failed totally. Not even detected in the BIOS. The destination hard drive happened to already be set as the next boot device, so as I watched the reboot I wasn't even aware that I was booting to the replacement subvolume, right up until mounting swap failed - the swap partition was on the SSD.
In order to do a send-receive, the subvolume must be read-only. So the first step is to make a read-only snapshot of the subvolume. This is required because as you might imagine, making a copy of a subvolume that is in use could result in corruption. A read-only snapshot can't be edited so it is presumed safe to send. Then you need only to have a destination to send it to. Since you're sending a read-only subvolume, you also are receiving a read-only subvolume so once the receiving is done, if you want to put it in use you must convert it to read-write. If you're just making a backup, you don't need to do that right away, but it's simple enough to do.
Here's a quick summary of the terminal commands required (as root) to accomplish the task I did above. I had three subvolumes on the SSD so I repeated this three times:
### Make a read-only snapshot of the subvolume named @Ubuntu_Server_14_04 ###
btrfs subvolume snapshot -r @Ubuntu_Server_14_04 @Ubuntu_Server_14_04_ro
### Send the read-only snapshot to a btrfs file system mounted at /mnt/backup ###
btrfs send @Ubuntu_Server_14_04_ro | btrfs receive /mnt/backup
### When complete, make a read-write snapshot of the received subvolume ###
btrfs subvolume snapshot /mnt/backup/@Ubuntu_Server_14_04_ro /mnt/backup/@Ubuntu_Server_14_04
### Delete the read-only snapshots for clean-up ###
btrfs subvolume delete @Ubuntu_Server_14_04_ro
btrfs subvolume delete /mnt/backup/@Ubuntu_Server_14_04_ro
and that's it. I just made a fully usable copy of my Ubuntu server install. Now I only have to edit grub and fstab to reflect the new UUID's and it's bootable. Since we're using the terminal to do this, another convenient feature of btrfs is you need only use the first two letters of most of the commands to accomplish a task. So this
btrfs subvolume snapshot -r @Ubuntu_Server_14_04 @Ubuntu_Server_14_04_ro
can be this:
btrfs su sn -r @Ubuntu_Server_14_04 @Ubuntu_Server_14_04_ro
to save a few keystrokes. BTW, if you wanted further protection against accidental deletions or potential software update snafu's, just keep the snapshot. Then you can roll back an install or recover a deleted file with ease.
The current implementation includes "send-receive" functionality that allows you to send an entire subvolume from one disk to another - even over a network - or to a file. This is an amazing tool and real time saver.
In the process of re-building my server (new hardware and re-configuring the drives), I used an older, small SSD. I immediately began having boot and space available problems on this drive (it wasn't full). Seeing the writing on the wall, before my last reboot, I did the send-receive from the SSD to one of the hard drives. I had both the Ubuntu server 14.04 and Kubuntu 15.10 installed to this drive (same btrfs partition, different subvolumes). I then prepared both of these new, received, subvolumes for booting: Which means I mounted them, edited the grub.cfg's and fstab's to change the UUIDs to the destination partition's UUID. Finally, I installed grub to the hard drive.
All of the above took a few minutes (the send-receive not included - that takes some time). The nice thing is I now had a complete bootable copy of two installs and I didn't have to go through all the hoops of other methods to replicate an install. Well, as luck would have it, the very next reboot the SSD failed totally. Not even detected in the BIOS. The destination hard drive happened to already be set as the next boot device, so as I watched the reboot I wasn't even aware that I was booting to the replacement subvolume, right up until mounting swap failed - the swap partition was on the SSD.
In order to do a send-receive, the subvolume must be read-only. So the first step is to make a read-only snapshot of the subvolume. This is required because as you might imagine, making a copy of a subvolume that is in use could result in corruption. A read-only snapshot can't be edited so it is presumed safe to send. Then you need only to have a destination to send it to. Since you're sending a read-only subvolume, you also are receiving a read-only subvolume so once the receiving is done, if you want to put it in use you must convert it to read-write. If you're just making a backup, you don't need to do that right away, but it's simple enough to do.
Here's a quick summary of the terminal commands required (as root) to accomplish the task I did above. I had three subvolumes on the SSD so I repeated this three times:
### Make a read-only snapshot of the subvolume named @Ubuntu_Server_14_04 ###
btrfs subvolume snapshot -r @Ubuntu_Server_14_04 @Ubuntu_Server_14_04_ro
### Send the read-only snapshot to a btrfs file system mounted at /mnt/backup ###
btrfs send @Ubuntu_Server_14_04_ro | btrfs receive /mnt/backup
### When complete, make a read-write snapshot of the received subvolume ###
btrfs subvolume snapshot /mnt/backup/@Ubuntu_Server_14_04_ro /mnt/backup/@Ubuntu_Server_14_04
### Delete the read-only snapshots for clean-up ###
btrfs subvolume delete @Ubuntu_Server_14_04_ro
btrfs subvolume delete /mnt/backup/@Ubuntu_Server_14_04_ro
and that's it. I just made a fully usable copy of my Ubuntu server install. Now I only have to edit grub and fstab to reflect the new UUID's and it's bootable. Since we're using the terminal to do this, another convenient feature of btrfs is you need only use the first two letters of most of the commands to accomplish a task. So this
btrfs subvolume snapshot -r @Ubuntu_Server_14_04 @Ubuntu_Server_14_04_ro
can be this:
btrfs su sn -r @Ubuntu_Server_14_04 @Ubuntu_Server_14_04_ro
to save a few keystrokes. BTW, if you wanted further protection against accidental deletions or potential software update snafu's, just keep the snapshot. Then you can roll back an install or recover a deleted file with ease.
Comment