ADSM-L

Re: D2D backup with TSM

2004-06-02 12:55:46
Subject: Re: D2D backup with TSM
From: Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 2 Jun 2004 12:54:29 -0400
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.

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