1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

Tapeless configuration

Discussion in 'TSM Installation, Upgrade and Configuration' started by stephrf, Dec 10, 2012.

  1. stephrf

    stephrf New Member

    Joined:
    Nov 20, 2003
    Messages:
    28
    Likes Received:
    0
    Occupation:
    Storage Administrator
    Location:
    UK
    Hi all, I'm planning to implement a TSM instance with no tape library in the short term probably medium term.

    My Primary and copy pools will be on NetApp 3270 FC disk. Which can do its own sort of defragmentation - so I'm told - I'm new to NetApp.

    Does anyone have any thoughts regarding performance on how to set up the pools: devt=disk or devt=file?

    Does anyone have any recommendations on maximum size of volume to present to the TSM instance and I guess also on the instance itself?

    Is anyone running a similar configuration?

    thanks rob
     
  2.  
  3. moon-buddy

    moon-buddy Moderator

    Joined:
    Aug 24, 2005
    Messages:
    6,073
    Likes Received:
    269
    Occupation:
    Electronics Engineer, Security Professional
    Location:
    Somewhere in the US
    I am running esssentially a tapeless setup but instead of NepApp (although we have NetApp as our primary storage devices), I am using Data Domain.

    This is definitely a way to go these days if one needs a tapeless environment. Setup devclass=file with volume sizes of 100 GB or 200 GB depending on the sizes of your files to backup. I suggest the lower value to start with and observe performance.

    Enable replication on the NetApp devices so you have your copy pool without ever setting one up. This would mean backup to NetApp directly and replicate data to another NetApp device for the copy pool.
     
  4. stephrf

    stephrf New Member

    Joined:
    Nov 20, 2003
    Messages:
    28
    Likes Received:
    0
    Occupation:
    Storage Administrator
    Location:
    UK
    Ed, unfortunately we aren't purchasing the replication software for the NetApp so will have to have TSM managing the copy pool aspect.

    Is there a reason why you prefer devclass=file over disk? It seems Ontap can reclaim free space on disk.
    thanks Rob
     
  5. moon-buddy

    moon-buddy Moderator

    Joined:
    Aug 24, 2005
    Messages:
    6,073
    Likes Received:
    269
    Occupation:
    Electronics Engineer, Security Professional
    Location:
    Somewhere in the US
    Either way does not matter. You can use disk or file for the devclass. Reclamation will work either way. I prefer devclass=file so I can control reclamation.
     
  6. stephrf

    stephrf New Member

    Joined:
    Nov 20, 2003
    Messages:
    28
    Likes Received:
    0
    Occupation:
    Storage Administrator
    Location:
    UK
    Ed, thanks. Just realised our Ontap reclaim might not work. I've only ever reclaimed file/tape pools in TSM - can you reclaim disk pools?
     
  7. moon-buddy

    moon-buddy Moderator

    Joined:
    Aug 24, 2005
    Messages:
    6,073
    Likes Received:
    269
    Occupation:
    Electronics Engineer, Security Professional
    Location:
    Somewhere in the US
    Not disk pools - reclaim is for sequential and as such will work for devlcass=file.
     
  8. chad_small

    chad_small Moderator

    Joined:
    Dec 17, 2002
    Messages:
    2,197
    Likes Received:
    43
    Occupation:
    AIX/SAN/TSM
    Location:
    Gilbert, AZ
    The recommended setup is to use the FILE devclass. I'd rather have one lost 100GB file than a whole storage pool become corrupted due to write issues depending on how you setup your diskpools.
     
  9. stephrf

    stephrf New Member

    Joined:
    Nov 20, 2003
    Messages:
    28
    Likes Received:
    0
    Occupation:
    Storage Administrator
    Location:
    UK
    Chad, Ed, thanks for your input. Rob
     

Share This Page