[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [linux-lvm] Backup costs (was: LVM reimplementationre)
- From: Jesus Manuel NAVARRO LOPEZ <jesus_navarro promofinarsa es>
- To: linux-lvm sistina com
- Subject: Re: [linux-lvm] Backup costs (was: LVM reimplementationre)
- Date: Thu Feb 7 07:54:02 2002
On Thu, Feb 07, 2002 at 11:34:08AM +0100, Jesus Manuel NAVARRO LOPEZ wrote:
That was intended to be humorous. Urinating on live electrical
On Thu, Feb 07, 2002 at 10:00:45AM +0100, Jesus Manuel NAVARRO LOPEZ wrote:[...]
Fair enough. I *don't* have childrens... but I tend to consider my PFY
like a bastard of my bastardness, does it counts?
Well... let's consider all aspects. I'm a sysadmin the kind of BOFH, so
late in the evening I usually find myself a bit overloaded on beer.
Specially on friday, if I have to stay at work past 5PM I have the
irresistible temptation to go to the closet and piss*1 on the
diskcabbinet. Good way to guarentee you won't have kids.
components tends to be a shocking experience.
Yep. Me too. I neither have childs nor PFY, so it really doesn't matter.
Yes: depends on my needs: If I need to recover any data, having *all*
For a backup policy you *must* take appart the media from the on-line
data to be protected. Having all your backup media in a single place is
*BAAAAAAAD* idea (TM). Depends on your needs.
your backup media in a single place is *BAAAAAAAD* idea (TM). If this
No, when you need to recover stuff, it's a *great* idea to have it
in one place.
Well, but this is not what I said. I purpousely bolded *all*, for
that's the key. It's a great idea have *some* backups at hand and
grouped (if only for the chance of your boss asking you for recovering
that porn... err... that paper he accidentaly deleted). But not *all*
your media. Obviously is not too operative to have all my backup media
in Dallas (I'm in Spain so it's not cost-effective).
When you suffer an environmental calamity, it's a bad idea.
place is the same (or near to) the place where the production data is
stored is simply unadjectivable.
Ever tried to push tens of gigabytes over a WAN?
Ever heared about "Never understimate the bandwith of a wagon full of
Depends on your needs.In case of disaster, if your backup media is in the proximities of your
production database (define "proximities" as needed) you won't be able
to recover table structures. One thing is what I say, and a *completely
different* issue is to decide *what* to backup, and how, not where.
I have one database that changes fast enough that if it's 36 hours
old, we're basically just recovering it for the table structures.
That wasn't my point.
My point was that for some stuff, 36 hour old data is useless, and
Then its *value* past 36 hours is... nihil. You told (implictly) that
your database schema was of some value even if they were more than 36
even a normal tape rotation schedule can put data out of reach for
10 or 12 hours minimum.
Yes, that's *potentially* true.
So, the amount of change by unit time is your key to decide what you
*need* to backup and what you don't?
I've got another one that changes fast enough that it's not worth
backing up. If it's more than 2 hours old, starting from scratch is
Sound *extremly* odd to me. I would say it should be *the value* of the
material (this include the cost to recreate it anew too, obviously), not
its change rate.
Not the necessity of backing up, but the cost. If the data is
changing that fast, it could easily be that by the time it's on
tape, it's out of date and effectively useless.
Again: it's not its change rate but its *value*. The more it values,
the more you can expense to "insure" it (part of your insurance policy
talks about *within a time frame*).
It the first case, off site backups don't make sense, so we have 2They won't make sense deppending on its *cost*, not its change rate.
backup hosts (seperated by about 10 feet currently, less in a day or
two) that get backups on an alternating (daily) basis.
No, it would be a lot cheaper to dump the dbs to tape, and carry the
tapes offsite, but (1) recovery time is almost tripled, and (2)
...and its *value* once recovered will be lower than having no data at
all. Again, *if* you manage to find a method so the value of the
recovered data is higher than the costs of having that method in place,
your job (if that's your job, of course) is point it out and implement it.
And yes, we know the problems with this. It's a calculated risk. We
can't afford geographically seperated facilities right now.
*Value* again. And about it, I recently knew about a multinational
company (so it were not only a one-site company) which main office was
at the twin towers. It would be able to restore from the people death
(though *many* of upper management died) but it didn't from the
Again, your backup strategy depends on your needs, your budget, and
your risk tolerance.
It only deppends on your needs. Your needs can include not surpassing
certain budget amount, but definetly it hasn't nothing to do with "risk
tolerance". "Risk tolerance" is either a winner bet or a misinformation
It doesn't make sense to spend $10k for a backup solution for $20k of
data. It does make sense to spend $10k to backup $100k.
Plainly true... except for the last value: it makes sense to spend $X at
most to backup $Y*p, where p is the probability of loosing that data
(ie. if the probability is 1, so you're certain to loss the data, you
can expend up to $100k to insure it -within the time frame that data
produces $100k revenues).
Of course. Your backup strategy surely deppends... *on the data value*
and only on this. From the very beginning I stated that for "home data"
No, it doesn't. It depend on several things:
(1) Value of data.
Plain data value
(2) Cost of downtime.
Data value too (in terms of lost revenue for the time the data is not
(3) Rate of change. (If your data set is completely worthless after
24 hours, but worth several million for the first hour, offsite
backups don't necessarily make sense etc.)
Data value too (in terms on how the value of data evolutions with time).
And probably some more I haven't thought of.
Probably: and they all will be expresable in terms of data value or will
have no significance at all.
jesus_navarro promofinarsa es
[Date Prev][Date Next] [Thread Prev][Thread Next]