CloudBerry Labs support?

[bigtfromaz]

@jlesage I licensed CloudBerry Backup and am running it on the Synology using your image. However there is a problem. There is a setting where you can specify the number of threads can start up. Among other things threads get used to upload files in parallel. However when running in the container it appears to be uploading 1 file at a time. It took my initial backup 12 days to complete. The last 8 were used to upload a large number of small files totaling 30 GB.

So I opened an issue with CloudBerry Labs and they have pointed out that Alpine Linux is not on their list of supported operating systems. Would it be difficult to build the container on Ubuntu? Also, can you think of anything that might be restricting the number of threads, or causing their threads to serialize?

From here down is a copy of the response I received from CloudBerry Labs.

---

Hello,

Thanks a lot for your waiting and patience.

As far as we can see, you're actually using the version which is not in our list of supported OS:

System type                     : alpine
System version                  : Alpine Linux v3.9

Can you please provide more clarity about your setup, so we could consider further investigation?

We look forward to hearing from you.

[jlesage]

I don't think that the fact that CBB is running in a container has anything to do with the issue. Binaries use shared libraries that come from their own package or from Ubuntu.

It seems that first support level try to filter issues before they reach the second level. Looking at the OS is an easy way to do it. Maybe you can refer them to https://github.com/jlesage/docker-cloudberry-backup/issues/3 ;)

[bigtfromaz]

A quick update. CloudBerry Labs decided to go ahead and open a support ticket after I sent them some configuration information taken from the Synology host along with the hardware specs.

Their first move from level 1 was to tell me that the CPU can only run 4 threads. I correct their miss-perception. As proof I offered to start the container using the command line instead of the GUI. I did that adding the --cpuset-cpus 0-3 parameter.

That didn't change the performance. So I created a special backup, designed to recreate the problem without needing to send 2 TB of data. I turns out that if I don't encrypt the backup and only use compression, it runs much faster sending 700 files in about 30 seconds. That's the opposite of my experience. Compression is usually far more expensive than reversible encryption.

It appears that when encryption is turned on in the backup it single threads the uploads. CPU demand never exceeded 27% during any test. I guess it may be possible that there is a less-than-optimal encryption library being chosen in this configuration.

The short answer is that the container seems fine and there is a performance issue in the product. It'll be interesting to see if they take ownership.

[bigtfromaz]

@jlesage OK we have come full circle. The CloudBerry Labs support tech that was handling my case passed it to another person, ostensibly to someone better equipped to work on the problem. Silly me, the new person is Level 1, and that person began the conversation by telling me once again that they don't support Alpine.

In order to remove that excuse I plan to copy your Dockerfile, and base it on Ubuntu. Do you have any suggestions regarding which version I should use? Also, is there anything special about the build or will a simple git clone followed by a "docker build" do the trick?

[jlesage]

You can use the latest version (jlesage/baseimage-gui:ubuntu-18.04-v3.5.2). And yes, running docker build -t jlesage/cloudberry-backup . should be enough.

[jlesage]

Did you try to install the application directly on another PC or a VM? It would be even better if you can reproduce like this.

[bigtfromaz]

@jlesage CloudBerry Labs got back to me. Here are some snippets:

I've consulted regarding your problem with our R&D guys. 

First of all as we stated earlier - we do not officially support our backup running from a docker container. That can and would slow down the backup process significantly, especially if you're backing up external (to a docker container) data:

Then he sends a couple of links that have nothing to do with the problem at hand. Disk performance may or may not be an issue but I suspect, usually not for a backup over the internet.

But they did say something I think is relevant:

Secondly you won't have enough entropy for proper support of /dev/random:

That comment came after they reviewed my logs. They did not say why entropy is important to their encryption process but if they are getting repeating numbers when expecting random numbers...

In any event, they are saying that is causing my problem. and point to this link:

[]https://stackoverflow.com/questions/26021181/not-enough-entropy-to-support-dev-random-in-docker-containers-running-in-boot2d)

The gist is the thread is that there is a problem with entropy when using light-weight versions of Linux in Docker. There are a few workarounds offered but I am not versed enough to make a choice.

To refresh the issue, the problem is causing backups to single thread so backups with a large number of small files take up to 100 times too long to complete.

Do you have any thoughts on how I should proceed?

[jlesage]

So the entropy would cause the use of a single thread? Do they tell how we can determine if the entropy is enough?