This is the second time I run into the error “Authorization key rejected by Storage daemon.”
It makes backups and restores impossible. Most traces / explanations on the internet will point at FD hostname or SD hostname or key mismatch issues.
That is of course always possible, but if you had it working until a week ago when you updated – please don’t let them discourage you. This error will also occur for any version 7 client connecting to a version 5 server. I’ve had it on my Macbook after running “port upgrade outdated” and just now on my FreeBSD desktop during a migration restore.
The jobs will abort after the client is asked to send/receive files.
Debug output of the storage daemon shows that this is in fact a client error, the bacula error message “
Authorization key rejected by Storage daemon
is completely wrong. They just abstracted / objectified their logging a little too much. The SD received the error “client didn’t want me” and has to pass it own. Not helpful. Sorry guys :)
As a warning / example, here have a look at the log:
JobName: RestoreFiles Bootstrap: /var/lib/bacula/mydir-dir.restore.1.bsr Where: Replace: always FileSet: Full Set Backup Client: Egal Restore Client: Egal Storage: PrimaryFileStorage-int When: 2014-09-14 12:40:15 Catalog: MyCatalog Priority: 10 Plugin Options: *None* OK to run? (yes/mod/no): yes Job queued. JobId=17300 *mess 14-Sep 12:40 waxu0604-dir JobId 17300: Start Restore Job RestoreFiles. 14-Sep 12:40 waxu0604-dir JobId 17300: Using Device "PrimaryFileDevice" 14-Sep 12:39 Egal JobId 17300: Fatal error: Authorization key rejected by Storage daemon. Please see http://www.bacula.org/en/rel-manual/Bacula_Freque_As[...] *status client=Egal Connecting to Client Egal at 192.168.xxx:9102 Egal Version: 5.2.12 (12 September 2012) amd64-portbld-freebsd10.0 Daemon started 14-Sep-14 12:43. Jobs: run=0 running=0. Heap: heap=0 smbytes=21,539 max_bytes=21,686 bufs=50 max_bufs=51 Sizeof: boffset_t=8 size_t=8 debug=0 trace=0 Running Jobs: Director connected at: 14-Sep-14 12:43 No Jobs running. ====
As you saw the restore aborts while a status client is doing just fine.
The same client is now running its restore without ANY issue after doing no more than downgrading the client to version 5.
*status client=Egal Connecting to Client Egal at 192.168.xxx.xxx:9102 Egal Version: 5.2.12 (12 September 2012) amd64-portbld-freebsd10.0 Daemon started 14-Sep-14 12:43. Jobs: run=0 running=0. Heap: heap=0 smbytes=167,811 max_bytes=167,958 bufs=96 max_bufs=97 Sizeof: boffset_t=8 size_t=8 debug=0 trace=0 Running Jobs: JobId 17301 Job RestoreFiles.2014-09-14_12.49.00_41 is running. Restore Job started: 14-Sep-14 12:48 Files=2,199 Bytes=1,567,843,695 Bytes/sec=10,812,715 Errors=0 Files Examined=2,199 Processing file: /home/floh/Downloads/SLES_11_SP3_JeOS_Rudder_[...]
All fine, soon my data will be back in place.
(Don’t be shocked by the low restore speed, my “server” is running the SDs off a large MooseFS share built out of $100 NAS storages.
I used to have the SDs directly on NAS and got better speeds with that but I like distributed storage more than speed)