Server(s) Data Storage; Big drives/raids with partitions or sep drives

[noprotein]

Greetings all,

I work for a portrait and production company. I've stepped into their tech role and am redesigning our servers and data layouts. We have a few different departments and use different programs for each. Art/retouching/graphics use Photoshop to touch up and create, a services department that runs exports from a few different image/data matching programs, printers who operate igen4's and kodak rp30's, and sales/customer service folks.

We take and store millions of images per year. Then those images which are shared by 20+ users are modified, designed, and printed. We have 4 servers and I'm wondering how to split up the data to best accommodate our workflow.

My first question which I'm putting in here (and i'm sure i'll have more ), is it better to have shared data on raids with partitions, raids/big drives with logical mirrors so it looks to the clients as separate drives (which I'll map), or separate drives altogether?

(a) create a raid 5/6/10 in each box and just share folders
(b) create a raid 5/6/10 in each, and make partitions
(c) use different sized drives to accommodate each department

All data will be backed up to various NAS boxes and other ideas I've yet to think of. Any input is appreciated and telling me why would be nice as well =)

 

[sminlal]

My experience is that users can't be relied on to reliably deal with backup issues - so having user-visible duplicate drives is probably not a good idea. It's better to let the hardware do that mirroring so that it always gets done no matter what (and bearing in mind that it doesn't eliminate the need for backup).

My proclivity would be to avoid using partitions since they tend to carve up space a little more rigidly than a folder structure would. You can create shares and apply protections to various folders to restrict access on a per-department basis if necessary.

The one area where partitions might be desirable is if you want to enforce disk quotas, since (depending on what kind of server you're using) these may need to be specified on a partition-by-partition (ie, "drive letter" by "drive letter") basis.

If you're going to use more than a few volumes, avoid RAID 5 because it becomes less robust the more drives you add. Stick with RAID 6 or 10 instead.

Be sure to thoroughly test AND DOCUMENT your recovery procedures before committing production data to the drives. In particular, make sure that you get notified right away if there's a drive failure, and make sure that you have a reliable way to know WHICH drive to pull out and replace. Consider using a hot spare so that the array starts to recover from failures immediately instead of waiting for someone to show up and swap a drive.

 

[kamel5547]

sminlal is prety much dead on IMO. I Folder structure is much better from an administrative point of view than partitions, and the end-user can't tell the difference.

Spend a good amount of time deciding a backup and retention strategy. Remember onsite copies are not backups, you need to have a schedule for taking media offsite. Also in my experience it is good to keep copies going back for quite some time as users will accidentally delete files and it can take years for anyone to notice.
Honestly I think tape is great, but there are other options, the main downside to tape is a high upfront cost to get the right setup (i.e. a tapeautoloader).