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]> 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]
> 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
_______________________________________________
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
