Totally agree. A search of the archives here will show me messing around with a Thecus 5200 and giving up because I couldn't get SSH working on it. This is a bad, bad NAS.
We've been running an Intel Entry Storage System ss4000-E for months now. We had a problem for a while where disk #1 would drop out of the RAID every few days. Thankfully, we had the extended warranty at MemEx and just kept swapping them out until it stopped. Very odd problem. It supported SSH out of the box with the factory firmware, but a subsequent firmware upgrade disabled it. However, a ticket to Intel support solved that and they told us how to re-enable it. We also tried an IOMEGA NAS (can't remember the model) but immediately gave up on it because it didn't have SSH either. J Evan Cortens wrote: > While on the topic of NAS devices, I just wanted to mention that I've > been spending quite a bit of quality time with the Thecus N5200, and I > heartily _don't_ recommend it. > > It's basically an expensive Celeron with 256 MB of ram (and a 64 MB > flash drive for system files), running a custom (and strangely > configured) Linux setup ( 2.6.13 kernel, again custom) with a pile of > hacked together PHP scripts and bash scripts for administration. Out of > the box it doesn't support SSH (but a third party module can be > installed, if your firmware is newer than 1.00.06). It uses software > RAID (on a 5 (+1 external) port Marvell SATA card) and supports all the > levels you want (JBOD, Raid 0, 1, 5, 10). I didn't buy this device, but > if it had been my decision, I'd simply have built a linux box, but then > again, I'm a halfway competent linux admin, whereas the people who have > to deal with the NAS device on a day-to-day basis aren't. > > Anyway, NAS good, Thecus bad! > > Hope this saves someone from a lot of trouble... > > Evan > > On 6/27/07, *Jon* < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > 1. What solution are you using presently? > > We use an Rsnapshot-variant which is basically a wrapper script for > rsync. > > I've modded it so that we retain 30 days worth of backups for any given > site on a NAS mounted into a VM offsite (we backup 22 servers from > various locations around Calgary to one central backup server). > Recovery > at the moment is done by us - we have no customer UI for that as we're > not ready to deal with the authentication issues yet. However, it's as > simple as firing up two fish or <insert favourite graphical scp client > here> windows and copying data from the backup to the original machine. > Same with searching - use whatever file search capabilities you have on > your backup machine to search the backups. > > I've done some very shallow digging into the rates for offsite backup > and I think somewhere in the $3 per GB range is fair. I have no idea why > someone would chage $3900 for 15GB of data unless they're storing it on > the space shuttle. > > There are many RAID-capable NASes on the market for under $1000 not > including drives. You can get into the remote backup market for under > $2K if you felt so inclined :) > > 2. What led you to chose that solution? > a. Pros > > Only the cost of hardware. We're cheap. > > b. Cons > > We live in fear of our NAS completely dying and totally losing > everyone's backups. > > 3. Is your solution a commercial vendor or one you host yourself? > > Already answered. > > 4. What are the costs involved? > a. initial setup > > About $1800 for the NAS and drives. We already had the computer and ISP > connection. > > b. monthly charges > > Nothing outside of our ISP fees (make sure you have a big enough > bandwidth allowance!) > > c. "incident" fees ie: I need help finding x. > > Since we haven't built the self-serve restore part yet, I handle 100% of > these issues. I have restored about 10 files so far this year, but I > have no idea what we charge for that. > > 5. Is there an OSS solution that is reliable, robust and easily > administered by the end user? > > Reliable and robust, yes. Administered by and end user? Don't know. I > find Rsnapshot very easy to use, but 'end user' leaves a wide range of > skill levels in doubt. I doubt the 'typical' end user could reconfigure > the backup system but once it's running they would never really have > to. > As for restore, if you conquer the authentication issue so that users > could only see their own backed up data, something simple like a WinSCP > icon on the desktop to log them into the remote server should suffice > for restore. > > 6. Any other comments/suggestions? > > Experience has taught me three things about this 'remote backup to NAS' > thing: > > 1. Get a NAS that supports SSH (many don't). If you ever have to get > your data off the NAS, you'll want to rsync or tar it off in order to > preserve the file permissions so you can continue to increment against > it. If you can't shell into it, your options for getting data that is > can be incremented against are limited (actually, I don't think they > exist). > > 2. Upload from the source is the biggest problem. If your clients have > 50+ GB of data on a residential ISP connection, you're going to be > backing them up for weeks the first time. > > 3. Incrementally backed up data in Linux almost always means hard links. > Hard links cannot survive across file systems so if you're backing up to > a network mounted NAS, you won't be able to copy the links. What this > means in the practical sense is that 50GB of data that comprises 30 days > of backups on the NAS will be ~1500GB if copied across to another > system. In most cases this copy is impractical and therefore once you > have backups on a NAS, they're there to stay. No real caveat here, just > food for thought. > > While the technology is well understood and widely available, it's the > security and redundancy of the system that costs the money. While > anyone > can set up a system like we have, the end customer is really paying for > the peace of mind that their backups are safe and sound in a secured > environment, etc rather than a beat up old PIII in someone's basement. > Any solution needs to be RAIDed at a minimum and many companies also > mirror the backups (backing up the backups, if you will). I think once > there is a copy of the data offsite, making more copies of it is > starting to go down the road of diminishing returns, but many will > disagree with me. > > > J > > Dave Watkins wrote: > > Hi All, > > > > I've just started looking at various offsite backup solutions for > a couple > > of clients and have been surprised at the pricing offered by some > providers. > > One provider quoted me $3900.00 to store 15GB of data initially > with all the > > backups and services I'd like. > > > > Basically, I have 2 clients in particular that would like to have the > > following: > > > > 1. store data off site > > 2. incremental backup nightly > > 3. ability to search/recover previous versions of a specific file > > 4. data recovery tool should be relatively simple > > 5. cost effective > > > > > > My questions are: > > > > 1. What solution are you using presently? > > > > 2. What led you to chose that solution? > > a. Pros > > > > b. Cons > > > > 3. Is your solution a commercial vendor or one you host yourself? > > > > 4. What are the costs involved? > > a. initial setup > > > > b. monthly charges > > > > c. "incident" fees ie: I need help finding x. > > > > d. other > > > > 5. Is there an OSS solution that is reliable, robust and easily > administered > > by the end user? > > > > 6. Any other comments/suggestions? > > > > > > For those of you that would like to remain anonymous you can > always email me > > directly if you like. I'll compile the results and post them to > the list in > > a generic format with all the identifiers removed if there is a > desire for > > such a compilation. > > > > Thanks, > > > > Dave Watkins > > > > > > > > > > _______________________________________________ > > clug-talk mailing list > > [email protected] <mailto:[email protected]> > > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > > Mailing List Guidelines (http://clug.ca/ml_guidelines.php > <http://clug.ca/ml_guidelines.php>) > > **Please remove these lines when replying > > > > -- > Key fingerprint: BDE0 DE52 B8C0 0CDF 7653 E5A2 D861 7877 0D3B 813E > http://www.jonwatson.ca > > "Trying to learn to hack on a DOS or Windows machine or under MacOS is > like trying to learn to dance while wearing a body cast" - ESR > > _______________________________________________ > clug-talk mailing list > [email protected] <mailto:[email protected]> > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying > > > > ------------------------------------------------------------------------ > > _______________________________________________ > clug-talk mailing list > [email protected] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying -- Key fingerprint: BDE0 DE52 B8C0 0CDF 7653 E5A2 D861 7877 0D3B 813E http://www.jonwatson.ca "Trying to learn to hack on a DOS or Windows machine or under MacOS is like trying to learn to dance while wearing a body cast" - ESR _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
