(using small voice) I guess it's not "lots." 124,858,663 files, 131 TB
occupancy, 90 GB database, ~100 clients.
Jim
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L@VM.MARIST.ED
WOW, the 342 Million files is what is killing you but it still seems like
an excessive amount of time. You mentioned Saturday as when it starts. You
are running expiration daily aren't you? You should be able to run
expiration and reclamation to completion each day or you need to look at
another in
Hardware mirroring and application mirroring serve slightly different
purposes. TSM mirroring saved our bacon once, the hardware mirrors did
not.
Andy Huebner
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Howard Coles
Sent: Wednesday, August 20,
Define LOTS?
My specs are:
194GB DB
206TB Occupancy
342,194,690 files
"Schneider, Jim" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager"
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L@VM.MARIST.EDU
cc
Subject
Re: [ADSM-L] DB Mirroring - Poll and question
We need 4-6 hours for 90GB DB, ~100 clients. The servers have LOTS of
files.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] DB Mirroring - Poll a
-Bjørn Nachtwey wrote: -
>I'm sorry, but I'm not sure how to describe the problem with a few
>words, so I'll tell what was done and what happend:
>
>user A uses an old PC running Windows98 (call it PC-A) and a
>TSM-Client (with nodename PC-AA).
>user B uses a newer PC running WindowsXP (ca
48 hours sounds like an awfully looong time to me.
On my busiest Linux server (90gb DB, ~100 clients) expiration completes in
20-30 minutes.
-Original Message-
From: Zoltan Forray/AC/VCU <[EMAIL PROTECTED]>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L]
As the saying goes "In a perfect world...".
I agree on not running client backups during expiration and that is how it
starts out (beginning at 8am Saturdays), but invariably runs into the next
backup cycle.
These machines have 8GB RAM and are dedicated to TSM. Quad 3Ghz
processors. RH Linu
IF you have your db on hardware mirrored disks then creating a mirrored
DB will not help you.
However, some general guides are to have multiple, smaller db volumes,
as this allows more concurrent processes to run against the db.
Also DO NOT run client backups while expire is running, it slows
eve
Mirrored DB and log volumes. Parallel write is on.
Andy Huebner
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Wednesday, August 20, 2008 11:15 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] DB Mirroring - Poll and questio
I am curious how many folks use TSM to mirror their databases? Do you
use "parallel write"?
As I experiment with my new server (see previous email about testing
expiration), I wonder if the DB mirroring and parallel writing on my
production servers is causing such a large difference in EXPIRE IN
On Aug 20, 2008, at 11:30 AM, Davis, Adrian wrote:
I'm trying the 5.4 client under Solaris (5.10 Generic_127111-10) and
I'm
getting the following error...
ld.so.1: dsmc: fatal: libCrun.so.1: version `SUNW_1.5' not found
(required by file /opt/tivoli/tsm/client/ba/bin/dsmc)
ld.so.1: dsmc: fatal:
I'm trying the 5.4 client under Solaris (5.10 Generic_127111-10) and I'm
getting the following error...
ld.so.1: dsmc: fatal: libCrun.so.1: version `SUNW_1.5' not found
(required by file /opt/tivoli/tsm/client/ba/bin/dsmc)
ld.so.1: dsmc: fatal: libCrun.so.1: open failed: No such file or
directory
One additional item on this, having done a few times.
A slight "gotcha". When you run the "preview" to see what
tapes to bring onsite, then you bring them back. You do the
"restore" and then sometimes find out that you still need another
tape or two.
Why? You have been running reclamation on
Dear all,
I'm sorry, but I'm not sure how to describe the problem with a few
words, so I'll tell what was done and what happend:
user A uses an old PC running Windows98 (call it PC-A) and a TSM-Client
(with nodename PC-AA).
user B uses a newer PC running WindowsXP (call it PC-B) and a TSM-Client
You can't run a move drm on a tape marked vault. You just have to Check
it in as Steve and I have said and then update it. DRM will take care
of the vault status from there.
I would think your offsite tape vendor has a way of contacting them, via
web or phone and telling them to bring back addit
Thanks for the confirmation Shawn. This is the first time there has
been a need to recall offsite tapes, and I assumed it would be a
function of "move drmedia". I know... Never assume.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Shawn Drew
Sent
Correct, recalling specific offsite tapes for a restore would not be done
with "move drmedia"
Move drmedia follows a normal "lifecycle". Recalling a tape for a restore
is an interrupt in that cycle, so it needs to be handled manually by using
"upd vol $VOL acc=readonly". Running this command puts
Thanks for the replies Howard and Steve.
I guess I am looking for a confirmation that recalling specific offsite
copypool tapes is not handled by using "move drmedia" commands. It
won't let me "move drmedia volnnn wherestate=vault
tostate=vaultretrieve", or "move drmedia volnnn
tostate=courierr
Have you try any DR product such TBMR?
In that case will you get back ACLs and OS exact how it looks from the backup
and you can do a Point-in-Time restore and no extra backups need to be done.
Best Regards / Med Vänlig Hälsning
Christian Svensson
Products Specialist
Cristie Nordic AB
Visit Addr
20 matches
Mail list logo
