[OpenAFS] Backup AFS with BackupPC?

Mitch Collinsworth mitch@ccmr.cornell.edu
Mon, 16 Oct 2006 14:54:28 -0400 (EDT)


Sorry for jumping in late on this.  I was out on vacation at the time.

On Sun, 8 Oct 2006, Stephen Joyce wrote:

> On Sun, 8 Oct 2006, seth vidal wrote:
>
>> Specifically I'm interested in how many of them can do:
>>  - volumeset backups or backup by wildcarded volume/partion names
>>  - full volume restores
>>  - directory restores preserving acls
>>  - individual file restores
>>  - incremental backups
>>  - backups spanning tapes
>>  - 100+GB volume backups and restores

The amanda solution can do all of this, though as has been stated elsewhere,
some assembly is required.

> Seth,
> I suspect you already know the answers..
>
> I'm not aware of anything, short of running two disparate backup solutions,
> or maybe mirroring your entire cell to another, that will do all that you
> ask. The two flavors of backing up AFS, as I understand them, are to either
> backup AFS's contents via "normal" methods (tar, rsync, etc), which
> accesses files via the fileserver and generally doesn't capture ACL or
> volume metadata, or to backup the volumes, which accesses the volserver and
> has the benefit of backing up directory ACLs, volume quotas, etc, but
> treats volumes, rather than files, as the backup unit.
>
> So any single solution is unlikely to have all the qualities that you ask
> for. Doing vos dumps and restores to disk still treats volumes as atomic,
> so there's no way to restore a single file or directory without restoring
> its volume first... and that's more cumbersome as volume size increases.
> However, by taking butc out of the equation and backing up directly to
> disk, you don't have the tape-spanning issues you alluded to and your
> volume sizes are not limited by the size of your tapes, unless you go on to
> back up to tape via backula, amanda, tar, or other method.
>
> But like I said, I suspect that you knew all of that...
>
> Someone please correct me if any of the above sounds wrong.

Well, ok.  Your analysis is mostly correct.  The amanda solution is to
do volume-based dumps (and vos dump does have a -time option that can be
used to implement incrementals), but piped through an extra step that
creates an index of all files included in each dump set.  This index can
then be consulted at restore time to pick off specific individual files
or directories that you wish to restore.  During a restore the complete
volume dump is read off the tape and then piped through a process that
that watches for and restores only the files/dirs requested.  Similar to
any standard tar or restore restore.

Amanda has traditionally been tape-spanning-phobic, but my understanding
is that someone has added that functionality as an option recently.  I
haven't tried it myself, but assuming it works, there's no reason it
wouldn't work with any data that's being shoved into amanda, be it afs
or whatever else.

And 100GB+ volumes are as far as I know only an issue of your backup
system being able to swallow that big.  With amanda's tape-spanning or
backup-to-disk capabilities it shouldn't be a problem.


> As for me, I'll probably use backula to do remote offsite backups of
> backuppc's level 0 dumps periodicly, but that's not set in stone yet. Oh
> and FWIW, I do have backuppc utilizing volumesets for backups. Of course,
> just like the AFS native backups, there's no individual file or directory
> restores without first restoring the volume. :-\

The amanda solution also does AFS-backup-style volume sets, but with
invidivual file/dir restores, as noted above.

-Mitch