diff --git a/content/1.md b/content/1.md
index a27d667..393ff17 100644
--- a/content/1.md
+++ b/content/1.md
@@ -6,7 +6,7 @@ type = "post"
 class="post first"
 +++
 
-It 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.
+It 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 does just what it sounds like: 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.
 
diff --git a/content/2.md b/content/2.md
index 037bf36..38df493 100644
--- a/content/2.md
+++ b/content/2.md
@@ -5,11 +5,11 @@ 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 mirror mode. But this is *wrong*!
 
 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).
 * Failure of the RAID controller itself (especially when using hardware RAID), the computer running the RAID, or the environment (a flood, fire, theft, etc.).
@@ -18,6 +18,6 @@ It does **not** protect you against any of the following things:
 
 Even ZFS, designed specifically to prevent the third point, is still susceptable to the others.
 
-The adage is simple: "RAID replicates **everything**, instantly, even the stuff you don't want." Like the deletion of a file or corruption.
+The adage is simple: "RAID replicates *everything*, instantly, even the stuff you don't want." Like the deletion of a file or corruption.
 
 For these reasons and more, RAID IS NOT A BACKUP!
diff --git a/content/3.md b/content/3.md
index 9c841b9..a04d8ab 100644
--- a/content/3.md
+++ b/content/3.md
@@ -5,11 +5,11 @@ weight = 3
 type = "post"
 +++
 
-* Always back up in **some way**. While a copy of the data on the same array won't protect you against all problems, it will protect you against some.
-* 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 RAID is only one copy for this purpose): the **original**, one **onsite copy**, and one **offsite copy**. Store the offsite copy in the cloud, or at a friend's house.
-* **Make backups regularly**, at least once a week; the day you need a backup is the day you realize you hadn't run it in 6 months and what you need isn't backed up.
-* **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.
+* Always back up in *some way*. While a copy of the data on the same array won't protect you against all problems, it will protect you against some.
+* 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 RAID is only one copy for this purpose): the *original*, one *onsite copy*, and one *offsite copy*. Store the offsite copy in the cloud, or at a friend's house.
+* *Make backups regularly*, at least once a week; the day you need a backup is the day you realize you hadn't run it in 6 months and what you need isn't backed up.
+* *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.
 
 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/) for my server and workstation backups.