Error while restoring a content backup


Hi there,

before I’ve delted the broken cloud domain some weeks ago, I’ve made some backups of the server settings and content. The restore of the server settings works, just the restore of the content backup, I get for all three backups an error while uploading. the files are between 100 and 350 MB. Is there maybe a limit for the backup files? Maybe someone knows something? @b?

Thanks so much!

How to restore a downloaded backup on linux system

Okay, no answer so far… sad

For me it seems, a larger backup is impossible to restore to the cloud domains. I found a working sandbox on my PC and made a fresh backup from the sandbox. Also around 300mb. If I try to restore it with the content settings page on the cloud server, after some time just a ERROR message pop up.

Even if no one has an answer, maybe it’s an important information for someone using seriously the cloud servers here on HF. You can make backups and feel safe - until you need one to restore.

Would be great, if a dev could answer here. Thanks


This is a bit worrying to me because I’m going to be shutting down my domain by the end of the month. I have a content backup saved, which I plan to use to bring the server back someday in the future. But this problem makes me think I might not be able to.

I wonder if this is a problem specific to your server, or to the location of your server? Have you tried creating a different cloud domain (on a different location - ie. New York, San Fran) and restoring to that one? I’ve had problems with the San Francisco server, and had to switch it to New York to get it working. Some of them seem to work less well than others.


Hi @Theanine, thanks for your reply. Yes, I’ve tried a server here at my location Frankfurt/Germany, San Francisco and also New York. It’s on all servers the same error:

Okay, maybe the backups are not broken, and it’s just something with upload of them. maybe a timeout or something else someone can fix. Maybe it never was tested with large backup files - don’t know.


Hello -
Looking at that error message it seems like the problem might be with the archive. We will look into this next week. If you don’t mind sending us the archive we could start by verifying the archive is not corrupted. Thanks!


Hi @divia, thank you! I’ll send you a message with the links!


Thanks I received it. Will get back to you when I find out more.


Hi @Skimi,

I have tested restoring your archives locally and was able to.
Taking a closer look at you error message, there is definitely an issue during the upload phase.
We have tested large files, but not on small connexions.
We’ll need a bit more information to figure out what exactly is going wrong.

Are you familiar with your browser’s DevTools?
If not, here are some instructions, the dev tools are pretty similar between most browsers.

  • Got to your domain content settings page
  • Right click on the page
  • Select the “Inspect” option
  • A new panel should open in your window
  • Select the “Console” tab in that panel.
  • On the web page, upload your archive
  • You might see some errors and warnings appearing in the console you just opened, forward those to me.


Hi @c, thank you for taking a look to this. I’ve made two vids for you. In short form, I get always a 400 (Bad Request) error message, instantly after login to the server. During the upload process there is no output in the console:

Failed to load resource: the server responded with a status of 400 (Bad Request)

After a second try, I got this:

jquery-2.1.4.min.js:4 GET 400 (Bad Request)
send @ jquery-2.1.4.min.js:4
ajax @ jquery-2.1.4.min.js:4
getDomainFromAPI @ shared.js:188
reloadDomainInfo @ settings.js:765
Settings.afterReloadActions @ settings.js:37
(anonymous) @ base-settings.js:122
j @ jquery-2.1.4.min.js:2
fireWith @ jquery-2.1.4.min.js:2
x @ jquery-2.1.4.min.js:4
(anonymous) @ jquery-2.1.4.min.js:4
load (async)
send @ jquery-2.1.4.min.js:4
ajax @ jquery-2.1.4.min.js:4
n.(anonymous function) @ jquery-2.1.4.min.js:4
getJSON @ jquery-2.1.4.min.js:4
reloadSettings @ base-settings.js:106
(anonymous) @ base-settings.js:173
j @ jquery-2.1.4.min.js:2
fireWith @ jquery-2.1.4.min.js:2
ready @ jquery-2.1.4.min.js:2
I @ jquery-2.1.4.min.js:2

here are the vids, just for the case:


Just to keep everyone else in the loop, I looked into this further with Skimi and then on my own.
I narrowed it down to the fact that the server runs out of RAM while trying to download and process the archive.

This is especially more likely to happen right after the server was setup since it might be baking the original assets for the first few minutes.
There are a few things we can do to reduce the memory footprint that we’ll be looking into.


@Skimi good news, I have a PR up that should fix the issue you’ve been seeing for servers with limited memory:

It probably will not make it to RC68, but it will be in RC69.

As I was working on this issue, I discovered a separate one where multi-gigabyte archives will fail instantly due to the library we use to transfer the file not handling files that big.
A bug has been filed separately and we’ll get to it as soon as possible.


Great news, thank you @c Clement. At moment I’m on vacation in dutch. Will try it when I’m back home.