[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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
***




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]