Re: amanda in an Andrew environment?
We've been working on amanda backups of AFS here, but not using AFS's backup system. We found that too painful. We ended up building our own dump program that wraps around vos dump. It's often said that DUMPER-API is coming, but I've seen nothing to suggest there's been any recent progress. Some preliminary work was done on it a while back but I think it stopped. I know very little about Coda but I don't see a need for an AFS backup that produces BSD dump-format output. We also wanted to be able to restore AFS dumps into non-AFS filesystems, but we were able to build a restore program that does this. It's just a matter of being able to decode the vos dump format. -Mitch On 11 Jul 2002, Greg Troxel wrote: Search the archives and google. Previous posters have mentioned modified amanda versions that incorporate the afs dump tool. I am only familiar with Coda (www.coda.cs.cmu.edu), which has its own backup program. Basically the idea is to use amanda to transport and store the bytestream from the native 'dump' version for the non-ufs filesystem. For various reasons, I use gnu tar to back up Coda. This loses the atomic snapshot that the 'real' backup does, and doesn't back up coda metadata (acls), but it works well enough. With the coming 'DUMPER' API, it should be possible to hook in native coda and afs clone/dump programs. I believe the coda folks have a modified amanda that does Coda. rant I really wish that the coda and afs backup programs would produce a BSD dump-format stream, with the files as files, and metadata as files with some funny names (e.g. lots of __, or ^A^F^S), so that one could restore them either on the coda/afs filesystems, or read them anywhere else. But this is really orthogonal to amanda running sendbackup-coda.c. /rant Greg Troxel [EMAIL PROTECTED]
amanda in an Andrew environment?
Let's say that for whatever reason an organization is a heavy user of the Andrew file system. (No NFS at all -- all AFS.) There are apparently locking issues with commercial backup software backing up Andrew file systems. (or so I've been told) The company in question has been using Budtool forever, and hated every moment of it. How would amanda benefit this situation? Thanks. Ron http://roc85.home.attbi.com Protesters against the wearing of animal skins by humans unaccountably fail to throw paint over Hell's Angels. -- Terry Pratchett
Re: amanda in an Andrew environment?
Greetings, Amanda does not backup data. She uses the filesystems native backup utility, usually some form of dump. So this way it is not amanda that archives the data it is the filesystems utilities, which should account for the locking issues. HTH, Drew On Thu, 11 Jul 2002, Ronald O. Christian wrote: Let's say that for whatever reason an organization is a heavy user of the Andrew file system. (No NFS at all -- all AFS.) There are apparently locking issues with commercial backup software backing up Andrew file systems. (or so I've been told) The company in question has been using Budtool forever, and hated every moment of it. How would amanda benefit this situation? Thanks. Ron http://roc85.home.attbi.com Protesters against the wearing of animal skins by humans unaccountably fail to throw paint over Hell's Angels. -- Terry Pratchett
Re: amanda in an Andrew environment?
Search the archives and google. Previous posters have mentioned modified amanda versions that incorporate the afs dump tool. I am only familiar with Coda (www.coda.cs.cmu.edu), which has its own backup program. Basically the idea is to use amanda to transport and store the bytestream from the native 'dump' version for the non-ufs filesystem. For various reasons, I use gnu tar to back up Coda. This loses the atomic snapshot that the 'real' backup does, and doesn't back up coda metadata (acls), but it works well enough. With the coming 'DUMPER' API, it should be possible to hook in native coda and afs clone/dump programs. I believe the coda folks have a modified amanda that does Coda. rant I really wish that the coda and afs backup programs would produce a BSD dump-format stream, with the files as files, and metadata as files with some funny names (e.g. lots of __, or ^A^F^S), so that one could restore them either on the coda/afs filesystems, or read them anywhere else. But this is really orthogonal to amanda running sendbackup-coda.c. /rant Greg Troxel [EMAIL PROTECTED]
