CPANEL-43516 - The system could not prune backups

Luis Mota

Member
Jun 1, 2015
18
1
53
Porto
cPanel Access Level
Reseller Owner
Hello guys, my problem is simple.
Everything works but I still get an error saying that "The system could not prune the "amazingfolder" (yesterday folder), but actually that folder don't exist anymore after the backup routine.

The first time I tried there was an error on some site (cpanel account) permissions and the system was unable to delete that folder but now everything is fixed and I still get the same error dispite the fact that everything goes fine, at least it seems to go.
 

Luis Mota

Member
Jun 1, 2015
18
1
53
Porto
cPanel Access Level
Reseller Owner
I think I found the problem "The system could not prune the “[_1]” directory due to an error."

Now I need to find "[_1]" directory -.-'

edit:
 
Last edited:

Luis Mota

Member
Jun 1, 2015
18
1
53
Porto
cPanel Access Level
Reseller Owner
I can't find this dir.
What is strange is that the error is displayed after the .master.meta sync

Code:
[2019-05-20 02:40:30 +0100] info [cpbackup_transporter] Upload attempt #1 starting for /backup/2019-05-20/accounts/.master.meta to backup_s3/2019-05-20/accounts/.master.meta for destination:  Nameofmybackupdestination
[2019-05-20 02:40:30 +0100] info [cpbackup_transporter] Successful incremental transfer of /backup/2019-05-20/accounts/.master.meta to backup_s3/2019-05-20/accounts/.master.meta for destination Nameofmybackupdestination
[2019-05-20 02:40:30 +0100] info [cpbackup_transporter] cpbackup_transporter - Checking queue for tasks
[2019-05-20 02:40:30 +0100] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 299s for new tasks
[2019-05-20 02:40:31 +0100] info [cpbackup_transporter] cpbackup_transporter - Checking queue for tasks
[2019-05-20 02:40:31 +0100] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 298s for new tasks
[2019-05-20 02:40:32 +0100] info [cpbackup_transporter] cpbackup_transporter - Checking queue for tasks
[2019-05-20 02:40:32 +0100] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 297s for new tasks

( ... )

[2019-05-20 02:45:30 +0100] info [cpbackup_transporter] cpbackup_transporter - Waiting up to 0s for new tasks
[2019-05-20 02:45:31 +0100] info [cpbackup_transporter] cpbackup_transporter - Checking queue for tasks
[2019-05-20 02:45:31 +0100] info [cpbackup_transporter] cpbackup_transporter - Exiting - the queue has been emptied; no more work to do after waiting for 300s
[2019-05-20 02:45:31 +0100] info [cpbackup_transporter] cPanel Backup Transporter Queue Daemon is being stopped.
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] Initializing log file
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] cpbackup_transporter - parent starting
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] cpbackup_transporter - child starting
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] cPanel Backup Transporter Queue Daemon started.
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] cpbackup_transporter - started
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] cpbackup_transporter - Checking queue for tasks
[2019-05-20 02:47:46 +0100] info [cpbackup_transporter] cpbackup_transporter - Processing next task
[2019-05-20 02:47:47 +0100] info [cpbackup_transporter] Instantiating Object
[2019-05-20 02:47:47 +0100] info [cpbackup_transporter] Starting a "prune" operation on the "Nameofmybackupdestination" destination ID "usi2ESkroDPNCGkcqDUkoTvT".
[2019-05-20 02:47:47 +0100] info [cpbackup_transporter] Base path for destination is backup_s3/
[2019-05-20 02:47:47 +0100] info [cpbackup_transporter] Performing prune operation, retaining 1 items on:  Metodo Rsync - para incremental
[2019-05-20 02:47:48 +0100] info [cpbackup_transporter] Pruning backup directory:  backup_s3/2019-05-19, from Nameofmybackupdestination
[2019-05-20 02:54:46 +0100] info [cpbackup_transporter] ERROR: Pruning backup_s3/2019-05-19 from Nameofmybackupdestination:  ssh slave failed: timed out
[2019-05-20 02:54:46 +0100] info [cpbackup_transporter] The system could not prune the “[_1]” directory due to an error.
[2019-05-20 02:54:46 +0100] info [cpbackup_transporter] Read the go.cpanel.net/directorypruning documentation for solutions to successfully prune the directory.
[2019-05-20 02:54:46 +0100] info [cpbackup_transporter] cpbackup_transporter - Checking queue for tasks
 
Last edited:

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,880
2,270
463
Hello @Luis Mota,

Can you open a support ticket so we can take a closer look at your system to see why this occurred? You can post the ticket number here and we'll link this thread to it.

Thank you.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,880
2,270
463
Hello,

To update, internal case CPANEL-25619 is open to address an issue where false backup pruning failures are reported when the rm command times out on the remote backup destination. The pruning itself should continue to succeed despite the errors reported in /usr/local/cpanel/logs/cpbackup_transporter.log.

I'll monitor the status of this case and update this thread for more information as it becomes available.

Thank you.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,880
2,270
463
I Have the same issue, any update of this?
Hello :)

There's no update to report at this time. I'll continue to monitor the case and update this thread with more information as it becomes available. Note the pruning itself should continue to succeed despite the errors reported in /usr/local/cpanel/logs/cpbackup_transporter.log.

Thank you.
 

vf-hostmaster

Active Member
Dec 27, 2021
33
12
8
United States
cPanel Access Level
Root Administrator
I believe I am also experiencing this issue. We get an alert about backup transport errors

The log states
[2023-06-21 02:32:36 -0500] info [cpbackup_transporter] ERROR: Pruning ******* from *******: ssh slave failed: timed out
[2023-06-21 02:32:36 -0500] info [cpbackup_transporter] The system could not prune the “*******” directory due to an error.


But the folder it was trying to prune looks like it was removed as desired.
 

FrancXPT

Registered
Apr 27, 2023
3
2
1
Morocco
cPanel Access Level
DataCenter Provider
@FrancXPT - can you post the specific error you're seeing from the log?
All Backups are marked complete, but the Transport Always has an error:

Unable to prune transport “XXX.XXXX.com”
Error pruning “2023-08-18” from “XXX.XXXX.com”: ssh slave failed: timed out
The system could not prune the “2023-08-18” directory due to an error.
Read the go.cpanel.net/directorypruning documentation for solutions to successfully prune the directory.

On inspection, Remote Backups seems fine.
I'm using incremental backups and rsync for remote server.
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
I've let the backup team know about the issue, but there isn't any type of ETA for getting this resolved. Since there's only been a few reports of this issue over the last several years, it isn't something critical, and since you know things are working well it's safe to ignore that error.
 

FrancXPT

Registered
Apr 27, 2023
3
2
1
Morocco
cPanel Access Level
DataCenter Provider
I've let the backup team know about the issue, but there isn't any type of ETA for getting this resolved. Since there's only been a few reports of this issue over the last several years, it isn't something critical, and since you know things are working well it's safe to ignore that error.
Thanks, I hope it gets fixed soon, I'm suggestion to let us specify a bigger timeout than 300sec for big servers this problem is happening on multiple servers when choosing incremental backups.
Thanks again for your response and have a good day.
 
  • Like
Reactions: nlaruelle and cPRex

nlaruelle

Well-Known Member
Sep 4, 2017
45
19
58
Belgium
cPanel Access Level
Root Administrator
Thanks, I hope it gets fixed soon, I'm suggestion to let us specify a bigger timeout than 300sec for big servers this problem is happening on multiple servers when choosing incremental backups.
Thanks again for your response and have a good day.
The same report and suggestion apply here.

We are pruning over 100GB of data on a SATA destination, but for each of our servers we keep encountering the notorious "Backup transport errors : Unable to prune transport… Error pruning … from … ssh slave failed: timed out" error.

This occurs even though we have confirmed that the directory has been well physically removed from the disk after manual verification.

The timeout of 300 or 30 seconds appears to be too short for a SATA drive with a large amount of data.

This issue is frustrating because, with everyday "Backup transport error," we can't determine quickly when an actual backup failure has occurred for real.
If we lose focus on this particular alert: "Backup transport errors," it could take days to the administrator to troubleshoot a serious issue with backup transportation.

Do you have an update about this concern ( @cPRex @cPanelMichael ? ), plenty of reports can be found here in the forums since 2018.

Thanks in advance!
 

cPRex

Jurassic Moderator
Staff member
Oct 19, 2014
17,470
2,843
363
cPanel Access Level
Root Administrator
I do see that the case has been closed on our side as "won't fix" as apparently this would take quite a bit of redesigning of the backup tool to resolve. Since things do actually work and there is no data loss, the developers have just opted to not fix this one due to the limited number of reports of the issue. I know that's not an ideal answer, but that's where things are right now.
 

vf-hostmaster

Active Member
Dec 27, 2021
33
12
8
United States
cPanel Access Level
Root Administrator
I do see that the case has been closed on our side as "won't fix" as apparently this would take quite a bit of redesigning of the backup tool to resolve. Since things do actually work and there is no data loss, the developers have just opted to not fix this one due to the limited number of reports of the issue. I know that's not an ideal answer, but that's where things are right now.
WE have been waiting for this to be addressed... The fact that you are not addressing real issues simply because a lot of noise hasn't been made has us extremely alarmed. Does this mean we need to hire someone to complain on this forum every week?