Dear list, I'm struggling to finish my last round of backups with Bacula 2.4.4, which I care to do before migrating to the latest version. My problem is simple to describe: with one of my (multiple, and otherwise working) media pools, the director fails to find a usable volume for use with a backup job (thus prompting for the labeling of a new one, which I really want to avoid).
I've spent the evening going through debug output and part of the source in src/dird/next_vol.c and src/cats/sql_find.c. Here is what seems like the part relevant to the problem of what I'm witnessing in the director debug output when I ask to run a job: Washington-dir: sql_find.c:323-0 fnextvol=SELECT MediaId,VolumeName,<snip> FROM Media WHERE PoolId=5 AND MediaType='LTO2 Ultrium' AND Enabled=1 AND VolStatus='Append' ORDER BY LastWritten IS NULL,LastWritten DESC,MediaId LIMIT 1 Washington-dir: sql_find.c:331-0 item=1 got=0 'got=0' means the query returned 0 rows. But copying and pasting the exact same query in fact returns the expected result of the tape I'm expecting. I can only wildly speculate about what could cause numrows or sql_num_rows(mdb)'s return value to not reflect the fact that there is in fact a result returned by the query. I've compared my sources to the latest branch in the git repository, but my coding skills are basic and nothing strikes me as being the obvious fix I could just patch in to finish the job. I would be grateful if a person more familiar with Bacula code could point me in a direction to try and get db_find_next_volume to play nice. Regards, Lucas ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
