NBU Ver: 5.1MP6
Why is it that even after a DSSU flush and no other running jobs, the
file system still shows up as %100 usage from a Linux server?
--
Nate SandersDigital Motorworks
System Administrator (512) 692 - 1038
This message and any attachments are intended only for
What do you mean by DSSU flush? Images that have not been copied to
tape will not purge unless you explicitly expire them. You can use
bpimagelist -L -backupid $image against each image on the DSSU to see
the number of copies. There is a known issue with 5.1 where partial
images are left behind,
On Thu, Jul 1, 2010 at 11:35 AM, Nate Sanders sande...@dmotorworks.comwrote:
NBU Ver: 5.1MP6
Why is it that even after a DSSU flush and no other running jobs, the
file system still shows up as %100 usage from a Linux server?
Several reasons. First, there were lots of bugs in the DSSU code
From the UI on the left is Storage Units. In here we have dssu1,2,3,4.
Right clicking on these and going to Change, then clicking on Disk
Staging Schedule you see Schedule type, which is (*) Frequency and is
set to 4 hours.
So every 4 hours it's supposed to be expiring and copying to tape, no?
So
This is also a two parter because I'm getting errors about DSSU being
full and jobs unable to write to it despite the fact a Flush just ran..
So maybe there are orphaned files in there. Not sure how to verify that
on DSSU.
On 07/01/2010 11:54 AM, Nate Sanders wrote:
From the UI on the left is
Run an ls on the directory where the images are. You should see
something like:
|Image Identifier|C#|F#|Backup Time|.img
Server_1234567890_C1_F1_1234567890.img
Server_1234567890_C1_F2_1234567890.img
Server_1234567890_C1_F3_1234567890.img
Server_1234567890_C1_F4_1234567890.img
Looks like 99% of the disk space was orphaned files. Thank you kind sir!
On 07/01/2010 12:45 PM, Martin, Jonathan wrote:
Run an ls on the directory where the images are. You should see
something like:
|Image Identifier|C#|F#|Backup Time|.img
Server_1234567890_C1_F1_1234567890.img
Hello Geeks,
I am facing issues while running inventory on LSU and also unable to create new
disk pool.
Error: Unable to fetch the data.
Environment:
Here we are using OST( Greenbytes:-GB-4000) for the backups.We have plugin
installed on two servers,Calypso and Knightrider2.
Calypso is used
So the problem looks to be bigger than that. I'm still getting write
failures and I even tried switching to a different physical disk for the
DSSU. Out of 10 jobs, the exact same 4 jobs are failing every time.
On 07/01/2010 01:03 PM, Nate Sanders wrote:
Looks like 99% of the disk space was
Give us the output of the job log.
-Jonathan
-Original Message-
From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Nate
Sanders
Sent: Thursday, July 01, 2010 5:29 PM
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re:
Has the job just gotten so large that it cannot write to disk staging
(700GB) any more? I know some of our Oracle Full jobs go straight to
tape because they are too large. But this is an incremental OS backup..
There is no way it's that large.
Try 1
PROCESS 1278017363 19536 bpdm
PROCESS
I write 1.5TB+ images to DSSUs all the time, so I don't think the images
are too big. I so use a maximum fragment size of 10GB. (10240MB). Do you
have the bptm and/or bpdm log from the media server with the DSSU? (Not
sure if bpdm was around in 5.1?) Is this one DSSU or all of them?
-Jonathan
We used to have same problem.
You need to use nbemmcmd -deletehost to remove it from EMM database. Before
you do that, take the ownership of all media written by a particular media
server, remove it from servers.conf, remove the associated storage units,
make media host override change etc.
Let
13 matches
Mail list logo