[OpenAFS] backup: Syntax error in dump schedule file

[Georg Sluyterman]

On 2012-11-07, at 01:02, Andrew Deason <adeason@sinenomine.net> wrote:

> On Tue, 06 Nov 2012 23:57:46 +0100
> Georg Sluyterman <georg@sman.dk> wrote:
>=20
>> First i tried to use the interactive mode for adding the first level
>> in the backup hierachy:
>>=20
>> # 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'
>>=20
>> I thought the syntax was correct (it looks like what I could find in =
the
>> documentation) but apparently I am wrong :).
>=20
> 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:
>=20
> backup> adddump -dump /testfull -expires in 27d
>=20
>> Then I tried, using command line arguments, to add some more levels:
>>=20
>> # 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
>>=20
>> backup: Internal error ; Can't retrieve dump schedule
>> # echo $?
>> 255
>=20
> 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.
>=20
> 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>.=20

Okay, I have done that. The error is easily reproducible.

>=20
>> 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?
>=20
> 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.
>=20
> 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:
>=20
> /testfull/sat0 expires in 13d any 0 0
>=20
> and replace the spaces before 'any' with, say, underscores, so it =
reads:
>=20
> /testfull/sat0_expires_in_13d any 0 0
>=20
> 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.
>=20

The last part actually worked. Thank you for your help.

>=20
> 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.
>=20

Okay. I have not found other good alternatives.=20
Bacula: Their (currently) rudimentary support for AFS is sadly totally =
undocumented and no help on their mailinglist.=20
Teradactyl: It is a bit out of my budget.=20
BackupAFS: (BackupPC fork) It does not seem that maintained, and my =
experience with it are not too impressive.
amanda-afs: I don't use Amanda, but that could maybe be an alternative.
vos dump: I would have to write a bunch of code taking care of =
scheduling etc.

If you have some input on my observations; I am listening :)

--=20
Regards
Georg Sluyterman