[OpenAFS] mass moving volumes from server to server ?

[Gary Gatling]

--000000000000a46fc1056b29e785
Content-Type: text/plain; charset="UTF-8"

Hello,

I was wondering if any users or developers have a solution for moving all
the volumes from one server to another?

We have a perl program that was written 11 years ago to do that. But it has
problems...

Its mixed in with this other perl code for programmatically creating
volumes and its a bit of a mess.

You have to remember  to run it inside of screen or tmux. If you forget to
do that, or you press CTRL-C to try to interrupt the script it passes
that CTRL-C down to vos command and volumes get corrupted. Then you might
have to go to tape backup.

The programmer who wrote it moved on a long time ago.

Does anyone have a solution they use for this? Something that could be
safely interrupted? The reason I ask is that I know of no other way to
handle things such as Red Hat kernel upgrades where a reboot is required.
Having an outage for kernel upgrades is problematic for us since so much
other technology depends on having afs working at all times. The kernel
updates seem to happen about every 2 weeks or so.

Thanks,

--000000000000a46fc1056b29e785
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>I was wondering if any users or =
developers have a solution for moving all the volumes from one server to an=
other?</div><div><br></div><div>We have a perl program that was written 11 =
years ago to do that. But it has problems...</div><div><br></div><div>Its m=
ixed in with this other perl code for programmatically creating volumes and=
 its a bit of a mess.</div><div><br></div><div>You have to remember=C2=A0 t=
o run it inside of screen or tmux. If you forget to do that, or you press C=
TRL-C to try to interrupt the script it passes that=C2=A0CTRL-C down to vos=
 command and volumes get corrupted. Then you might have to go to tape backu=
p.<br></div><div><br></div><div>The programmer who wrote it moved on a long=
 time ago.</div><div><br></div><div>Does anyone have a solution they use fo=
r this? Something that could be safely interrupted? The reason I ask is tha=
t I know of no other way to handle things such as Red Hat kernel upgrades w=
here a reboot is required. Having an outage for kernel upgrades is problema=
tic for us since so much other technology depends on having afs working at =
all times. The kernel updates seem to happen about every 2 weeks or so.</di=
v><div><br></div><div>Thanks,</div><div><br></div><div><br></div></div>

--000000000000a46fc1056b29e785--