Let me just add that currently scheduled bandwidth can only be switched between preset parameters(max 1000 Kbytes/s), but in version 5.9 you will be able to enter any number you want manually.

Hi,

This is actually one of the known issues we're currently working on. The fix is expected to arrive in version 6.0. I've already added you to the list of clients to be notified when it is released.

Judging by your screenshot the backup is still working. How long has it been stuck in that state?

Perhaps I misunderstood you, but if the VM backups are performed on 5.0 you most likely will encounter various compatibility issues during restore to 6.5.

I'm afraid that it will not be possible, please refer to this article: https://communities.vmware.com/thread/559000
This version is simply not backwards compatible.

Regarding your second question:
You can of course restore that backup to the cloud.

A lot of it depends on the hardware and software(AV/FW). In ideal environment it would be variant C, but as I've mentioned, it depends on various factors/bottlenecks, like cache settings.

Just an update in case anyone else encountered the same issue.

Looks like there were some problems with repository. Synchronization helped(although it took a while to complete) and that fixed the issue.

I left a reply for you in that ticket. Looks like you de-selected some partitions for the backup, so the data in that chain is not tied to the ones that were created after that.
You would need to delete those backups manually.

Reducing the thread count in tools > options > advanced might help, but that is not a guaranteed workaround.

Any possible automation is prohibited in the free version. You can only change storage class for the already uploaded files.

Regarding how files appear on storage side: Do you see that files were already transferred to IA in AWS console? Did you try refreshing the tab in Explorer after confirming that the files were moved?

1) It would be better to make sure that the folder path on source mirrors the original one. Usually you can simply modify the path on storage side, but due to Glacier specifics you need to make sure everything stays the same on that machine.

2) Yes, that is possible. You can read about that here: https://kb.msp360.com/cloud-vendors/seeding-data/seeding-data-via-cloudberry-backup-part-ii

3) I'm afraid that won't be possible, at least not yet. Linux backups to Glacier work via lifecycle and you won't be able to put the data into the same vault.

Hi! Feel free to ask questions here. If you think that some topic is too expansive you can create a separate thread for it.

Ok, thanks! Forwarded that info to our R&D.

Currently this is not yet implemented.
Could you clarify how/where do you want to this to be seen in UI so that I pass this info to our developers?

That version didn't entirely fix the issue, so it still happens on some configurations. A hot fix is in the works and will be deployed in version 5.8.7.

First of all I would suggest to double-check if you have followed all setup instructions thoroughly.

You can refer to out product blog articles:
https://www.msp360.com/resources/blog/how-to-do-a-full-server-restore-on-amazon-ec2/

Make sure that you have configured vmimport role correctly:
https://www.msp360.com/resources/blog/how-to-configure-vmimport-role/

In order to restore your backup as EC2 instance you need to grant the following permissions to your Amazon Web Services user.

"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:ImportInstance",
"ec2:ImportImage",
"ec2:RunInstances",
"ec2:DescribeInstances",
"ec2:MonitorInstances",
"ec2:RequestSpotInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"ec2:TerminateInstances",
"ec2:ModifyInstanceAttribute",
"ec2:CreateTags",
"ec2:CancelImportTasks",
"ec2:StartInstances",
"ec2:DescribeConversionTasks",
"ec2:DescribeImportImageTasks",
"ec2:ImportVolume",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:StopInstances",
"ec2:DescribeKeyPairs",
"iam:ListRoles",
"iam:CancelImportTasks",
"s3:ListAllMyBuckets"
],
"Resource": "*",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::{your bucket name}",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "ses:*",
"Resource": "*",
"Condition": {}
}
]
}

I mentioned that repository option is for backup software in case you still see the files there.

In case it's a purely Explorer issue it is better to troubleshoot it via our support portal, so please create a ticket regarding that here: https://support.msp360.com

In that case the files will be left on storage and will be available for restoration.

Do you mean that files are still visible in the backup software after being deleted via Explorer?

In that case do the following in backup software:
1. Go to Tools > Options > Repository and click on Synchronize Repository button.
2. In Synchronize Repository window select your Account from drop-down menu.
3. Click on Synchronize Now button.

Yes, it is better to update the software to the latest version. The log file you've sent is not enough, so after update start Backup Service under administrator account: go to Tools > Change Service Account, enter local administrator account name and password, click OK. The service will be restarted automatically.

If you still have any issues after that create a ticket at https://support.msp360.com