As Richard Sims suggested, "Q Content" can help you figure out what is going on.
To get a better handle on what's actually getting sent off-site in this collocated stgpool, take the list of volsers that are being sent to the vault from today. Do this before reclamation gets started on this stgpool...
For each tape, issue the command "q content <volser> count=1". Since the stgpool is collocated, you will be able to easily identify what node is using each tape. Q content runs fairly quickly when you specify count=1, so if you batch up the commands (maybe as a macro), it should not take too long.
You can redirect the output to a text file, and use that as input to another program for analysis (Excel works pretty well for Q&D sorting and grouping). This will also allow you to verify whether data from any unexpected nodes is sneaking in there.
Good luck,
Ted
At 09:38 AM 10/14/2003 -0400, you wrote:
3590H tapes which hold 60GB uncompressed. I've seen as much as 297GB fit on a tape using the tape drive's compression and compressible data (SQL databases). I'm backing up much less that that per night per server. The largest critical server is only 31GB on average. NONE of them should take up more than one tape per night each. Since the tapes leave daily almost empty they are immediately eligible for reclamation. I would expect that the next day backup storage pool to offsite should go to the tapes that were create during reclamation and not to scratches. As I monitor maintenance processing this seems to be the case. I do not understand why so many tapes should be ejected from the library. It's taking quite some time to eject the tapes each day and an equal amount of time to insert all the onsiteretreive tapes. I'm hoping that someone can point to where I should look. I've verified that the non-critical pool is NOT collocated and that THAT pool is pointed to by the default management class. I have to set up an include statements in the DSM.OPT files to point nodes to the critical (collocated) pool so I'm fairly confident that nodes are not going there that do not belong there.
Take care, Al
Alan Davenport Senior Storage Administrator Selective Insurance Co. of America [EMAIL PROTECTED] (973) 948-1306
-----Original Message----- From: David E Ehresman [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 8:56 AM To: [EMAIL PROTECTED] Subject: Re: Too many DRM tapes leaving 3949 library daily.
How much data are you backing up per node? What size tapes are you writing to?
