Cloud Storage and (S)FTP Limitations

Author: Kostas Tsakiridis, 2BrightSparks Pte. Ltd.

When SyncBack is accessing files on a supported cloud storage or (S)FTP server it relies on a certain, predefined set of commands that the server can understand and execute. In other words, SyncBack cannot do as it wishes (meaning accessing and modifying content) without going through the cloud/FTP server, which acts as a middleman.

For example, if SyncBackPro needs to upload a file to Dropbox then it must first authenticate itself. To do this, SyncBackPro needs to provide login details to Dropbox so it can access the files on Dropbox on the user's behalf. The user has already configured the profile in SyncBackPro so it can access their files. If the user did not do this, then SyncBackPro cannot access their files. This is basic security. Once SyncBackPro has been allowed to connect to Dropbox, and access the user's files, it then needs to ask Dropbox to perform file operations on its behalf.

It is imperative to understand that there is absolutely no way for SyncBack to access any files stored on a cloud/FTP server without going through the server itself via a properly defined set of instructions. If, for any reason, the server rejects SyncBack’s request to access folders/files then there is nothing it can do. SyncBackPro does not have direct access to the files, i.e. it cannot bypass the cloud/FTP server.

If you are using a cloud storage’s native sync application, e.g. OneDrive, Dropbox, Google Drive etc., you may notice performance differences when comparing to SyncBackPro. This happens because the native sync applications leverage on features that are not available to third party applications, such as SyncBackPro, giving them a performance advantage when it comes to some features. SyncBackPro does have features that can greatly improve performance, e.g. Fast Backup, but they are not always suitable for the situation, e.g. if copying from a cloud service.

Many cloud and FTP services have quotas. The quota (limit) may be on the amount of storage that can be used. This is often the case with cloud storage services, e.g. Google Drive, where you pay based on the maximum amount of storage space you can use. There can also be quotas on other resources, e.g. bandwidth. You may be limited on how much you can send and receive. SyncBack cannot bypass any kind of quota as this is enforced by the cloud or FTP server.

Most cloud services also have rate limits. When this limit is exceeded, the client is often throttled to stop it using too many resources on the service. For example, with Egnyte there are limits on how many times a client (SyncBack) can call the server to do something, e.g. get the details on a file. Those limits can be per second and per day.

Some services, e.g. Google Drive, will throttle based on the overall load on their servers and if they consider your usage to be excessive. In this case SyncBack must slow down by pausing between each call to the service. Again, it cannot bypass this. The service will simply reply to all calls with an error and request that fewer calls are made. It will not respond correctly until the calls are reduced.

Note that in terms of SFTP, in addition to offering encryption through a secure channel, it also enables mutual authentication between the user and host.

Conclusion

When accessing files on a remote storage system, like the cloud and FTP, SyncBack does not have direct access the files. It must ask use the remote storage system to access those files on its behalf. There is no way to bypass the server and get unrestricted access directly to the files.