[OpenAFS] Error restoring volumes from backup

Mon, 16 Jul 2007 10:20:05 -0600

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Gérald Macinenti wrote:
<blockquote cite="mid13924480.1184308189549.JavaMail.root@m11"
 type="cite">Kim Kimball a écrit :
  <br>
  <blockquote type="cite">The backup dump command has "-append" as an
option.
    <br>
    <br>
Do you know if this was used when the dumps were created?
    <br>
  </blockquote>
yes it was used, and as I understand, this is what caused the problem
as appending to a dump is only supported for tape devices, not files.
  <br>
  <br>
</blockquote>
Oh, I didn't know that and hadn't tried.  Thanks for the info.<br>
<blockquote cite="mid13924480.1184308189549.JavaMail.root@m11"
 type="cite">So the problem arises each time you want an incremental
dump for the same volset or want to backup a new volset on a device
which already holds a dump: you *must* use a separate file each time,
isn't it?
  <br>
  <br>
</blockquote>
If append dump won't work for files then you must be right.  In fact
there's a 'mount script' example in the AFS Admin Reference at <a
 href="http://www.slac.stanford.edu/comp/unix/afs/openafs/doc/html/AdminReference/auarf018.htm#HDRCFG">AFS
Admin Reference (IBM)</a> that indirectly confirms that appends to a
file don't work, but I hadn't understood the full implications.  "A
value greater than
one indicates that the Tape Coordinator cannot access &lt;the target
file&gt;" ...  I haven't worked with the script but it is intended to
automate the renaming of the target file and may help.  I can't comment
on how restores would work with this scheme.<br>
<br>
Quote<br>
<p><b>Example CFG_</b><var>device_name</var> <b>File for Dumping to a
Backup Data File</b>
</p>
<p>In this example, the administrator creates the following entry for a
backup
data file called <b>HSM_device</b> in the
<b>/usr/afs/backup/tapeconfig</b> file. It has port offset
20.
</p>
<pre>   1G   0K   /dev/HSM_device   20

</pre>
The administrator includes the following lines in the
/usr/afs/backup/CFG_HSM_device file. To review the meaning
of each instruction, see the preceding Description section.

<pre> MOUNT /usr/afs/backup/file
 FILE YES
 ASK NO

</pre>
Finally, the administrator writes the following executable routine
in the
/usr/afs/backup/file file referenced by the MOUNT
instruction in the CFG_HSM_device file, to control how the Tape
Coordinator handles the file.

<pre> #! /bin/csh -f
 set devicefile = $1
 set operation = $2
 set tries = $3
 set tapename = $4
 set tapeid = $5

   set exit_continue = 0
   set exit_abort = 1
   set exit_interactive = 2

   #--------------------------------------------

   if (${tries} &gt; 1) then
      echo "Too many tries"
      exit ${exit_interactive}
   endif

   if (${operation} == "labeltape") then
      echo "Won't label a tape/file"
      exit ${exit_abort}
   endif

   if ((${operation} == "dump")   |\
       (${operation} == "appenddump")   |\
       (${operation} == "restore")   |\
       (${operation} == "savedb")    |\
       (${operation} == "restoredb")) then

      /bin/rm -f ${devicefile}
      /bin/ln -s /hsm/${tapename}_${tapeid} ${devicefile}
      if (${status} != 0) exit ${exit_abort}
   endif

   exit ${exit_continue}
"

</pre>
<p>Like the example routine for a tape stacker, this routine uses the
<tt>tries</tt> and <tt>operation</tt> parameters passed to it by the
Backup System. The <tt>tries</tt> parameter tracks how many times the
Tape Coordinator has attempted to access the file. A value greater than
one indicates that the Tape Coordinator cannot access it, and the
routine
returns exit code 2 (<tt>exit_interactive</tt>), which results in a
prompt
for the operator to load a tape. The operator can use this opportunity
to change the name of the backup data file specified in the
<b>tapeconfig</b> file.
</p>
<p>The primary function of this routine is to establish a link between
the
device file and the file to be dumped or restored. When the Tape
Coordinator is executing a <b>backup dump</b>, <b>backup restore</b>,
<b>backup savedb</b>, or <b>backup restoredb</b> operation, the
routine invokes the UNIX <b>ln -s</b> command to create a symbolic
link
from the backup data file named in the <b>tapeconfig</b> file to the
actual file to use (this is the recommended method). It uses the value
of the <tt>tapename</tt> and <tt>tapeid</tt> parameters to construct
the
file name.<br>
</p>
<p>ENDQUOTE<br>
</p>
<p><br>
Kim<br>
<br>
</p>
<strong></strong>
<blockquote cite="mid13924480.1184308189549.JavaMail.root@m11"
 type="cite">If so I don't find it very confortable to use as you must
define differents TC on different ports, one per file, or you have to
change the file on behalf of the TC (have a link that points to a
different file each time you wants to add something on the same disk)?
  <br>
  <br>
ps: restoring such appended dumps doesn't work with standard commands
but the size of the backup file seems to grow at each backup, so I
guess the data must be restorable in a (tricky) way or another.
  <br>
  <br>
  <br>
</blockquote>
<br>
<blockquote cite="mid13924480.1184308189549.JavaMail.root@m11"
 type="cite">
  <blockquote type="cite"><br>
    <br>
Gerald Macinenti wrote:
    <br>
    <blockquote type="cite">Carsten Schulz-Key wrote:
      <br>
      <blockquote type="cite">Gerald Macinenti wrote:
        <br>
        <blockquote type="cite">When trying to restore a volume for
which I have incremental dumps on tape (not a tape but a file on an
external disk), I can sucessfully restore the last full dump but
increments are not appended, I have the following error in butc output:
          <br>
        </blockquote>
        <br>
It seems, you're encountering the following problem:
<a class="moz-txt-link-freetext" href="http://www.openafs.org/pipermail/openafs-info/2007-February/025284.html">http://www.openafs.org/pipermail/openafs-info/2007-February/025284.html</a>
        <br>
        <br>
You have to use separate dump files if you want to do incremental dumps
:-( ...
        <br>
      </blockquote>
ok, thank you very much, sad news...
      <br>
      <br>
Is there any plan to develop an append-to-file feature?
      <br>
      <br>
Cheers
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </blockquote>
  <br>
  <br>
</blockquote>
</body>
</html>