[clug-talk] Offsite Backup Solutions - What are you doing?

Wed Jun 27 09:54:52 PDT 2007

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 <me at jonwatson.ca> 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
> > clug-talk at clug.ca
> > 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
> clug-talk at clug.ca
> http://clug.ca/mailman/listinfo/clug-talk_clug.ca
> Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
> **Please remove these lines when replying
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://clug.ca/pipermail/clug-talk_clug.ca/attachments/20070627/0930626f/attachment.html 