Issue Backup/Dump Rotation Issues Since 12.5 Upgrade

[magestyx]

I see lots of others are having backup/dump rotation issues but I've yet to see solutions. They were working fine on Plesk 12 and I've done no changes to my FTP backup system, so there has to be something going on with Plesk 12.5 . The identical issue is happening on all our Plesk servers. The backups are generally getting created fine, but old backups are not being removed from the FTP.

Here's the errors I'm getting on tons of domains accross all our Plesk servers:
Unable to rotate dump: The dump rotation is failed with code '126' at /usr/local/psa/admin/bin/plesk_agent_manager line 1224.
Unable to rotate dump: The dump rotation is failed with code '151' at /usr/local/psa/admin/bin/plesk_agent_manager line 1224.

I know what the error codes mean:
126: "FTP network error"
151: "Dump does not exist in repository"

But that's not helping me solve anything. Since the only thing that's changed is the Plesk version, the issue has to be a bug with something in there.

CentOS 6.5 (Final)‬
12.5.30 Update #43

Please help.

Thanks.

 

[Bitpalast]

Is your FTP repository accessible from the console, e.g. via sftp?

 

[magestyx]

Correct. Everything else seems to work totally fine and I can setup new backups to the FTP and see backups that are already on the FTP. It is only those two errors happening and no old backups being removed is the problem.

 

[Bitpalast]

What is the owner and group of the files on the remote FTP repository? What are the file permissions on the directory and files?

 

[magestyx]

I'm not 100% sure what the owner is, in FileZilla it just shows the Owner/Group as numbers. It's the same login/password and all settings in Plesk that I use for Filezilla so the logged in user is the same in any case. The FTP server is just a standard FTP, too - no special settings. All folders are standard 755 and the backups being created are the usual 644. Again, all of this was the same as Plesk 12 was using. Plesk 12.5 must have some change which has added FTP issues since this same exact situation is happening on every one of our systems since the 12.5 update.

 

[Bitpalast]

Do you have access to the FTP server's configuration file? In that case I recommend checking the timeout variables. It is possible that a large backup takes so much time that after the transfer finishes the connection expires, so that consecutive attempts of the server running Plesk to connect to the server fail. That in turn could lead to Plesk thinking that there is a network issue (which actually IS the case in this scenario). Else please be aware that the backup procedure is very reliable and normally I'd say the computer is right when it detects a network issue. We are also running several hosts with Plesk and have not seen a similar problem after upgrading from 12.0 to 12.5.

 

[magestyx]

I only have access to the FTP itself - no configs. That's an interesting idea, though - I hadn't thought of that. Still, if that was the issue it seems it'd have happened prior to the 12.5 update, but at that point it was removing old backups fine. All the sites are the same or almost the same size as before the update. If this is the case, then it seems it'd be best for Plesk to open a new connection after a completed upload to remove the older files. Since absolutely nothing changed except for the Plesk version, we're still stuck without a practical solution, though. If I try and change settings in the FTP backups then other, worse issues happen like not being able to connect. What we have in there right now all seems to be the best setup possible with this one odd exception.

 

[Bitpalast]

Maybe you can try to backup to a different FTP space to rule out the possibility of an issue with your current FTP backup space. You could, e.g., use any webspace you have with another provider.

 

[magestyx]

That is an idea we're considering. Just strange that Plesk 12 worked totally fine with the current FTP setup. I just thought since I saw so many people on here having backup errors that I thought our case might be more common, but perhaps not.
Thanks.