|
There are some new disk features in NBU 6.5, and there seems to be some confusion around them. Hopefully I can clear that up.
First, neither of these options should be confused with the current way that integrated VTLs copy virtual tapes to physical tapes, which is thebarcoding-matching method that was discussed in other posts. These options are COMPLETELY DIFFERENT.
Option 1: OpenStorage API
Symantec working with "Intelligent Disk Targets" (their term for disk targets that have a file system interface and do cool stuff like de-dupe). The idea is for the IDTs to code to this API. Once they've done that, Symantec will do a whole bunch of cool stuff via this APIthat they can't do via a VTL interface. This will include the things that are available via the Advanced Disk Storage Unit in 6.5, and will also include other things like optimized de-duplication, direct to tape copy, etc. (I don't think the direct to tape copy is currently in the code. That's a future.)
AS OF TODAY, the API is in 6.5, but no Symantec partners have released products that use it. Some have coded and are testing, but none have made it available via GA. (My guess would be that the early adopters here are likely to be vendors like Data Domain whose primary interface to NBU has been a NAS interface.)
Here's the page on this (although right now the link to the data sheet is broken).
NetBackup 6.5 Options Option 2: NDMP Direct Copy
I've been asking for this for a while, and I'm really excited it's out, well, almost out...
Symantec didn't/doesn't like the current Integrated VTL model of copying virtual to physical tape. (They like the idea of having the VTL do its own copying, but not how it's currently done. It's a copy process that they can't control and/or report on. )
This option, that they've been working on for 1.5 years or so, is going to give us our cake and let us eat it too. This will allow VTLs thatcan talk to tape to do so and let NetBackup control and report on the process. NetBackup will use NDMP as a control protocol (the original coders of NDMP would be so proud to know of this use of their protocol that was never envisioned) to tell the VTL to copy image A to another tape. Via this protocol a tape will be loaded into a drive, NetBackup
will label it and get it ready to send the image, and then NetBackup will tell the VTL to send the image, much in the way that it tells a filer today to send an NDMP dump directly to tape. As far as NBU is concerned, they're not involved once that's done. The VTL will tell it, "done," and NBU will record which tape it got copied to. The VTL could also, of course, say things like "failed," or "tape is full, I need another tape," etc. (It supports spanning tapes.)
(The fact that this is using NDMP has nothing to do with the format of the backup. It will be able to copy regular backups and NDMP backups.)
What I'm looking forward to is a VTL that uses this interface NOT to copy to real tape, but to copy to another VTL, using de-dupe & replication in the background to copy the image instantly and magicly, while still allowing NetBackup to control the process. Just think. If you were use de-dupe and replicating VTL a to VTL b, VTL a could "copy" an image to VTL B without actually making the copy, just by moving bits around. This would rock, but it's definitely just a dream at this point.
AS OF TODAY, the API is in 6.5, but none of the partners have gone GA with their product that supports this feature. They are in testing and it should be out soon (my guess is sooner than the Open Storage API). (Again, my guess here would be that the early adopters of this are likely to be Integrated VTL vendors like Falconstor, Quantum/ADIC, & NetApp. There's no reason that all VTL vendors shouldn't be able to do this, though.) You can read about how to configure this option in the NetBackup NDMP manual.
|
