On 2012-11-07, at 01:02, Andrew Deason <[email protected]> wrote:
> 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]>. Okay, I have done that. The error is easily reproducible. > >> 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. > The last part actually worked. Thank you for your help. > > 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. > Okay. I have not found other good alternatives. Bacula: Their (currently) rudimentary support for AFS is sadly totally undocumented and no help on their mailinglist. Teradactyl: It is a bit out of my budget. 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 :) -- Regards Georg Sluyterman _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
