joshuaboniface
/
raidisnotabackup
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Replaced bold [doesn't work in theme] with italics [hopefully works] for emphasis

This commit is contained in:
Joshua Boniface 2016-09-29 13:31:21 -04:00
parent 49ce41250b
commit 05642c5032
3 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/1.md
View File

@ -6,7 +6,7 @@ type = "post"
class="post first" 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. 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.

6
content/2.md
View File

@ -5,11 +5,11 @@ weight = 2
type = "post" 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. 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). * 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.). * 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. 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! For these reasons and more, RAID IS NOT A BACKUP!

10
content/3.md
View File

@ -5,11 +5,11 @@ weight = 3
type = "post" 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. * 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 *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. * 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. * *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. * *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. 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.