On 3/3/2017 12:29 PM, Harald Barth wrote: > > adsmpipe replacement: > > /afs/hpc2n.umu.se/lap/tsmpipe/x.x/src/ > > Used with some scripts do put vos dumps into TSM archive. This is the > current backup solution for at least 3 AFS cells I know about. > > Harald.
There is also LTU's tsmafs which is available on GitHub https://github.com/mattiaspantzare/tsmafs On 3/1/2017 1:52 PM, Dave Botsch wrote: > Sounds like the most recent TSM patches may or may not be in the > OpenAFS tree? > > Are you aware of any reason that this api is not enabled by default? I > believe it would be a huge win for OpenAFS to be able to advertise > native TSM support. The primary reason is because a third party sdk is required to use the api and that sdk is licensed for use only to customers that have a valid license for the commercial product. Beyond that there were other reasons. The current TSM support was merged into the OpenAFS repository prior to the existence of the Gerrit review system and the buildbot continuous integration system. It was merged without significant review by third parties. The code quality is quite poor as Anders noticed in Aug 2015. https://gerrit.openafs.org/#/c/11960/ Since there was no method by which the Gatekeepers could test the TSM functionality nor guarantee that it didn't alter the behavior of backups for non-TSM using organizations, the decision was made to merge the code as a build time option for those organizations that wanted it. On 3/3/2017 11:00 AM, David Boyes wrote: > The IBM-supplied TSM butc support relies on a XBSA (an OpenGroup > standard) compatibility library that was not updated past version 6.1 > of the TSM client on HP/UX, Solaris SPARC and AIX. Linux and Solaris > x86 were never supported for the XBSA-based client. A fairly > substantial amount of work would be needed to bring that support up > to the current client levels (basically recoding to support the > native TSM API). There was some discussion about doing that circa > 2009, unclear if anything happened with that. The XBSA standard was adopted not only by Tivoli Storage Manager but also by Veritas NetBackup. As David Boyes said, IBM abandoned the XBSA standard and now only supports their own proprietary API (loosely based on the XBSA model.) OpenAFS only ever included support for TSM, not NetBackup. The Backup Tape Controller (butc) when XBSA is supported permits a remote XBSA enabled backup system to be used in place of a tape device or local file system. Full and incremental volume dumps are sent to butc and stored in the XBSA service and the object identifier of the specific backup is stored in the AFS backup database just as if the dump had been stored to a tape device. XBSA and the Spectrum Protect SDK are fresh in my mind because AuriStor recently finished integrating Spectrum Protect support into the AuriStor File System. AuriStorFS now supports IBM Spectrum Protect and the older Tivoli Storage Manager releases. This is in addition to our support of Teradactyl's True Incremental Backup System and BackupAFS. The XBSA implementation is modular so we can add support for Veritas NetBackup and object stores in the near future. Jeffrey Altman AuriStor, Inc.
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
