[OpenAFS] Practical strategies for a backup in a (very) small
Wed, 11 Jan 2006 12:21:45 +0100
to my point of view it is the best, to do regular volume dumps (vos
dump) on these external disks, this should be no problem with a little
bit scripting around.
there is another advantage: using the -localauth option for vos, you can
perform this action without the need of having tokens.
Jeffrey Hutzelman schrieb:
> On Tuesday, January 10, 2006 12:19:52 PM -0500 Madhusudan Singh
> <email@example.com> wrote:
>> With extensive help from Russ and others on this list, I setup our afs
>> cell on a debian server many months ago, and it has been working out
>> us really well. I have defined backup volumes for every user and bos
>> executes a backup process every 24 hours at an unearthly hour. However,
>> the backup volume is located on the same physical disk as the actual
>> user volumes, and thus is really not a backup.
>> The physical location of the cell server (there is only one machine in
>> this cell with no plans to add any more) is quite secure. I would like
>> to migrate the backup volumes onto removable storage all the same (such
>> as a large USB harddisk). I have a few questions :
>> 1. Is this a wise choice given the constraints (I cannot add any more
>> machines to this cell, at least right now) ?
>> 2. Depending on your opinion on 1, how should I migrate the backup
>> volume, nothing else, to the new location ?
> You cannot "migrate" backup volumes to storage other than where the
> corresponding read/write volume resides. An AFS backup volume is a
> read-only, copy-on-write snapshot of its parent; it is intended to
> allow users to recover from unintended changes without administrator
> intervention (if they notice soon enough), and to provide something
> you can take offline long enough to dump it without causing a
> significant service outage.
> For disaster recovery, you will need to perform regular volume dumps
> to separate media such as disk or tape, using 'vos dump', the built-in
> backup system, or one of several third-party packages which are
> available for this purpose.
> -- Jeffrey T. Hutzelman (N3NHS) <firstname.lastname@example.org>
> Sr. Research Systems Programmer
> School of Computer Science - Research Computing Facility
> Carnegie Mellon University - Pittsburgh, PA
> OpenAFS-info mailing list