Alan, Glad to hear you figured it out! Those keys are very close to each other. It's an easy mistake to make. We are all human.
You use slackware. It's linux on hard mode. I realize that I give a lot of detail in my messages, and sometimes specify information that is almost certainly unnecessary. I feel a need to make absolutely sure that I've given all the information that could possibly be relevant, and I am reluctant to assume that someone will 'know what I mean' or 'figure it out'. This verbosity is probably a failing on my part, and perhaps also useful sometimes. Your skillset was never in doubt on my end. I know you've earned your chops - you use slackware. :) A buddy of mine uses slackware, and he's told me a little bit about it. One thing I might mention - you use older hardware. I get it - I use older / recycled hardware myself. Your hard drives are surely rather ancient at this point, or at least the 250GB spool drive is. I've heard too many horrible stories from the old graybeards I've encountered about tapes that don't have the data they were supposed to have, or had been destroyed by dirty / damaged tape drives. I've also heard numerous horror stories about drives that fail and systems that go down. You've seen many things, so you've probably heard some of those stories too. Have you tested your backups recently with a verify job? LTO media is rated for long term storage, but only for a certain number of read/write operations. Running verify jobs with level=data and verifying by jobid lets you check your backups on tape for validity. I definitely recommend spot-checking your various tapes to ensure they are still holding good data. Additionally, you need to be sure your tape drive isn't dirty. Cleaning tapes now and again are necessary. Also, cleaning tapes get dirty and need to be replaced! Please note the following caveats / gotchas: You must have a job of type verify specified in the configuration in order to run a verify job. A verify job with level Data and only selecting a job name will verify the most recently ran instance of that job, but not older jobids. A verify job with level Data and specified by jobid will validate the data in a volume for that jobid, but not the freshness of the metadata vs the bacula catalog (because unless the jobid you're verifying is the absolute newest, the metadata will always be out of date). A verify job with level VolumeToCatalog is the most thorough check of backup data validity, as it verifies both the backup data and metadata. However, it can only be run against the most recently executed instance of a job. In contrast, a Data verify job is usually better for checking the validity of older backup data, as it does not require the tape metadata to be up-to-date. A verify job with level = data and accurate = yes will essentially behave exactly like a verify job of level VolumeToCatalog, throwing errors if the jobid being verified doesn't have the most recent metadata in the catalog. This can be very confusing if you don't understand what is happening. Don't ask me how I know ;) An additional thing to consider - are you doing disaster recovery backups? In the parlance I'm using, such a backup would consist of a job that specifically backs up bacula configuration files and catalog files. *The general idea here is that the bacula catalog and configuration are backed up into their own volumes to make a recovery operation using bscan and bextract easier.* The sooner you can recover bacula configuration files and restore a fresh catalog backup, the easier it will be to start restoring backups. For DR, I've adopted this process suggested by Bacula Systems. Please note that there is a syntax error in the provided configuration - the second fileset definition isn't terminated with a }. Additionally, I had to supply the catalog backup script and command used by my system instead of the one used in the example. This concept uses its own pool, which would mean separate media for these backups in your case. You'd have to decide how to implement it in your case. https://www.baculasystems.com/enterprise-data-backup-best-practices/#y5 My DR plan uses disk backups, with separate SD-conf devices (so I can drop my DR config in place on multiple systems, and just link the config files to the main conf files (using '@/my/DR-dir.conf' / '@/my/DR-sd.conf' in the relevant bacula-*.conf file). This latter detail probably isn't necessary for your case. I did implement a separate cloud job backing up files both locally and to an s3 compatible cloud (backblaze). I did find backblaze s3-compatible cloud fairly easy to set up, though I'm led to understand that the Amazon driver in bacula 15.x is MUCH better than the S3 driver in prior versions of bacula. You might consider adding a disk just to hold DR backups (with the downside that it's always attached and can be damaged by power surges or malware), and/or inserting a tape dedicated to this role. Multiple DR backups would probably be wise, as well as building a DR bootable environment that is ready to import DR backups from disk. Finally, you might consider pre-emptively replacing older hard drives with newer units. Keep in mind that there was an issue with SATA power connectors where some power supply manufacturers improperly connected a certain pin to ground. That pin was unused in the SATA specification used by older drives, so the PSU error didn't matter until newer drives using an updated version of the SATA specification started using that pin for 3.3v or something. The pin usually wasn't necessary for operation and the drives would usually function just fine if the PSU didn't provide 3.3v on that pin, but if it was shorted to ground the drives might not start up. The solution was to google which pin and put a tiny piece of polyamide / kapton tape over that pin, if that issue was encountered. In a pinch, scotch tape might work too. Your system is old enough that you might encounter this issue, so I thought I'd mention it. If you choose to move to SATA SSDs, keep in mind that while you'll see a huge performance boost vs spinning rust, consumer grade SATA SSDs can be worn out very quickly by linux's frequent write operations. If you do go for SATA SSDs, make sure you use enterprise grade units rated for the usage... or just stick with spinning rust. See what I mean? Probably too much information, but certainly everything I can think of that might be useful. Good luck, and let us know if we can help in any way. Regards, Robert Gerber 402-237-8692 r...@craeon.net On Sat, May 31, 2025 at 3:44 PM Alan Polinsky <alan.polin...@gmail.com> wrote: > Rob et al: > > > Thank you all for assistance. All I can say is that getting old is not > for the faint of heart. I used to be the person that handled unfixable > errors: logic, syntax, spelling et al. My error was NOT the attach point, > though for consistency I stayed with /media. As you get older, the eyes > tend to substitute characters with other ones, especially when they are > small. My spool directory had a _ instead of an =. Oh well... > > > Alan > On 5/30/25 13:24, Rob Gerber wrote: > > Alan, > > It occurred to me that my LTO8 drive's device entry from my bacula-sd.conf > could be helpful. Here you go. > > > Device { > Name = "drive0" > MediaType = "LTO-8" > ArchiveDevice = "/dev/tape/by-id/scsi-1097013295-nst" > RemovableMedia = yes > RandomAccess = no > AutomaticMount = yes > AlwaysOpen = no > Autochanger = yes > DriveIndex = 0 > SpoolDirectory = /mnt/spool > MaximumSpoolSize = 75G > } > > The other thing you might try is to 'sudo su bacula' then 'touch > /bacula/working/filename.ext'. See if the bacula user has permission to > write to the spool dir. > > Regards, > Robert Gerber > 402-237-8692 > r...@craeon.net > > > On Thu, May 29, 2025 at 8:57 PM Rob Gerber <r...@craeon.net> wrote: > >> Alan, >> >> > Spool Directory /bacula/working >> >> If you entered the Spool Directory directive as you specified it in your >> email, then it is probably malformed. I believe the proper format is: >> Spool Directory *=* /bacula/working >> >> You will need to restart bacula-sd after adding the new directive to >> bacula-sd.conf. >> >> You will also want to specify a maximum spool file size in the SD. >> Maximum Spool Size = size >> >> So you have a disk with available usable space of 231 GB, you will want >> to specify >> Maximum Spool Size = 231G >> >> My personal precaution is to specify a maximum about a gig less than my >> total available spool size, so I always leave a little extra space. >> >> Find your total available space with >> df -h | grep /dev/sda1 >> >> Personally, I wouldn't name your spool directory 'working', to avoid >> conflating it with the actual bacula working directory. I would also >> personally avoid sharing a spool disk with anything else if you can help >> it. The whole point of the spool is to fill with data before despooling. >> Other processes don't like when all the available disk space is used up. If >> the spool runs out of space and something isn't handled politely, you want >> jobs to fail, not for *bacula* to fail. >> >> I very highly recommend you read more about spooling here (using an >> archive.org link since the bacula web server seems to be having trouble >> right now): >> >> https://web.archive.org/web/20221002134501/https://www.bacula.org/9.6.x-manuals/en/main/Data_Spooling.html >> >> You can run 'ps aux | grep bacula' to see what bacula processes are >> running. I would expect to see bacula-dir, bacula-sd, and bacula-fd on your >> primary bacula server. >> >> As Bill mentioned, you can launch the bacula-sd in the foreground and in >> debug mode to troubleshoot why it isn't starting. >> > # sudo -u bacula /opt/bacula/bin/bacula-sd -d100 -f (adjust the >> path to where bacula-sd lives on Slackware) >> >> You can also launch the bacula dir and bacula sd in test mode, where the >> process starts, checks the validity of its config file, reports the first >> error found (if any), and exits. To do this, run: >> sudo bacula-dir -t -u bacula -g bacula # Bacula-dir config file test >> sudo bacula-sd -t -u bacula -g bacula # Bacula-sd config file test >> >> Once you've fixed the reported error, rerun the config file test for the >> relevant bacula component to find the next error. Fix that error, if any. >> Repeat until it exits 0, without any output. >> >> Please note that you very much DO NOT WANT to launch bacula processes as >> root (except for the FD). This is because bacula processes create state and >> pid files in the bacula working directory, and if it is ran as root these >> files will be owned by root and will have the wrong permissions the next >> time bacula launches as the bacula user (default bacula user is 'bacula', >> you may have done something different). >> >> Regards, >> Robert Gerber >> 402-237-8692 >> r...@craeon.net >> >> >> On Thu, May 29, 2025 at 4:48 PM Alan Polinsky <alan.polin...@gmail.com> >> wrote: >> >>> Bill: >>> >>> >>> Thanks for getting back so quickly. In my original (non spool file >>> inclusion) i get: >>> >>> tcp 0 0 0.0.0.0:9103 0.0.0.0:* LISTEN >>> 10177/bacula-sd >>> >>> Including the spool file directive I get nothing. In all conf files I >>> list the host name as slcakware.polinsky.home >>> >>> >>> In Slackware, software is stored at >>> >>> /var/bacula >>> >>> That directory is owned by root:root. All subsidiary directories, >>> plugins, scripts, and working are bacula:bacula. (As I mentioned all those >>> directories are on the second sdb disc. I have attached sda1 to /bacula. >>> that parent direcotry is owned by root:root. the /bacula/working directory >>> is owned by bacula:bacula. >>> >>> For right now I am sticking with the original configuration. >>> >>> >>> Alan >>> On 5/29/25 17:15, Bill Arlofski via Bacula-users wrote: >>> >>> On 5/29/25 3:02 PM, Alan Polinsky wrote: >>> >>> I've been running Bacula 9.6.7 for many years with an attached LTO3 tape >>> drive. The machine hosting Bacula is an old Dell Optiplex. Though I am >>> always in Slackware, there is a small 250 gig drive that had Windows 10 >>> installed on it, even though It was never booted in that operating system. >>> With the prospective of Microsoft abandoning Windows 10, I decided to >>> reformat that disc as ext4 and attached it to /bacula. The directive in >>> /etc/fstab is /dev/sda1 /bacula ext4 defaults 0 0. >>> >>> I created a directory under that called working and changed ownership to >>> bacula:bacula. In the bacula-sd.conf file I added: >>> >>> Spool Directory /bacula/working >>> >>> >>> I have changed no other directives in the two remaining conf files. I >>> get the following error >>> >>> >>> Fatal error: bsockcore.c:208 Un >>> able to connect to Storage daemon on slackware151.polinsky.home:9103. >>> ERR=Connection >>> refused >>> >>> The added disc is sda, Slackware is on sdb. What do I have to >>> additionally change to allow the spool file to use sda? >>> >>> >>> Thank you. >>> >>> >>> Alan >>> >>> >>> Hello Alan, >>> >>> This looks to me like the SD is not starting/running on >>> `slackware151.polinsky.home` >>> >>> On that system what does this show: >>> >>> # netstat -tlpn | grep 9103 >>> >>> I suspect a missing permission, or wrong ownership further up the >>> /opt/bacula tree... >>> >>> You can test the SD in debug and foreground mode: >>> >>> # sudo -u bacula /opt/bacula/bin/bacula-sd -d100 -f (adjust the path >>> to where bacula-sd lives on Slackware) >>> >>> >>> ...And should quickly see what the reason is. >>> >>> >>> Hope this helps, >>> Bill >>> >>> >>> >>> _______________________________________________ >>> Bacula-users mailing >>> listBacula-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-users >>> >>> _______________________________________________ >>> Bacula-users mailing list >>> Bacula-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bacula-users >>> >>
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
