Re: [PATCH] allow backup utility to mark volumes as ancient
Jan Harkes
> 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
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 <nho...@tuxdriver.com>
* Software Engineer, Red Hat
****************************************************/
Jan Harkes
> 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
