SSD cards/drives for Mac Pro Server?

OWC's SSDs are better than the ones sold by Apple. But as for the rest of your query I'd say that you would be better served by talking with the tech support people at OWC especially about their products.

Generally speaking you can RAID any number of drives whether HDD or SSD. I'm uncertain as to why you need constrain yourself to a one volume solution when you can create a RAID of high speed hard drives that can provide pretty fast service almost comparable with an SSD.

WD 10K VR 1TB $300 each, 200MB/sec each. 3-4 of those - rule #1 keep adequate free space.

4 x 4TB Hitachi $400 each - gets good feedback reviews on MPG

SSD setups with multiple PCIe SSD can get to 1TB

www.macperformanceguide.com

for whatever reason but I would get the system and library data separated - you get much better performance

(for a number of reasons I don't want to split it so that system disk and files are on different volumes).

The single biggest performance payback on a Mac Pro (that is not compute-bound and has enough RAM) is to establish a Boot Drive -- with System, Library, Applications, and the hidden unix files on its own drive. That is the way I run my Server at home.

This keeps Mac OS X Virtual Memory system from wrecking the performance of regular file access -- whether you have the User files on a RAID or not.

Also, if you expect "near Hard Drive" performance, Gigabit Ethernet with jumbo frames is a must. That may mean you need a Gigabit Ethernet Switch (but not a Router, since most file transfers go direct and do not use the Router).

An Application that insists on keeping its database on the boot drive, and has no mechanism for assigning it to another drive is doomed to perform like cr@p forever. If there is no method built into the program, you can move its database manually by using Aliases or Symbolic Links.

This article by Japamac disusses the virtues of Boot Drives:

Make room for Performance: Moving the Home Folder

This chatty article discusses the same issue from a different perspective:

http://chris.pirillo.com/how-to-move-the-home-folder-in-os-x-and-why/

Server software is most often used to support a multitude of Macs connected by an Internal Network. If that is not the setup you are intending to use, please ignore my outburst about upgrading your local Network to Gigabit Ethernet.

2) backups: when everything is on 1 disk, it's very easy to clone it (nightly) and have a complete system that can be moved to another computer or used in case something goes wrong. If I have stuff spread across 2 disks, how does backup work?

Mac OS X contains more that a quarter million files that do not change from day-to-day. There is no need to spend the time or space to copy that stuff off daily.

For Mac OS X, you make a clone. Depending on your tolerance, this could be monthly or more often as you desire.

Mac OS X can be restored from DVDs and brought up-to-date in about two hours, without losing anything. Or downloaded in about the same amount of time.

-------

For User files, you can use Time Machine to do hourly automatic backups, and weekly or daily clones of just the User data. This takes much less time and is more likely to get done.

For cloning User data, use a trio of External drives and take the latest drive off-site weekly (or whatever your data-reconstruction threshold is), as soon as the backup is completed. If User data is sensitive, you will need to encrypt the drive to take it off site.

Moving the system to different computers, huh?

That is unique.

You could have the system on one drive on each computer and move the database too.

You are not talking about removing drive sleds or are you?

You can take non-system / you could have everything in an external box

But having system and even your and especially your database index and master files should always not be on the same drive.

System drive - OS and applications and whatever normally goes into System, Library etc (and not sub folders in Users)

DB Index (SSD)

DB Master and support DB

You could put everything in a 4-drive enclosure, would not change or matter though I think it is easier to have the system on internal boot drive (240GB SSD, WD 10K 500GB $200 200MB/sec - so both are almost the same except the SSD is 1000:1 faster adn higher IO per second.

The idea behind modern Operating Systems is that most System stuff is Read-Only by design. This greatly simplifies the Paging scheme. So you will find that the only System files that have changed since Installation are in:

/Library/Caches

/Library/Preferences

/Library/Managed Preferences

Dozens of other System Directories, representing tens of Gigabytes and over a quarter million files could be set to Read-Only with no impact on daily operation.

For User files, all the files you as a User have changed are in:

/Users/your_name/

This includes all the preferences you set on a User-by-User basis-- they are in:

/Users/your_name/Library/Preferences

Database systems have been around for decades and isolation of and use of multiple drives.

And with OS X going back to early 2003.

Keep what you have as backup, use CCC to clone just /Users to another drive.

Clone OS with /Users and any account sub folder, and keep each accounts ~/Library with the system - makes life easier and easy to test.

The OS is always linked to the GUID number of the volume (and volume can be a disk or an array) and the array can even be moved to different SATA ports, even from internal to external as long as all the members of the array or volume are present.

Yes, the installer can be "trusted."

Every database has its index, and to improve performance the index was / is never on the same device to reduce any bottleneck and let the index stay hovering and the database searches to be performed separate and concurrently.

If you can load an index into memory and page-fix it great, use a RAM Disk (virtual volume) so the index does not need to be read into memory even to speed up requests (we use to serve 100s of users that needed 2 second response time, not 20 seconds).

"Guaranteed"? No.

As a programmer by trade, I can say with authority that there is no guarantee against programmer stupidity.

Applications that write outside of "Standard" directories will find that program operation is blocked by lack of access to arbitrary directories. The program cannot continue due to permissions problems. This causes a Tech support nightmare.

But look at modified dates on directories that hold your programs. I believe you will find that no modifications were made in program directories after installation -- they were all made in Preferences directorys.