From 13b62c70c6af13afada33563bbdd8eb50c032997 Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Wed, 22 Feb 2017 00:37:53 -0500 Subject: [PATCH] Added extra post and changed some lines --- content/1.md | 4 +++- content/2.md | 2 -- content/3.md | 15 +++++---------- content/4.md | 18 ++++++++++-------- content/5.md | 14 ++++++++++++++ 5 files changed, 32 insertions(+), 21 deletions(-) create mode 100644 content/5.md diff --git a/content/1.md b/content/1.md index b370ec5..798fca3 100644 --- a/content/1.md +++ b/content/1.md @@ -8,8 +8,10 @@ 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. -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. You would usually see this for system disks in uptime-critical servers. There also exist more advanced modes, the most common of which is called RAID-5, and consists of 3 or more disks with data stripped (written sequentially), along with parity information, across the disks. +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, and should not ever be used for redundancy. + The [Wikipedia page for RAID](http://en.wikipedia.org/wiki/RAID) provides some helpful information about the history and benefits of the various RAID implementations. diff --git a/content/2.md b/content/2.md index 6d0ac14..d2bf1ea 100644 --- a/content/2.md +++ b/content/2.md @@ -16,8 +16,6 @@ It does _not_ protect you against any of the following things: * Data corruption on-disk from filesystem bugs, cosmic rays, or minor hardware or firmware failures. * 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). -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. For these reasons and more, RAID IS NOT A BACKUP! diff --git a/content/3.md b/content/3.md index 1b96ac3..23502f7 100644 --- a/content/3.md +++ b/content/3.md @@ -1,16 +1,11 @@ +++ -title = "So how do I back up?" -description = "Backups are a contentions and complicated subject, but these simple rules should help guide you." -weight = 3 +title = "But what about those fancy file systems?" +description = "You can still destroy your data." +weight = 2 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, and automate if possible; 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 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 other destructive commands. A fire can still destroy your whole rack. -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. +Like RAID, ADVANCED FILESYSTEMS STILL AREN'T BACKUPS! -Do you need to back up everything? Of course not. That's up to you to decide. Some data is replaceable, some isn't. If it isn't, back it up! diff --git a/content/4.md b/content/4.md index 44b3a13..d94880d 100644 --- a/content/4.md +++ b/content/4.md @@ -1,14 +1,16 @@ +++ -title = "I've learned something!" -description = "Great!" -weight = 4 +title = "You've convinced me - so how do I back up?" +description = "Backups are a contentions and complicated subject, but these simple rules should help guide you." +weight = 3 type = "post" +++ -Now that you're in the know, get to making and checking a backup of your data, before you lose it! +* 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, and automate if possible; 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. -More information can be found on the following pages: +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. -* http://www.smallnetbuilder.com/nas/nas-features/31745-data-recovery-tales-raid-is-not-backup -* http://blog.open-e.com/why-raid-is-not-a-backup/ -* http://serverfault.com/questions/2888/why-is-raid-not-a-backup +Do you need to back up everything? Of course not. That's up to you to decide. Some data is replaceable, some isn't. If it isn't, back it up! diff --git a/content/5.md b/content/5.md new file mode 100644 index 0000000..44b3a13 --- /dev/null +++ b/content/5.md @@ -0,0 +1,14 @@ ++++ +title = "I've learned something!" +description = "Great!" +weight = 4 +type = "post" ++++ + +Now that you're in the know, get to making and checking a backup of your data, before you lose it! + +More information can be found on the following pages: + +* http://www.smallnetbuilder.com/nas/nas-features/31745-data-recovery-tales-raid-is-not-backup +* http://blog.open-e.com/why-raid-is-not-a-backup/ +* http://serverfault.com/questions/2888/why-is-raid-not-a-backup