This isn't something to do with the '2GB chunking' issue is it?
Just from your comment of seeing <1>share, <2>share>, <3>share etc.
I saw this rear it's ugly head when we upgraded to 7.4.5.
When I queried this, I was told that we needed to install a patch as although
the backups looked like they have worked we would be unable to recover from
them. Not sure how true that was, we just installed the patch. I'd certainly
make sure that this 2GB chunks thing isn't happening, and if it is, get the
patch for it.
Hope this helps... Allan.
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of PeterPGS
Sent: 18 May 2010 09:51
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Networker 7.4.4 trouble with restore
George Sinclair wrote:
> PeterPGS wrote:
>
> > Yes, and when I change it to date 1 everything looks ok and at date 2 I see
> > empty directories.
> > Maybe because the incremental backup didn't find any changes? But restore
> > should present all files all the time as if a full backup was made.
> > Or am I missing something here?
> >
>
> 1. Is that second date an older date? Is it beyond the browse policy for
> the client? I've seen similar behavior on Unix when I push the browse
> date back beyond what's still in the client's index.
>
Browse policy and retention policy are the same and both on quarter.
During the weekend a full backup is made, starting on Friday evening. From
Monday till Thursday incremental backups are made.
Sofar I don't see any logic on when I can see files or only directories when I
try to restore.
It only happens with Windows clients, not for Sun NAS shares.
Also it used to work correctly. Nothing changed really, only Windows updates
installed so that is why I am thinking of some patch causing this.
George Sinclair wrote:
>
> 2. Try running 'mminfo' on the backup server to determine the actual
> time of the affected save set (down to the seconds) and then try setting
> the browse time on the client to that exact date and time. I think by
> default, NW uses the current date/time, and when you change the date to
> an older value, it either uses the current time or 23:59:59?
>
> Also, obtain the 'nsavetime' value for the affected save set as:
>
> mminfo -s server -q 'savetime>date,name=saveset,client=clientname' -r
> "name,totalsize(4),savetime,nsavetime"
>
> Pick the appropriate nsavetime value from the list and then run:
>
> nsrinfo -s server -t nsavetime client
>
> and see if anything shows up and if so, what is reported. Does the
> command return an error like this????:
>
> scanning client `client' for savetime ...blah-blah-blah ... from the
> backup namespace on server servername
> 0 objects found
>
> If so, it's either beyond the browse time or nothing was backed up on
> that date/time for that saveset.
>
With the mminfo command I see for several shares different lines. One with just
the name of the share, then one with <1>share and then another with <2>share.
The first gives 0kb, the second 2000mb and the third again 0kb.
Checking with nsrinfo I see for the second one several files and when I set the
browse time before the third I see the files also.
So something happens that causes the backup to restart. And sometimes it works
and sometimes it doesn't.
Is there any way to find the reason for the restart?
George Sinclair wrote:
>
> 3. Are you by any chance using different time zones on the server versus
> the Windows client? Make sure the time zone on the Windows client for
> your login session (where you're actually running the recover tool)
> matches the time zone on the server for your login session there (or
> wherever the 'mminfo' command was run). Otherwise, you might be entering
> a time value that is too far ahead or behind.
>
No, the time zones are the same for server and client.
George Sinclair wrote:
>
> 4. Have you turned on any 'skip' directives? If so, you might need to
> specify an exact time, particularly if it's from an earlier time on the
> same day where it was previously not using a 'skip'.
>
> George
>
No, no directives specified.
Best regards,
Peter
+----------------------------------------------------------------------
|This was sent by peter AT pgserve DOT nl via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
