what's the backup agent's version? Have you opened a ticket in support by chance?

, thanks for the question.

It's not available via the API.
Though, it's available to download the logs from a backup client. This could be achieved with our CLI.
Do you have anything to call that command on your endpoints?

, let me describe a workaround while we don't have GFS in place:
It would require 3 buckets and 3 plans, each having it's own retention and destination.
But except for daily backups, I personally think that block level is not a good option that could makes your desired retention policy much longer.
Thanks

Can you please send a screenshot?
Is there any antivirus software on the machine?
Thanks

, we're about to release OTP (one-time passwords) that you can download and use instead of 2FA if/when it's not available.
In the meantime please reach out to support from the email which you used for the purchase. Also be ready to attach your invoice as proof.
Thanks

, let's cross the alert with your logs from the agent. My guess is that your agent's gotten updated and this is why the hash is different now.
Do you have the exact time when the alert triggered? If you do, then please send logs to our support with the link to this thread in the big field.
Thanks

James,
Here's an example:
Retention policy:
Condition A: Keep 2 versions.
Condition B: Delete after 90 days, always keep the last version.

If both conditions are checked then it will be: (A) OR (B).
In other words, if you run backup daily and files being changed, on day 3 it will start deleting the 1st version.
And in another case with the same conditions if a backup is running daily but files are haven't changed this will not be purged even after 120 or 365 days.

Hi Matheus,

My guess would be that antivirus or a firewall is preventing the agent from working properly.
Or in rare cases, it could be IPS (intrusion prevention system that decrypts SSL, inspects it and re-encrypts it on the fly).
Here's what has to be reachable by the agent:
https://kb.cloudberrylab.com/managed-backup-service/mbs-tcp-ports-configuration

Use this header: x-amz-acl:bucket-owner-full-control
Here's an article how to configure it:
https://www.cloudberrylab.com/resources/blog/how-to-set-custom-http-headers-for-amazon-s3-objects/

Hi Sean,
I'm afraid we don't have that.
We don't have PowerShell on bootable media.
And I'm not sure if WinPE supports NIC teaming in the first place.

Do you have your switch configured to Switch independent or switch dependent teaming mode according to the article below?
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nic-teaming/create-a-new-nic-team-on-a-host-computer-or-vm

1. It won't. You can go to Users->Users page and click on the red cross for a specific user which has a computer configured to. By clicking the red cross you will a pop-up that will show a selection of what to delete (all/specific computer/delete nothing, but the user reference). Deleting from Capacity report won't delete data in the cloud.

2. Folders in the cloud depend on users.
Go to Users->Users and click on the user icon on the lefthand side of the screen and you will see its user-id in a pop-up. In the bucket, it will be like %bucketname%\MBS-%user-id%

, what firewall are you using?
What is the version of the agent?

, looks like you're in restore-only mode.
https://help.cloudberrylab.com/cloudberry-backup/restore/restore-only-mode

Please click on the button above Restore button, click on "Edit accounts", then Advanced settings and untick "restore only mode".

Please let me know if it helps.

Can you please upload a screenshot?

Thank you for updating this thread with the link provided.

A piece of log provided is that sufficient.
It could be a permissions issue. Are you using an application key?
Please send logs (tools -> diagnostic) to support and add a link to this thread.
Thanks

Hi Tom,
Sorry to hear about your phone.
Recovery codes are on the roadmap, but there's no certain ETA as of now.
Your Central account is tied to your email. Please send an email to support from that email with a link to this thread.
Thanks!

>The problem is not lack of access to the EFS encrypted files

This is the problem. Local System account doesn't have access to those EFS encrypted files.

In any case on order to back those up you need to have read access. It's not about compromising, it's about backing up.

Thanks

try this: https://kb.cloudberrylab.com/standalone-backup/general/how-to-backup-efs-encrypted-files-with-system-account

The real-time schedule in the backup wizard that we have is a near real-time backup.
As of now runs every minute and pushes data to the cloud. It will never complete because the idea of it is to have its schedule to run every minute and upload changes to the cloud.
In other words, it pushes data, wait for 1 minute, collecting changes on the filesystem in the meantime and transfers the next batch of files.
Can you send a screenshot saying it will complete in 3 years? This is something unexpected, at least for me.