Hi, With 5.3 ITSM server, look at group by node also. This will reduce the # of tapes use per node without creating the need for extra stg pools. For crital systems create their one colloc group for less critical system create small colloc groups and all the other system can be put into one colloc group.
I haven't seen a large restore on a wintel file server system where the problem wasn't at the backup client most of the restore time. Starting up the restore could hammer the ITSM server for a time, but after the restore starts to sent large amounts of data (thus many files), all restore sessions went into sent-wait. Regards, Karel -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Lipp Sent: maandag 27 augustus 2007 23:40 To: ADSM-L@VM.MARIST.EDU Subject: Re: Looking for suggestions to speed up restore for a Windows server How about periodic Image backups of the file server volumes? Couple that with daily traditional TSM backups and perhaps you have something that works out better at the DR site. The problem is as you described it: lots of files to create. Did you observe that you were pecking through tapes, or was the bottleneck at the file create level on the Windows box? Or could you really tell? Even if you create another pool for the directory data (which is easy to implement) you would still have that stuff on many different tapes. What about a completely new storage pool hierarchy for that one client? And then aggressively reclaim the DR pool to keep the number of tapes at a very small number. I'd really like to know where the bottleneck really was. If it's file create time on the client itself, speeding up other things won't help. If that's the case, then I like the image backup notion periodically. Even if you did this once/month, the number of files that you would restore would be fairly small compared to the overall file server. And the TSM client does this for you automagically so the restore isn't hard. And this also brings up the fact that a restore of this nature in the a non DR situation probably isn't much better! Thanks, Kelly Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kauffman, Tom Sent: Monday, August 27, 2007 12:40 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Looking for suggestions to speed up restore for a Windows server We had our fall D/R hotsite test last week and all went well -- except for the recovery of our primary Windows 2003 file sharing system. It just takes WAY too long. Part of the problem is the sheer number of files/directories per drive -- I'm working with the Intel/Windows admin group to try some changes when we swap this system out in November. Part of the problem is that the directory structure is scattered over a mass of other backups. I'm looking for suggestions on this. The system is co-located by drive, but only for five of the nine logical drives on the system. I may have to bite the bullet and run all nine logical drives through co-location. Is there any way to force the directory structure for a given drive to the same management class/storage pool as the data? I'm thinking I may have finally come up with a use for a second domain, with the default management class being the one that does co-location by drive. If I go this route -- how do I migrate all of the current data? Export/Import? How do I clean up the off-site copies? Delete volume/backup storage pool? I'm on TSM Server 5.3.2.0, with a 5.3 (not sure of exact level) client. TIA Tom Kauffman NIBCO, Inc CONFIDENTIALITY NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient. If you are not the intended recipient, please do not read, distribute or take action in reliance upon this message. If you have received this in error, please notify us immediately by return email and promptly delete this message and its attachments from your computer system. We do not waive attorney-client or work product privilege by the transmission of this message.
ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
