New to the community? Start here

[Snapshot Pro] 504 GATEWAY TIME-OUT The server didn't respond in time.

Hello!

I have this issue where I cannot successfully start using Snapshot Pro on one site. Everytime time it ends with 504 GATEWAY TIME-OUT The server didn't respond in time.

Since it is hosted on hosting using cPanel, I have limited options to set crucial settings like MAX_EXECUTION_TIME, POST_MAX_SIZE, UPLOAD_MAX_FILESIZE, MEMORY_LIMIT…. I did my best using .htaccess (even found out technical limit which I cannot overpass)… I've read and studied some existing Posts on WPMUDEV regarding this subject etc.

There is now Updraft (free) in production as an offsite backup solution, but I would like to start using Managed Snapshot instead.

a) https://wpmudev.com/forums/topic/snapshot-interfering-with-updraft-plus

b) https://wpmudev.com/forums/topic/snapshot-fails-when-media-files-are-included

c) https://wpmudev.com/forums/topic/snapshot-pro-snapshot-not-completing-and-taking-site-off-line

Facts / settings:

— WP 4.9.9

— PHP 7.2

— cPanel 76.0.20

— Updraft free in production (working almost as expected) – exception for "Snapshot" folder

— Snapshot Pro to be used – exception for "Updraft" folder

— PHP options

max_execution_time 120

(this is max possible in cPanel PHP options, so it is overridden by .htaccess using value of 600 (at the moment) or even more; I've tried 800, 1000 and 1200)

memory_limit 512M

(this is max possible in cPanel PHP options and cannot be overridden by .htaccess…. if I tried, setting was ignored and dropped back to the default value of 128M)

— .htaccess

php_value max_execution_time 600

php_value post_max_size 100M

php_value upload_max_filesize 100M

— wpconfig.php

define('WP_MEMORY_LIMIT','512M':wink:;

define('SNAPSHOT_TABLESET_CHUNK_SIZE', 50);

define('SNAPSHOT_FILESET_CHUNK_SIZE', 50);

— Website size at the moment 3.2 GB (everything included)

— More than enough storage space left on server for local copy (temp), which is 6.1 GB used out of 20 GB

Please advise / help / … Thank you!

Best Regards,

dg

Tue, 5 Mar 2019 12:45:42
More Snapshot Pro discussions
Snapshot Pro
  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    Thank you for providing all the info and a detailed description of what you did up to that point! It’s always helpful in debugging.

    I tried running a backup and it finished with the same error.

    My guess is that the PHP settings are still not enough to make Snapshot work with a 3GB site. But you might give it another try – please set up and run a scheduled backup. It may work, especially since the settings you added to wp-config are used for scheduled backups only.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hum, I tried N tries today and it just doesn’t want to start any Scheduled backup. At first, I didn’t like the choice of only “rounded” hours at xx:00, but than I figured out that system stamps/adds minutes based on the time when you schedule backup = smart.

    So the latest try should have been at 14:43, because I’ve set it up at 13:43. At the moment, time is 14:53 and Job wasn’t started / run.

    It was exactly like this before noon today for 2 times. I even tried Managed backup with scheduled time and nothing happened. Weird.

    Maybe I am doing something wrong, maybe it is about the time difference between WPMUDEV systems and my local time?! I don’t know.

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    Thank you for the update. The backups run on WordPress cron, so they are not precise (and they can’t really be). It depends on whether someone visits your site, because only then WP can notice whether there’s a job in the queue to be done and the time is right (ie. scheduled timestamp > current timestamp).

    As for the time settings – that shouldn’t be a problem.

    I’ll try to run Snapshot now, but in the meantime you may look if there’s a /wp-content/debug.log

    Also, please and add this to your wp-config.php:

    define('WP_DEBUG', true);
    
define( 'WP_DEBUG_LOG', true );
    
define( 'WP_DEBUG_DISPLAY', true );
    
define('SNAPSHOT_BACKTRACE_ALL', true);

    This adds another level of debug info and creates a debug file in case it’s not enabled.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hello Pawel,

    thank you for fast response and explanation. I have just added DEBUG settings into wp-config. I just that WP_DEBUG_DISPLAY set to TRUE will not show errors to users – just a precaution, since I am not sure how exactly that “DISPLAY” prompts in action..

  • damyang
    • Site Builder, Child of Zeus

    This is interesting. I’ve checked file system and all today’s tries are documented there. Every folder for Snapshot try contains zip file at approx 400 MB. It was failed try obviously, since Snapshot dashboard says None for Last Snapshot. As I mentioned, I tried to set “one time” Managed Snapshot and that folder is empty. See screenshots…

    It is nice to see that even my “14:00” set up tried at 13:48 as it can be seen from screenshot.

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    This certainly shows that the backup part of Snapshot is working. I think the server may have still ran out of resources, even with higher settings for memory and execution time. I’d like to investigate further by looking at the files via FTP or cPanel.

    Would you mind sharing access credentials with us so I can take a look at possible causes of this issue?

    Note: Don’t leave your login details in this ticket.

    Instead, you can send us your details using our contact form https://wpmudev.com/contact/#i-have-a-different-question and the template below:

    NOTE: Don’t change selected topic in the dropdown, just leave it at “I have a different question”.

    Subject: “Attn: Pawel Pela“

    – Site login URL

    – WordPress admin username

    – WordPress admin password

    – FTP credentials (host/username/password)

    – cPanel credentials (host/username/password)

    – Folder path to site in question

    – Link back to this thread for reference

    – Any other relevant urls/info

    Please reply in this thread once you send the credentials.

    As for the WP_DEBUG_DISPLAY define, you can set it to false, so errors won’t show up on the site. They will still be recorded in debug.log – so please always take a look if there’s something Snapshot is telling us there.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Good evening! Well, maybe it something else, because I am not sure in which time zone you are operating… :slight_smile: Thank you for your cooperation and a will to proceed with further investigation.

    Regarding WP_DEBUG_DISPLAY, I’ve set it to False. In the late afternoon I was observing debug.log how it is rapidly gaining size so logging obviously works. If I find something usefull there, I will let you know.

    I successfully shared access using contact form so you are free to check it out…

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    I hope you’re well today and thank you for the update!

    First of all, enabling debug provided us with some useful data and we can now remove the debug lines from wp-config.php for the time being. I’ll do that in a moment.

    I received the credentials from you and was able to log in to cPanel. This allowed me to take a look at the logs generated. I downloaded them and I’ll look for solutions now.

    I’ll update you as soon as I find anything, but for now I just wanted to give you a heads up so you know why I disabled debug.

    Kind regards,

    Pawel

  • Pawel Pela
    • Ex Staff

    Hello again Damjan!

    I've found a couple of issues with configuration on your server. Please take a look.

    In your wp-config.php you added Snapshot's defines at the end of the file, so they weren't included at all. I moved them above the line which starts with "/* That's it, stop editing" because all defines have to be there, or they will be ignored. Moving those lines there didn't unfortunately solve the issue.

    The backup process seems to be running, there's no issue with it. As you said earlier, there are some partial zip files remaining after failed backups. You can delete them btw and also the log files (/error_log, /wp-content/debug.log and all the logs in /wp-content/uploads/snapshot/_logs/).

    Another thing is that Snapshot is using PHP to create backups. Normally, when a server's configuration allows this, Snapshot uses a much faster method by executing commands directly on the server. When the admins disable this functionality, it falls back to a slower PHP method. You can talk to the server admins and ask them to enable exec() in PHP, but they rarely agree to do it because it opens up a security hole. Definitely it's worth to try, and please explain that you need this functionality to make automated backups.

    You will notice the most important issue when you run a backup and log in to your cPanel. In the sidebar on the right you should see some meters. One of them, the I/O meter is the most important here. When I tried running Snapshot backup, the meter filled almost to full capacity (and turned red). This means that your server is running out of resources while performing backups and the process gets killed by the operating system. You may want to ask the server admins to give you some additional resources to work with – I think it's more probable they will agree to this than to enable exec().

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hello Pawel,

    thank you for your time and excellent support. Regarding I/O meter; I’ve noticed that in the past and already moved customer to better Hosting package, but to be honest it’s pretty much the same except more storage :slight_frown: I don’t think customer will be willing to pay more, “just to enable backup”, especially since Updraft works OK now. It is more about me, who wants to switch to Snaphost, just to get as much possible plugins under one Vendor’s roof and get PRO edition along as well. If one asks Hosting provider, they already guarantee backup as well, where I am not aware if it is offsite or not. I will check, because now it started to interest me.

    I deleted Log file and those Partial backups as you suggested; it was already on my radar :slight_smile:

    And finally, I opened support ticket to Hosting provider with your findings and request for comment and/or action from their side. I will report here as soon as they get back to me.

    Until than, thank you again and have a nice time!

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    From my side I would like to thank you for your cooperation, because your feedback proved to be very helpful and crucial to solving this issue! I’m also happy to hear about your plans to use our plugins and services for your needs on a regular basis – I’m a fan of them as well and I do enjoy the experience, so I understand you perfectly.

    Since you enjoy our plugins, maybe you will be interested in using our hosting service as well? We’ve rolled out new hosting plans a couple of days ago. Definitely worth checking out. It also integrates smoothly with all our plugins, especially Snapshot, so there’s an additional benefit. Here’s the page if you are interested: https://wpmudev.com/hub/hosting/

    I’ll be waiting to hear how it went with the hosting people. They might agree to some additional I/O if they are able to do it, it’s a 50/50 from my experience.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hello!

    Hosting provider processed my ticket. We already have top most powerful packet there is and beyond it, there is only VPS. They checked logs and observed lack of system resources sometimes and I suppose that is just in time with Snapshot.

    They are now asking if we are able to provide System Requirements for Snapshot?

    Thank you!

    Damjan

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    Nice to hear that your hosting company seems to be interested in helping you and they are looking for feedback.

    The requirements to make backups are never hard limits, as each site is different. It’s hard to say what amount of I/O will be sufficient, but certainly allowing for more I/O is the most crucial step here. In each case, this requires adding some resources on the server and checking if they are enough until you arrive at the right amount.

    As I said earlier, it’s best to make any backups using system commands (PHP function exec() runs those commands). This is much much much faster than using the built-in PHP support for making database dumps and creating zip archives. It also actually seems to be easier in terms of resource usage, because running system commands is directly handled by the operating system and the OS usually “knows” how to optimise this. It’s a bit more tricky if you’ve got PHP engine in between.

    I would say, that if your hosting company isn’t willing to enable exec() for you, they may try to add 50% more disk I/O and see if that’s okay for both you and them. Especially, since you are already using their largest package. You will be using this additional I/O only once in a while, when running backups, so this may not be a big deal, if they are able to do this.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Thank you Pawel, you are awesome. I totally understand your explanation and technicalities underneath. I hope they will be able to do something about it. I guess they are now collecting all possible information to be able to take considerable decision…

    Oh, I remebered your suggestion for trying WPMUDEV Hosting. I didn’t ignore that message, just forgot to comment it. I already know everything about it since the product was launched to Beta back in december. I am a fan of it and I am pretty impressed about the solution. In the matter of fact, I am just testing Shipper for some other sites and have opened case with Luis. It didn’t work, but I don’t care. I will move manually some production smaller sites and observe…

    I’ll get back to you with new infos.

    Damjan

  • damyang
    • Site Builder, Child of Zeus

    Hello!

    I hope you've had a great weekend. Few hours ago a reply came from hosting provider and it's got some happs news. There's a well known fact that PHP exec() is disabled by default – obviously – we all know that. What is not so common, at least for me and until now, that it can be easily enabled by cPanel's PHP settings :slight_smile: Please see screenshots attached.

    Now, when I tried creating local Snaphot after exec() was enabled, the same error appeared – I waited for it / or successful Snapshot, while writing this message.

    What I don't know is, if the new setting was applied yet or not… I am not sure, what should have been done to be sure it's effective. If the server would be mine, I would restart at least Apache, but here I can't do it.

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    That’s great news! Yes, the changes you’ve made should be working now. One thing though, please still take a look at the hosting’s admin panel statistics while creating backups. There should be a noticable change in usage if the settings have been applied. Before it was showing 80-90% of I/O usage, as far as I remember. And the meter was red.

    I would check it myself, but the credentials I’ve got don’t work anymore and there’s no Support Access enabled.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hello Pawel,

    Regarding access hit me this morning, so I went and enabled it now for 2 weeks :slight_smile: I did check I/O monitor while Snapshot was started, but I checked only at the beginning for few seconds and it was “normal” or let’s say expected. It was way below red, somewhere between 40-60%. But as I said, maybe it went up later… I forgot to check it later while running.

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    I can see the exec() Snapshot completed successfully – that’s good.

    I logged in to your site and ran Managed Backup to check how that goes, but because I’m currently on mobile internet, my connection sometimes drops – so I scheduled a Managed Backup for today. Please check in a couple of hours how it went. It’s currently set to Daily, so please disable it once it runs. I also monitored usage stats shown in cPanel – they are high, but less than what was before, so that’s good and expected.

    Still, please check the Metrics >> CPU Usage page in cPanel, after you go there, the [Details] provide some charts on the resource usage if you don’t want to stay and check the stats in person.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hey!

    I managed just to check your reply and see charts today – screenshots attached. I marked I/Os produced by Updraft with blue for comparison with Snapshot, which are marked by yellow. Snapshot Scheduled backup at 2pm was not successful.

    What I find interesting is that it always fails at different file, but every time it gets to cca 409-509 MB. It’s feels like maybe there comes some kind of a “kill process” command from servers side, because it “thinks” that the process is not running or sth like that. Weird.

    Damjan

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    Hmmm, yes, that may be it – processes often get killed if they are using exceeding allowed resources. I don’t know the exact configuration of that server, so I can only take an educated guess that it’s a combination of I/O usage and the duration that triggers this action. Also, another factor is current server load – the operating system may be set to decide to kill the more resource heavy processes to ensure equal access for other websites on that machine. This may explain why the process stops at different files – the OS reaction time may vary here, for example one more visitor to some website may trigger this at any moment.

    On a side note, please also allow system and shell_exec in addition to exec and see if that helps. From the logs it seems like Snapshot is still falling back to the PHP method.

    It comes to my mind that maybe this is because there is no zip command installed on the hosting or it is not allowed to be run from PHP (or simply not be in the search path), so even if Snapshot is able to execute system commands, it can’t use this method. Please ask the hosting people if they have it and if it is allowed to be executed from PHP at all.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Thank you Pawel,

    I disabled “system” and “shell_exec” as well, tried again, same issue. I will go now and represent attached charts to the hosting people and ask for at least trial of increasing I/Os. It is more than obvious that “sh*t hits the fan” :slight_smile: It is much more clearer image when filter is set to minutes.

    I’ll report back to you…

    BR,

    Damjan

  • damyang
    • Site Builder, Child of Zeus

    I remembered that it would be at least interesting to see, what Updraft is doing, while it's processing backup. As I can see from attached table it is much more gentle with I/Os. It has more pauses during the process and when it goes to max, it's around 17000, which represents cca 85% of limit, where Snapshot goes to almost 100% and insists there until time-out occurs.

    This makes me think that there is a possibility, that Updraft first checks its limits per server, where it's running and than it limits itself to "85%".

    Do you think it is possible that one product would have this kind of logic implemented? And there I come with possible feature request or idea at least for Snapshot, regardless of Updraft?

    I am not aware how many issues of this kind Snapshot has – observing generally. Or is my case "one in a million"?

    BR,

    Damjan

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    Thanks for the update. I’m looking forward to hearing how the negotiations with the hosting company went!

    Actually, as you know, backups are kind of specific, in the sense that they are heavily reliant on hosting’s configuration and capabilities. So it’s a difficult task to make them work in every kind of environment. We sometimes do receive news from other members that they are facing similar issues – and we are usually able to tune some things to make this work.

    As for Snapshot vs Updraft I/O usage – I can’t say really, though I cecked Updraft a bit to maybe find out how it’s done, but couldn’t find the piece of code responsible for this. I think it may actually proactively split the work into smaller chunks, as you said. Nevertheless, I’ve got word from Snapshot developers that at this moment we are planning a major update to Snapshot’s backup engine which will – amongst other things – do something like you are talking about. So, since this is on our roadmap, I think creating a feature request here is not even necessary :slight_smile:

    I’ll be waiting to hear how the hosting replied. Then we’ll try to maybe fine-tune some settings.

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Execelent! I am really looking forward to improvements, no matter what they are, improvements are always welcome! :slight_smile:

    Until now, no feedback from hosting, I will report for sure. Thank you for clarification and great news about Snapshot’s roadmap.

    Damjan

  • damyang
    • Site Builder, Child of Zeus

    Hello!

    I don’t come with happy news from hosting. They actually came up with the question if we know or if we can estimate, how much time does the process of Snapshot take. And added immediately after that, that if it takes more than 120 s, they can’t do anything, because some global shared hosting settings take effect which can’t be changed. Only way out would be VPS of course. I get it.

    That made me think once again about everything from scratch. One of the most mentioned setting regarding all of this is “php_value max_execution_time”. So I wanted to observe what is happening into details. And measure time while at it.

    Note here: Hosting’s cPanel allows max_exection_time of 120 s (that’s why they mentioned this value), but at the same time they forgot I already override that with .htaccess and succesffully set it to 600 s. I’ve even tried 800 and 1000 and 1200 few weeks back, but it was all the same, so I’ve put it back to 600 and that’s how it is set until we are having this thread opened

    So… after backup was started I was refreshing Snaphost’s backup folder in file manager like crazy for some time and observing steps (Live log) of what Snapshot was doing. I believe you already know all of this, but this helped me understood few things.

    Based on this observation, I think every step it takes is the process of its own and for each one of them, timer starts for php max_execution_time. Because almost all of the steps are targeted for SQL DB Tables, these are very fast.

    But when it comes to the last step of backing up files, that takes a lot of time (depends on the total size of everyhing, especially Uploads folder) and here is where the fun starts.

    Since this page is having 3+ GBs and becaus this step is a single proces, it takes more than 600 s. (quite expected) Since I was observing all of this having stopwatch in action, I figured out that “504 GATEWAY TIME-OUT / The server didn’t respond in time.” happens right about after 600 s or 10 mins.

    I’ve intentionally change max_execution_time to 1200 and tried again. It didn’t matter. Same happend after 10 mins so there are really some global settings which overrides my .htaccess (which overrides cPanel).

    I think that with this we came to an end, because it seems that this concludes everything. I can’t do anything more. I guest I can disable Snaphost now and let it rest in peace until that major update comes around, which will hopefully change some mechanisms for me to be able to enjoy it. I guess you agree?

    Thank you for all your time and will to help. You definitely teached me some stuff on the way and I thank you for that as well!

    Best Regards,

    Damjan

  • Pawel Pela
    • Ex Staff

    Hello Damjan!

    I’m sorry that you faced this issue. Hopefully you will return when we release the big update!

    You did a lot of great debugging work in the meantime and that’s something worth appreciating!

    The hosting people may be right, although they should be able to override this value for one site. Maybe they are not happy to do it because they have some educated reasons like having a limited amount of resources and not allowing service interruptions for other sites. This may be the case with some hostings.

    With configuration, there are two approaches here when a global value is set: ignore user overrides or halt execution and give an error (usually 500 Internal Server Error) if user tries to override. Seems like your hosting goes with the first option, which is quite reasonable, and in my opinion better. You can actually check a lot of things about PHP on your host by placing a new file somewhere with the following contents:

    <?php phpinfo();

    When you access this file in your browser, it will print a lot of data about your current settings. What’s most important, it will show you the local and global values side by side, so you can compare and see if they were overriden or not.

    As I said, we are preparing an update to help with this exact situation where hosting setup limits how much can be done. I’ve subscribed to the appropriate task in our task app so I will get notifications when our developers post updates on their progress. I’ll have a link to this thread ready so I’ll come back here to give you an update before release. Maybe it will be possible to share the beta version so you can check it out, we’ll see, I’m not sure yet.

    Thank you once again for the patience and your work here!

    Kind regards,

    Pawel

  • damyang
    • Site Builder, Child of Zeus

    Hello Pawel!

    You bet I will return using Snaphost after it will be updated. In fact it will be left installed only with jobs disabled. I am more than willing to test beta version and become early adopter, when it will become available so I am really thankful you will leave a message once we’ll get there.

    Regarding “phpinfo.php”. Yeah, I know that, but I didn’t remember to check this upon hosting :slight_smile: I use it every time when I setup my own servers to check stuff, but I don’t know why it didn’t cross my mind to put the file here to check stuff :S Eh well, I will take some more time just to see settings, because I am curious.

    I will mark this case as Resolved now, so I will not “bother” you anymore. If not before, we will meet again when that update comes around… Thanks again for everything!

    Have a nice day!

    Damjan

  • damyang
    • Site Builder, Child of Zeus

    Hello Pawel and the rest of the team!

    I am sorry to reopen this thread, but I would like to know if there are any improvements on this yet, because I would really like to start using your awesome plugins for real, not just to observe and wait will happen (I have similar story with another plugins of yours). I am well aware that this is primarily issue with the hosting provider’s settings but nevertheless… I believe this one is far from being the only one. Thank you!

    Damjan

  • Kasia Swiderska
    • Support nomad

    Hello damyang ,

    I have spoken with Snapshot developers and they are preparing incremental backups for it. You can see it’s on the Roadmap https://wpmudev.com/roadmap/ for the plugin.

    It means that Managed Backups and Snapshots will be more reliable on hosting like yours.

    However, at the moment I can’t give ETA for this change.

    It will be a major rewrite of Snapshot and we are all eagerly waiting for it.

    kind regards,

    Kasia

  • damyang
    • Site Builder, Child of Zeus

    Hello! Major version is here for quite some time, I am well aware of that. When I will have a chance, I will test it out and provide feedback. I am not sure at the moment if 3rd party storage is supported, like Google drive etc?

  • damyang
    • Site Builder, Child of Zeus

    Hello! I am reopening this issue, now using the latest version of Snapshot Pro 4.3.2

    PHP is 7.4 now
    max_execution_time 120 (set in cPanel, but overriden by .htaccess, info below)
    max_input_time 60
    max_input_vars 5000
    memory_limit 1024M
    post_max_size 50M

    .htaccess
    php_value max_execution_time 1200
    php_value post_max_size 256M
    php_value upload_max_filesize 128M

    wp-config
    define(‘WP_MEMORY_LIMIT’,’512M’);
    define(‘SNAPSHOT_TABLESET_CHUNK_SIZE’, 100);
    define(‘SNAPSHOT_FILESET_CHUNK_SIZE’, 100);

    Snapshot Pro Log analysis
    =========================
    ONLY ERROR PART OF THE LOG:
    [error] 2021-05-07 21:39:15 The backup has failed to complete. The API responded with: snapshot_failed_UnknownError

    LAST PART OF THE LOG
    [info] 2021-05-07 22:12:01 Communication with the service API, in order to get region, was successful.
    [info] 2021-05-07 21:49:24 Communication with the service API, in order to configure destination, was successful.
    [info] 2021-05-07 21:48:54 Communication with the service API, in order to configure destination, was successful.
    [info] 2021-05-07 21:48:22 Communication with the service API, in order to update a backup schedule, was successful.
    [info] 2021-05-07 21:39:21 The plugin has completed the backup of all requested files.
    [info] 2021-05-07 21:39:17 The plugin has completed the backup of all requested files.
    [info] 2021-05-07 21:39:17 Communication with the service API, in order to retrieve snapshots, was successful.
    [info] 2021-05-07 21:39:17 Communication with the service API, in order to retrieve snapshots, was successful.
    [error] 2021-05-07 21:39:15 The backup has failed to complete. The API responded with: snapshot_failed_UnknownError
    [info] 2021-05-07 21:39:13 The API has requested the backing up of files.
    [info] 2021-05-07 21:39:02 The API has requested the backing up of files.
    [info] 2021-05-07 21:38:35 Snapshot has completed sending back the filelist to the API, so we’re ready to begin the actual backup of the files.
    [info] 2021-05-07 21:37:56 The API has requested the filelist for the currently running backup.
    [info] 2021-05-07 21:37:54 Snapshot has sent back the filelist consisting of 22594 files but the file iteration hasn’t been completed yet. Awaiting for the next filelist request from the API.