[OpenAFS] vos dumps to S3 via S3 Storage Gateway?

[Dave Botsch]

I have on my mind to look at tsmafs... I had thought, tho, that that was
making use of the TSM api.

On Fri, Mar 03, 2017 at 01:50:36PM -0500, Jeffrey Altman wrote:
> 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.
> 

> begin:vcard
> fn:Jeffrey Altman
> n:Altman;Jeffrey
> org:AuriStor, Inc.
> adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United States
> email;internet:jaltman@auristor.com
> title:Founder and CEO
> tel;work:+1-212-769-9018
> note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=0D=0A=
> 	Skype: jeffrey.e.altman=0D=0A=
> 	
> url:https://www.auristor.com/
> version:2.1
> end:vcard
> 




-- 
********************************
David William Botsch
Programmer/Analyst
@CNFComputing
botsch@cnf.cornell.edu
********************************