[OpenAFS-devel] Backing up AFS with Amanda

[Mitch Collinsworth]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1417697521-1842065972-1115866181=:2929
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: 8BIT


Yes, duplicating the name we used does seem like it could lead to some
confusion.  I'm not sure why my name appears in one of Marc's files but
that could lead to confusion, too, seeing as I'm the primary instigator
of the ccmr.cornell.edu amanda-afs.

The big differences I see between the two are:
  - we do real size estimates of both level 0 and higher incremental
    levels, while Marc just takes a SWAG at incremental level estimates.

  - we implemented a slightly simplified version of the traditional AFS
    backup concept of volume sets, while Marc lists every AFS volume
    individually in the amanda disklist.  That might work but I didn't
    want to clutter the disklist that way.  In a cell of any size it will
    result in a HUGE disklist.  Also there use to be a problem that a
    large list of entries from a single client would fail due to the
    amanda server trying to list them all in an single UDP packet request
    to the client.  That was solved for the most common cases a few years
    ago when the max packet payload size was increased, but I somehow
    doubt it was increased enough for Marc's setup to work in a large AFS
    cell.

Also, Marc, you might be interested to know that I got a small patch
accepted into amanda that allows for disklist entries to begin with
"afs:" which will signal selfcheck not to try to check the "directory".

And Kris, while we did make some use of the API's, we also call vos dump
directly to do the actual volume dumps.

-Mitch



On Wed, 11 May 2005, Kris Van Hees wrote:

> Also look at:
>
> 	ftp://ftp.ccmr.cornell.edu/pub/amanda-afs
>
> It's somewhat confusing that it has exactly the same name, but either way, I
> have found it to be in good working order.  It implements things directly
> using the AFS APIs rather than depending on the user level utilities that
> come with AFS, which is just a different approach.
>
> 	Kris
>
> On Wed, May 11, 2005 at 06:44:37AM -0500, Marc W. Mengel wrote:
>> I was having a discussion with someone here at the HEPiX conference, and
>> it appears folks might be interested in my hacks for doing backups of
>> AFS with Amanda.  These were working, as best I can recall, but
>> were then dropped because we switched to Teradactyl`s TIBS for our
>> AFS backups.
>>
>> It is implemented with the following parts, available at:
>>   http://www-css.fnal.gov/~mengel/amanda-afs
>>
>> gtar-afs-wrap.sh
>>      variation of the usual tar wrapper script, you tell amanda that
>>      this script is tar when you configure it.  It assumes pathnames
>>      of the form /vicepx/volname is a specification for AFS volume
>>      ´volname´ stored on partition /vicepx (for suitable values of x)
>> mkdisklist.sh
>>      this makes a disklist of your AFS volumes in your cell.  You should
>>      run it before starting a backup...
>> disklist
>>      sample output of the above
>> restore_partition
>>      script to restore all AFS volumes on a given partition
>> tocvol.c
>>      c program to generate a TOC from an afs volume dump file.
>>
>> Marc
>>
>> _______________________________________________
>> OpenAFS-devel mailing list
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
> -- 
> Never underestimate a Mage with:
> - the Intelligence to cast Magic Missile,
> - the Constitution to survive the first hit, and
> - the Dexterity to run fast enough to avoid being hit a second time.
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
--1417697521-1842065972-1115866181=:2929--