ADSM-L

Re: Backup question - Full and Incremental

2005-11-15 01:08:01
Subject: Re: Backup question - Full and Incremental
From: John Black <sunmansun AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 15 Nov 2005 00:56:50 -0500
Eric,
 If memory serves me right, the TOSTGPOOL parameter is not required.
Therefore, when it is not specified the data is collocated to volumes in the
FROMSTGPOOL.
 See the following excerpt:
  MOVE NODEDATA (Move Data by Node in a Sequential Access Storage
Pool)<http://webdocs.caspur.it/ibm/tsm-5.1.5/mvs/html/reference/anrmrf02.htm#ToC_194>

Use this command to move data located in a sequential-access storage pool.
You can move data for one or more nodes, or a single node with selected
filespaces. The data can be located in either a primary or copy storage
pool. *This command is helpful for reducing the number of volume mounts
during client restore or retrieve operations by consolidating data for a
specific node within a storage pool, or to move data to another storage
pool.* For example, you can use this command for moving data to a
random-access storage pool in preparation for client restore processing.

The MOVE NODEDATA command takes two forms, depending on whether you are
moving data only for selected filespaces. The syntax and parameters for each
form are defined separately.
---MG


On 11/14/05, Jones, Eric J <eric.j.jones AT lmco DOT com> wrote:
>
> Thanks for the answers on the full/incremental backups.
> I did some research on the move node but it looks like you move from one
> pool to different pool(could be very confused). I would like to move
> within the same pool but combine all the backups from a node(20+ tapes)
> to 1 or 2 tapes within the same pool to help with restores. Some of
> the machines have been backed up for years and the data is spread across
> so many tapes. Can the pools be the same (FROMSTGPOOL and TOSTGPOOL)?
> Never used this command before and a little nervous.
>
> Thanks for all the help,
> Eric
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> John Black
> Sent: Monday, November 14, 2005 4:28 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Backup question - Full and Incremental
>
> Eric,
> To organize your data, the following command should do the trick: *move
> nodedata; *when you have a chance, please research. Additionally, yes,
> full
> (selective) backups are seems as files. And as such, the normal copy
> group
> retention periods apply. I hope this information was beneficial
> --MG
>
>
> On 11/14/05, Jones, Eric J <eric.j.jones AT lmco DOT com> wrote:
> >
> > Good Afternoon.
> >
> > I have a question on backups and how if you mix full backups and
> > incremental backups the data is stored.
> >
> > We are running TSM 5.2.2 on all our TSM clients(AIX, SUN, Windows
> 2000,
> > windows 2003), and the server is AIX 5.2 with TSM 5.2.2.
> >
> > We normally just run incremental for all our machines and over the
> years
> > the data gets scattered every where(number of tapes and in some cases
> > 30+) so restores can be very slow. We keep all our data for 90 days so
> > with the incremental backups the files expire after 90 days if the
> file
> > has been backed up(90 day policy/keep up to 90 backups). My question
> is
> > if I want to do a full backup every 120 days just to better organize
> my
> > data on less tapes(current data) does it effect the incremental data
> > that is on tape in any way? Does TSM see the backups including a full
> > backup as files and they expire after a given amount of time?
> >
> > From what I could find that is the case but I do not want to mess up
> > years of data and the users were asking lots of questions on how it
> > might affect them. They would be happy with the possibility of faster
> > restores.
> >
> > Another question came up, is there any way to have TSM organize data
> > already on tape for a specific server so it's on a few tapes instead
> of
> > spread across many tapes? Just seeing if we could better manage our
> > data.
> >
> >
> > Thanks
> >
> > Eric Jones
> >
>