Here is my current RAID-6 setup:
What a RAID promotes is laziness in backup. You may have the best intentions but I would bet that after years of use, you will slack off of backups
Then when you aren't paying attention it stops working and then the nervousness kicks in:
1 How long has it been since the array has been backed up?
2 What will I lose if I can't get the array back up?
3 Oh crap, 2 drives are out of the array. If I lose one more…
4 And… a lot of curse words if it isn't coming back up.
Pros
1 The drives are one file system. No special considerations necessary for type of data
2 Can handle 2 drive failures before data is lost
Cons
1 If the Array fails (3+ drives are bad) all remaining drives are useless
2 Mounting a large raid file system takes 5-10 minutes
3 Adding a drive back into the array takes 1-2 days to complete
4 Regardless of the operation (read/write), all drives are hit to complete it
5 Backup drives can not be hot-swapped into the array. Data must be copied off them
6 The structure of the backup drives does not match the structure of the array
7 You need all the drives for your space right away even if half of the space is unused for years
> NOTE: You can grow an array but it is unlikely you would do this
8 All drives need to be the same size in the array. Some can be larger, but the extra space is lost
Here is my new/proposed no-RAID setup:
This is my new solution. I will cover my rationale for exactly how I came to this conclusion later
Components of the solution:
1 Constantly changing data is dealt with separately with a glacial or cloud backup (documents)
ie: I will not be putting constantly changing data on this server.
I will be keeping this data in a cloud or glacial back up
2 Once data is added to a drive, it never moves.
3 When a drive is full, it is never touched again
4 The drive that is currently being added to is backed up nightly via rsync
5 When the current drive is full
a The drive is never touched again
b The backup is taken out and a new backup is put in place
c A new "current" drive added into the enclosure
d A secondary backup is made outside the array of the latest full backup
e The secondary backup is stored in a different/safe location
Pros
1 Regardless of how many drives fail, the remaining drives are still useful
2 Adding a backup drive into the enclosure immediately makes the system fully functional
3 Only the drive with data is hit for read/write
4 Likely, the latest drive is hit the most and the older drives remain inactive extending lifespan
5 The backup drive exactly mirrors the file structure
6 Backup is automatically handed by rsync
7 There is more space available in the enclosure
8 You only need new drives as you use up space
9 New drives can grow in size as new drives become cheaper
10 This approach encourages/enforces backups
Cons
1 Data is partitioned by drive. This is not really a big deal
2 This is slightly more manual in nature (rsync versus raid recovery)
3 Finding a specific file may require looking onto multiple drives based on how organized you are
4 A tiny amount of space will be unused on each drive when the latest file won't fit onto it
5 This may require a few more drives.
Exactly what is stored on the file system?
You have 2 classes of data:
1 data that costantly changes
These are documents, a personal database and a personal source repository (< 1% of space)
2 data that never changes
audio, images, videos (> 99% of space)
When to use a RAID?
If the contents of the file system are out of your control, by all means, use an array
If the majority of your data changes (large database), use a RAID
If you need to store something that exceeds the size of any one drive, use a RAID
Otherwise, I would suggest a RAID is overkill and does not provide the backup you think it will
Unchanging data
Audio, Images and Videos never change.
This is a very important consideration. If you are like me, that is 99.9% of your data.
No video will ever exceed 3TB. Once I put a video in place, it never moves.
Why exactly would I want a RAID?
Raid != Protection
A raid does not provide protection.
If your drive monitor stops working or there is corruption in your array, you are screwed.
I say this this from practical experience.
It has happened TWICE. Turn your back on a "smoothly" running array and it will fuck you.
This is the LAST thing you want to hear when coming in from yard work:
"dad, xbmc isn't working anymore for mom and me"
How valuable is your data and your time?
Do you have a solid backup policy in place? This is your home btw. I highly doubt it.
Even if you have the data in some form somewhere, how long will it take to reconstruct it?
How valuable is your time?
How much of the data can not be recovered?
How much time can you afford for your system to be offline while you recover data?
Who is affected by not having this data for weeks?
Having a drive organization strategy
After many years of data hording, I think static data falls into these categories:
1 images
2 audio
3 video (you may choose to break this into a few subcategories)
4 software
5 pdfs
My intent is to have these same directories on each drive regardles if any data resides in it
Additional thoughts
If you never expect a file to have the same name across drives you could write a nightly
script to add symlinks
These symlinks would go from each drive onto your main linux OS drive
Having the same specific directory structure on each drive would make this pretty darn simple
Give yourself a little wiggle room on each drive
If you use a video client like XBMC, things change over the years on what they support
You will likely have nfo files and/or custom dir structures for XBMC to recognize your files.
I have custom code I've written to rebuild these based on the files.
No comments:
Post a Comment