Grigori,
Regarding the point made below:
>>1) migration is totally controlled by TSM Server and depends on number of
>>nodes and number of migration processes. I am afraid to overlap migration
>>activity and backup/restore operations.<<
I don't know how big your disk pool is but you should be able to completely
migrate data off to the next storage pool by running it outside the backup
window and by upping the migration process parameter in the disk storage pool.
In our environment, we are able to clear our disk storage pool by running
migrations between 7:30AM - 5PM on multiple TSM servers when there are no
backup activities. We go up to 4 migration processes if needed to migrate the
data faster off the disk pool.
BERTAUT TCHUISE
Storage Support Administrator
Legg Mason Technology Services
*410-580-7032
BTchuise AT leggmason DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Grigori Solonovitch
Sent: Wednesday, July 29, 2009 1:37 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Move data from DISK pool to FILE pool
Hello Christian,
Thank you very much for your proposal. I understand that it is much easier to
use migration, but I am still going to use procedure based on data movement
because of:
1) migration is totally controlled by TSM Server and depends on number of
nodes and number of migration processes. I am afraid to overlap migration
activity and backup/restore operations. TSM Server can be overloaded because
both the source and target storage pools are on SAN disks with very high
performance. Data movement is manually controlled and can be done at time with
minimal backup/restore activity (for example, at the weekends);
2) unfortunately there are limitations in disk space. I am not able to
allocate FILE storage pool with the same size as DISK storage pool initially. I
am planning to move raw logical volumes selectively to release SAN data volume
from DISK pool, allocate it to FILE pool and continue process like this till
all data will be moved.
We are converting DISK pools to FILE pools as a preparation to upgrade to TSM
6.1 with de-duplication. We hope to save some disk space in primary storage
pools and increase expiry period for data. Unfortunately, another option based
on IBM VTL hardware with de-duplication is very costly (high available VTL,
upgrade existing old libraries and stop using old SSA disks at Head Office and
Disaster Site is approximately $1,000,000). So we have no choice nowadays.
In addition, I have discussed all disadvantages of using file systems for
primary pools with IBM. According to IBM:
1) using JFS2 file system will reduce risk in general, because it is much
better than old JFS file system;
2) all virtual volumes have to be allocated manually and sequentially to avoid
fragmentation (maxscratch=0);
3) file system utilization have to be kept as close as possible to 100% to
prevent any possibility of fragmentation.
I understand it will be real headache to monitor and control FILE storage pools
in this case, but I have no choise.
Thank you very much for all other comments and proposals for my request.
Kindest regards,
Grigori G. Solonovitch
Senior Technical Architect
Information Technology Bank of Kuwait and Middle East http://www.bkme.com
Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: G.Solonovitch AT bkme
DOT com
Please consider the environment before printing this Email
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Christian Svensson
Sent: Tuesday, July 28, 2009 3:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] SV: Move data from DISK pool to FILE pool
Hi,
If I where you I should like this instead.
1) Rename your old Diskpool
2) Create your File Pool with the same name as the old Diskpool
3) Update your Diskpool with HIGH=0 LOW=0 and NEXT=FILEPOOL (Disable Cache also
if you have any)
4) Wait 2-3 days
5) Delete all Volumes in your DISKPOOL and Delete DISKPOOL
Now will you migrate the data and you can still backup to your new STG POOL
with any issue an no extra work for you.
But why do you wanna move to FILE CLASS? Do you wanna use De-duplication? You
know you will delay your backups and get a lot of fragmentation if you don't
pre-create all Volumes? This has nothing with TSM really, but most of the issue
is the filesystem, TSM need to create the file first before TSM can save any
data to that volume, and that will create a delay.
If TSM creates multiple volumes, then will you get fragmentation.
I normally don't recommend anyone to have FILE CLASS as first storage pool. I
only use that if a customer want to have a VTL but don't have any money to buy
a real VTL.
Best Regards
Christian Svensson
Cell: +46-70-325 1577
E-mail: Christian.Svensson AT cristie DOT se
Skype: cristie.christian.svensson
________________________________________
Från: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] för Grigori
Solonovitch [G.Solonovitch AT BKME DOT COM]
Skickat: den 28 juli 2009 12:35
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: Move data from DISK pool to FILE pool
Dear TSMers,
We have TSM 5.5.1.1 under AIX 5.3.
I need to move data from DISK primary storage pool (raw logical volumes) to
FILE primary storage pool (JFS2 file system).
There are 3 tape copy pools for DISK primary pool.
I am going to use next procedure:
1) create FILE primary storage pool with appropriate size;
2) move data from DISK primary storage pool to FILE pool by "move data <vol>
stg=<FILE> reconstruct=no" (volume by volume);
3) delete DISK primary storage pool;
4) rename FILE storage pool to old DISK pool name.
My expectations:
1) all existing tape copy pools, made for DISK pool, will be still legal
for FILE primary storage pool (no need to make extra backups and it is possible
to restore any data in FILE storage pool);
2) no need to modify any copy groups connected to old DISK pool because of
the same storage pool name;
3) expiry process will continue to work normally;
4) full/incremental backup history will be untouched by data movement.
Am I right?
I will deeply appreciate any comments.
Thank you very much in advance.
Kindest regards,
Grigori G. Solonovitch
Senior Technical Architect
Information Technology Bank of Kuwait and Middle East http://www.bkme.com
Phone: (+965) 2231-2274 Mobile: (+965) 99798073 E-Mail: G.Solonovitch AT bkme
DOT com<mailto:G.Solonovitch AT bkme DOT com>
Please consider the environment before printing this Email
Please consider the environment before printing this Email.
________________________________
"This email message and any attachments transmitted with it may contain
confidential and proprietary information, intended only for the named
recipient(s). If you have received this message in error, or if you are not the
named recipient(s), please delete this email after notifying the sender
immediately. BKME cannot guarantee the integrity of this communication and
accepts no liability for any damage caused by this email or its attachments due
to viruses, any other defects, interception or unauthorized modification. The
information, views, opinions and comments of this message are those of the
individual and not necessarily endorsed by BKME."
IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security numbers,
account numbers, or personal identification numbers. Delivery, and or timely
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends
that you do not send time sensitive
or action-oriented messages to us via electronic mail.
This message is intended for the addressee only and may contain privileged or
confidential information. Unless you are the intended recipient, you may not
use, copy or disclose to anyone any information contained in this message. If
you have received this message in error, please notify the author by replying
to this message and then kindly delete the message. Thank you.
|
