Personal FTP Repository Backup Failing on Upload

[Scott.B]

I've been trying to get a Personal FTP Repository Backup to work, but it always fails on uploading the file.

The Backup process itself works fine:

• it creates the backup files in /var/lib/psa/dumps
• it also successfully creates the tar archive file in /usr/local/psa/PMM/tmp.
• it connects to my FTP server just fine and starts the upload

After the last point is where it fails. The backup file is 5GB in size and it usually fails after transfering around the 2GB to 2.5GB of the file.

When it fails I get the following error from the task log

ERROR: () Can't upload file clients/ronco/domains/ronco.ca/FullSiteBackupFTP_ronco.ca_info_1510221458.xml' to ftp. Error code: 1

When I check the Backup Manager log files in /var/log/PMM/backup <date and time>/backup.log the last lines are as follows

[2015-10-22 15:19:07.524|17435] INFO: Curl error (55) : Failed sending data to the peer
[2015-10-22 15:19:07.524|17435] INFO: CurlError[76931fac-9dab-42b3-86c2-48b87d6ae33f]: Curl error: Failed sending data to the peer [./ftp.cpp:418]
void plesk::tFtpConnection::UploadFile(const string&)
[2015-10-22 15:19:07.524|17435] INFO: TransportError[9a62d718-3a5d-4578-89e4-b2d6b441e241]: Transport error: unable to put local file /usr/local/psa/PMM/tmp/backup1jENbr/FullSiteBackupFTP_ronco.ca_1510221458.tar to FullSiteBackupFTP_ronco.ca_1510221458.tar: Curl error: Failed sending data to the peer [./transport.cpp:706]
virtual void plesk::tRepositoryFtp:: PutFile(const string&, const string&)
[2015-10-22 15:19:08.320|17435] INFO: pmm-ras finished. Exit code: 1
[16770]: 2015-10-22 19:19:08 ERROR 2d3e3170-aafd-4ee8-864b-5f31a32dfcd5 Can't upload file 'clients/ronco/domains/ronco.ca/FullSiteBackupFTP_ronco.ca_info_1510221458.xml' to ftp. Error code: 1
[16770]: 2015-10-22 19:19:08 DEBUG Uploader output: Transport error: unable to send directory to repository: Transport error: unable to put local file /usr/local/psa/PMM/tmp/backup1jENbr/FullSiteBackupFTP_ronco.ca_1510221458.tar to FullSiteBackupFTP_ronco.ca_1510221458.tar: Curl error: Failed sending data to the peer

I'm not sure why it is failing during transfer.

• It is not a space issue on the FTP Server as there is about 300GB free space there.
• It is not a rights issue because the file does get created
• I'm not sure if it is because of the file size and Plesk itself fails the upload because of some sort of limitation.

If anyone can help me figure out why this is happening it would be greatly appreciated as I've exhausted all avenues that I know of with my knowledge of Plesk.

Thank you

 

[Dmitry Y.]

Suppose Plesk version you are using is 12.0, not a 12.5, as in 12.5 it has auto resume function for backup upload.
The error occured because of network problems. Unfortunately 12.0 unable to resume failed upload. I'm afraid it can be solved by revising your network. Another way is to export dump using "pmm-ras --export-dump-as-file" command and upload it with thirdparty utility, which support resume

 

[Scott.B]

Yes I am running 12.0.18 Update #69.

How stable is 12.5 and has it been made available for General Release? I don't have a test environment only a production environment as my dedicated server is with 1and1. If I do the upgrade to get resume support I do not want to face potentially buggy software.

I don't see the update on my main Plesk screen but I do see it available in Updates & Upgrades. My settings here are configured for General Release.

 

[vlikhtanskiy]

Hi @Scott.B!

Plesk 12.5 in General Available since October 13.

Possible reason why you don't see it available in Updates & Upgrades: your hosting provided has it's own mirror of Plesk packages and there is no Plesk 12.5 in that mirror (as far as I know 1&1 has such mirror). You can contact you hosting provider for more details.

 

[Scott.B]

To confirm I do see it my Updates and Upgrades. I just didn't see it as an available update on my Home screen.

Since you have confirmed that it is now a General Release then for me it is a safe upgrade.

I will upgrade the server to 12.5 in the coming days and test out the resume function and post back here letting you know the outcome.

Thank you to all for your support.

 

[Scott.B]

OK well I did the upgrade to 12.5 and ran a backup again.

Once again it failed during FTP file transfer. The error this time is

Unable to upload dump to FTP, it remains in server repository and you can manually download and upload it to FTP. Upload diagnostic message: Data transfer failed because of connectivity problems. Please, check connection to FTP and try again

I was told that 12.5 has an auto resume function, but obviously this didn't work.

Is there a setting somewhere I need to enable for the resume function to work or is it enabled by default? If it is enabled by default why didn't it work?

 

[UFHH01]

Hi Scott.B,

please check your log - files for any errors, or the task - depending log, for a reason or cause to this error. Make as well sure to try out passive mode and consider to go without compression as already suggested:

One last note:

Some hosting provider offer as well an additional FTP-BackUp-repository which might not be compatible to compress files. In such cases, you should set the option "Do not compress backup files", when you use backups including FTP - storage, to avoid errors. ( Home > Tools & Settings > Backup Manager > Backup Settings )

 

[Bitpalast]

This does not feel like a Plesk issue to me. Some more suggestions: You may want to check the log files of the FTP server on the target machine. Very likely that FTP server is configured to limit connections in one or the other way:
a) max instances: The number of parallel FTP processes allowed on the target machine. If other FTP connections are present, your own may possibly be interrupted.
b) session timeout: In many FTP servers the number of seconds a connection may stay open is limited. E.g. "TimeoutSession" in ProFTPD. If your transfer exceeds that limit, the connection will be closed by the remote (target) host and your backup will fail.
c) max clients, max clients per host, max clients per user: If these are limited and an old client connection is not yet closed, a new client connect may fail. It may also simply be a hanging FTP process on the remote (target) host that causes this issue, because old client connections have never been closed and still count against the maximum.
d) max hosts per user: If you transfer files from several source hosts to the remote host, maybe your sources are too many. The remote host could limit the number of source IP addresses it will handle for one specific FTP account at a time.
e) max storage file size: Occasionally the file size of FTP transfers may be limited by such a configuration. If one of your backup .tar.gz files exceeds that size, it cannot be transferred.

 

[Scott.B]

The FTP server in question is our companies FTP not a 3rd party. I also have passive mode and FTPS enabled in my personal ftp repository settings.

Also which log do I check for FTP errors on backup, would this be in the backup log?

Hi Scott.B,

please check your log - files for any errors, or the task - depending log, for a reason or cause to this error. Make as well sure to try out passive mode and consider to go without compression as already suggested:

I'll check my FTP server settings, for what you suggested and let you know.

This does not feel like a Plesk issue to me. Some more suggestions: You may want to check the log files of the FTP server on the target machine. Very likely that FTP server is configured to limit connections in one or the other way:
a) max instances: The number of parallel FTP processes allowed on the target machine. If other FTP connections are present, your own may possibly be interrupted.
b) session timeout: In many FTP servers the number of seconds a connection may stay open is limited. E.g. "TimeoutSession" in ProFTPD. If your transfer exceeds that limit, the connection will be closed by the remote (target) host and your backup will fail.
c) max clients, max clients per host, max clients per user: If these are limited and an old client connection is not yet closed, a new client connect may fail. It may also simply be a hanging FTP process on the remote (target) host that causes this issue, because old client connections have never been closed and still count against the maximum.
d) max hosts per user: If you transfer files from several source hosts to the remote host, maybe your sources are too many. The remote host could limit the number of source IP addresses it will handle for one specific FTP account at a time.
e) max storage file size: Occasionally the file size of FTP transfers may be limited by such a configuration. If one of your backup .tar.gz files exceeds that size, it cannot be transferred.

As for the resume feature in 12.5 would the above still prevent it from working?

 

[Bitpalast]

As for the resume feature in 12.5 would the above still prevent it from working?

Yes. To me the issue seems to be an issue on the remote FTP host, not on the Plesk host. FTP cannot resume if the FTP connection is blocked by the remote host.

 

[Scott.B]

OK so I'm running Filezilla as my FTP server and looked all over for the settings you are talking about and below is all I found.

 

[Bitpalast]

According to your initial case statement you can connect to this server and start an upload. This rules out issues with a firewall. But maybe you are using a dynamic IP address that frequently changes? If your IP changes while you are uploading, could that maybe the reason for that the transfer is interrupted? Also check the "Logging" of your FileZilla Server. The log file will likely tell you what your system does when it closes the connection that is coming in from your host.

There is no problem with raising the timeout and performance values, e.g. 0 for unlimited users, 100 for number of threds, 600 for connection timeout, and so on ... Do that first to make sure that this is not an issuse for the transfer. If you are at home behind a firewall and using a regular DSL line, there could be hundreds of issues with FTP transfers to your PC, better practice would be to backup to a "real" FTP space at a web provider.

You can easily test what is happening by doing a manual FTP transfer, e.g. open a command shell on your host, then enter "ftp username@remotehost", then "put filename.tar.gz" for some big file (replaces username with user name, remotehost with IP of your target host, filename.tar.gz with the filename you want to transfer). What does the FTP shell command tell you when the transfer fails? Does it fail at all or does the transfer work? What are the log entries in the FileZilla server?

 

[Spooner]

I have the same problem when backing up a large Abonnement daily to FTP (180 GB). Manually via backup manager it will work.
My Settings: NO passive mode, FTPS activated

Errormessage:
Unable to upload dump to FTP, it remains in server repository and you can manually download and upload it to FTP. Upload diagnostic message: Data transfer failed because of connectivity problems. Please, check connection to FTP and try again

Do you have the same problem? does anyone can help?

 

[Tobias Stein]

I get the same error. Interestingly not every day but from time to time it comes up.
As Spooner mentioned a manual backup works great.

 

[B_P]

I have the same issue for the server-wide backup to the defined FTP repository with Ubuntu 12.04 and Plesk 12.5.30 Update #20. Here are my settings:
Planned backups:
- Daily incremental backup
- Full backup every week
- Save backups for 4 weeks
- Backup everything
- Backup to (external) FTP storage
- no separation into files of x MB
- notify in case of failures

FTP settings:
- FTPS
- Passive mode
- use FTP storage
- (account details)
- use password to protect file

General backup setting:
- save backup locally if FTP upload fails.

What I observe now since ~3 weeks (January 21, 2016) is that the incremental upload work without troubles. However, the automated full backups fail to upload with the following message in the log file:
[2016-02-05 00:24:59.656| 3409] INFO: Error 55 Failed sending data to the peer
[2016-02-05 00:25:04.656| 3409] INFO: Trying to resume upload...
[2016-02-05 00:25:05.317| 3409] INFO: The utility executed with the return code: -1
[2016-02-05 00:25:05.339| 3409] INFO: Seek out of scope of stream cache[89e4dcf3-4e5c-4ae2-82bf-3931d1ff4761]: Data transfer failed because of connectivity problems. Please, check connection to FTP and try again [:2045000063]

However, I can see a file with almost the size of the reported backup in my FTP storage.
Interestingly, a manually initiated full backup can be completed without problems.

As the error message states, the backup is stored locally. How can I easily retry the FTP upload without using the UI (where I need to download the file to my client & upload it to the server). It feels as if the tgz file that contains all single backup files is only temporary?

 

[romand700]

Hallo,
I have the same problem when backing up daily to FTP (20 GB). Manually via backup manager it will work.
My Settings: YES passive mode, NO FTPS

Errormessage:
Unable to upload dump to FTP, it remains in server repository and you can manually download and upload it to FTP. Upload diagnostic message: Data transfer failed because of connectivity problems. Please, check connection to FTP and try again

Do you have the same problem? does anyone can help?

 

[Wailer]

Same problem here,

Ubuntu 12 LTS, plesk 12.5.

Manual backups work, scheduled ones fail to upload. I have tried 2 different FTP servers, one of them on local LAN, so it's not a connectivity problem. Somehing is going wrong inside plesk when using schedule.

 

[B_P]

Current system: Ubuntu 12.04.5 LT, 12.5.30 Update #39, Virtual Host

Hi all,
I can confirm the report by romand700: Whenever I manually initiate a full backup through the Plesk panel, the backup succeeds. Only the autmated full backup fails from time to time.
My provider (HostEurope) replied that the number of allowed network connection had been exceeded multiple times, which would in turn disable the network device temporarily. This could of course be one potential reason. The question is now: why does this only happen if the automated backup runs?
Today the backup failed again. What I can see is that "yellow" alert happened: for tcpsndbuf the soft limit had been reached, however it did not reach the hard limit.

One more question: Is there a chance / command to move a backup that is stored on the server to the FTP storage that is setup in the Backup Manager?

@vlikhtanskiy: Do you have any idea what we could do?