Re: [linux-lvm] Backup costs (was: LVM reimplementationre)

[Jesus Manuel NAVARRO LOPEZ <jesus_navarro@promofinarsa.es>]

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@promofinarsa.es
***