Hi Del!
Your statement "Customer always have the option of not installing a fix
release, and waiting for the next PTF or release of that Data Protection
client" may be true in most cases, but not when new platform support is
added. You don't have the option to wait for a new release because you
can
We have always run IBM drives, and have never 'planned' for extra drives
to allow for drive failure. I have just upgraded from 10 to 16 drives in
the library, but that's a capacity and D/R issue. So far, I've had *one*
LTO-2 drive fail such that it needed replacement in just under two years
of use.
Hi,
If you really want TSM to read the tape
you can try to restore the data to a
different location.
Regards,
Alexander
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]
> On Behalf Of Norita binti Hassan
> Sent: Tuesday, August 08, 2006 10:20 AM
> To: AD
On Aug 8, 2006, at 4:19 AM, Norita binti Hassan wrote:
I need to know how to verify the backup content. Currently, I'm
using the 'q
content' command.
What I want to do here is I need to verify it by reading the backup
tape to
know the backup content rather than using
The query command. It's the
Hi all,
I need to know how to verify the backup content. Currently, I'm using the 'q
content' command.
What I want to do here is I need to verify it by reading the backup tape to
know the backup content rather than using
The query command. It's the user requirement to make sure the existing of
dat
Norita,
Instead "query" command, try to use "audit volume"
Wira
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: Tuesday, August 08, 2006 8:12 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] How to verify backup content??
On
If you backup your data from a primary tape stgpool to a copy stgpool you can
be sure that the data on the primary tape stgpool can be read.
To verify that all tape data can be read you simply have to check if all primary
tape data is on a copy stgpool.
So a combination of query content (to know th
This is an old, well-known bug. I saw this fairly often in 5.1.6.5.
Restart the server and they'll all go away, to Scratch status where they
belong. Fixed, I believe, in 5.3.something. DELETE VOL works OK as a
workaround, but is only necessary if you run short supply on scratch
tapes before it is c
Where Reclamation was in progress, IBM Technote 1190174 applies.
Richard Sims
On Aug 8, 2006, at 10:38 AM, Roger Deschner wrote:
This is an old, well-known bug. I saw this fairly often in 5.1.6.5.
Restart the server and they'll all go away, to Scratch status where
they
belong. Fixed, I beli
We have around 400 windows servers and our clients get error 12's on
a regular basis. The issue is that Tivoli error 12's
are generic error that they seem to use as a catch all for a number of
errors. So I am checking our backups on a regular basis.
We have the Tivoli for windows 5.3.2 client. I
At 09:00 AM 8/8/2006, Kauffman, Tom wrote:
The biggest item to remember about LTO is that these are streaming tape
drives; if your system can not provide the data fast enough to keep the
tape in motion they have to stop, back up, and come up to speed again.
They aren't designed for that -- the 3
TSM 5.2.2
AIX 5.2
Hello Everyone!
I am getting the following errors in my dsierror.log file:
08/08/06 10:54:27 Management class '.../*' named on include/exclude line 0
does not exist.
Here is the actual include statement:
include /back_txprod:backups-3.0/.../* database
I know this a syntax
>> On Tue, 8 Aug 2006 11:37:37 -0400, Paul Zarnowski <[EMAIL PROTECTED]> said:
> This was more true with LTO-1 than with -2 or -3. The later
> generation drives can vary their speed to try to match the data rate,
> thus avoiding some backhitching. But Tom is correct that the motors
> in the 3592
HP LTO1 drives also had the ability to vary their speed. This was
one of the main reasons we purchase HP LTO1 drives instead of
IBM LTO1 a long time ago.
3592 drives also have this ability.
Rick
Paul Zarnowski
<[EMAIL PROTECTED]
>
It looks like it thinks there's a space between /back_txprod:backups-3.0/
and .../* ; If there is a space there, remove it, or try putting the file
specification in quotes.
Robben Leaf
Enterprise Storage Backup and Retention
651-962-2698
[EMAIL PROTECTED]
"Laura Lantz"
Hello All,
If I wanted to move files from one volume to another volume in the
same Storage Pool, Is there anyway to predict/preview how long a Move
Data command process will take? There is no selection choice using the
5.2
Admin Gui, And I didn't see any preview option examples using the
command
You won't get that sentiment from me.
As I have said in the past, my experience with LTO2 and 3583 library is
that they are [EMAIL PROTECTED]&* garbage. Even IBM stated that LTO was never
designed to handle the load we are putting through them (we have over 400
tapes in use per 3583-L72 library).
Hi,
I have a couple of tape volumes which do not show up via the q vol
command but I cannot check them in as scratch tapes (see below).
Any ideas?
tsm: ANLTSM>q vol 915ACFL2
ANR2034E QUERY VOLUME: No match found using this criteria.
ANS8001I Return code 11.
tsm: ANLTSM>checkin libvol lb1.1.0.2
Paul,
They may be database backups or exports oe backupsets
Select * from volhistory where volume_name='BLAH' may prove informative.
Steve
Steven Harris
AIX and TSM Admin
Brisbane Australia
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Paul Du
Hello Paul,
Check out the query volhist command, or look at the volhist file, and see if
the tape is listed as one of the special use tapes. That is it was used as a
database backup tape, or export tape, or
len
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTE
Yes it is a DB backup.
Thanks
Paul
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
> Behalf Of Len Boyle
> Sent: Wednesday, 9 August 2006 10:01 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] Missing tape volumes
>
> Hello Paul,
>
> Check out the q
>> On Tue, 8 Aug 2006 16:45:05 -0400, Zoltan Forray/AC/VCU <[EMAIL PROTECTED]>
>> said:
> This is why we are moving to 3592-E05 drives. Besides the capacity
> difference, the reliability we have seen with 3590 drives (even those that
> are 10+ years old), far exceeds the LTO's. We mount 1000's
We currently have our primary and copy storage pools for SQL backups as
follows:
Primary Copy
SQLDB_DISKPOOL SQLDB_COPYPOOL
SQLDB_TAPEPOOL SQLDB_COPYPOOL
SQLMETA_DISKPOOLSQLMETA_COPYPOOL
Is there any problem if I change the SQLMETA_DISKPOO
23 matches
Mail list logo