I believe this is the general recommended sequence in most contexts where
the initial incrementals are directed to disk to be later migrated to tape.
That covers most sites.
For those sites with VTLs the situation changes. You are not migrating from
primary storage pools, disk based, to copy p
TSM has their "wheel of life" with the recommended operational procedure:
http://www.redbooks.ibm.com/redbooks/SG245416/wwhelp/wwhimpl/common/html/wwhelp.htm?context=SG245416&file=21-02.htm
Thanks,
Ron
Ron Welsh
Systems Administrator
Systems & Technology
Open Solutions In
Is there really recomended sequence every TSM Environment should follow?
Or does it depend on your Individual environmental needs?
Tim
Larry Clark wrote:
1- backups nodes
2- backup primary disk pools to tape (copypool)
3- migrate primary disk pool to tape
4- backup primary tape pool to tape
Well done !
> -Message d'origine-
> De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De
> la part de Larry Clark
> Envoyé : mardi 2 octobre 2007 13:03
> À : ADSM-L@VM.MARIST.EDU
> Objet : Re: [ADSM-L] Migration question
>
> 1- backups nodes
> 2- backup primary disk pools to tape (
1- backups nodes
2- backup primary disk pools to tape (copypool)
3- migrate primary disk pool to tape
4- backup primary tape pool to tape (copypool) ( this allows picking up
files to copypool not completed in 2 before 3 was triggered)
5- db backup
6- expiration
7- reclaim primary tape pool
8- re
May I suggest a sequence ?
1- backups nodes
2- backup primary disk pools to tape
3- backup primary tape pool to tape
4- migrate primary disk pool
5- db backup
6- expiration
7- reclaim primary tape pool
8- reclaim copy pool
Pierre
> -Message d'origine-
> De : ADSM: Dist Stor Manager [mai
On 02/10/2007, at 2:35 AM, Dollens, Bruce wrote:
I have a question that I feel a little stupid in asking.
What is the difference between migration and backup primary (disk) to
copy (tape)?
Other people have already answered, so I won't bother. :)
I am working on changing my scheduling up an
hi Bruce,
migration *MOVES* your clients' data from a PRIMARY storage pool
to a NEXT PRIMARY storage pool, e.g. from DISK to a primary TAPE pool.
backup stgpool *COPIES* clients' data stored on a PRIMARY pool
to a COPY pool (that has to be SEQUENTIAL, i.e. a tape pool).
after the successful back
And about your sequence list.
- Expiration will trigger the reclamations
- You might want to schedule your backup primary to copy prior to your
migration. Assuming you are backing up to disk, then migrating to tape.
That way, you avoid the overhead of mounts of tapes when you are creating
copypool
Migration moves the data from one primary pool to another. A storage pool
backup is copying the data from a primary storage pool to a copy storage
pool.
Mark Remeta
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Dollens, Bruce
Sent: Monday, Octob
Migration involves moving between primary storage pools.
The conventional situation was ( before VTLs) a site would have a hierarchy
of storage. The clients would back up to disks to permits a large number of
concurrent backups, then those backups to disk would be migrated to tape.
Both are primar
Ralph,
The migration process will pick the node that is currently occupying the
greatest amount of space in the disk pool, and will migrate all of that
node's data (not just the largest individual files belonging to that node)
to tape before it checks again to see if we're below the low migration
Nope !
Migration uses drives based on the smallest number of :
A) max number of migration processes set for stgpool to be migrated
B) number of tape drives in the devclass of the stgpool being
migrated to
C) unique node's data in the stgpool to be migrated
OK, so if you ha
Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To:[EMAIL PROTECTED]
cc:
Subject:Re: Migration question
No, each storage group has a setting that controls the number of migration
processes used during migration. Do a Q STG F=D to show the
setting, and UPD STG
No, each storage group has a setting that controls the number of migration processes
used during migration. Do a Q STG F=D to show the setting, and UPD STG
MIGPR=<#> to change it. For example, to use 3 drives during the migration
of a stgpool named DISKPOOL, enter UPD STG DISKPOOL MIGPR=3.
Roy,
You don't have to do the backup of the diskpool first, but why wouldn't you?
That is what you should do every day anyway. If all the data in diskpool
has already been backed up to your copypool in your daily processing, it
will only take a few seconds and you'll have piece of mind when you
Hi,
I think IBM wants you to have at least 2 copies of backups on tape media.
So, I would also recommend that.
Regards,
Burak
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
07.05.2002 16:13
Please respond to ADSM-L
I would say NO, that would cause you problems. When you restart the server
it will expect the files to still be in the disc pool if you skip item #2.
In this case you would have to do a restore stgpool to make the server
happy. You will not be saving any time by skipping item #2 and most likely,
i
Thanks but that willl not work here. I have mount retention set at 1 minute.
When I inherited the system, mount retention was set at 1 HOUR and with
collocation and lots of nodes *SM had almost all 24 tape drives tied up
preventing other batch processes and HSM from getting any drives! It's
behavi
EMAIL PROTECTED]
Subject: Re: Migration question
Thank you, and all the others who have responded. I inherited *SM and those
who set it up before me were under the impression that it WOULD back the
data up twice. I believed otherwise but I gave them the benefit of the doubt
and asked. Again, thank you
ECTED]; [EMAIL PROTECTED]
+ Subject: Re: Migration question
+
+
+ From: [EMAIL PROTECTED]
+ To: [EMAIL PROTECTED]
+ Date: Fri, 17 Aug 2001 13:31:08 -0400
+ Subject: Re: Migration question
+
+ 'Course TSM is smart!
+
+ We do what you describe every night - saves a lot of tape mounts,
+ especially
+
Yes, it is smart enough that it won't backup the data twice. It keeps
track of all that stuff.
David Longo
>>> [EMAIL PROTECTED] 08/17/01 12:58PM >>>
My concern is this. I do not want to back up the data TWICE from the disk
pool to the offsite pool. (Once from disk to offsite pool and again fro
'Course TSM is smart!
We do what you describe every night - saves a lot of tape mounts, especially
since our onsitetape is collocated:
backup stgpool diskpool offsitecopypool
migrate to onsitetape
backup stgpool onsitetape offsitecopypool
BACKUP STGPOOL is always INCREMENTAL - TSM checks the D
23 matches
Mail list logo
