A little under 3 years ago, I started exploring btrfs for its ability to help me limit data loss. Since then I’ve implemented a snapshot script to take advantage of the Copy-on-Write features of btrfs. But I hadn’t yet had the funds and the PC case space to do RAID1. I finally was able to implement it for my photography hard drive. This means that, together with regular scrubs, I should have a near miniscule chance of bit rot ruining any photos it hasn’t already corrupted.

I went with Backblaze first because they were highly recommended by LifeHacker. Then I chose Crashplan for my main Linux computer because Backblaze doesn’t do Linux. Crashplan offers a family plan that covers 2-10 computers, but I only need to cover 2 computers (my laptops don’t have anything that needs backing up). Covering two computers on Crashplan is more expensive than doing one computer on Crashplan and one on Backblaze. So the less efficient and more complicated setup is the cheaper one; oh well.

Hard drives are relatively cheap, especially nowadays. But I still want to stay within my budget as I setup my backups and system redundancies. So, ideally, for my backup RAID I’d take advantage of btrs’ ability to change RAID types on the fly and start off with one drive. Then I’d add another and go to RAID1. Then another and RAID5. Finally, the fourth drive and RAID6. At that point I’d have to be under some sort of Job-like God/Devil curse if all my drives failed at once, negating the point of the RAID. The best thinking right now is that you want to have backups, but want to try not to have to use them because of both offline time and the fact that a restore is never as clean as you hope it’ll be.

So, back when I started this project, I laid out that one of the reasons I wanted to use btrfs on my home directory (don’t think it’s ready for / just yet) is that with RAID1, btrfs is self-healing. Obviously, magic can’t be done, but a checksum is stored as part of the data’s metadata and if the file doesn’t match the checksum on one disk, but does on the other, the file can be fixed. This can help protect against bitrot, which is the biggest thing that’s going to keep our children’s digital photos from lasting as long as the ones printed on archival paper. So, like I did the first time, I’ll first be trying it out in a Fedora VM that mostly matches my version, kernel, and btrfs-progs version. So, I went and added another virtual hard drive of the same size to my VM.

Back in August I finally had some time to do some things I’d been wanting to do with my Snap-in-Time btrfs program for a while now. First of all, I finally added the weekly code. So now my snapshots are cleaned up every three days and then every other week. Next on the docket is quarterly cleanups followed up yearly cleanups. Second, the big thing I’d wanted to do for a while now: come up with unit tests! Much more robust than my debug code and testing scripts, it helped me find corner cases. If you look at my git logs you can see that it helped me little-by-little figure out just what I needed to do as well as when my “fixes” broke other things. Yay! My first personal project with regression testing!

Night of the second day:

# btrfs sub list /home
ID 275 gen 3201 top level 5 path home
ID 1021 gen 3193 top level 275 path .snapshots
ID 1023 gen 1653 top level 275 path .snapshots/2014-03-13-2146
ID 1024 gen 1697 top level 275 path .snapshots/2014-03-13-2210
ID 1025 gen 1775 top level 275 path .snapshots/2014-03-13-2300
ID 1027 gen 1876 top level 275 path .snapshots/2014-03-14-0000
ID 1028 gen 1961 top level 275 path .snapshots/2014-03-14-0100
ID 1029 gen 2032 top level 275 path .snapshots/2014-03-14-0200
ID 1030 gen 2105 top level 275 path .snapshots/2014-03-14-0300
ID 1031 gen 2211 top level 275 path .snapshots/2014-03-14-0400
ID 1032 gen 2284 top level 275 path .snapshots/2014-03-14-0500
ID 1033 gen 2357 top level 275 path .snapshots/2014-03-14-0600
ID 1035 gen 2430 top level 275 path .snapshots/2014-03-14-0700
ID 1036 gen 2506 top level 275 path .snapshots/2014-03-14-0800
ID 1037 gen 2587 top level 275 path .snapshots/2014-03-14-0900
ID 1038 gen 2667 top level 275 path .snapshots/2014-03-14-1700
ID 1039 gen 2774 top level 275 path .snapshots/2014-03-14-1800
ID 1040 gen 2879 top level 275 path .snapshots/2014-03-14-1900
ID 1041 gen 2982 top level 275 path .snapshots/2014-03-14-2000
ID 1042 gen 3088 top level 275 path .snapshots/2014-03-14-2100
ID 1043 gen 3193 top level 275 path .snapshots/2014-03-14-2200

Morning of the third day:

I got my new hard drive that would replace my old, aging /home hard drive. As you read in part 1, I wanted to put btrfs on it. This is my journey to get it up and running. Plugged it into my hard drive toaster and ran gparted.

[caption id=“attachment_7889” align=“aligncenter” width=“421”] Gparted for new drive[/caption]

[caption id=“attachment_7890” align=“aligncenter” width=“500”] Gparted for new drive1[/caption]

Recently I once again came across an article about the benefits of the btrfs Linux file system. Last time I’d come across it, it was still in alpha or beta, and I also didn’t understand why I would want to use it. However, the most I’ve learned about the fragility of our modern storage systems, the more I’ve thought about how I want to protect my data. My first step was to sign up for offsite backups. I’ve done this on my Windows computer via Backblaze. They are pretty awesome because it’s a constant backup so it meets all the requirements of not forgetting to do it. The computer doesn’t even need to be on at a certain time or anything. I’ve loved using them for the past 2+ years, but one thing that makes me consider their competition is that they don’t support Linux. That’s OK for now because all my photos are on my Windows computer, but it leaves me in a sub-optimal place. I know this isn’t an incredibly influential blog and I’m just one person, but I’d like to think writing about this would help them realize that they could a) lose a customer and b) be making more money from those with Linux computers.