[linux-lvm] Backup costs (was: LVM reimplementationre)
Jesus Manuel NAVARRO LOPEZ
jesus_navarro at promofinarsa.es
Thu Feb 7 04:34:01 UTC 2002
Hi, Petro:
Petro wrote:
> On Thu, Feb 07, 2002 at 10:00:45AM +0100, Jesus Manuel NAVARRO LOPEZ wrote:
[...]
>>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.
>
Fair enough. I *don't* have childrens... but I tend to consider my PFY
like a bastard of my bastardness, does it counts?
>
>>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.
Yes: depends on my needs: If I need to recover any data, having *all*
your backup media in a single place is *BAAAAAAAD* idea (TM). If this
place is the same (or near to) the place where the production data is
stored is simply unadjectivable.
If I don't need to recover data, I can go without any backup at all.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
> Depends on your needs.
>
> 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.
>
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'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
> fine.
>
So, the amount of change by unit time is your key to decide what you
*need* to backup and what you don't?
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.
> It the first case, off site backups don't make sense, so we have 2
> backup hosts (seperated by about 10 feet currently, less in a day or
> two) that get backups on an alternating (daily) basis.
>
They won't make sense deppending on its *cost*, not its change rate.
> Oh, this is in addition to these databases being replicated pairs.
>
This doesn't add nothing to value your backup strategy. Again the value
is the key. You have replicated in pairs, do you? What then in case of
fire on you operations center? I'd bet you'll loose both of your servers.
> Again, your backup strategy depends on your needs, your budget, and
> your risk tolerance.
>
> 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.
>
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"
just burning some CDs from time to time, or no backup at all can be good
enough (but again, even burning some CDs has no sense in case you
want/need your data even if your "PC-room" burns out, if you have your
CDs on the same table the PC is).
>
>>*1: Standard dramatization in place. I *don't* do that (specilly true
>>if my boss is reading this article X^D )
>>
>
> No, but a handful of metal filings are (1) more effective, (2) less
> traceble, and (3) less likely to get your pecker arced off.
Yep. But I don't find it quite as funny
--
SALUD,
Jesús
***
jesus_navarro at promofinarsa.es
***
More information about the linux-lvm
mailing list