ADSM-L

Re: [ADSM-L] SNAPDIFF problems

2010-07-30 12:00:38
Subject: Re: [ADSM-L] SNAPDIFF problems
From: "Sheppard, Sam" <SSheppard AT SDDPC DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 Jul 2010 09:00:24 -0700
Yeah; that was one of the many problems we have run into in getting this to 
work. The workaround for that one was to specify:

TESTFLAG SNAPDIFFNAMEFILTEROFF

Not this current problem.
Thanks
Sam Sheppard
San Diego Data Processing Corp.
(858)-581-9668

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Strand, Neil B.
Sent: Friday, July 30, 2010 7:01 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] SNAPDIFF problems

Sam,
   There may be a problem with the language set on the NetApp volumes.
We had a similar problem when we implemented snapdiff 2 years ago but I
cannot recall the exact fix.  Review the attached link for further info.

http://communities.netapp.com/thread/8392?tstart=0


Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Sheppard, Sam
Sent: Thursday, July 29, 2010 5:15 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] SNAPDIFF problems

Don't think that's us as our idletimeout is already set to 3600 and the
backup always fails after 10-15 minutes.
I suspect it's a Netapp problem.

Thanks
Sam Sheppard
San Diego Data Processing Corp.
(858)-581-9668

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Cameron Hanover
Sent: Thursday, July 29, 2010 1:50 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] SNAPDIFF problems

We were having snapdiff backups show up with Failed 8 under 'q events'
until we upped idletimeout to 60 minutes.  We didn't test thoroughly,
but I believe snapdiffs were showing failed when the command session
idled out when non-snapdiff backups wouldn't show as such.

-
Cameron Hanover
chanover AT umich DOT edu

"Our integrity sells for so little, but it is all we really have. It is
the very last inch of us, but within that inch, we are free."
--Valerie (V for Vendetta)

On Jul 29, 2010, at 4:29 PM, Sheppard, Sam wrote:

> After several stops and starts, I finally managed to get the SNAPDIFF
feature to work on our 6.1.3.4 server.  Client is Win 2003 server 64 bit
6.2.0.1. We have been backing up a large Windows file and print store
with 5 or 6 servers and having problems with volumes that were too large
and with too many files.  These are being migrated to CIFS on Netapp.
The first of these was moved a little over a week ago and was backing up
fine using the SNAPDIFF feature until Monday night's backup. This backup
failed with:
>
> ANR0480W Session 503377 for node DPCRCFPUT01 (WinNT) terminated  -
connection with client severed. (SESSION: 503377)
>
> This has been failing ever since; gets the error, restarts then gets
the error again after about 10 minutes or so until the window expires.
>
> This fails consistently with both the scheduled backup and with the
command line when the -SNAPDIFF option is specified.  Remove the
SNAPDIFF and everything consistently works fine, although it takes a bit
longer.
>
> Any ideas out there?
>
> Thanks
> Sam Sheppard
> San Diego Data Processing Corp.
> (858)-581-9668
>
>

IMPORTANT:  E-mail sent through the Internet is not secure. Legg Mason 
therefore recommends that you do not send any confidential or sensitive 
information to us via electronic mail, including social security numbers, 
account numbers, or personal identification numbers. Delivery, and or timely 
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends 
that you do not send time sensitive 
or action-oriented messages to us via electronic mail.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.

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