No Raid solution

[time]

I'm thinking that with the advent of SSD, small servers or desktops don't always need real-time drive mirroring, i.e. RAID 1. Mercutio uses shadow copying in his desktops, and I feel that's an acceptable risk for small servers as well.

I'm also unconvinced that striping to improve transfer rates makes any sense - seems to me we're really limited by the interface and whatever the latest controller chip is.

Of course, the insane pricing of SSDs is what's driving this line of reasoning. I'd like to use a 240GB SSD in a server; it's a bit small yet very expensive. It's not too small for primary data, but another use for a shared drive is to store various backups etc. If I supplemented that with a 1TB disk drive (updated maybe once an hour or even once a day), I could have my cake and eat it too.

I'm visualizing an image copy from the SSD to the disk drive, with the BIOS set to boot from the SSD first. If the disk drive dies, no primary data is lost.

Has anyone already done this? What are the pitfalls?

 

[ddrueding]

Not 100% applicable, as I visualize all my servers (even if it is a small business with one VM). I now have a half-dozen servers with a Z-Drive and a spinning disk backup. Depending on what they are willing to spend on ESXi licensing, I either do 30-minute snapshots or every night backups combined with some file-level frequent backups if needed.

Of course, this isn't redundancy, but we knew that. It is fast and reliable enough for most applications.

I have been keeping tabs on Merc's issues with OCZ support (or lack thereof), and it does have me a bit worried, but those things are pretty darn stable and really darn quick.

 

[CougTek]

Not 100% applicable, as I visualize all my servers...

You mean that you virtualize all your servers.

 

[ddrueding]

You mean that you virtualize all your servers.

Um, yes....yes....that is what I meant. I'm exhausted. Between doing demo all day and reading lighting specs all night...I'm toast.

 

[CougTek]

That's the three decades you've lived kicking in. Get used to it.

 

[time]

wneddnce:

 

[Bozo]

For our servers, I use two drives in RAID 1 for the operating system and programs. A separate hard drive for data. Through out the day the data is transferred to storage computer. How often this is done is determined by the process owner. Twice a day, all the data is transfer off site to another storage computer.
Database files (mdb) are copied twice a day to a computer setup with disks for each day of the week. Because the .mdb files are being updated and accessed through out the day, it is possible to corrupt a database file. This way we can go back a day or two to find a non corrupt file.
Using SSDs for our servers would not make sense. Once the system is up and running, the boot/program drives see very little activity. And our storage drives are in the TBs.

 

[time]

You have terabyte-sized Access databases?!!! :eek4:

 

[Bozo]

You have terabyte-sized Access databases?!!! :eek4:

No, but the combination of lots of databases adds up to TBs.

 

[Chewy509]

No, but the combination of lots of databases adds up to TBs.

Considering Access MDBs are limited to 2GB in size, that's a lot of DBs. (Assuming Access XP/2003 or better, earlier versions had a 1GB limit).

 

[time]

How do you achieve the second backup each day? Do you make sure everyone's out of their system around lunchtime?

This is all good, by the way. Please keep it coming.

 

[Stereodude]

You mean that you virtualize all your servers.

You never know. The servers could be only in his head.

 

[Mercutio]

Some database systems have a provision for doing online backups. It's not impossible to manage.

I do make use of RAID 1 on systems where I feel it's appropriate, mostly for critical business data on servers.

 

[time]

The things is, that at 1-2 million hours MTBF, the SSD is possibly the least likely component in the box to fail. Power supplies are doing well to claim 100,000 hours and fans are usually less than that. This is at low temperatures, but SSDs are unfazed by higher operating temperatures.

In other words - assuming manufacturers meet their quality targets - an SSD will be less likely to fail than a motherboard. Software is a far, far more likely cause of data loss.

So is RAID still a sensible way to manage risk in a system as a whole?

 

[ddrueding]

I agree with your sentiments, Time, except for the possibility that the power supply (with it's higher chance of failure) has the potential to take the SSD with it. Of course, if it does, it is likely to take as many SSDs as you like with it. Which reinstates your point.

 

[timwhit]

Some database systems have a provision for doing online backups. It's not impossible to manage.

I do make use of RAID 1 on systems where I feel it's appropriate, mostly for critical business data on servers.

This is really DB dependent. For some of our Oracle DBs we do log shipping. For MySQL I run dumps and then the dumps are backed up. For both of these approaches the database can be online. One of our MySQL DBs is also being replicated to another machine. Replication is fairly easy to setup. I'm not sure how we backup our MS SQL DBs, but I know we run backups online.

I can't believe anyone has TBs of data in MS Access. There are several free databases that are much more robust.

 

[Bozo]

Considering Access MDBs are limited to 2GB in size, that's a lot of DBs. (Assuming Access XP/2003 or better, earlier versions had a 1GB limit).

Most are MS SQL server.

A lot of the data comes from proprietary software.

 

[Bozo]

How do you achieve the second backup each day? Do you make sure everyone's out of their system around lunchtime?

This is all good, by the way. Please keep it coming.

I don't know. That's up to the engineers and programmers. I maintain the hardware.

 

[ddrueding]

I'm not a DB guy, but one place I worked replicated all of their production DBs to another, which was itself replicated to several other locations including dev and backup. The backup server was disconnected and shut down cleanly before being backed up, restarted, reconnected, and resynched (resunk?). As soon as it was consistent again it got shut down and backed up again.

Not sure if this is the best way to do it, but it seemed to work for them.