[gpfsug-discuss] Lost disks

[RICHARD RUPP]

If you are under IBM support, leverage IBM for help. A third party utility
has the possibility of making it worse.



From:	John Hearns <john.hearns at asml.com>
To:	gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:	07/27/2017 06:40 AM
Subject:	Re: [gpfsug-discuss] Lost disks
Sent by:	gpfsug-discuss-bounces at spectrumscale.org



Mark,
  I once rescued a system which had the disk partition on the OS disks
deleted. (This was a system with a device mapper RAID pair of OS disks).
Download a copy of sysrescue  http://www.system-rescue-cd.org/ and create a
bootable USB stick (or network boot).
When you boot the system in sysrescue it has a utility to scan disks which
will identify existing partitions, even if the partition table has been
erased.
I can’t say if this will do anything with the disks in your system, but
this is certainly worth a try if you suspect that the data is all still on
disk.


From: gpfsug-discuss-bounces at spectrumscale.org [
mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Mark Bush
Sent: Wednesday, July 26, 2017 8:19 PM
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] Lost disks

What is this manual header reconstruction you speak of?   That doesn’t
sound trivial at all.

From: Oesterlin, Robert [mailto:Robert.Oesterlin at nuance.com]
Sent: Wednesday, July 26, 2017 12:46 PM
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] Lost disks

One way this could possible happen would be a system is being installed
(I’m assuming this is Linux) and the FC adapter is active; then the OS
install will see disks and wipe out the NSD descriptor on those disks.
(Which is why the NSD V2 format was invented, to prevent this from
happening) If you don’t lose all of the descriptors, it’s sometimes
possible to manually re-construct the missing header information - I’m
assuming since you opened a PMR, IBM has looked at this. This is a scenario
I’ve had to recover from - twice. Back-end array issue seems unlikely to
me, I’d keep looking at the systems with access to those LUNs and see what
commands/operations could have been run.

Bob Oesterlin
Sr Principal Storage Engineer, Nuance



From: <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Mark Bush <
Mark.Bush at siriuscom.com>
Reply-To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date: Wednesday, July 26, 2017 at 12:29 PM
To: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>
Subject: [EXTERNAL] [gpfsug-discuss] Lost disks

I have a client has had an issue where all of the nsd disks disappeared in
the cluster recently.  Not sure if it’s due to a back end disk issue or if
it’s a reboot that did it.  But in their PMR they were told that all that
data is lost now and that the disk headers didn’t appear as GPFS disk
headers.  How on earth could something like that happen?  Could it be a
backend disk thing?  They are confident that nobody tried to reformat disks
but aren’t 100% sure that something at the disk array couldn’t have caused
this.


This message (including any attachments) is intended only for the use of
the individual or entity to which it is addressed and may contain
information that is non-public, proprietary, privileged, confidential, and
exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any use, dissemination,
distribution, or copying of this communication is strictly prohibited. This
message may be viewed by parties at Sirius Computer Solutions other than
those named in the message header. This message does not contain an
official representation of Sirius Computer Solutions. If you have received
this communication in error, notify Sirius Computer Solutions immediately
and (i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication. Thank you.
Sirius Computer Solutions


-- The information contained in this communication and any attachments is
confidential and may be privileged, and is for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. Unless explicitly stated otherwise in the body of this
communication or the attachment thereto (if any), the information is
provided on an AS-IS basis without any express or implied warranties or
liabilities. To the extent you are relying on this information, you are
doing so at your own risk. If you are not the intended recipient, please
notify the sender immediately by replying to this message and destroy all
copies of this message and any attachments. Neither the sender nor the
company/group of companies he or she represents shall be liable for the
proper and complete transmission of the information contained in this
communication, or for any delay in its receipt.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170727/0370c42b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170727/0370c42b/attachment.gif>