[OpenAFS] Re: user home directory replication
Jonathan Nilsson
jnilsson@uci.edu
Thu, 22 Jul 2010 13:45:12 -0700
--0016e64e9d20d907e8048bffff89
Content-Type: text/plain; charset=UTF-8
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 <adeason@sinenomine.net> wrote:
> On Fri, 16 Jul 2010 20:00:39 -0400
> Brandon S Allbery KF8NH <allbery@ece.cmu.edu> 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
--0016e64e9d20d907e8048bffff89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>
Strangely, this message was just delivered to me now, or I would have comme=
nted sooner.<br><br><div class=3D"gmail_quote">On Sun, Jul 18, 2010 at 13:4=
7, Andrew Deason <span dir=3D"ltr"><<a href=3D"mailto:adeason@sinenomine=
.net">adeason@sinenomine.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Fri, 16 Jul 20=
10 20:00:39 -0400<br>
<div class=3D"im">Brandon S Allbery KF8NH <<a href=3D"mailto:allbery@ece=
.cmu.edu">allbery@ece.cmu.edu</a>> wrote:<br>
<br>
> I was thinking simulated tiered backup volumes by snapshotting an<br>
> existing (presumed daily) backup volume every month or so. =C2=A0It wo=
uld<br>
> have to be managed manually/by custom scripting, of course, but it'=
;s<br>
> safer on the user end than trying to snapshot with "vos release&q=
uot;.<br>
<br>
</div>So every month 'vos clone' to a "monthly" backup vo=
lume in addition to<br>
the daily. Does that do what you're thinking, or am I missing something=
?<br></blockquote><div><br>This is not clear to me: why is vos clone "=
safer on the user end than trying to snapshot with vos release" ?<br>
<br>I was planning to have a script iterate through the volumes that I want=
to backup and run 'vos release <volume_name>', then 'bac=
kup dump <volume_set>'.=C2=A0 In the backup database I've def=
ined a <volume_set> to include all volumes on my "backup file se=
rver" which is just a file server that is added as a RO site for all m=
y volumes.=C2=A0 Now I've got a dump archive and a "hot-spare"=
; RO copy of my data.<br>
<br>It seems to me that "vos clone" is not as effective because o=
f some limitations which I read in the man page (correct me if these are in=
correct or outdated):<br>=C2=A01) 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)<br>
=C2=A02) there can only be 4 clones of a volume (that doesn't take me v=
ery far back for archiving. users expect to be able to restore quickly from=
up to a month ago)<br>=C2=A03) you can't "vos move" a clone =
(no mobility)<br>
<br>Of course, I realize I'm relatively new to OpenAFS, so I'm tryi=
ng to glean as much knowledge from you all as possible.=C2=A0 My solution i=
s just what I came up with when I looked at the available operations I can =
perform on a volume.<br>
<br>Regards,<br><br>--<br>Jonathan<br></div></div>
--0016e64e9d20d907e8048bffff89--