OK, brought the DB cluster down, brought one MariaDB node back up as a standalone server. Re-ran the diff that failed earlier, and unsurprisingly, it ran with no issues. So I tried a Full to disk.
Well, it's not writing to disk. The BAT console SAYS it is, but it isn't. It did not create a new volume in the Full-Disk pool and use it. Neither is it requesting a tape. run job="Asgard Backup" fileset="Asgard Full Set" level="Full" client="asgard" pool="Full-Disk" storage="babylon4-file" priority="10" when="2017-07-29 23:01:55" yes Job queued. JobId=14298 run job="Babylon5 Backup" fileset="Gentoo Full Set" level="Full" client="babylon5" pool="Full-Disk" storage="babylon4-file" priority="10" when="2017-07-29 23:44:38" yes Job queued. JobId=14299 Both FULL jobs are just sitting there catatonic, neither starting nor requesting media nor throwing an error. Not even a 'Job requires attention' message. So I retried it with the director at -d 200 again, and found this: minbar-dir: msgchan.c:232-14300 >stored: JobId=14300 job=Babylon5_Backup.2017-07-29_23.53.01_04 job_name=Babylon5Backup client_name=babylon5 type=66 level=70 FileSet=GentooFullSet NoAttr=0 SpoolAttr=0 FileSetMD5=XnE+++/2d6+IsXhMY9+hQD SpoolData=0 WritePartAfterJob=1 PreferMountedVols=1 SpoolSize=0 rerunning=0 VolSessionId=0 VolSessionTime=0 sd_client=0 Authorization=dummy minbar-dir: msgchan.c:233-14300 === rstore=0 wstore=7fef1c004dc8 minbar-dir: getmsg.c:151-14300 bget_dirmsg 91: 3000 OK Job SDid=3 SDtime=1501377713 Authorization=LMGK-LHNM-LPGC-GLNB-CPFO-LNNC-DBDI-LFEP minbar-dir: msgchan.c:235-14300 <stored: 3000 OK Job SDid=3 SDtime=1501377713 Authorization=LMGK-LHNM-LPGC-GLNB-CPFO-LNNC-DBDI-LFEP minbar-dir: msgchan.c:244-14300 sd_auth_key=LMGK-LHNM-LPGC-GLNB-CPFO-LNNC-DBDI-LFEP minbar-dir: msgchan.c:322-14300 Wstore=babylon5-sd minbar-dir: msgchan.c:330-14300 wstore >stored: use storage=babylon5-sd media_type=LTO-4 pool_name=Full-Tape pool_type=Backup append=1 copy=0 stripe=0 minbar-dir: msgchan.c:337-14300 >stored: use device=LTO-4 minbar-dir: getmsg.c:151-14300 bget_dirmsg -1: minbar-dir: getmsg.c:151-14300 bget_dirmsg -1: minbar-dir: getmsg.c:151-14300 bget_dirmsg -1: minbar-dir: getmsg.c:151-14300 bget_dirmsg -1: So, first problem (still present): You tell it at the console to run a Full job but use a different pool, and it says "OK, I'm doing what you said", and then it *ignores* what it was just told and uses the Pool the schedule says for Full jobs. Any customization of a Job that conflicts with what the Schedule specifies for that Job level is simply overridden. This behavior was wrong in 7.x, and it's still wrong in 9.x. Job customization by the administrator should ALWAYS override ANY defaults for the job. "The Administrator Is Always Right." Console overrides defaults, NOT defaults override console. Or why have a console at all? Second problem: When it decides to go ahead and use a different Pool and Storage than I told it to, that's not working anyway. No mount request, no operator notification. Usage question here: Does the Job definition or Schedule need to be changed to use the fictional Autochanger now INSTEAD of the Storage? And what's it going to do when the Autochanger wants a drive and slot number? -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
