cPanel Backup Transporter Wait Time Setting
Good Day,
I recently enabled Google Drive as a backup destination for my cPanel backups. The process is working and local backups are all fine and there.
Remote backups are only partially there as many of my cpanel account backups are missing.
I checked the cpbackup_transporter log file and everything is working fine and there are no timeouts.
Some of my accounts are quite large (up to 200gb) and the largest backup I see on my remote location is about 40gb.
What I suspect is happening is that some backups are taking longer to create than 300s and so the cPanel Backup Transporter service "successfully completes" before the backup service completes the account its working on and the cPanel Backup Transporter service thinks all its work is done.
I have checked the configuration and there is no way to change the 300s setting that the cPanel Backup Transporter service waits.
cpanel transporter log file tail:
[2025-01-12 02:32:58 +0200] info [cpbackup_transporter] Successful transfer of /backup/weekly/2025-01-12/accounts/ {REMOVED} for destination Google Drive
[2025-01-12 02:33:27 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 270s for new tasks
[2025-01-12 02:33:57 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 240s for new tasks
[2025-01-12 02:34:27 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 210s for new tasks
[2025-01-12 02:34:57 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 180s for new tasks
[2025-01-12 02:35:27 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 150s for new tasks
[2025-01-12 02:35:57 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 120s for new tasks
[2025-01-12 02:36:27 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 90s for new tasks
[2025-01-12 02:36:57 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 60s for new tasks
[2025-01-12 02:37:27 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 30s for new tasks
[2025-01-12 02:37:57 +0200] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 0s for new tasks
[2025-01-12 02:37:58 +0200] info [cpbackup_transporter] cpbackup_transporter - Exiting - the queue has been emptied; no more work to do after waiting for 300s
[2025-01-12 02:37:58 +0200] info [cpbackup_transporter] cPanel Backup Transporter Queue Daemon is being stopped.
How can I increase the 300s the cpbackup_transporter service waits to something higher?
My "Maximum Destination Backup Timeout" setting is at the default 2700s - but this is not the setting cpbackup_transporter is using and I see no way in the UI to change the 300s setting.
Thanks in advance!
-
Hey there! I don't have a way to increase that 300s number. Can you check the main cpbackup log (not cpbackup_transporter) to see if there are any creation issues mentioned there?
0 -
No errors occurred in the main cpbackup log file.
Example of log output of an account that backed up but didnt get transported:
[2025-01-12 07:57:07 +0200] pkgacct completed
[2025-01-12 07:57:07 +0200] info [backup] Successfully backed up account “XXX” to “/backup/weekly/2025-01-12/accounts”
[2025-01-12 07:57:07 +0200] info [backup] Adding metadata information for XXX to backup at /backup/weekly/2025-01-12
[2025-01-12 08:17:14 +0200] info [backup] Queuing weekly backup copy of “XXX” for transport of “/backup/weekly/2025-01-12/accounts/XXX.tar.gz” to “weekly/2025-01-12/accounts/XXX.tar.gz”
[2025-01-12 08:17:14 +0200] info [backup] This particular transport will be queued with keep_local = 1 , based on the need to copy weekly (1) and/or monthly () copies as well.
[2025-01-12 08:24:05 +0200] info [backup] Queuing transport of file: /backup/weekly/2025-01-12/accounts/XXX.tar.gz
[2025-01-12 08:24:05 +0200] info [backup] no_transport = 0 .. and queueid = TQ:TaskQueue:18586
[2025-01-12 08:24:05 +0200] info [backup] leaving queue_backup_transport_item
[2025-01-12 08:24:05 +0200] info [backup] checking backup for YYYBut then in the transporter log file, "XXX" isnt even mentioned.0 -
Thanks for the details. It's odd that it was queued and then still didn't get moved properly with the transporter. This will likely be one we'll need to see a ticket on since it seems to be unique to your system, as I don't have similar reports of this happening at this time. Could you create a ticket so this can be investigated?
0
Please sign in to leave a comment.
Comments
3 comments