*whacks evil Stratics hosting and backup services with deco tool*

[Skylark SP]

OUR SCREENIES!!!!!

OUR ARCHIVES!!!!!

OUR FAQS & TUTORIALS!!!!!



Go data recovery peeps!

-Skylark

 

[Duncan McDermott]

Do you think there is a chance any of that will return or is it lost forever?

 

[T_Amon_from_work]

Do you think there is a chance any of that will return or is it lost forever?

Oh gad ... I hope so. There was a lot of stuff in my corner of the world I have no idea of how to rebuild. My experience with recovery of somewhat near the magnitude I **think** Stratics is having to do is typically been in the 85-90% good recovery.

If the databases were SQL structures of ANY kind (MySQL, etc) and decent transaction logging and backups, it's possible that only the last few hours of posts before crash are unrecoverable.

BIG HUGE DISCLAIMER: I am not in the know on this situation, but hazarding a guess from 30+ years IT and as DBA on more than 19 databases in the nuclear power plant IT arena.

EDIT IN: Look in UHall ... Basara responds about this fiasco. I drop the percentages maybe 20 points unless the surface scan recovery method being used works better than I've experienced. <mumbles some obscenities and stalks off>

 

[Skylark SP]

Do you think there is a chance any of that will return or is it lost forever?

I am sure they will recover some, the problem is it sounds like they are relying solely on data forensics recovery type techniques right now. What the recovery specialists have to do is scan each segment of the disk drives and attempt to recover the data that was there BEFORE the data center wiped the drives and tried to overwrite them with a new OS. Probably they will find gaps or areas that are garbled with pieces of newer data that was written or areas that were truly deleted. The forums and probably most of the associated data was stored in SQL database so I suppose they will be looking for file headers of that type. An SQL database is transaction driven so the logs of what happened is as important as the actual data bits. Every change to the database is a "transaction" and is logged - it keeps a copy of the original piece of data and notes the change that was made. There is usually some fuss factor in restoring a database in getting the state to match the latest transaction log state (or picking a cutoff point).

Data forensics isn't my thing, usually I am only concerned with making sure a drive is rendered unable for anyone to use such recovery tools on it when I retire a machine. I am also not an SQL admin.

I guess it will depend on how thoroughly the existing disks were wiped and how much was overwritten subsequently before the discovered their error.

I'd be tempted to go with restoring an old backup if the loss was that extensive, and be resigned to a complete loss of everything after the backup point or painstakingly restoring the data gap using a current transaction log if it existed, but an "old" backup to me would be a week or so, and it sounds like their "backup" service went far longer than that without doing their job.

*edit*

BIG HUGE DISCLAIMER: I am not in the know on this situation, but hazarding a guess from 30+ years IT and as DBA on more than 19 databases in the nuclear power plant IT arena.

That is what happens when I leave post composition windows open forever, T'Amon. But now I can entertain myself speculating on the early time line of your career and the Three Mile Island accident.

-Skylark

 

[T_Amon_from_work]

... *edit*
That is what happens when I leave post composition windows open forever, T'Amon. But now I can entertain myself speculating on the early time line of your career and the Three Mile Island accident.

-Skylark

I got the hands crossed AFTER TMI. They did that all themselves. What happened with us is that we were setting up a training classroom with 30 systems that were to point to a test instance of a very important database for maintaining Union qualcards.

With him reading and me verifying, we blilthely went and setup INI files that pointed ... you guessed it ... right to production. One stinking character difference in the instance names and we get a severe put-down! <shrug>

After that we insured that any test or development instance was plainly established with the word TEST or DEV somewhere in the naming. AND we alter the procedure to note the need to doublecheck things any-d***-way!

My plant is in the Top 10 in the US fleet for performance. After getting that title once and then losing due to a management decision that cost us the ranking, we regained it 5 months ago.

We've also set an industry record for manhours without a lost-time accident per OSHA rules ... 15.4 million before we had one. Prior record was 10.6 mill. We are just a bit better than the average nuke ...

 

[Basara]

We might get lucky on this -

After all, if someone can recover 99% of the data from a drive that survived from the COLUMBIA breakup (look for an AP story dated on this past Friday), this type of data recovery should be a relative walk in the park.

Last I heard from the Stratics heads, the data recovery had the potential to be near 100%, but it was more a matter of getting everything reassociated where it needs to be (i.e. the logs). It may well be that they got into the format but not completed it yet (let alone installing anything else) when someone got hold of them and said "You guys ever gonna pull that unit? It's still showing in service. And, since you're down there already, check on the Stratics server - they're reporting an outage." Oops....


That, and possibly trying to move ahead with the switchover to VBB permanently, earlier than planned (Stratics has been alpha-testing VBB for several months with such a plan, but conversion wouldn'thave happened until at least the last part of the year, without this issue occurring).