Revamp wording throughout

content/1.md

@@ -8,9 +8,9 @@ class="post first"
 
 RAID is a common technique to provide _resiliency_ and _availability_ to a set of data and protect against one of the most common data loss scenarios: the failure of a disk.
 
-The simplest type of RAID is a 'mirror', which keeps two or more copies of data on two or more different disks. If one disk fails, the second copy is still available and no data loss has occurred. You would usually see this for system disks in uptime-critical servers.
+The simplest type of RAID is a 'mirror', which keeps two or more copies of data on two or more different disks. If one disk fails, the second copy is still available and no availability or data loss has occurred. You would usually see this for system disks in uptime-critical servers.
 
-There also exist more advanced modes, the most common of which are RAID-5 and RAID-6, and consists of 3-4 or more disks with data stripped (written sequentially), along with parity information, across all disks.
+More common for bulk data are more advanced modes like RAID-5 and RAID-6, which consists of 3-4 or more disks with data stripped (written sequentially), along with parity information, across all disks, and which can tolerate losing 1 or 2 (respectively) disks in the array before losing data.
 
 It's worth noting that a pure 'stripe', also called RAID-0, is not really a RAID level - it *increases* the risk of data loss rather than decreasing it, since one disk failure destroys the whole array. It should never be used for redundancy or any critical data.
 

content/2.md

@@ -5,15 +5,13 @@ weight = 2
 type = "post"
 +++
 
-Having a number of disks in RAID may _seem_ like a backup, especially if you're using a mirror mode. But this is _wrong_!
+Having a number of disks in RAID may _seem_ like a backup, especially if you're using a mirrored RAID mode like RAID-1 or RAID-10. But this is _wrong_!
 
-RAID protects you against one and only one thing: a disk failure. 
+RAID protects you against one and only one thing: a disk failure. It does _not_ protect you against any of the following things:
-
-It does _not_ protect you against any of the following things:
 
 * Multiple disk failures beyond the RAID level chosen (e.g. both disks in a mirror, or 3 disks in a RAID-6), including possible [UREs](https://holtstrom.com/michael/blog/post/588/RAID-5-URE-Failures.html).
-* Failure of the RAID controller itself (especially when using hardware RAID), the computer running the RAID, or the environment containing the servers (a flood, fire, theft, etc.).
+* Failure of the RAID controller itself (if applicable), the computer running the RAID, or the environment containing the servers (e.g. a flood, fire, or theft).
-* Data corruption on-disk from filesystem bugs, cosmic rays, or minor hardware or firmware failures, which can and do happen all the time - you usually just don't notice and software works around it.
+* Data corruption from filesystem bugs, cosmic rays, or minor hardware or firmware failures, which can and do happen all the time - you usually just don't notice and software works around it.
-* Malicious or accidental deletion or modification of files by yourself or another party, including viruses, bad application writes, or administrative mistakes (e.g. `rm`-ing the wrong file or `mkfs` on an existing filesystem), which any seasoned sysadmin has done at least once (and hopefully not to production data)!
+* Malicious or accidental deletion or modification of files, including by viruses, bad application writes, or administrative mistakes (e.g. `rm`-ing the wrong file or `mkfs` on an existing filesystem).
 
 The adage is simple: "RAID replicates _everything_, instantly, even the stuff you don't want it to."

content/3.md

@@ -5,6 +5,6 @@ weight = 3
 type = "post"
 +++
 
-There exists a number of file and storage systems with some advanced, RAID-like features. These include ZFS, btrfs, and Ceph. On the surface, these might give you the illuson of protection, but don't be deceived. You can still trash your whole system (or cluster, for Ceph). You can still `rm` files or run other destructive commands accidentally. A fire can still destroy your whole rack. A malicious user could overwrite your database. Even the smartest most advanced storage engine is still susceptable to at least one, and almost always several, fatal failure modes.
+There exist a number of storage systems with advanced, RAID-like features, including ZFS, btrfs, and Ceph. On the surface, these might give you the illuson of additional protection, but don't be deceived. Even the smartest most advanced storage engine is still susceptable to at least one, and almost always several, fatal failure modes that can destroy your data.
 
-Like RAID, ADVANCED FILESYSTEMS STILL AREN'T BACKUPS! Just make another copy of the data, okay!?
+Just like RAID, advanced storage systems still aren't backups.

content/4.md

@@ -5,12 +5,11 @@ weight = 4
 type = "post"
 +++
 
-* Always back up in _some way_. While a copy of the data on the same array won't protect you against all, or even very many, failure modes, it will protect you against some, and those are usually the most common.
+* Always back up in _some way_. While a copy of the data on the same array won't protect you against all, or even very many, failure modes, it will protect you against some, and those are usually the most common. Remember that a _backup on the same server_ is still susceptable to some of the _same failures as the original data_ set, but having 2 copies is still better than 1.
-* A _backup on the same server_ is susceptable to the _same failures as the original data_ set (hardware failure, natural disasters, and the like).
+* A good rule of thumb is _three copies_: the _original_ (RAID or otherwise); one _onsite copy_ on a different, preferrably offline, medium; and one _offsite copy_. Store the offsite copy in the cloud, a data vault, or at a friend's house; just keep it somewhere else. This is often called the "3-2-1" rule: 3 copies, 2 different media types, 1 offsite.
-* A good rule of thumb is _three copies_: the _original_ (RAID or otherwise); one _onsite copy_ on a different, preferrably offline, medium; and one _offsite copy_. Store the offsite copy in the cloud, a data vault, or at a friend's house, just keep it somewhere else.
+* _Make backups regularly_, at least once a week, preferrably more, and automate it! Forgetting to back something up and then needing just that backup a common scenario and is never fun, and the more frequently you back up, the better your recovery resolution, and back up regularly-changed files more often.
-* _Make backups regularly_, at least once a week, preferrably more, and automate it! Forgetting to back something up and then needing just that backup is never fun, and the more frequently you back up, especially incrementally, the better your recovery resolution.
+* _Test_ your backups regularly, at least once a month; _a backup is worthless if you can't restore from it_. Just because you have a backup doesn't mean you're protected: always test them and fix any problems. If you never test your backup, you will almost certainly find it doesn't work, right when you need it.
-* _Test backups regularly_, at least once a month; _a backup is worthless if you can't restore from it_. Just because you have a backup doesn't mean you're protected; always test them and fix any problems. If you never test your backup, you will almost certainly find it doesn't work, right when you need it.
 
-There are dozens of backup utilities out there; I'm not going to prosthelytize for any one of them, but I personally use [BackupPC](http://backuppc.sourceforge.net/) and good ol' fashoned `rsync` for my server and workstation backups.
+There are dozens of backup utilities out there which work well; I'm not going to prosthelytize for any one of them, but I personally use [BackupPC](http://backuppc.sourceforge.net/) and plain old `rsync` for my server and workstation backups.
 
-Only you can determine what you need to back up, but if you can't replace some data, you should definitely back it up - Murphy's Law applies here as much as anywhere.
+Only you can determine what you need to back up, and that differs for everyone. But if you can't replace a set of data, you should definitely back it up: Murphy's Law applies here as much as anywhere.

content/5.md

@@ -5,7 +5,7 @@ weight = 5
 type = "post"
 +++
 
-Now that you're in the know, get to making and checking a backup of your data, before you lose it!
+Now that you're in the know, get to making and checking a backup of your data, before you lose it! As someone who lost precious, priceless data both to a lamp falling on a drive and a major corruption bug in a bad enclosure, trust me when I say that you will thank yourself later.
 
 More information can be found on the following pages: