ADSM-L

Re: D2D backup with TSM

2004-06-03 11:00:08
Subject: Re: D2D backup with TSM
From: "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 3 Jun 2004 16:59:18 +0200
Hi Steve!
I totally agree! We are also seriously investigating the option to put our
primary pool on disk. To me, the file device class is no option, because you
still have to reclaim.
In my ideal TSM world I just have to take care of four things:
1) Start a database backup one or two times a day
2) Run expiration once a day
3) Backup the one and only diskpool once a day
4) Use the rest of the day for reclaiming the copypool
Indeed IBM should alter the way data gets written to a diskpool so we can
use it for permanent primary store. I myself will forward this as an
enhancement request to my sales rep.
You also stated: "While they are at it, maybe an online database defrag
utility would come in useful as well...". According to the presentation that
was mentioned here yesterday, IBM is seriously looking into the possibility
to migrate the TSM database to DB2. In that case, we can do online reorgs.
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: Steve Schaub [mailto:Steve.Schaub AT HAWORTH DOT COM]
Sent: Thursday, June 03, 2004 14:53
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D backup with TSM


Very interesting.

It sounds to me like an opportunity for Tivoli to create a white paper
for us TSM admins on "Best Practices in a Disk-Only TSM Environment".
Although I would really prefer that they come up with a solution for the
DISK fragmentation problem so  that I don't have to cludge around with
FILE types.  While they are at it, maybe an online database defrag
utility would come in useful as well...

Steve Schaub
Systems Engineer, Operations & Storage
Haworth, Inc
616-393-1457 (desk)
616-886-8821 (cell)
Steve.Schaub AT Haworth DOT com

-----Original Message-----
From: Richard Rhodes [mailto:rrhodes AT FIRSTENERGYCORP DOT COM]
Sent: Wednesday, June 02, 2004 12:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D backup with TSM


Thanks for all the replies . . . . an interesting discussion.

That is an interesting presentation Tim pointed to.  It answeres lots of
questions.

It's sounding like using only a DISK device pool for d2d backups isn't a
very good idea.  But FILE device pools seem to be limited.

It sounds to me like you want to keep DISK device pool for staging are
just like we do today, providing multiple concurrent access for backups.
Then, migrate the files to  FILE device pool for long term storage.
And, make sure you turn on client compression.  Also, realize that all
the files for the FILE device pool will have to be in one filesystem.
The copy storage pool could be a FILE device pool on another disk
system, or, a tape system if you need to ship them offsite.

Since I have experienced disk subsystem crashes with loss data, I
couldn't ever use just one disk system.  I think I'd have to have
separate disk systems for the primary pools and copy pools (or tape),
and maybe even a third subsystem for the db and staging pools.  Yes,
I've been called paranoid . . . but it comes from experience.


Thanks!

Rick







                      "Rushforth, Tim"
                      <TRushforth@WINNI        To:
ADSM-L AT VM.MARIST DOT EDU
                      PEG.CA>                  cc:
                      Sent by: "ADSM:          Subject:  Re: D2D backup
with TSM
                      Dist Stor
                      Manager"
                      <[email protected]
                      .EDU>


                      06/02/2004 12:23
                      PM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






That can only be done on a sequential access pool.  If you try on a
storagepool of device type disk you will get:

ANR1718E MOVE DATA: Reconstruction of file aggregates is supported only
for movement in which the source and target storage pools are
sequential-access. ANS8001I Return code 3.

-----Original Message-----
From: Steve Schaub [mailto:Steve.Schaub AT HAWORTH DOT COM]
Sent: June 2, 2004 11:03 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D backup with TSM

I was under the impression that performing a "move data xxxxxx
reconstruct=y" would reconstruct the aggregate, thus effectively
performing reclamation on a disk type volume.  Probably not what the TSM
developers intended it for, but it might be just the ticket for those
moving to disk-only infrastructures (and not wanting to use file based
volumes).

Steve Schaub
Systems Engineer, Operations & Storage
Haworth, Inc
616-393-1457 (desk)
616-886-8821 (cell)
Steve.Schaub AT Haworth DOT com

-----Original Message-----
From: Rushforth, Tim [mailto:TRushforth AT WINNIPEG DOT CA]
Sent: Wednesday, June 02, 2004 10:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: D2D backup with TSM


> When would an aggregrate be reclamed when using a DISK device pool?
> Rick


Once again check out
http://ew.share.org/callpapers/attach/Long_Beach_Conference/S5725a.pdf

There is a table that compares Disk Pools (Random Access) to Seq File
Disk pools.  The answer is aggregrate reconstruction is not supported on
disk pools.


**********************************************************************
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**********************************************************************

<Prev in Thread] Current Thread [Next in Thread>