Veritas-bu

[Veritas-bu] Two restores not allowed to same filesystem?

2007-03-13 17:14:03
Subject: [Veritas-bu] Two restores not allowed to same filesystem?
From: jlightner at water.com (Jeff Lightner)
Date: Tue, 13 Mar 2007 17:14:03 -0400
Thanks but my answer was in the log I attached.  The answer being I need
to read more closely or better yet pay attention when I copy scripts and
edit them.

The server being restored to is atucvd01.   Since I'd set the
FORCE_MEDIA_RESTORE option to that server and the log (not the part I
show here) indicated it had successfully mounted ON atucvd01 I foolishly
expected it was restoring TO atucvd01.   However the log (the part I do
show here) clearly shows it was restoring to atudvd01 and since the
filesystem didn't exist there it created it as a subdirectory of a small
filesystem.   It was this small filesystem on atudvd01 that was filling
up rather than the one I was looking at on atucvd01.  The script I used
had specified atudvd01 rather than atucvd01 as the client and I missed
it on the edit.

As Homer Simpson would say:  D'oh!

-----Original Message-----
From: Justin Piszcz [mailto:jpiszcz at lucidpixels.com] 
Sent: Tuesday, March 13, 2007 3:54 PM
To: Jeff Lightner
Cc: veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Two restores not allowed to same filesystem?

Set VERBOSE = 5 on the client and check the appropriate restoration log 
file, also log the output on the master server, that is strange.

On Tue, 13 Mar 2007, Jeff Lightner wrote:

> Does NetBackup prohibit two restores to the same filesystem at the
same
> time?  (e.g. lock the space for exclusive use somehow?)
>
> Background:
> We were running an alternate path restore of 3 streams.   One of the
> streams failed due to I/O error on read after restoring 10 files.
> Using bpimmedia and bpflist I was able to determine all the files for
> the failed stream and delete from the list the 10 that were
successful.
> I then started a bprestore using that list.
>
> It gave the following log entries after mount and position:
> 15:35:11 (178059.001) INF - Beginning restore from server atucvd01 to
> client atudvd01.
> 15:35:14 (178059.001) /database/proddata01/tx_datam08.dbf
> 15:35:14 (178059.001) Changed /database/proddata01/tx_datam08.dbf to
> /database/conv2data/tx_datam08.dbf
> 15:35:36 (178059.001) Could only write 102912 of 262144 bytes to file
> /database/conv2data/tx_datam08.dbf at file offset 100372992
> 15:35:36 (178059.001) Couldn't write to file
> /database/conv2data/tx_datam08.dbf: No space left on device
> 15:35:36 (178059.001) Removing /database/conv2data/tx_datam08.dbf
>
> The device is /database/conv2data and it was only 25% full at the time
> this message occurred so is NOT out of space.   The file as you can
see
> is not that large.   The only thing I can think is that the original
> restore (still running the other two streams) somehow has locked the
> filesystem so that only it can restore to it.
>
> If that isn't the case is there some other reason I would get such a
no
> space left message on a filesystem that is clearly not full?
>


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