Issue FTPS Backups failing after update to 18.0.37

[Vince]

Hi,

I have 6 VPS running on Centos 7.9 with Plesk Obsidian.
Backups are configured the same way on all servers : everyday on an external FTPS server, passive mode enabled.

All was running fine so far, but 2 of the 6 VPS has been updated to Plesk Obsidian 18.0.37 (update 1).
Since then, i have the same error every day on every backup task :
Unable to create the remote backup: Transport error: Unable to create the directory 'ftps://myexternalftpserver/mybackups/': Curl error: (21) Quote command returned error: Last FTP request: MKD mybackups Last FTP response: 550 Can't create directory: File exists

No problem with the 4 other servers wich have not recieved the update, and are still on Plesk Obsidian 18.0.36.

I have seen the similar resolved thread here : Remote Backup failed since update to 18.0.37
But the solution is to configure the FTP server, on wich i have no configuration access at all.

Is there a way to fix the problem on Plesk side ?

 

[ScottGoddard]

I had this issue also. It seems that there was a change to the FTP transport code that required me to untick the option "Require TLS session resumption on data conection" on the FTP server. This Post gives more info.

 

[Vince]

Thx for your reply, but as i mentioned it in my original message, i've already seen this info/post :

I have seen the similar resolved thread here : Remote Backup failed since update to 18.0.37
But the solution is to configure the FTP server, on wich i have no configuration access at all.

Unfortunately, i don't have access to the FTP server configuration, so i can't disable "ssl_reuse" option on it.
I'm wondering if it could exist a solution on Plesk side.

 

[Vince]

Hi,

I'm sorry to insist, but i have another server wich have been updated (to Plesk Obsidian 18.0.37 update 2) this time.
And backups are failing the same way as the others.

So to recap, 6VPS here, backuping to the same FTPs server :
- 3 updated to 18.0.37 (update 1 or 2) : backups are failing since the update (working fine before) as described on my first post.
- 3 still on 18.0.36 : all working fine.
- i cannot disable "ssl_reuse" option on the FTPs server (don't have config access to it).

Is there a way to fix the problem on Plesk side ?

 

[Vince]

Hello,

Sorry, me again with same problems...

2 more servers updated to 18.0.37 (update 2), with backup failing the same way.
The only server left with 18.0.36 is backuping like a clockwork.

Still no solution on the Plesk Side ?

 

[trialotto]

@Vince,

To some extent, this is not really a problem related to Plesk or a problem on the Plesk side.

In essence, there is one explanation for the difficulties that you are encountering.

The source FTP server has mod_tls enabled by default and mod_tls requires SSL session persistence for data transfers - this is a security feature.

One can relax the SSL session persistence behavior, for instance by adding the line

TLSOptions NoSessionReuseRequired

to a file /etc/proftpd.d/custom.conf that can contain all customisations that you desire - please note that a restart of proftpd is not necessary.

However, the aforementioned solution is only a work-around, not a solution.

Stated differently, there are 2 issues here that should be addressed :

1 - you are creating backups to a target FTP server that is not under your full control : that is a big "no no!" in terms of security and infrastructure design,

2 - the target FTP server is, at least to some extent, not configured properly : in case that the connection is lost, the target FTP server is requesting a new SSL session, while the source FTP server requires SSL session persistence - if for any reason the target FTP server cannot maintain the data connection, then you will have a failing backup.

In summary, your current target backup FTP server cannot provide the control and stability that is required for any backup solution.

It is highly recommended that you find another backup server that provides full control and (connection) stability!

I hope the above helps a bit.

Kind regards........

 

[mow]

1 - you are creating backups to a target FTP server that is not under your full control : that is a big "no no!" in terms of security and infrastructure design,

This is standard practice if you have rented backup space at your hosting provider.
(And that's why you use passwords for the backup.)

2 - the target FTP server is, at least to some extent, not configured properly : in case that the connection is lost, the target FTP server is requesting a new SSL session, while the source FTP server requires SSL session persistence - if for any reason the target FTP server cannot maintain the data connection, then you will have a failing backup.

I think you have that backwards. Also, there is no such thing as a source ftp server in this case. (Technically it is possible to send data from an ftp server directly to another, but that is horribly deprecated and basically guaranteed to not work with SSL anyway.)

 

[trialotto]

@mow

in response to your statement

This is standard practice if you have rented backup space at your hosting provider.
(And that's why you use passwords for the backup.)

I can only say : it is not standard practice...... it only is the case with hosting providers that are renting out disk space as a service, often by using very (very) old servers (with very old hardware and OS) that are configured to function as some kind of stand-alone FTP server with a fancy name "backup server".

You can do portscans on most "backup servers" offered by hosting providers and you will see that there are a lot of security issues - if you are a bit handy, then you can even get some data about the server software ...... or even get remote access.

And that is why you should not use "rented" backup space : just rent your own server and use that as a full-blown backup AND FAIL-OVER server.

I am not starting a discussion here, I am only are giving a well-intended advice with respect to "just taking things for granted" (read: you should not do that - if a hosting provider offers backup space, then it is often to make use of excess storage space on modern and old machines that they cannot rent out) and with respect to "think about backup structure" (read: FTP based backup is static - if your source server breaks down, then you first need to fix the source server and/or install a new server before you can restore the static backup ........ a static backup that contains a snapshot of some moment in time. Simply stated, you are having downtime and you are probably missing some data of the most recent moments in time).

In response to

I think you have that backwards. Also, there is no such thing as a source ftp server in this case. (Technically it is possible to send data from an ftp server directly to another, but that is horribly deprecated and basically guaranteed to not work with SSL anyway.)

I can only say : no, I do not have this backwards.

Plesk uses compression software and secure FTP (read: SSL based connections) to transfer the compressed data to the target server.

In order to use the FTP or FTPS protocol, one needs an FTP client to connect to the target FTP server.

Yes! One might argue that I use the wrong word when saying "source ftp server".

Yes! One might also need to think about the fact that Plesk uses the built-in client of the source FTP server.

Yes, Yes! One might think it is strange....... since Plesk migration manager is fully able to exploit and use all advantages of the rsync program.

In short, no, I do not have this backwards ..... I was simply trying to give an explanation that is clear.

So, thank you for the addition........... it was apparently not clear............... and please tell me : should I use "source server" or "source FTP client" ?

Kind regards.....

 

[Vince]

Hi,

Thank you for your replies.

I understand FTPs backup to a server that is not under my full control is not ideal, but it was also a choice.
I just want to rent a backup space, not to manage the FTP server (Monitoring, security updates, data replication, etc... All that stuff is handled by my provider).
Having to manage several Plesk server is enough for me already.

Now, i also understand that my actual backup space does not provides all the options needed since the 18.0.37, so i have to find another compatible one, or explore other solutions.

 

[trialotto]

Hi,

Thank you for your replies.

I understand FTPs backup to a server that is not under my full control is not ideal, but it was also a choice.
I just want to rent a backup space, not to manage the FTP server (Monitoring, security updates, data replication, etc... All that stuff is handled by my provider).
Having to manage several Plesk server is enough for me already.

Now, i also understand that my actual backup space does not provides all the options needed since the 18.0.37, so i have to find another compatible one, or explore other solutions.

@Vince

In essence, the only requirements for a "backup server" are

- cheap storage : in terms of price per Gb per month
- sufficient storage space : the limit on storage should not cause backups to fail
- firewall : close all ports and only allow traffic on FTP ports for specific IPs associated with your source server(s)
- sufficient bandwidth : a 1Gbit connection is recommended

and in most cases, "standard" (managed) backup services will not tick all four boxes, unless you are willing to pay a considerable fee per month.

In contrast, any cloud based storage service of the big three (Microsoft, AWS and Google) will tick all four boxes (and more, if you look at much more sophisticated requirements).

However, cloud based storage services as part of a backup solution can become complicated : you have to create a VM that functions as a FTP backup server or you have to add so-called fileshares (based in the cloud) to your local machine.

The simple truth is that you do not need complicated constructions (read: they are only desirable for many reasons, but not necessary).

You can simply rent a cheap server and (only) install a FTP server - since FTP is a stable protocol, there is not much need for maintenance.

Personally, I use both : simple FTP servers on dedicated machines and a cloud based solution.

In fact, what I do is this :

- multiple small and simple FTP servers : they are used to receive 1 or 2 backup copies that have a retention rate of 1 to 3 days,
- a cloud based storage : the FTP server is putting backup copies into (cheap) cold storage in the cloud, to have an almost infinite retention rate,
- a (self-managed) cloud based solution : this is the advanced part of the backup solution - dynamic backup of each file that has been changed,

and please note that I use multiple FTP server to decrease the risk that disk failure on one of the FTP servers will damage or delete (all) backup files and/or to decrease the risk that a compromised backup server becomes a security risk and/or to reduce the risk that backups are failing (for instance, as a result of any hardware failure or resource overusage) - in addition, it is cheaper and more practical to have simultaneous backups running to multiple FTP servers : the FTP servers can have small disks (read: cheap) and bandwidth can remain small (read: cheap) and multiple backup processes can run at once (read: fast).

In summary, if you know what you need to backup (in terms of storage, bandwidth and processing time), then you can start planning a backup solution that works for you - in most cases, a small FTP server of a couple of euros per month will suffice.

I hope the above helps a bit!

Kind regards......

 

[Vince]

@Vince

In essence, the only requirements for a "backup server" are

- cheap storage : in terms of price per Gb per month
- sufficient storage space : the limit on storage should not cause backups to fail
- firewall : close all ports and only allow traffic on FTP ports for specific IPs associated with your source server(s)
- sufficient bandwidth : a 1Gbit connection is recommended

and in most cases, "standard" (managed) backup services will not tick all four boxes, unless you are willing to pay a considerable fee per month.

In contrast, any cloud based storage service of the big three (Microsoft, AWS and Google) will tick all four boxes (and more, if you look at much more sophisticated requirements).

However, cloud based storage services as part of a backup solution can become complicated : you have to create a VM that functions as a FTP backup server or you have to add so-called fileshares (based in the cloud) to your local machine.

The simple truth is that you do not need complicated constructions (read: they are only desirable for many reasons, but not necessary).

You can simply rent a cheap server and (only) install a FTP server - since FTP is a stable protocol, there is not much need for maintenance.

Personally, I use both : simple FTP servers on dedicated machines and a cloud based solution.

In fact, what I do is this :

- multiple small and simple FTP servers : they are used to receive 1 or 2 backup copies that have a retention rate of 1 to 3 days,
- a cloud based storage : the FTP server is putting backup copies into (cheap) cold storage in the cloud, to have an almost infinite retention rate,
- a (self-managed) cloud based solution : this is the advanced part of the backup solution - dynamic backup of each file that has been changed,

and please note that I use multiple FTP server to decrease the risk that disk failure on one of the FTP servers will damage or delete (all) backup files and/or to decrease the risk that a compromised backup server becomes a security risk and/or to reduce the risk that backups are failing (for instance, as a result of any hardware failure or resource overusage) - in addition, it is cheaper and more practical to have simultaneous backups running to multiple FTP servers : the FTP servers can have small disks (read: cheap) and bandwidth can remain small (read: cheap) and multiple backup processes can run at once (read: fast).

In summary, if you know what you need to backup (in terms of storage, bandwidth and processing time), then you can start planning a backup solution that works for you - in most cases, a small FTP server of a couple of euros per month will suffice.

I hope the above helps a bit!

Kind regards......

Interesting informations, even if i prefer managed services, i understand that simple FTP servers are not so time consuming to maintain.
It's just that a small amount of time is always more than no time at all

To be honest it's pretty hard nowadays to find managed FTP backups services ticking all our needs (also considering datacenter locations, privacy policies etc.)
And running our own "cheap" servers could be the only way to keep FTP backup as secondary solution.

I'm going to explore that way, considering that for us FTP backups are a "just in case" solution (So may be data-replication of datas stored in the backup server is not really needed for example).
Our primary backup solution is already a cloud based solution (Acronis Cloud Backup with an agent runing on plesk servers to backup only changed files and databases at least 3 times a day).

So even if there is always a way to do better, i think it could be enough like that (Acronis + Cheap FTP without replication)

 

[trialotto]

@Vince

I was a bit surprised when reading that you already have a "good" backup solution, like Acronis Cloud Backup.

On the one hand, it is a good fundament for a solid backup solution.

On the other hand, Acronis Cloud Backup is not so good in terms of price/quality ratios and there is the issue of propagated advantages that are not present.

Let me explain more about the "propagated advantages" that are essentially absent.

First of all, if you are making a list of files to backup, then you will notice that most files are rather static by nature - a daily backup will suffice.

In addition, some data should not be backup at all - consider for example data caches - and other data - like log files - should be centralized without backup (read: log files should be present on a local machine and a centralized machine that allows centralized control of logs and events in those logs).

Moreover, the most important data should not be backed up in static files - databases should be replicated, as opposed to creating static backups.

It is really hard to find a backup solution that can tick all the boxes and that offers a really adequate backup solution out-of-the-box.

All the above simply means that we can (reasonably) compare backup solutions in terms of pricing (per Gb per month) and quality.

In my humble opinion, "quality" is something that is subject to personal preferences.

Nevertheless, "price" is something that can be objectively measured : simple FTP servers will cost 5ct per Gb per month at most and cloud based storage will cost less than 1ct per Gb per month (if you use cloud based storage to store static backups).

I have not seen an out-of-the-box backup solution that offers that kind of pricing...... so, I am sticking to simple FTP servers

Kind regards....

 

[Vince]

In my humble opinion, "quality" is something that is subject to personal preferences.

Yep i agree with that.
Needs and preferences are different beetween anyone and from a project to another.

First of all, if you are making a list of files to backup, then you will notice that most files are rather static by nature - a daily backup will suffice.

In addition, some data should not be backup at all - consider for example data caches - and other data - like log files - should be centralized without backup (read: log files should be present on a local machine and a centralized machine that allows centralized control of logs and events in those logs).

We know that, and Acronis solution allows us to choose what and how we want (only changed files) to backup/exclude, as well as it allows us to launch pre/post backup commands like mysqldumps to make clean databases exports (Not as good as replicated databases on fail-over servers, but still a good backup plan).

It is really hard to find a backup solution that can tick all the boxes and that offers a really adequate backup solution out-of-the-box.

Also true, and if you find a solution ticking all boxes, affordable & not too time consuming, do not hesitate to share