More details on the error currently only can be found in the logs, so it's better to send them to us for investigation via tools > diagnostic menu. You can also click "open in folder" button to check them out yourself.

As for providing more info, we're working on a big update that will introduce error codes and provide more info regarding the error messages.

It's a known problem when using hybrid plans caused by files with the same modification date. Should be fixed in June. As a workaround you can use 2 separate plans instead of a hybrid one.

Couldn't find any info on that on the net, but it shouldn't cause any problems, as far as I'm aware.

This might require attention of our devs. Make sure you're on version 6.0.2 and send us logs via tools > diagnostic menu. Add link to this thread in the issue description so the ticket can be transferred to me.

In all cases like that it's best to contact support, since there could be several reasons for such things to happen(spike of I/O activity the disk caused by some other process, for example).

Glad to know that things got back to normal. Most likely that was just a temporary problem on Google's side.

Ouch, that makes things complicated. Even our support department would advise you to update if you create a ticket, but that will most likely "break" your installation without clean reinstall. Besides, if you're using the software on Server 2003/Xp, we've stopped support for these systems.

Here's what I propose: if possible, send us diagnostic logs via tools > diagnostic menu and specifically mention that these logs are for Matt and also paste the link to this thread in the issue description. The ticket will then be transferred to me and I'll see if I can help you with your problem.

May be a repository problem that some of our users experienced recently. Make sure you're on version 6.0.2, synchronize repository via tools > options > repository, and if the issue persists send us diagnostic logs via tools > diagnostic menu.

db ots Is right here, you need to make sure that our portal is reachable from that machine.
Here's an article that might help https://kb.cloudberrylab.com/managed-backup-service/mbs-tcp-ports-configuration

According to our bug-tracker that's a known issue. I'll add you to the list of people to be notified upon the fix being released and request update from our R&D. Let's continue communication in the recently created support ticket.

Re-sent activation email from our side. Check your spam folder, according to our monitoring tools these messages are sent correctly.

Yeah, it's a known bug, escalated the ticket to our developers. If anyone observes the same behavior during NTFS permissions restoration please send us diagnostic logs to speed up the process of fixing the problem.

They're not duplicated per se, we just introduced new universal delimiter for backups starting from version 6.0, nothing will change in terms of functionality or performance of the software.
This change allows to migrate local/cloud backups effortlessly without performing any changes to the data itself. Snowball import is also much more streamlined due to these changes.

Might be a repository corruption. Can you send me the ticket number via PM?

Looks like a known problem, will be waiting for the logs in our ticket system to investigate further and confirm that.

Yes, synthetic full won't work even with Glacier storage class due to API limitations, but we're working on that.

Don't have any particular info on why the release is delayed, so it's difficult to say what is the current status of implementation.

That's currently an expected functionality. AWS CLI uploads data simply as an archive without any tags to track the file. As far as I'm aware that's how most of the applications work when uploading data to Glacier.

Sorry, no news on that yet.

Sorry, no ETA yet. Extracting files remotely from an image-based backup is a little bit more challenging than simple file restore and we want to make sure we make it right.