Time to update your Disaster Recover documentation/procedures, get management 
to back you up! Nothing like the REAL thing to get some focus on the real issue!
Rebuild and move on.

Sent from my iPhone

On Mar 19, 2012, at 17:07, RPN01 <nix.rob...@mayo.edu> wrote:

> I'm assuming that the disks that were scratched were the ones on the "old"
> side of the migration, and without useful backups, I'd have to say that
> you're probably out of luck at this point. I would have thought that there'd
> have been several points in this process where the system pointed out to the
> Systems Programmer that he was aiming the gun directly at his foot, long
> before he pulled the trigger. ("This device is mounted, do you really want
> to do this?" type messages...) Then again, I can also see how I could
> "trick" the system into doing it, via some ill-advised MW links, so....
> 
> You needed to check your backups before you ever mounted the first disk to
> begin the migration. Always have a verified plan for failure before
> beginning any potentially dangerous project.
> 
> At this point, recreate the system on the new disks and see what people can
> recover / recreate their files and work, and hope for the best. Fire the
> people who told you they were backing up your system. Learn from the
> experience to always test your backups and recovery procedures periodically.
> 
> Sadly, all the cards were stacked against you.
> 
> Having said all this, I managed to write over our zOS DB2 data this last
> summer during a disk migration. (But the zLinux data was all safe and
> protected... :) You really have to check what you're about to do several
> times before actually doing it, and even then, crossing your fingers doesn't
> hurt.
> 
> -- 
> Robert P. Nix          Mayo Foundation        .~.
> RO-OC-1-18             200 First Street SW    /V\
> 507-284-0844           Rochester, MN 55905   /( )\
> -----                                        ^^-^^
> "In theory, theory and practice are the same, but
> in practice, theory and practice are different."
> 
> 
> 
> On 3/19/12 3:26 PM, "Helio Mario Neves Pimentel de Oliveira"
> <h...@engepel.com.br> wrote:
> 
>> Yes 7 disks.
>> I don´t how far the formatting exec went, before the machine hanging.
>> 
>> Sadly to say, but my reality is that the back-up (which was made in a
>> separate x86 machine) was neglected by the people in charge.
>> All this happened during the storage migration SHARK to DS8000.
>> 
>> Yes we built a second Linux. But the LVM / partition were not recognized.
>> Only the disk not managed by the LVM could be mounted.
>> 
>> Helio Mario
>> 
>> -----Mensagem original-----
>> De: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] Em nome de RPN01
>> Enviada em: segunda-feira, 19 de março de 2012 16:40
>> Para: LINUX-390@VM.MARIST.EDU
>> Assunto: Re: Emergency
>> 
>> So, you have seven disks involved. Which disk(s) were formatted?
>> 
>> Key question: Do you have any sort of backups of the disks, and at what
>> level? (File level or device level) How old are they?
>> 
>> How active were (i.e. How much updating was there on) the disks?
>> 
>> Do you have a second Linux image on which you could mount the disks and
>> assess the damage?
> 
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to