Can't seem to find additional backup transporter logs
Hi there,
I have a VPS running cPanel/WHM v130.0.16 with nightly backups configured. I have one remote backup destination, which is an S3-compatible storage service.
I've had an issue for the past two nights where the system and account backups failed to transfer, due to the error: "Amazon responded with 411 Length Required".
I'm in contact with the storage service's support team, and they had me run two additional backups, once after enabling tracing for my account and another after tweaking some settings on their side. I did this using "/usr/local/cpanel/bin/backup --force".
On the second run, two accounts (out of four) had their backups transferred, but the rest failed. I can find three log files (nightly automatic, first manual, second manual) for the backup process in "/usr/local/cpanel/logs/cpbackup/", but only two exist (nightly automatic, first manual) in "/usr/local/cpanel/logs/cpbackup_transporter".
Is there a reason I can't seem to find the transport log for the second, manual run? I received the notification email for the failure, but they don't provide much information other than "this thing failed to transfer".
-
Check the latest log in /usr/local/cpanel/logs/cpbackup_transporter/
There can be more than one transports in one log.0 -
Check the latest log in /usr/local/cpanel/logs/cpbackup_transporter/
There can be more than one transports in one log.My apologies for not being clearer. The last lines in the latest log are for the first run I did around 8 AM EST (13:00 UTC). Nothing appears in there for the second, which was around 11 AM EST (16:00 UTC):
[2025-12-09 13:26:48 +0000] info [cpbackup_transporter] cpbackup_transporter - Exiting - the queue has been emptied; no more work to do after waiting for 300s
[2025-12-09 13:26:48 +0000] info [cpbackup_transporter] cPanel Backup Transporter Queue Daemon is being stopped.0 -
I don't have a good explanation for this one as I'd expect them to be in the location you've already checked.
0 -
I ran the backup again, and a third log was created this time. Oddly enough, the output from the second run was in this log (plus a bit from the first)... The timestamp in the filename also matched the time of the second run.
For cPRex (to pass on to the team):
Not sure if this would be a fix for the seemingly itinerant log data, but having a separate log file for each "run" of the transporter (like there is for the backup itself) would be much clearer. It would also be nice if the failure notification for backups included the exact error messages.
Thanks, everyone!
0 -
That doesn't sound like the normal behavior to me, as I would expect each run to get its own log file. If this is something that you can reproduce it would likely be best to create a ticket so this can be investigated.
0
Please sign in to leave a comment.
Comments
5 comments