From 112e622367dade2bb7c06c72a5c6a0c720e33b5e Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Wed, 28 Sep 2016 12:25:10 -0400 Subject: [PATCH] Fixed markdown formatting --- content/1.md | 2 +- content/2.md | 6 +++--- content/3.md | 10 +++++----- content/4.md | 4 ++-- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/content/1.md b/content/1.md index 7c28505..4a8e0dd 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 617a496..3910985 100644 --- a/content/2.md +++ b/content/2.md @@ -5,9 +5,9 @@ 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: +RAID protects you against one and only one thing: a disk failure. It does **not** protect you against any of the following things: 1. Multiple disk failures beyond the RAID level chosen (e.g. both disks in a mirror, or 3 disks in a RAID-6). 2. Failure of the RAID controller itself (especially when using hardware RAID), the computer itself, or the environment (a flood, or fire, perhaps). @@ -15,6 +15,6 @@ RAID protects you against one and only one thing: a disk failure. It does *not* 4. File corruption from bad writes or bit rot (except for ZFS), including whole-volume corruption from administrative mistakes (e.g. =mkfs= on an existing filesystem). 5. Malicious or accidental deletion or modification of data by yourself or another party, including viruses. -The adage is simple: "RAID replicates _everything_, even the stuff you don't want, like the deletion of that file you needed." +The adage is simple: "RAID replicates **everything**, even the stuff you don't want, like the deletion of that file you needed." For these reasons and more, RAID IS NOT A BACKUP! diff --git a/content/3.md b/content/3.md index 1747f30..d697edd 100644 --- a/content/3.md +++ b/content/3.md @@ -5,10 +5,10 @@ weight = 3 type = "post" +++ -1. 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. -2. A _backup on the same server_ is susceptable to the _same failures as the original data_ set (hardware failure, natural disasters, and the like). -3. 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. -4. _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. -5. _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. diff --git a/content/4.md b/content/4.md index 364b951..e28cf80 100644 --- a/content/4.md +++ b/content/4.md @@ -9,5 +9,5 @@ Now that you're in the know, get to making and checking a backup of your data, b More information can be found on the following pages: -http://blog.open-e.com/why-raid-is-not-a-backup/ -http://serverfault.com/questions/2888/why-is-raid-not-a-backup + * http://blog.open-e.com/why-raid-is-not-a-backup/ + * http://serverfault.com/questions/2888/why-is-raid-not-a-backup