Forum Discussion

JHudson's avatar
Level 4
15 years ago

D2D Emulation

This might be more of an HP thing, but I'm thinking it has more to do with Backup Exec.

I have a 4TB D2D server and a 1x8 G2 Autoloader with LTO3 400GB attached to Backup Exec.  The D2D server is emulating the 1x8 G2 Autoloader as well as the tape size.  We do daily differentials on the D2D as well as a weekly full on the D2D.  That weekly full then gets copied off to tape.  A monthly full is done that goes directly to tape.

However, this new D2D server has this fancy new deduplication technology (we are upgrading from an older HP D2D120 unit with only 2TB and no deduplication technology) which is really expanding how much information we can store on the D2D server.  What we are running into now though, is the physical limitations of a 1x8 G2 Autoloader emulation on the D2D server.  With deduplication running, we are finding that we are only filling up half of the physical disk space while all the emulated tapes are filled up within Backup Exec (24 tapes).

So, can I make the D2D server emulate a different size tape (such as 1.6 GB tapes) and have it copy fine to the 400 GB tapes within Backup Exec?  So, if one weekly full backup will take up half of one emulated 1.6 GB tape from the D2D server, will it (Backup Exec) know to separated that one two tapes?  Somewhere along the line, I could have sworn that I read that the two needed to be the same.  In other words, the D2D had to emulate what you had for a physical tape drive in order for the copy job to work correctly.

Can any one impart some knowledge or experience on this issue?
  •  Backup Exec does not copy byte for byte between the devices, it duplicates the data stream from the backup set and the creates new catalog information as it goes. Admittedly the usual different size scenario is a lot of 4GB BKF files being duplicated to say a 200GB tape (so lots of catalogs to one catalog) but it should handle it either way. 

9 Replies

  • Sorry, in my original post in the third paragraph, I was referring to 1600GB tapes or 1.6TB - not 1.6GB.
  • Backup Exec sees the emulation as a certain size (vitual) media - then to change it you would have to reconfigure the device to present larger virtual media - these sorts of settings come from the hardware/vtl/D2D device not from within Backup Exec - so if it is possible you will  need to talk to HP.

    As confirmation, if it was a real tape device - say an LTO4 and you insert a smaller LTO3 tape into the hardware, then it is the hardware itself that detects the difference in the tape technology and tells Backup Exec that the tape is smaller.
  • As far as making the D2D emulate a larger or smaller drive, I understand that.  Those settings are created when creating the library within the D2D server.

    What I'm saying is that to tell the D2D that it has a......say........1.6 TB virtual tape (which is a possibility through the library settings on the D2D server), how will that react with a 400GB tape when it is trying to copy our weekly full from virtual tape to regular physical tape?

    From what I can gather, Backup Exec is creating a FAT table of sorts at the beginning of a tape for faster retrieval.  So, I would imagine everything would start fine.  However, would Backup Exec know to create another table when it went to a new tape?

  •  Does Backup Exec see these 1.6TB Virtual tapes as tapes or as B2D files. 

    Also is it a Backup Exec job that moves that data from the virtual 1.6TB tapes to the real 400GB tapes as a duplication job? or is is something that is being performed by the D2D device.

    If Backup Exec is running a duplicate job then it will write the MTF format to the 400GB tapes and add the data - asking for new tapes as each fills up -  in the same way that if you duplicated a 4GB Backup to Disk File to 400GB tapes. Duplicate jobs copy the backed up data (not the format)  from one media to another irrespective of the size or type of the media.

    BTW Backup Exec writes using the MTF format to tapes and encapsulates the MTF structure inside of BKF files when writing to disk (unless GRT is involved)

  • Sorry for the slow response here.  Backup Exec sees these 1.6TB virtual tapes as tapes (I would assume anyways).  As far as Backup Exec is concerned, it is nothing more than another 1x8 G2 Autoloader with LTO3 tapes.  However, we have never done anything more with the D2D server than emulate our actual 1x8G2 Autoloader with LTO3 tapes.  So, by making the D2D server look like a different setup other than the number of slots I have, I'm not sure how things would react.

    But, yes, it is a Backup Exec job that is moving the data from (currently anyways) a 400 GB tape to the real 400 GB tapes as a duplication job.  The same scenario would be true if I were to enlarge the tapes to 1.6TB.  Backup Exec would be controlling the job from virtual tape to physical tape.

    My only concern is this.  Now, we have a 1:1 ratio of virtual tape to physical tape.  So, when a 400GB virtual tape fills up a real physical tape will fill up.  Then we move on to the next tape.  The table at the front of the tape is what I'm most concerned with.  If I do a full backup, and it fills up 1200GB of a 1600GB tape (virtual tape on the D2D server), then one table has been written at the front of the tape for catalog purposes.  When I copy that off to tape, it will fill up three 400 GB tapes and the table will obviously be on the first tape.  However, will tapes 2 and 3 have a table on them as well?

    Since we are now using a 1:1 ratio of virtual tape to physical tape, a table (it has been impressed upon me that this table is important, whatever exactly is it used for  - I guess to find data faster) is written on each tape and consequently, that is thus written on each tape.  I guess a better question is this.  If I do the scenario I lined out - one 1200GB backup from one tape to three 400GB tapes - will I need to place all three tapes into the system to do a restore of one file simply because the table for all of them is going to be on one tape a.k.a. the first tape in line?

    Quite honestly, I can't see a scenario in which I wouldn't want to do that anyways, but I know the quesiton will be asked because Backup Exec reports which tape the data is written on.
  •  Backup Exec does not copy byte for byte between the devices, it duplicates the data stream from the backup set and the creates new catalog information as it goes. Admittedly the usual different size scenario is a lot of 4GB BKF files being duplicated to say a 200GB tape (so lots of catalogs to one catalog) but it should handle it either way. 
  • I think I'm following what you are saying.  I suppose I need to get another Extended Library License to test such a thing don't I?  I would want to create a second library within the D2D server in order to run some tests with this format to see how it runs for us.  Is there someone I can call to get like a temp 30 day license with our support agreement?
  •  You can't trial an additional LEO that I'm aware of in a production system.

    Perhaps on a full trial mode install you could run whatever amount of drives you want.
  • I've found that you don't need any extra licensing on BE 2010 (and therefore possibly BE 12.5) if your Virtual Tape Library only has one Virtual drive in it. Can you not just create another VTL library on the HP D2D device and try it out. We're using HP's D2D2504i, and if you use a D2DBS Generic library you can have 48 virtual tapes in them. Surely the one advantage in keeping the tape sizes the same as the physical tapes is if you use the 'tape attach' functionality and plug a tape drive into the D2D for 'archiving' or copying Virtual Tapes to physical tapes.
    Pete Cousins