One thing puzzles me: if I run an ADSM file backup
(or any backup that traverses directories like tar)
doesn't that mean that the entire filetree being
backed up has to be accessed via the AFS cache?
It doesn't seem very efficient compared with
doing a regular AFS backup by volume.
--
cheers
-implicit system:administrators rl system:backup rl ...
This is of course the right thing. This is one of the bunch of
small enhancements to Transarc AFS that are of high value and
low coding effort that should have been happening a long time
ago. Hopefully this will now happen with
On Tue, 3 Oct 2000, Paul Blackburn wrote:
// One thing puzzles me: if I run an ADSM file backup
// (or any backup that traverses directories like tar)
// doesn't that mean that the entire filetree being
// backed up has to be accessed via the AFS cache?
//
// It doesn't seem very efficient
This raises an interesting point. Perhaps now would be a good time
to start compiling a wishlist for enhancements to OpenAFS. What
would be the best way to organize it? On a web site perhaps?
Regarding the DNS idea I know this has been around for a long time
(the record type was defined ages
Actually, AFSDB in DNS has been done for quite some time. In addition, you
could now support it using either the AFSDB records (which are documented
and supported by BIND) and also the SRV records like can be used for krb5
KDC location.
-- Nathan
-Original Message-
From: Earl R
// -implicit system:administrators rl system:backup rl ...
We are running 3.6.2.3 and I can't find it anywhere.
In 3.5.3.51 it's present as a fileserver argument. Should not differ
in 3.6. Today, you can only change the rights of system:administrator.
Also, are there docs on creating the
Actually, amanda would be relatively easy, just plug in a handler for vos
dump and vos restore. Unfortunately, we're no longer using amanda, stuck
with seagate bkupexec... otherwise I'd have long ago added support to it to
backup volumes. Although there is a possibility that I will be deploying a
Earl R Shannon wrote:
I agree that this would be nice. However, to do it "correctly"
would require the creation of another type of record in
DNS similar to an MX record for a mail handling machine.
As I understand it (perhaps incorrectly) an effort was made
to do this and was met with some
On Oct 3, 9:17 Mitch Collinsworth ([EMAIL PROTECTED]) wrote:
This raises an interesting point. Perhaps now would be a good time
to start compiling a wishlist for enhancements to OpenAFS. What
would be the best way to organize it? On a web site perhaps?
Sounds like a good idea. I'd
"Neulinger, Nathan R." wrote:
It might be worth considering the AfsWebSecure approach - which bypasses the
cache entirely. Although you'd have to come up with client code at that
point to integrate directly into the tool you were using.
The biggest problem we've run into with backups is that
That's interesting, are you multiplexing with multiple servers? Cause from
limited testing, I've found that doing more than one vos dump at once to the
same server doesn't actually increase your data rate any, or increases it
only a tiny amount. If the disks on the server were the bottleneck, it
-Original Message-
From: Harald Barth [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 03, 2000 8:49 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: AFS backup/restore using ADSM
// -implicit system:administrators rl system:backup rl ...
We are
Unfortunately, UMR is too cheap to buy a decent backup package, so we're
stuck with Seagate BkupExec. We've got a really ugly hack in place to make
it work with afs. Basically wrapping libc using a LD_PRELOAD'ed library.
What I described below would be shifting that wrapped functionality from
The biggest problem we've run into with backups is that the volume dumps are
just so slow. On a server that we can pull 25 MB/sec sustained off the
disks, we still can't get any more than 3MB/sec or so with vos dump.
Yes. Same numbers here. It is more efficient to use vos dump in terms
of
To really be successful, such a system should really be implemented in
conjunction with a dynamic root.afs volume, to automagically create
the mount points in /afs as well as find the vldbs. _That_ would be
cool.
The Arla folks thought that too, that's why they have implemented it.
Unfortunately, seagate has nice capability for backing up Novell and
Exchange using their native backup API's. unless that were to get hacked
into amanda...
You don't have to convince me... I'd dump seagate, novell, and exchange in a
second, but..
-- Nathan
-Original Message-
Well that would be the easy kludge method I was referring to. That
would get us volume backups and restores. I'll probably give this
a try sometime in the next few months. Conceptually it seems like
an improvement over AFS backup, but so far I haven't found anyone
who's actually tried it.
Another nice feature of Amanda is its index, which allows restoring
single files. This is something AFS backup doesn't do. It could be
done in Amanda but it would take more effort. For one thing mount
points would need to be tracked.
Probably the best way to manage this would be to have
That's what I was talking about - parse the volume dump as it is being
retrieved from the server. I think there is already code out there to do
that.
-- Nathan
-Original Message-
From: Mitch Collinsworth [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 03, 2000 3:49 PM
To:
On Tue, 3 Oct 2000, Neulinger, Nathan R. wrote:
Another nice feature of Amanda is its index, which allows restoring
single files. This is something AFS backup doesn't do. It could be
done in Amanda but it would take more effort. For one thing mount
points would need to be tracked.
Enthusiastically seconding Lyle's advocacy
of small servers for AFS.
I'm looking for a WANFS that allows every PC
to be a server, subject to the trust model.
Even mobile, not always connected, PCs.
andy.glew Best way: on a Wiki. (Wiki is a server side scripting system
andy.glew that allows collaboration using forms interface.)
I'll second that. For this sort of discussion-turned-public-record,
there's nothing else like it.
Although it wasn't the original implementation, the Zope
Harald Barth wrote:
The Arla folks thought that too, that's why they have implemented it.
Yes, that is excellent. I think Lyle also makes a good point about
the proliferation of cells with OpenAFS. The issue with DNS-based
vldb resolution is that it codifies the relationship between cell
23 matches
Mail list logo
