allow backup utility to mark volumes as ancient

[Neil Horman-2]

Hey all-
        I had recently set up a backup server using the latest git tree and
discovered that while backups could be taken the backup utility wasn't properly
marking the backed up volumes as ancient.  I found I was able to do so manually,
but needed to specify the backup volume id to volutil, rather than the primary
volume id.  The backup utility was having the same issue, and I wrote this patch
to fix it.  With it, I'm able to take backups and mark the corresponding volumes
as ancient properly.  I also converted the call to use NewVolMarkAsAncient,
which is in line with what volutil uses.

Regards
Neil

Signed-off-by: Neil Horman <nhorman@...>


 backup.cc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/coda-src/volutil/backup.cc b/coda-src/volutil/backup.cc
index ddab9c2..2127f9e 100644
--- a/coda-src/volutil/backup.cc
+++ b/coda-src/volutil/backup.cc
@@ -708,7 +708,7 @@ int MarkAsAncient(volinfo_t *vol) {
     if (Hosts[reps[i].serverNum].rpcid == BADCONNECTION)
  continue;
 
-    rc= VolMarkAsAncient(Hosts[reps[i].serverNum].rpcid, volId, reps[i].repvolId);
+    rc= NewVolMarkAsAncient(Hosts[reps[i].serverNum].rpcid, reps[i].backupId);
     if (rc != RPC2_SUCCESS) {
  LogMsg(0,0,stdout, "VolMarkAsAncient (%x) failed on %x with %s\n",
        Hosts[reps[i].serverNum].rpcid, /* For debugging. */
--
/****************************************************
 * Neil Horman <nhorman@...>
 * Software Engineer, Red Hat
 ****************************************************/

[Jan Harkes]

On Tue, Oct 28, 2008 at 03:35:30PM -0400, Neil Horman wrote:
> Hey all-
> I had recently set up a backup server using the latest git tree and
> discovered that while backups could be taken the backup utility wasn't properly
> marking the backed up volumes as ancient.  I found I was able to do so manually,
> but needed to specify the backup volume id to volutil, rather than the primary
> volume id.  The backup utility was having the same issue, and I wrote this patch
> to fix it.  With it, I'm able to take backups and mark the corresponding volumes
> as ancient properly.  I also converted the call to use NewVolMarkAsAncient,
> which is in line with what volutil uses.

Not sure why that original code isn't working because the
NewVolMarkAsAncient implementation on the server simply looks up the
volume replica id and replicated volume group id values from the VRDB
and then calls the same VolMarkAsAncient function.

So although volutil is using a different RPC2 call compared to the
backup utility they both end up doing the same thing and as far as I
can see the backup program is calling the old RPC with the correct
arguments so without understanding why it is broken, I don't feel
comfortable applying this patch.

Our backups for the past 8 years have been run using a modified version
of Amanda, which is why I needed a better way to use volutil ancient
from a script. The NewVolMarkAsAncient implementation was added to
simplify the arguments needed for volutil ancient, and we already needed
to know the backup volume id because it is used by volutil dump.

More recently I've started using BackupPC which needed no changes to
itself, we only needed a fairly trivial script on the Coda servers that
uses volutil and codadump2tar to return a tar formatted stream. The
change that I added to Coda was an improved way to create a volume dump
so that we can efficiently run incremental dumps while still having
access to full path information for the codadump2tar conversion.

Jan

[Neil Horman-2]

On Mon, Nov 03, 2008 at 01:42:08PM -0500, Jan Harkes wrote:

> On Tue, Oct 28, 2008 at 03:35:30PM -0400, Neil Horman wrote:
> > Hey all-
> > I had recently set up a backup server using the latest git tree and
> > discovered that while backups could be taken the backup utility wasn't properly
> > marking the backed up volumes as ancient.  I found I was able to do so manually,
> > but needed to specify the backup volume id to volutil, rather than the primary
> > volume id.  The backup utility was having the same issue, and I wrote this patch
> > to fix it.  With it, I'm able to take backups and mark the corresponding volumes
> > as ancient properly.  I also converted the call to use NewVolMarkAsAncient,
> > which is in line with what volutil uses.
>
> Not sure why that original code isn't working because the
> NewVolMarkAsAncient implementation on the server simply looks up the
> volume replica id and replicated volume group id values from the VRDB
> and then calls the same VolMarkAsAncient function.
>
> So although volutil is using a different RPC2 call compared to the
> backup utility they both end up doing the same thing and as far as I
> can see the backup program is calling the old RPC with the correct
> arguments so without understanding why it is broken, I don't feel
> comfortable applying this patch.
>
> Our backups for the past 8 years have been run using a modified version
> of Amanda, which is why I needed a better way to use volutil ancient
> from a script. The NewVolMarkAsAncient implementation was added to
> simplify the arguments needed for volutil ancient, and we already needed
> to know the backup volume id because it is used by volutil dump.
>
> More recently I've started using BackupPC which needed no changes to
> itself, we only needed a fairly trivial script on the Coda servers that
> uses volutil and codadump2tar to return a tar formatted stream. The
> change that I added to Coda was an improved way to create a volume dump
> so that we can efficiently run incremental dumps while still having
> access to full path information for the codadump2tar conversion.
>
> Jan
>
>

Admittedly I've not dug down that deeply, but looking at it my guess is that it
has something to do with the fact that NewVolMarkAsAncient calls
VolMarkAsAncient using the parent id of the backup volume you pass to it, while
VolMarkAsAncient when called from the client, simply passes the volume id of the
volume that you just backed up (not the backup volume id).

Regards
Neil

--
/****************************************************
 * Neil Horman <nhorman@...>
 * Software Engineer, Red Hat
 ****************************************************/

[Jan Harkes]

On Mon, Nov 03, 2008 at 03:29:27PM -0500, Neil Horman wrote:
> Admittedly I've not dug down that deeply, but looking at it my guess
> is that it has something to do with the fact that NewVolMarkAsAncient
> calls VolMarkAsAncient using the parent id of the backup volume you
> pass to it, while VolMarkAsAncient when called from the client, simply
> passes the volume id of the volume that you just backed up (not the
> backup volume id).

Right, but those two volumes will be the same because the backup
volume's parent-id is set to the value of the volume that it was cloned
from (i.e. the backed up volume). Which is why it seems like something
else must have been wrong when the mark-as-ancient was failing and the
patch only seemed to have fixed it.

The backup program is as far as I know quite strict about not marking a
backup unless everything actually completed successfully. So even when
we did get a complete and consistent dump, but the rpc reply times out
it will not mark this as a successful backup. I think there were quite
extensive logs written in /vice/backup or someplace similar, but I
haven't looked at this for at least 8 years now.

Jan