Backup Central

Hi TSMers,

I have some questions about Collocation Groups Reclamation and restore.

First, my environment I have a Tape STGpool with 3 Collocation Groups and 10 nodes per Group.

1.- When one volume is reclaimed in this pool. How TSM does the reclamation? moving files from one node from Volume to Scratch one or TSM moves all nodes in the CG at the same time without distinction ?

2.- When TSM restores files from these tapes. Does it restore all files in a sequential way ?. I mean TSM is reading the tape from the beginning and if it finds files to belong to this TSM Client from different directories it restores independently of the directory which this files belong or TSM server prepares a list of file and it is looking one per one in the tape... or Which is the procedure ?

3.- In case of migration, if we don't have CG TSM migrates files per node. What happens if we have CG ?

4.- In case we have a lanfree backup with 4 parallel sessions , is CG suitable for this TSM Clients ?

5.- Last question, in order to restore the client node. Are there differences between these procedure and multiplexing competitors ones ? ...

Thanks,

Fran

Francisco Molero writes:
[...] I have some questions about Collocation Groups Reclamation and restore.

First, my environment I have a Tape STGpool with 3 Collocation Groups and 10 nodes per Group.

1.- When one volume is reclaimed in this pool. How TSM does the reclamation?
moving files from one node from Volume to Scratch one or TSM moves
all nodes in the CG at the same time without distinction ?

I've always understood the activity log message
"ANR1176I Moving data for collocation set <m> of <n> ..."
to relate to the number of passes done over the source tape.
I have not seen these numbers grow since we introduced
group collocation on a rather large scale ...

2.- When TSM restores files from these tapes. Does it restore all files in a sequential way ?.
I mean TSM is reading the tape from the beginning and if it finds files to belong
to this TSM Client from different directories it restores independently of the directory
which this files belong or TSM server prepares a list of file
and it is looking one per one in the tape... or Which is the procedure ?

(Nothing to do with collocation groups, IMHO) TSM first prepares a list of tapes,
then processes each tape once (and of course, sequentially). Same with EXPORT NODE, MOVE NODEDATA, etc.

3.- In case of migration, if we don't have CG TSM migrates files per node.
What happens if we have CG ?

Once a tape has been mounted for a collocation group's data, all nodes in that group are migrated.
At least when the source pool is of type DISK, I'd guess that files will still be ordered by filespace and node,
just like they are by filespace in the case of collocation by node.

4.- In case we have a lanfree backup with 4 parallel sessions , is CG suitable for this TSM Clients ?
5.- Last question, in order to restore the client node. Are there differences
between these procedure and multiplexing competitors ones ? ...
[...]

Can't contribute to these two questions.

Best regards,

Wolfgang J. Moeller <moeller < at > gwdg.de>

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > vm.marist.edu] On Behalf Of Wolfgang J Moeller
Sent: Friday, March 12, 2010 8:51 AM
To: ADSM-L < at > vm.marist.edu
Subject: Re: [ADSM-L] Collocation Groups Reclamation and Restore

Francisco Molero writes:
[...] I have some questions about Collocation Groups Reclamation and restore.

First, my environment I have a Tape STGpool with 3 Collocation Groups and 10 nodes per Group.


3.- In case of migration, if we don't have CG TSM migrates files per node.
What happens if we have CG ?

Once a tape has been mounted for a collocation group's data, all nodes in that group are migrated.
At least when the source pool is of type DISK, I'd guess that files will still be ordered by filespace and node,
just like they are by filespace in the case of collocation by node.

Not always. I often find volumes with a few inches used belong to a client belonging to a CG residing on another volume. It certainly looks as if files ready for migration find the desired volume in use by another member of the CG, so they go to scratch.

As for reclamation, this morning I removed a client. 2 of its volumes popped to the top of the list of reclamation candidates (2 reclamation processes). One went to the expected collector. The second went to scratch.


Fred Johanson
TSM Administrator
University of Chicago

773-702-8464

Fred Johanson writes:
Once a tape has been mounted for a collocation group's data,
all nodes in that group are migrated.
At least when the source pool is of type DISK, I'd guess
that files will still be ordered by filespace and node,
just like they are by filespace in the case of collocation by node.

Not always. I often find volumes with a few inches used belong to a client
belonging to a CG residing on another volume. It certainly looks as if
files ready for migration find the desired volume in use by another member
of the CG, so they go to scratch.

As for reclamation, this morning I removed a client. 2 of its volumes
popped to the top of the list of reclamation candidates (2 reclamation processes).
One went to the expected collector. The second went to scratch.

OK, I meant _normally_ (that is to say, when I'm watching).

Rarely, I believe the same thing to happen here (we regularly run
two migration processes in parallel). TSM Server 5.5.2.1, btw.

I do manually clear out a few "duplicate filling" volumes per week & server,
but then there are several more possible reasons, among them routine changes
to collocation groups (new nodes getting backed up w/o being assigned a group,
nodes removed from a group when they get too large).

Occasionally I do see a filling volume with a large amount of data on it
not being written to for a couple of days, while new data menawhile goes
to a less occupied volume - in violation of the rule that the "fullest" tape
was chosen first. Just another very-low-priority TSM bug, I'd guess ...

Lately, I also discovered "phantom volumes":
Filling, not appearing in any node's Q NODEDATA, no contents according to
Q CONTENTS; but invariably MOVE DATA would find & move around some 2..3 files
totalling a few Mbytes.
Likely you have to REMOVE NODE more often than the average TSM operator,
in order to see such things. [You'd also better(?) have some tool
in addition to TSM SELECT in order to spot all of this weirdness. ;-]

Best regards,

Wolfgang J. Moeller <moeller < at > gwdg.de>

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

Laura Lantz is no longer with OBI. Please send email to the following
address and/or remove her from your distribution list. This mailbox
will be closing effective March 18. Thank you.

Laura's email address is: laurakev13 < at > yahoo.com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Wolfgang J Moeller
Sent: Monday, March 15, 2010 6:07 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: Collocation Groups Reclamation and Restore

Fred Johanson writes:
Once a tape has been mounted for a collocation group's data,
all nodes in that group are migrated.
At least when the source pool is of type DISK, I'd guess
that files will still be ordered by filespace and node,
just like they are by filespace in the case of collocation by node.

Not always. I often find volumes with a few inches used belong to a
client
belonging to a CG residing on another volume. It certainly looks as
if
files ready for migration find the desired volume in use by another
member
of the CG, so they go to scratch.

As for reclamation, this morning I removed a client. 2 of its volumes
popped to the top of the list of reclamation candidates (2 reclamation
processes).
One went to the expected collector. The second went to scratch.

OK, I meant _normally_ (that is to say, when I'm watching).

Rarely, I believe the same thing to happen here (we regularly run
two migration processes in parallel). TSM Server 5.5.2.1, btw.

I do manually clear out a few "duplicate filling" volumes per week &
server,
but then there are several more possible reasons, among them routine
changes
to collocation groups (new nodes getting backed up w/o being assigned a
group,
nodes removed from a group when they get too large).

Occasionally I do see a filling volume with a large amount of data on it
not being written to for a couple of days, while new data menawhile goes
to a less occupied volume - in violation of the rule that the "fullest"
tape
was chosen first. Just another very-low-priority TSM bug, I'd guess ...

Lately, I also discovered "phantom volumes":
Filling, not appearing in any node's Q NODEDATA, no contents according
to
Q CONTENTS; but invariably MOVE DATA would find & move around some 2..3
files
totalling a few Mbytes.
Likely you have to REMOVE NODE more often than the average TSM operator,
in order to see such things. [You'd also better(?) have some tool
in addition to TSM SELECT in order to spot all of this weirdness. ;-]

Best regards,

Wolfgang J. Moeller <moeller < at > gwdg.de>

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

--
Warm regards,
Michael Green


On Tue, Mar 9, 2010 at 9:01 PM, Francisco Molero <fmolero < at > yahoo.com> wrote:



2.- When TSM restores files from these tapes. Does it restore all files in
a sequential way ?. I mean TSM is reading the tape from the beginning and if
it finds files to belong to this TSM Client from different directories it
restores independently of the directory which this files belong or TSM
server prepares a list of file and it is looking one per one in the tape...
or Which is the procedure ?


In terms of restore order TSM uses opportunistic approach. It doesn't tries
to restore in alphabetical order for example. The restore thread will read
all the relevant files from a particular tape regardless of their
alphabetical order or backup dates. Then move to next tape. The goal is to
minimize the amount of tape mounts.

Hello Colleagues,

I have found all answer to my questions. And from my point of view are very interesting and I would like to share with all TSMpeople.

1.- When one volume is reclaimed in this pool ( Pool with CG). How TSM does the reclamation? moving files from one node from Volume to Scratch one or TSM moves all nodes in the CG at the same time without distinction ?

---- it moves it from all nodes

2.- When TSM restores files from these tapes. Does it restore all files in a sequential way ?. I mean TSM is reading the tape from the beginning and if it finds files to belong to this TSM Client from different directories it restores independently of the directory which this files belong or TSM server prepares a list of file and it is looking one per one in the tape... or Which is the procedure ?

----- it restores sequentially - so that it minimizes the tape movement.

3.- In case of migration, if we don't have CG TSM migrates files per node. What happens if we have CG, it is per node or per CG ?

---- per CG

4.- In case we have a lanfree backup with 4 parallel sessions , is CG suitable for this TSM Clients ?
---- sure, the better question is do they have enough data being written to keep the tapes streaming, versus the advantages of writing to disk.

5.- Last question, in order to restore the client node. Are there differences between these procedure and multiplexing competitors ones ? ...

--- yes. for multiplexing, they have to rebuild each individual file. THis causes lots of tape positioning, and additional process to rebuild the files. Multiplexing has a very large NEGATIVE impact on restore times.

Regards,

Fran





----- Mensaje original ----
De: Wolfgang J Moeller <moeller < at > GWDG.DE>
Para: ADSM-L < at > VM.MARIST.EDU
Enviado: mar,16 marzo, 2010 00:07
Asunto: Re: Collocation Groups Reclamation and Restore

Fred Johanson writes:
Once a tape has been mounted for a collocation group's data,
all nodes in that group are migrated.
At least when the source pool is of type DISK, I'd guess
that files will still be ordered by filespace and node,
just like they are by filespace in the case of collocation by node.

Not always. I often find volumes with a few inches used belong to a client
belonging to a CG residing on another volume. It certainly looks as if
files ready for migration find the desired volume in use by another member
of the CG, so they go to scratch.

As for reclamation, this morning I removed a client. 2 of its volumes
popped to the top of the list of reclamation candidates (2 reclamation processes).
One went to the expected collector. The second went to scratch.

OK, I meant _normally_ (that is to say, when I'm watching).

Rarely, I believe the same thing to happen here (we regularly run
two migration processes in parallel). TSM Server 5.5.2.1, btw.

I do manually clear out a few "duplicate filling" volumes per week & server,
but then there are several more possible reasons, among them routine changes
to collocation groups (new nodes getting backed up w/o being assigned a group,
nodes removed from a group when they get too large).

Occasionally I do see a filling volume with a large amount of data on it
not being written to for a couple of days, while new data menawhile goes
to a less occupied volume - in violation of the rule that the "fullest" tape
was chosen first. Just another very-low-priority TSM bug, I'd guess ...

Lately, I also discovered "phantom volumes":
Filling, not appearing in any node's Q NODEDATA, no contents according to
Q CONTENTS; but invariably MOVE DATA would find & move around some 2..3 files
totalling a few Mbytes.
Likely you have to REMOVE NODE more often than the average TSM operator,
in order to see such things. [You'd also better(?) have some tool
in addition to TSM SELECT in order to spot all of this weirdness. ;-]

Best regards,

Wolfgang J. Moeller <moeller < at > gwdg.de>

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany