Re: Offsite volumes

2003-12-05 Thread Tom Kauffman
The entry is deleted from the TSM database, effectively removing it from the off-site volume. This is yet another reason why you need to send copies of the TSM database offsite as well -- because the file *will* still exist on the off-site database backup as well as being physicall present on the

Re: Offsite volumes

2003-12-05 Thread Richard Sims
>What happens to data on offsite volumes when the time has come to expire the >data from TSM? Does TSM delete the entry from the database even though the >offsite volume is unavailable, thus rendering the file on the offsite volume >as unrecoverable even though the file still exists on the offsite

Re: Offsite Volumes

2003-03-11 Thread Nicholas Cassimatis
You can see this if you're running "delete volhist type=dbbackup todate=-X", and X is less than the value for "DB Backup Series Expiration Days" in the output of "query drmstat". What is happening is the dbbackup tapes are being removed from the TSM server inventory before the tapes they are store

Re: Offsite Volumes

2003-03-10 Thread Steve Harris
One common cause for this is that you are running delete volhist on your db backups rather than letting DRM handle it (or with a shorter retention than DRM does). TSM then forgets about the DB backup tapes that are offsite. HTH Steve Harris AIX and TSM Admin Queensland Health, Brisbane Austral

Re: Offsite Volumes

2003-03-10 Thread Peter Pijpelink - P.L.C.S. BV Storage Consultants
Hello Marcel, Please take a look here and select Media Manager, http://www-3.ibm.com/software/tivoli/products/tivoliready/storage.html greetings Peter At 23:23 10-3-2003 +0100, Marcel J.E. Mol wrote: We see the same thing. Last week we took all ofsite tapes for a disaster test and found 18 out of

Re: Offsite Volumes

2003-03-10 Thread Mahesh Tailor
David, thanks for the email. See my responses below. (Using caps to differentiate answers not to shout.) Mahesh Mahesh Tailor WAN/NetView/TSM Administrator Carilion Health System Voice: 540-224-3929 Fax: 540-224-3954 >>> [EMAIL PROTECTED] 03/10/03 17:14 PM >>> Yes, I have seen this and there are

Re: Offsite Volumes

2003-03-10 Thread Muthyam Reddy
** High Priority ** we too facing same problem and recently we did manual volume inventory, recoverd 300tapes. please provide if anyone got solution. thanks /mani >>> "Marcel J.E. Mol" <[EMAIL PROTECTED]> 03/10/03 05:23PM >>> We see the same thing. Last week we took all ofsite tapes for a disas

Re: Offsite Volumes

2003-03-10 Thread Marcel J.E. Mol
We see the same thing. Last week we took all ofsite tapes for a disaster test and found 18 out of 50 were not listed in q drme. I cannot guarantee that the tape operators did not make mistakes and we will double check in the coming weeks but it sure sound as a lot of lost tapes. I suspect that it

Re: Offsite Volumes

2003-03-10 Thread Mahesh Tailor
Yes, these volumes are also counted (via q volh type=dbb). Mahesh Mahesh Tailor WAN/NetView/TSM Administrator Carilion Health System Voice: 540-224-3929 Fax: 540-224-3954 >>> [EMAIL PROTECTED] 03/10/03 16:51 PM >>> Do you include the database tapes in reporting and bringing back? -Original M

Re: Offsite Volumes

2003-03-10 Thread David Longo
Yes, I have seen this and there are a number of reasons that can cause this. 1. Are you using DRM to expire the DB tape? You should be, if not that can be a cause. 2. How detailed are your operations people and your tape return procedure? Example: if ops is using the "Move DRM " command to re

Re: Offsite Volumes

2003-03-10 Thread Davidson, Becky
Do you include the database tapes in reporting and bringing back? -Original Message- From: Mahesh Tailor [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 3:18 PM To: [EMAIL PROTECTED] Subject: Offsite Volumes Hello! TSM 5.1.6.2 on AIX 4.3.3.10 I am running DRM and I am seeing lar

Re: offsite volumes

2001-10-01 Thread Mark Stapleton
On Thu, 27 Sep 2001 11:01:12 +0200, it was written: >in the process of moving backup volumes offsite volume U11108 was >successfully moved to VAULT >09/27/01 10:24:22 ANR6683I MOVE DRMEDIA: Volume U11108 was moved from > > NOTMOUNTABLE state to VAULT. > >however the recla

Re: Offsite volumes going to scratch

2000-10-02 Thread Joe Faracchio
pending to empty means they are not read/write pending to scratch means they are read/write when the reuse delay expires regardless of its length (or shortness). ... joe.f. Joseph A Faracchio, Systems Programmer, UC Berkeley On Sat, 12 Aug 2000, Leo Humar wrote: > Have you checked that th

Re: Offsite volumes going to scratch

2000-08-12 Thread Leo Humar
Have you checked that the reuse delay for this storagepool is set to the number of days? Leo Humar LCS Pty Ltd [EMAIL PROTECTED] No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced. -Original Message- From: Ray Baughman

Re: Offsite volumes going to scratch

2000-08-09 Thread Joel Fuhrman
On my AIX TSM 3.7.3.0 server a volume becomes EMPTY. Maybe because I set "ACCESS=OFFSITE" and "LOCATION=" for the offsite volume. When returned and ACCESS is changed to READWRITE, the volume goes from EMPTY to SCRATCH. On Wed, 9 Aug 2000, Ray Baughman wrote: > Hello All, > > I have recently upg