Backups fail with 'transport error'

[serichards]

For some reason the new backup system in whm doesn't work properly with ftp. The old one was perfectly fine backing up into the same ftp space, along with various other systems.

Every single log file has this 'transport error'.

Unable to send “/backup/2014-03-13/accounts/serpop.tar.gz” to destination “ftp”
Unable to send “/backup/2014-03-13/accounts/alnlp.tar.gz” to destination “ftp”
Unable to send “/backup/2014-03-13/accounts/pluser.tar.gz” to destination “ftp”


Looking through this forum this is an ongoing issue that cpanel don't seem to have fixed from months ago.

I know remember why I didn't bother with the new back up system when I first installed cpanel over a year ago. It doesn't work! I think I had a similar errors then. I used the legacy one and that was absolutely fine.

Any files that are over in the back up space seem rather smaller than they should be so it's making a right mess of a simple job. It just gathers some files and ftps them over. That isn't difficult. It shouldn't be making such a poor job of it.

It's definitely not an issue with the ftp space itself as I have other automated systems using it at different times.

When is there going to be a solution to this known and serious issue?

 

[cPanelMichael]

Hello

Please review the following log file:

/usr/local/cpanel/logs/cpbackup_transporter.log

Do you notice any specific error message when the transfer attempt occurs?

Thank you.

 

[serichards]

Last 30 lines of that file:

eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 574
	cPanel::TaskQueue::__ANON__() called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/StateFile.pm line 246
	eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/StateFile.pm line 246
	cPanel::StateFile::Guard::call_unlocked(cPanel::StateFile::Guard=HASH(0x2890380), CODE(0x27f0608)) called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 579
	cPanel::TaskQueue::process_next_task(cPanel::TaskQueue=HASH(0x28907d0)) called at /usr/local/cpanel/bin/cpbackup_transporter line 89
	eval {...} called at /usr/local/cpanel/bin/cpbackup_transporter line 87
[2014-03-13 02:18:05 +0000] warn [cpbackup_transporter] Upload attempt failed: Upload failed
 at /usr/local/cpanel/Cpanel/LoggerAdapter.pm line 26
	Cpanel::LoggerAdapter::warn(Cpanel::LoggerAdapter=HASH(0x1ee5d88), 'Upload attempt failed: Upload failed\x0A') called at /usr/local/cpanel/Cpanel/Backup/Queue.pm line 310
	Cpanel::Backup::Queue::transport_backup::attempt_to_upload_file(Cpanel::Backup::Queue::transport_backup=HASH(0x1ebbde8), Cpanel::Transport::Files::FTP=HASH(0x2873d78), '/backup/2014-03-13/accounts/pluser.tar.gz', 'cpanel_backups/2014-03-13/pluser.tar.gz', Cpanel::LoggerAdapter=HASH(0x1ee5d88)) called at /usr/local/cpanel/Cpanel/Backup/Queue.pm line 187
	Cpanel::Backup::Queue::transport_backup::process_task(Cpanel::Backup::Queue::transport_backup=HASH(0x1ebbde8), cPanel::TaskQueue::Task=HASH(0x27f0c50), Cpanel::LoggerAdapter=HASH(0x1ee5d88)) called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 571
	eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 574
	cPanel::TaskQueue::__ANON__() called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/StateFile.pm line 246
	eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/StateFile.pm line 246
	cPanel::StateFile::Guard::call_unlocked(cPanel::StateFile::Guard=HASH(0x2890380), CODE(0x27f0608)) called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 579
	cPanel::TaskQueue::process_next_task(cPanel::TaskQueue=HASH(0x28907d0)) called at /usr/local/cpanel/bin/cpbackup_transporter line 89
	eval {...} called at /usr/local/cpanel/bin/cpbackup_transporter line 87
[2014-03-13 02:18:05 +0000] warn [cpbackup_transporter] Upload attempt failed: No data connection
 at /usr/local/cpanel/Cpanel/LoggerAdapter.pm line 26
	Cpanel::LoggerAdapter::warn(Cpanel::LoggerAdapter=HASH(0x1ee5d88), 'Upload attempt failed: No data connection\x0A') called at /usr/local/cpanel/Cpanel/Backup/Queue.pm line 310
	Cpanel::Backup::Queue::transport_backup::attempt_to_upload_file(Cpanel::Backup::Queue::transport_backup=HASH(0x1ebbde8), Cpanel::Transport::Files::FTP=HASH(0x2873d78), '/backup/2014-03-13/accounts/pluser.tar.gz', 'cpanel_backups/2014-03-13/pluser.tar.gz', Cpanel::LoggerAdapter=HASH(0x1ee5d88)) called at /usr/local/cpanel/Cpanel/Backup/Queue.pm line 187
	Cpanel::Backup::Queue::transport_backup::process_task(Cpanel::Backup::Queue::transport_backup=HASH(0x1ebbde8), cPanel::TaskQueue::Task=HASH(0x27f0c50), Cpanel::LoggerAdapter=HASH(0x1ee5d88)) called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 571
	eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 574
	cPanel::TaskQueue::__ANON__() called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/StateFile.pm line 246
	eval {...} called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/StateFile.pm line 246
	cPanel::StateFile::Guard::call_unlocked(cPanel::StateFile::Guard=HASH(0x2890380), CODE(0x27f0608)) called at /usr/local/cpanel/3rdparty/perl/514/lib64/perl5/cpanel_lib/cPanel/TaskQueue.pm line 579
	cPanel::TaskQueue::process_next_task(cPanel::TaskQueue=HASH(0x28907d0)) called at /usr/local/cpanel/bin/cpbackup_transporter line 89
	eval {...} called at /usr/local/cpanel/bin/cpbackup_transporter line 87
[2014-03-13 02:18:17 +0000] info [cpbackup_transporter] cPanel Backup Transporter Queue Daemon is being stopped.

Looks like a bug of some kind. A no transport error is nonsensical as ftp works perfectly with everything else...the old style back up also works perfectly. New one creates the folders correctly and uploads some of the files so I reckon it's being dim and dropping the connection part way through and not re-establishing it properly.

 

[cPanelMichael]

Could you open a support ticket so we can take a closer look? You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[serichards]

I've raised it with my VPS provider as I'd assume other customers will also have the same issue. I've asked for the ticket number with cpanel when it is passed up to them.

 

[Infopro]

...

Looking through this forum this is an ongoing issue that cpanel don't seem to have fixed from months ago.

I know remember why I didn't bother with the new back up system when I first installed cpanel over a year ago. It doesn't work! I think I had a similar errors then. I used the legacy one and that was absolutely fine.

...

I would only like to add here that I use the new backup system too, with remote FTP, and it's been working as expected. I don't know that this is an ongoing issue, rather an issue that comes up from time to time when users have issues with configuration, or some other issue.

I think it's safe to say that there are realistically millions of other sites, including my own, being backed up on a regular basis using these new backup tools that you're not hearing from.


Hang in there, cPanel Technical Support will get you sorted. I'm sure of it.


GL!

 

[serichards]

I thought I had raised a ticket with cpanel when I first had the problem but I can't find record of it. It was over a year ago and I don't think there was a resolution as I switched to the legacy backup which worked fine.

It seems to be an issue that pops up every now and then. But if the legacy backup works with ftp then there is no reason the new one shouldn't.

 

[cPanelMichael]

If you can find the ticket number let us know, and we can search for the outcome of the support incident. Or, if you are opening a new ticket, you can update this thread with the new ticket number.

Thank you.

 

[serichards]

Ticket number is apparently 4662797.

Anyone know of any free ftp accounts with a few GB of space so they can test a different ftp space?? I'm amazed there isn't some kind of ftp test account.

I suspect it's an issue with my ftp space but also an issue with cpanel not being able to resume correctly as cyberduck seems to cope ok.

 

[leonex]

I had the same problem. I opened one ticket, assitance modified the file /var/cpanel/backups/config
but not solved the problem.
I solved by writing my script that transfers backup files to ftp server.
P.S. 2 months ago i tested if cpbackup_transporter worked but not worked.

 

[serichards]

Opened a ticket to ask them to link it to the existing one.

Cpanel people are on it

Seems the problem was a basic school boy error with timeouts set in the backup configuration. I'm amazed the support I pay for didn't even work this out.

Took the cpanel person about 2 minutes to see the probable issue.

The ftp issue has been ongoing for ages. I'm sure the old legacy backup either worked ok or didn't notice when it didn't upload the whole of the file. The ftp space I have seems to take much longer to allow the upload than I had ever imagined so the time outs need to be several hours rather than just the standard hour which used to be enough.

Time to find another vps provider as this is another instance of where they couldn't help with something that was straight forward.

 

[cPanelMichael]

I am happy to see the issue is now resolved. Thank you for updating us with the outcome.

 

[serichards]

They're broken again. More transport errors. Really not impressed with reliability of this back up system. This time it didn't transfer one of the files at all.

warn [cpbackup_transporter] Upload attempt failed: Connection to remote server stalled at /usr/local/cpanel/Cpanel/LoggerAdapter.pm line 26
Cpanel::LoggerAdapter::warn(Cpanel::LoggerAdapter=HASH(0x1ea8d88), 'Upload attempt failed: Connection to remote server stalled') called at /usr/local/cpanel/Cpanel/Backup/Queue.pm line 310

It claims it has stalled. The timeout is 3 hours and the date on the file is 2.34am so it started it then, transferred nothing and then gave up after I assume sitting there and doing nothing for the remainder of the time until the email at 5.35am. So it does the same thing with whatever time out is set. Tries to transfer but if it loses the connection it will sit there until the timeout and fail to re-establish the connection.

It is the last large file with the main user contents that continually fails ie the one that is most critical!


Upload attempt failed: Couldn\'t setstat remote file: Failure') called at /usr/local/cpanel/Cpanel/Backup/Queue.pm line 310


I'm not trying to configure webdav instead and get a weird error: Validation for transport “webdav” failed: Could not open “https://webdav.ftpprovider.com:443/cpanel_backups/”: Operation failed. You can only open a collection (directory)

cpanel_backups is a directory! I have tried it with and without the trailing / and it's the same. There is only one user account and they have access to all files and folders. Don't have the same issue with either sftp or ftp on the exact same folder.

It also works via cyberduck using webdav so it's another issue with cpanel.

 

[cPanelMichael]

Please reply to the support ticket to report this issue so we can take a closer look. You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[serichards]

It has decided to generally work via sftp so I haven't re-opened the ticket. It either works fine or it will sit there until it times out having transferred precisely 0. This is even with a time out value of 8 hours. If it starts doing it continually again then I'll open a ticket and post it here.