On Tue, Sep 1, 2009 at 7:51 PM, Edward M. Corrado<[log in to unmask]> wrote:
> Thus I have to believe them that they did not have a compromised
> server and instead they had a hardware failure. I have no idea why
> they couldn't just restore from backup which would at least gotten
> them back to where they were from the last backup (which presumably
> was at most a week ago, if not someone should have a lot of explaining
> to do to someone).
I didn't want to join this speculation party, but here goes.
It's quite possible that part of the problem here is that the
"significant hardware failure" meant that the replacement was a
completely different architecture (let's say for argument's sakes that
the server that failed was AS/400 and the replacement was Solaris on
an Intel server) because IT policy (or, you know, reality) dictated
that the old hardware would be replaced if it failed.
So then we're not just talking about backing up from tape -- things
need to be compiled -- there are perhaps problems with legacy C
libraries, character sets, *whatever*.
When I was working at Emory, we had a grant funded project that
indexed a handful of collections of SGML EAD files in an app called
iSearch (http://www.etymon.com/tr.html#). When the (admittedly
neglected) VA Linux server it ran on had a major problem it was
insanely non-trivial to get this completely orphaned application
running in a contemporary operating system (in this case, RedHat).
Old versions of iSearch /would not under any circumstances/ compile --
new ones couldn't read the old data. The application was down for --
I don't know -- months, IIRC. Granted, this was nowhere near the
priority of GPO's PURL server -- but you can't stop time to solve
these sorts of Catch-22s, either.
Things happen. Catastrophes generally have the added advantage of
ensuring they don't happen again for a while.