Re: Hot Backup - Mailing list pgsql-hackers

From cbbrowne@cbbrowne.com
Subject Re: Hot Backup
Date
Msg-id 20021024211214.3D1BEC86F@cbbrowne.com
Whole thread Raw
In response to Hot Backup  ("Sandeep Chadha" <sandeep@newnetco.com>)
List pgsql-hackers
The world rejoiced as andrew@libertyrms.info (Andrew Sullivan) wrote:
> Having undertaken the exercise, I really can say that it is a little
> strange to think about what would happen to data I am in charge of in
> case a fairly large US centre were completely blown off the map.  But
> with a little careful planning, you actually _can_ think about that,
> and provide strong assurances that things won't get lost.  But it
> doesn't pay to call such questions "silly", because they are
> questions that people will demand answers to before they entrust you
> with their millions of dollars of data.  

I was associated with one data center that has the whole
"barbed-wire-fences, 40-foot-underground-bunker, retina-scanning"
thing; they apparently /did/ do analysis based on the site being a
potential target for nuclear attack.

Realistically, two scenarios are much more realistic:
a) The site resides in a significant tornado zone where towns   occasionally get scraped off the map;
b) The site isn't far from a small but busy airport, and they did   consciously consider the possibility of aircraft
crashinginto the   building.  Presumably by accident, not by design; the company owns   quite a number of jet aircraft,
sothat vulnerabilities involving   misuse of aircraft would rapidly "fly" to mind...  (Painfully   and vastly moreso
since9/11, of course :-(.)
 

When doing risk analysis, it is certainly necessary to consider these
sorts of (admittedly paranoid) scenarios.  

It's a bit fun, in a way; you get to look for some pretty odd-ball
situations; the "server room being overrun by Mongol Hordes."  That
particular one isn't too likely, of course :-).
-- 
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.ntlug.org/~cbbrowne/advocacy.html
"I've discovered  that P=NP, but the  proof is too long  to fit within
the confines of this signature..."


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_database datistemplate
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_dump and large files - is this a problem?