On Tue, 06 Nov 2012 23:57:46 +0100 Georg Sluyterman <[email protected]> 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 <[email protected]>. > 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 [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
