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.

Exporting large backups

Discussion in 'TSM Operation' started by rayslinky, Jul 8, 2010.

  1. rayslinky

    rayslinky New Member

    Joined:
    Mar 30, 2009
    Messages:
    3
    Likes Received:
    0
    Location:
    Boston
    We are in the final stages of migrating from 10 year old hardware running TSM 5.3.6 to new hardware running TSM 5.5.2. To accomplish this, we have been using "export node" to get the data to the new server. This has worked great for making the transition mostly seamless for the users and can be accomplished during the day while no backups are occurring.

    We are now left with four nodes that have very large backup sets (800GB, 900GB, 2TB, and 4.5TB). Unfortunately these are all Oracle TDP backups, with transaction log backups happening every 4 hours. I tested doing an export of the 2TB one and it took 18 hours. I then issued the command again with FROMDate and FROMTime parameters for the past 18 hours worth of data. This resulted in creating additional filespaces for each of the databases (/Database was recreated as /Database1). This doesn't look good, so we didn't cut over.

    Is anyone aware of a way to accomplish this migration, short of suspending the TDP processes during the migration? All data is housed on a Virtual Tape Library (EMC DL4200).
     
  2.  
  3. TonyB

    TonyB Senior Member

    Joined:
    Dec 10, 2009
    Messages:
    384
    Likes Received:
    9
    Location:
    Sydney, Australia
    Did you try using "mergefilespaces=yes" during the import operation?

    T
     
  4. reinaldo

    reinaldo New Member

    Joined:
    Jun 22, 2010
    Messages:
    7
    Likes Received:
    0
    Occupation:
    TSM administrator
    Location:
    Puerto Rico
    Make a full backup of data to directly from the 800Gb node to the old tsm's DISK pool and then you make an export node from old tsm server to the new one.
    The reason for this step because it is faster for the old server to read from the disk to read the cartridge, so the process takes less time.

    Use the export node with "Filedata=allactive merge=yes toserver=newtsmserver"
     
  5. rayslinky

    rayslinky New Member

    Joined:
    Mar 30, 2009
    Messages:
    3
    Likes Received:
    0
    Location:
    Boston
    Thanks

    Thanks guys. I was able to test it today and MERGE=yes solved my problem. I successfully migrated the 2TB node and my DBAs are happy.
     
  6. travelsick

    travelsick New Member

    Joined:
    Oct 27, 2010
    Messages:
    66
    Likes Received:
    3
    With mergedata=yes, did I read that if you already have x amount of data transfered; then after the original node performs another nightly backup, you perform a 2nd export to get the remaining data transfered,
    that the mergedata=yes will be able to merge the data properly and handle all versioning and expiration associated with your backups on the new node?

    Unfortunately, I can't find where I read that about mergedata.
     
  7. rayslinky

    rayslinky New Member

    Joined:
    Mar 30, 2009
    Messages:
    3
    Likes Received:
    0
    Location:
    Boston
    Yes, if you don't specify merge=yes, you wind up with new filespaces, duplicating what already existed from the previous export/import. From "HELP EXPORT NODE":

    Code:
    [B]MERGEfilespaces[/B]
         Specifies whether Tivoli Storage Manager merges client files into
         existing file spaces on the target server (if they exist), or if Tivoli
         Storage Manager generates new file space names. The default is NO.
    
         You can only specify this parameter if you have specified the TOSERVER
         parameter.
    
         [U]Valid values are:[/U]
         [B]Yes[/B]
              Specifies that imported data on the target server is merged with
              the existing file space, if a file space with the same name
              already exists on the target server.
         [B]No[/B]
              Specifies that Tivoli Storage Manager generates a new file space
              name for imported data on the target server if file spaces with
              the same name already exist.
         [U]Note:[/U]
              If an operation is interrupted and re-started, consider selecting
              YES so your data is not imported into a new file space.
    
     
  8. travelsick

    travelsick New Member

    Joined:
    Oct 27, 2010
    Messages:
    66
    Likes Received:
    3
    Thanks! I did read and understand that, it just didn't specifically mention the versioning of backups being part of mergedata. I know I've read it somewhere, just cannot remember where.

    Thanks again.
     
: export, tdp

Share This Page