Backup does not write dump to FTP repository

[andre.spindler]

Beginning with today, all Backups to FTP repository failed.
Even updates being started manually fail.
FTP Space is not full, there are still app. 400GB free space left.
I was also able to do a ftp upload on terminal using ftp client.
Server is accessible, credentials are right, but backup fails.
So please tell me why backup stops working after having done login.

This are the last few lines of the current psadump.log (removed server url and username):

[2014-10-24 13:38:46.754|17907] INFO: Repository 'ftps://[XXX]//as/': Initializing...
[2014-10-24 13:38:46.754|17907] INFO: Transport: Get repository transport ftps://[XXX]//as/
[2014-10-24 13:38:46.754|17907] INFO: Transport: Init credentials for user '[XXX]'
[2014-10-24 13:38:46.756|17907] INFO: Repository 'ftps://[XXX]//as/': Initialized
[2014-10-24 13:38:46.758|17907] INFO: pmm-ras finished. Exit code: 1

==============================

 

[Kaos1337]

I have a problem with the backup function too since yesterday. I'll open a dedicated thread this evening.

 

[g4marc]

try to delete customers Cache from Online-shops etc.
i had same problems with backup to tfp-repository,
obviously there is a issue on plesk 12 to handle special filenames given from shop for faster crawling.
if you look to the logs, backup stops sending to ftp from server-repositoy every time at the same abonnement (shop-cache)

 

[UFHH01]

I think it's rather an FTP - transfer issue... and not a Plesk failure. For further investigation please try to provide logs from the FTP - transfers, which have not been succesfull finished. In some cases it is helpfull to change the error - log mode from default to debug, or something similar, depending on your used FTP - client and or FTP - server - software.

 

[andre.spindler]

Thank you for your responses.

There is noch cached data from online sources. No shop is running on the server at all. There are only instances of TYPO3 CMS. But also the backup of the complete system configuration done by plesk and without any user data fails.
Uploads using a cli client works well.

The last successfull backup was October 23th early in the morning at 6:00.
The first backup failed at October 24th at 2:00.
I am sure on the welcome screen I saw a plesk update of October 23th or 24th.
Now there is printed "12.0.18 Update #21, zuletzt aktualisiert: Okt. 26, 2014 08:36 AM". So there has been an update one and a half hour ago, but this problem is not fixed.
Where can I see the update log?

Which do you mean with FTP log? Is there a debug mode in Plesk?
The FTP Backup server is run by my web hoster (Strato), so it is not possible for me to enable a FTP log on the server.

EDIT:
I just loccked again into the exiting logs I have reported before. There is also some information at the end I have not reported because, because there is first the massing that connection is closed and afterwards the reason - ???

[2014-10-26 10:13:22.131| 6504] INFO: Repository '/var/lib/psa/dumps': Initializing...
[2014-10-26 10:13:22.131| 6504] INFO: Transport: Get repository transport /var/lib/psa/dumps
[2014-10-26 10:13:22.131| 6504] INFO: Transport: Init credentials for user ''
[2014-10-26 10:13:22.131| 6504] INFO: Repository '/var/lib/psa/dumps': Initialized
[2014-10-26 10:13:22.132| 6504] INFO: Repository 'ftps://XXX.de': Initializing...
[2014-10-26 10:13:22.132| 6504] INFO: Transport: Get repository transport ftps://XXX.de
[2014-10-26 10:13:22.132| 6504] INFO: Transport: Init credentials for user 'YYY'
[2014-10-26 10:13:22.133| 6504] INFO: Repository 'ftps://XXX.de': Initialized
[2014-10-26 10:13:22.133| 6504] INFO: pmm-ras finished. Exit code: 1
[6278]: 2014-10-26 09:13:22 ERROR 3d866492-ba8b-4fae-8a24-05f9210cb505 Can't upload file 'resellers/aaa/clients/bbb/backup_ccc_1410261013.xml' to ftp. Error code: 1
[6278]: 2014-10-26 09:13:22 DEBUG Uploader output: Error: basic_string::_S_construct NULL not valid

 

[UFHH01]

Be aware that at the moment you will be as well notified, if the updates where for Windows systems only ( as in this case #20 and #21 ). You might have a look at

http://download1.parallels.com/Plesk/PP12/parallels-plesk-12.0-for-linux-change-log.html
and
http://download1.parallels.com/Plesk/PP12/parallels-plesk-12.0-for-windows-change-log.html
​

...to compair them.

You suggest that Plesk is updating something that works perfectly on all servers, that I administrate, andre.spindler - your problems might be user/server - specific and has to be investigated to solve the issue/problem... but there is no need for a general update, if it works as expected on other servers.

 

[andre.spindler]

Thank you for the link.

But what I don't understand: As the latest two micro updates are for windows versions only - why is my plesk updated anywhere?
And why does this happen although automated updates are disabled. Security fixes should be installed by this setting, but every update is installed. I have this issue not only with the current 12.0.18, but already with 11.5.30 (http://talk.plesk.com/threads/undoc...though-automated-updates-are-disabled.299932/). Another reason for this behaviour would be that these fixes are not only bugfixes and contain also security patches, but aren't declared this way.

Regards,
André Spindler

 

[g4marc]

As i know Typo3 works with static cached files too? in your case, i would give it a try and find that directory(s) for cleaning.
I don't know, if it has something to do with ftp-transfer or a issue at Plesk. In fact, deleting the cache-files it works for me.
obviously plesk finished the dump and quit directly after checking credetials.
I had likely the same error log. Plesk can't read this specific xml-file from packing, stops the uploading-process and delete the backup-file that was temporary parked to the server-repository.

But it's just a suggestion, for me it had worked well...anyway...

 

[andre.spindler]

Ok, to get things clear:

1. On the websites having a TYPO3 installed there is no static file cache activated.
2. There are websites without TYPO3 which also fail to backup. On the server there have been created different customers with their own websites. And there are separate backup tasks for each customer. And there are 2 customers without any CMS or something similar. One has only a small dummy website with exaclty one html file and about five images. The other one has no website at all and contains just a large file backup. On both there is no CMS, no PHP, no Perl, no Ruby, no MySQL. But all of the backups fail when writing the data to the ftp repository.
3. Creating of the tgz-archives works, also dumping the databases from MySQL. So I can't image why the content of these files (including the filepaths stored within) should be the reason to not copy them to the ftp repo.

Tonight I tried a local ftp backup. As I have a FTP Server (proftpd) running on the server, I enabled logs, created a backup user and then I used this as FTP repository for the backup.

First I did a login with filezilla with the following results. Connection was established:
------------------------------------------------------------------------------------------------------------
84.142.106.52 UNKNOWN - [28/Oct/2014:01:48:46 +0100] "USER backup" 331 -
84.142.106.52 UNKNOWN backup [28/Oct/2014:01:48:46 +0100] "PASS (hidden)" 230 -
------------------------------------------------------------------------------------------------------------

Then I set up a backup job of a small website (backup size 1,5MB) in plesk and got the following results:
------------------------------------------------------------------------------------------------------------
[IP] UNKNOWN - [28/Oct/2014:01:51:05 +0100] "USER backup" 331 -
[IP] UNKNOWN backup [28/Oct/2014:01:51:05 +0100] "PASS (hidden)" 230 -
[IP] UNKNOWN backup [28/Oct/2014:01:51:05 +0100] "PWD" 257 -
[IP] UNKNOWN backup [28/Oct/2014:01:51:05 +0100] "PASV" 227 -
[IP] UNKNOWN backup [28/Oct/2014:01:51:05 +0100] "TYPE A" 200 -
[IP] UNKNOWN backup [28/Oct/2014:01:51:05 +0100] "LIST -a" 226 323
[IP] UNKNOWN backup [28/Oct/2014:01:51:05 +0100] "QUIT" 221 -
------------------------------------------------------------------------------------------------------------
IP address was right, but I have removed it here. Looks like ftp connection has been established, but after receiving the file list the connection is closed immediately - no error visible.
Credentials are correct. If i just create a dummy file in the folder, it is visible in the file list plesk shows.
Also I was able to upload a file with filezilla using the backup account.

The requested log information by UFHH01 is now here - so the should be an answer from parallels.

 

[andre.spindler]

The issue is solved - and it is related to some bugs of plesk which should be fixed.
As there was no useful help from parallels I hope they will read this sugestions and improvements I write down here:

1. move default setting for tmp data from /usr/local/psa/PMM/tmp to /tmp
2. delete tmp data when FTP trnasfer fails
3. create useful error messages

The explanation in detail:

• I run Plesk 12.0.18 MU#22 on CentOS 6.6
  
• In any case a backup is always done by creating several files in /var/lib/psa/dumps/
• If target for the backup is a FTP space, these files have to be packed to one archive (perhaps separated by junk size)
• To create the archive plesk uses by default /usr/local/psa/PMM/tmp. This is the first "bug", as temp data is created within user data storage instead of using /tmp.
• If FTP transfer fails, the temp files are not deleted. This is the second bug.
• In conjunction plesk fills your partition where /usr/ is located with temporary data. As this is usually on the root drive, this will lead to an inoperable system where all services without ssh run into trouble and stop working. Even Plesk itself is terminated, something lika a suizide...
• I have an owncloud installation with about 102GB of data and my system running on a 128GB SSD (/var and /tmp are located on a 2TB HDD raid). You can imagine what happened several times.
• As the server was down several times for this reason, created /tmp/usr_local_psa_PMM_tmp and set a symlink from /usr/local/psa/PMM/tmp to it. Although there are still ftp errors, this will not lead to a complete downtime of the server any more.
• Last week I did some cleanup and unfortunately I delete this directory itself, not only its content. So no archives could be created any more.
• So I found the solution:
  As there was no working FTP backup any more, I did some research to create single archives from the backup data manually by hand. When creating the archive file, I received an error telling me that the temp file could not be found. So I discovered the directory doesn't exist.
  But if you receive something like "Can't upload file 'resellers/<path>/backup_info_1410310949.xml' to ftp. Error code: 1" as error message, you don't think of an error when creating tmp files. So this is the third bug.

Regards,
André

 

[Josh12]

Thanks for reporting this bug. I noticed my tmp directory was not being cleaned because my backup routine "fails" every evening (really it's just trying to download from a non existant sql server, the backup still completes as normal)
Good luck on getting this fixed anytime soon though, Parallels is SLOOOOW at fixing bugs.