Hello

I'm considering sending a rackmount server away for colocation in order to offer offise backup to a couple of my clients.

I post quite a bit here and respect people's opinions, so I'm asking the question here forum, instead of other forum. I hope someone has an opinion.

What is the most important components in a file server for offsite backup? (obviously storage space). Is copying files to remote locations RAM intensive, CPU intensive or HDD intensive?

All hosting companies are on fast enough conections, and we can assume that most of my clients are on upload speeds of no greater than 1mbit. Furthermore, we can assume that not too many clients will be acessing it at the same time.

Therefore, where is the bottleneck going to be? Should I invest in dual processors, lots of RAM or very, very fast hard drives? Or will it not make too much difference if the connection speed is a maximum of 1mbit.

Thanks in advance, and thanks for reading.

Hamish

I would say go for a good hard drive controller (SCSI or ATA - Serial ATA is IMHO not suitable for production use, especially not on storage critical systems) and use RAID for redundancy. You don't want to loose all your data because a disk goes bad.


Håkan

Hey, thanks.

I thought about IDE becuase (a) inexpensive, (b) tried and tested, and (c) i don't feel that the speed of IDE drives will be the bottleneck.

What do you think about CPU and RAM?

Hamish

SCSI might be better so you can take advantage of RAID. (SCSI and RAID are definately tried and true) If all the info is going across the internet, then there won't be many bottlenecks on the PC you'll have to worry about. Even when talking about network speeds 100 times faster than you are talking about the network is still slower than the harddrives. If not that many people will be connecting then you probably don't need bleeding edge speeds and massive amounts of RAM. But even so, I would want higher RAM quantities than CPU speed. Most CPU's are over 2 GHz anyways.

I'd say the biggest thing you need to focus on is dependability and uptime. Unfortunately that costs. Believe me, the first time a backup fails because an IDE drive crapped out, somebody will accidentally delete hours of unrecoverable work. Murphey's law very much applies to computer backups.

lol, I hate Murphey's law!

Any idea on the slowest CPU you would reckomend? I was thinking, for cost reasons, or getting an older machine, like P3.

Thanks
Hamish

Whats wrong with using a 3ware SATA hardware RAID controller and a dozen 400 GB IBM/Hitachi SATA drives. I have no problems using IBM hard drives. People has no problems using 3ware controllers in Linux.

You probably want to use two controllers set as RAID 5 and then use software RAID for RAID 1. This will increase reduntacy and increase reading performance.

An 80386 can handle 1 Mbit any day. People still think that to speed up internet speed is to speed up the processor which is wrong. You can use a dual P3 866 MHz. It should not cost you too much at this time.

Backing up with a 128 kilobyte per second connection (1 Mbit) is going to take days, weeks, months. I suggest increasing the bandwidth to something more managable like 1280 kilobyte per second (10 Mbit) or 2560 kilobyte per second (20 Mbit).

Hey

thanks for all your help. I really appreciate it.

Hamish

I think the answer depends quite a bit on the application that will be running on the server, as well as the amount of traffic (both users and data transfer) it will be getting. If it is a high traffic site, where data redundancy and failover capability is critical, I likewise would recommend SCSI with RAID. For low usage sites, I'd still make the same recommendation, although it would be a judgment call as to whether or not the added cost would be justified. For low activity sites, perhaps such as those that are primarily designed to serve as a backup machine with fairly low amounts of file exchanges, you probably could get away with plain ATA disks, and simply make regular backups.

Regardless of what you do, I would not skimp on RAM. If you will doing a fair number of data transfers, my bet would be that you'd be more likely to be capped by RAM than by CPU.

As for disk space, I think that the key factor is data volatility. If the number and size of your files will be relatively stable, it's easier to evaluate how much storage you likely would need (Rule of thumb: once a drive is using about 75-80% of its capacity, you need more space) Alternatively, if you have very volatile data, and will have significant day by day swings between using only a fraction of your total space and using almost all of it, then realistically you need to purchase a lot more storage, since your needs will vary so much.

That's just my 2 cents; good luck with it either way -- J.W.

Hey

thanks for that. Do you think that ECC ram is critial in a fairly small server, or would some like kingston non ECC be fine?
Hamish

Disclaimer: I am very biased in favor of Kingston.

That being said, in my experience Kingston memory is the only RAM I would consider purchasing, and I would have full confidence in any of their products.

This is not to say that other manufacturers are bad, but only that I think Kingston is excellent. -- J.W.

For servers, you should use ECC memory. It helps make the system more reliable and stable during uptime.

I wished that I used ECC memory instead of non-ECC for my desktop systems (Athlon and P4). My 386 system has never had problems with programs like my faster system because the obsolete system has parity memory or ECC memory.