Again, please look at the "Unsupported" section of
Limitations & known issues with SFTP in Azure Blob Storage - Azure Storage. It clearly states that resuming uploads are unsupported.
@Peter Debik
Exactly my point.
Nevertheless, we apparently both speak English, but we do not understand each other.
So, I suggest that you create an Azure development account, create a storage space and activate SFTP (with all permissions allowed for the SFTP user).
Then try to fill in the SFTP credentials in Plesk, in the pages dedicated to SFTP Backp - part of the Backup to Cloud Pro extension.
Before pressing enter, make sure that you have the Azure Portal open on the storage account that you have created and that you can refresh instantly, to see what happens in the storage account.
You will see that - when pressing enter - the SFTP client on the Plesk side will create a file ..... and delete that file.
At least, that is what should happen and what did happen in the past.
Nevertheless, the SFTP client will moan about something and give you some error notifications.
Yes, error notifications, even though the test file has been created properly and deleted properly.
So, when not talking about file transfer related issues, there is the aforementioned issue that is clearly related to the SFTP client from Plesk.
Now, let's talk about the transfer related issues that I mentioned.
Microsoft states that file upload resumption is not allowed.
Microsoft actually means to say that "IF the transfer is interrupted FOR WHICHEVER REASON, THEN the file upload will not resume".
So, connectivity issues on the SFTP client side, bad code on the SFTP client side ....... that is mostly the reason why file uploads fail ......... since on the Azure side there is no real problem with connections (read: it is almost impossible to break the connection on the Azure side!!!!)
In fact, Microsoft does not allow for file resumption IN ORDER TO PREVENT THAT BAD SFTP CLIENTS make a mess of Azure and endanger SECURITY!
Now, back to the file transfer related issues CAUSED by the SFTP CLIENT.
There is this remarkably simple test that one can do in order to investigate the topic "how bad is the SFTP client?" : just use SFTP directly from the command line on a server and upload any (small or large) file to Azure ........ it goes without any problem.
IF direct SFTP to Azure is not an issue at all, then the SFTP client provided with the Backup to Cloud Pro extension must be an issue.
Sure, we do not want to alarm anybody, but there certainly is something about the SFTP client provided with the Backup to Cloud Pro extension.
One can try 100 times to create an upload via SFTP to Azure and most of the attempts will fail, but some of the attempts are succesful to some degree.
Nevertheless, none of the succesful attempts are coherent or consistent in terms of results.
Again, this proofs that there is nothing wrong on the Azure side of SFTP transfers - only the SFTP client should be investigated.
Having said all of the above, it is possible to provide a simple analysis of the transfers that were tested and that were succesful in the past.
Yes, 100MB, 1GB, 100GB transfers are/were NOT an issue on the Azure side.
That is, when SFTP to Azure was still working properly!
So, if these small and large files cannot be transferred at all, then the SFTP client is not working at all.
In fact, the last time I checked, the SFTP client stated that the client was not able to connect, even though the test file was written - how can a SFTP client not connect and still write a test file??????
So, having concluded that the SFTP client does not work properly AT THIS MOMENT, now BACK TO THE DAYS WHEN IT WORKED.
At the time the SFTP to Azure functionality worked properly, it was not an issue to send a file of any size to Azure.
Stated differently, we need to talk about what actually happens under the hood of the SFTP protocol machine.
SFTP is inherently ineffective for large transfers and is associated with a huge disadvantage : a considerable performance overhead.
SFTP works with a single TCP connection, mostly with limits set to throughput : the chunk size.
SFTP works with SSH to decrypt and decrypt data, so file resumption is barely possible if connectivity issues occur during the tranfer of a chunk or a file.
In brief, SFTP inherently works with chunks and the SFTP client should be coded in such a way that chunks are properly transferred AND coded in such a way that chunks (or files) can be resumed if a temporary failure during transfer occurs.
The last paragraph gives simple hints were Plesk Team can or should improve the Cloud to Backup Pro extension, at least for Azure support.
Nevertheless, that is not the full issue here.
As stated before, SFTP via SSH to Azure works fine and the SFTP to Azure via the Cloud to Backup Pro extension does not .......
............... so, if SFTP works over SSH and SFTP via SSH to Azure works fine, then there is a big issue with the SFTP client provided by Plesk.
For security reasons, we do not allow SFTP to Azure via the Cloud to Backup Pro extension, given the issues with this particular SFTP client.
Sure, we can talk about what a manual of Microsoft seems to suggest or what you seem to deduct from my posts ......
........ but should it not be more IMPORTANT to get a PAID-FOR extension - like the Cloud to Backup Pro extension - working PROPERLY AND SECURE???
As for my English, my sincere apologies if it cannot be comprehended in full.
Kind regards....
Facebook
Twitter
