[OpenAFS] Re: backup: Syntax error in dump schedule file

[Andrew Deason]

On Tue, 06 Nov 2012 23:57:46 +0100
Georg Sluyterman <georg@sman.dk> wrote:

> First i tried to use the interactive mode for adding the first level
> in the backup hierachy:
> 
> # backup -localauth
> backup> adddump -dump /testfull expires in 27d
> backup: Created new dump schedule /testfull
> FindDump: expires, error in dump name specification
> backup: Invalid path name 'expires'
> FindDump: in, error in dump name specification
> backup: Invalid path name 'in'
> FindDump: 27d, error in dump name specification
> backup: Invalid path name '27d'
> 
> I thought the syntax was correct (it looks like what I could find in the
> documentation) but apparently I am wrong :).

No, the expiration date is a separate argument. See
<http://docs.openafs.org/Reference/8/backup_adddump.html> for usage and
examples. You want something like:

backup> adddump -dump /testfull -expires in 27d

> Then I tried, using command line arguments, to add some more levels:
> 
> # backup adddump -dump "/testfull/sat0 expires in 13d" -localauth
> backup: Created new dump schedule /testfull/sat0 expires in 13d
> backup: waiting for job termination
> # backup adddump -dump "/testfull/sat0/sun1 expires in 13d" -localauth
> backup: Syntax error in dump schedule file, line is: /testfull/sat0
> expires in 13d any 0 0
> # backup listdumps -localauth
> backup: Syntax error in dump schedule file, line is: /testfull/sat0
> expires in 13d any 0 0
> 
> backup: Internal error ; Can't retrieve dump schedule
> # echo $?
> 255

So, I think this created a schedule named
'/testfull/sat0 expires in 13d'. But, I think schedule names are not
supposed to have spaces in them, which is why the later commands
explode.

The backup command shouldn't let you create backup schedules like that,
but apparently it does. That should be fixed; if you want, file a bug by
emailing <openafs-bugs@openafs.org>. 

> What do I do from here? E.g. how do I delete the entry in the
> database, so I can start again and hopefully succeed in setting up the
> backup?

The easiest way is probably to just delete the database and start over.
That is, stop the buserver process, delete the budb.DB0 and budb.DBSYS1
files, and start the buserver process again.

But you can also fix the entry manually. If you stop the buserver
process, you can edit the budb.DB0 file manually. Find the text:

/testfull/sat0 expires in 13d any 0 0

and replace the spaces before 'any' with, say, underscores, so it reads:

/testfull/sat0_expires_in_13d any 0 0

Then if you start the buserver process again, you should be able to list
your dump schedules again, and should be able to delete it. Manually
altering the database is not usually advised, and this may not work in
the future and is unsupported, etc etc.


You should also know that I'm not sure how many sites actually use the
AFS native backup system anymore, so you may keep encountering little
issues. If you keep reporting issues, we'll fix them as well as we can,
but there are alternatives that may be more popular.

-- 
Andrew Deason
adeason@sinenomine.net