ADSM-L

Re: [ADSM-L] NDMP Restore Problems with Mirapoint Filer

2008-06-18 15:33:49
Subject: Re: [ADSM-L] NDMP Restore Problems with Mirapoint Filer
From: "Clark, Robert A" <Robert.Clark AT PROVIDENCE DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 18 Jun 2008 12:32:11 -0700
I don't have any specific advise about Mirapoint, but I would be looking
for something like a syslog or ndmpd.log file (on the Mirapoint).

In most ndmp troubleshooting, most of the most useful information tends
to come from the datamover's side. Sometimes it is necessary to tell
ndmpd or its equivalent to do verbose logging as well.

[RC]

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Sergio Fuentes
Sent: Wednesday, June 18, 2008 8:02 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] NDMP Restore Problems with Mirapoint Filer

We're currently at an standstill on how to resolve our NDMP restore
problems with TSM and Mirapoint and I'm reaching out to this list to see
if anyone else has experienced this problem or any potential solutions:

We have a series of Mirapoint mail filers running MOS 3.8.5-GA.
We're trying to configure 3-way NDMP backups and restores via TSM (NDMP
version
4) on our TSM server version 5.4.2 on AIX 5.3.

We've managed to get backups to work with both TOC enabled and disabled.
The problem occurs on restore of NDMP data (both full image dumps and
incremental via TOC).  Within 5 minutes of initiating a restore "restore
node mirapoint /usr/store" the restore fails out without any real
discriptive message:

06/17/08   17:11:08      ANR1065I Restore of NAS node MIRAPOINT, file
system
                           /usr/store, started as process 50 by
administrator
                           SFUENTES.  A full image for this file system
will be
                           restored to destination /usr/store.
(SESSION: 40,
                           PROCESS: 50)
06/17/08   17:11:27      ANR1104E NAS Restore process 50 terminated -
NDMP session
                           errors encountered. (SESSION: 40, PROCESS:
50)

06/17/08   17:11:27      ANR0985I Process 50 for RESTORE NAS (FULL)
running in the
                           BACKGROUND completed with completion state
FAILURE at
                           17:11:27. (SESSION: 40, PROCESS: 50)

In this case it was a matter of seconds, but the same message repeats
for any restore.  There are no successful mounts of any tape drives, the
/usr/store volume is knocked offline and MOS has to be rebooted.

The kicker is that back in April when we were ready to deploy for
production, somehow all the planets aligned correctly and the restores
actually worked for
2-3 weeks.  Once we moved the TSM instance to a production server
however, the restores failed once again and they've failed ever since.
Even moving back to the dev server, restores still fail.

We've done TSM server traces, low-level network traces and we're about
ready to get Mirapoint support on the line.  An IBM call has been opened
but has not yielded much.  I've checked on relevant APARS and though
some are similar to our problem, the APARS have been fixed on 5.4.2 but
the restore problem still occurs.

More info for those interested:

q datamover:
                Data Mover Name: MIRAPOINT
                Data Mover Type: NAS
                     IP Address: hidden
             TCP/IP Port Number: 10000
                      User Name: hidden
       Storage Pool Data Format: NDMP Dump
                        On-Line: Yes
Last Update by (administrator): hidden
          Last Update Date/Time: 06/12/08   12:53:15


on MOS:
ndmp get version
4
ndmp get dma
default
ndmp get preferredip
(same as IP Address above)

Is there something I'm overlooking? Any ideas?

Thanks!

Sergio
U. of Maryland


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not the addressee you are hereby notified that you 
may not use, copy, disclose, or distribute to anyone the message or any 
information contained in the message. If you have received this message in 
error, please immediately advise the sender by reply email and delete this 
message.

<Prev in Thread] Current Thread [Next in Thread>