Strangely, this message was just delivered to me now, or I would have
commented sooner.

On Sun, Jul 18, 2010 at 13:47, Andrew Deason <[email protected]> wrote:

> On Fri, 16 Jul 2010 20:00:39 -0400
> Brandon S Allbery KF8NH <[email protected]> wrote:
>
> > I was thinking simulated tiered backup volumes by snapshotting an
> > existing (presumed daily) backup volume every month or so.  It would
> > have to be managed manually/by custom scripting, of course, but it's
> > safer on the user end than trying to snapshot with "vos release".
>
> So every month 'vos clone' to a "monthly" backup volume in addition to
> the daily. Does that do what you're thinking, or am I missing something?
>

This is not clear to me: why is vos clone "safer on the user end than trying
to snapshot with vos release" ?

I was planning to have a script iterate through the volumes that I want to
backup and run 'vos release <volume_name>', then 'backup dump
<volume_set>'.  In the backup database I've defined a <volume_set> to
include all volumes on my "backup file server" which is just a file server
that is added as a RO site for all my volumes.  Now I've got a dump archive
and a "hot-spare" RO copy of my data.

It seems to me that "vos clone" is not as effective because of some
limitations which I read in the man page (correct me if these are incorrect
or outdated):
 1) it must reside on the same server as the RW volume (no fast recovery
from a hardware failure, still have to restore from a dump)
 2) there can only be 4 clones of a volume (that doesn't take me very far
back for archiving. users expect to be able to restore quickly from up to a
month ago)
 3) you can't "vos move" a clone (no mobility)

Of course, I realize I'm relatively new to OpenAFS, so I'm trying to glean
as much knowledge from you all as possible.  My solution is just what I came
up with when I looked at the available operations I can perform on a volume.

Regards,

--
Jonathan

Reply via email to