File backup functionality is included in every version of the product, so you don't need to buy additional licenses.

There are no limits on files or upload size in the Ultimate version, so you've got nothing to worry about.

File name encryption is available for local backups, S3, B2. Azure, Google Cloud, all Openstack and S3-like storage providers.

Please open the command prompt, navigate to the user profile folder and run command "attrib". If the folder in question has "S" attribute, it means that the folder is considered a system one and it will not be copied unless you remove that attribute, or change backup plan to include system files.

Most likely the attribute was either applied manually or via inherited permissions.

System State backups are only available for Server systems. I presume the software was previously installed on a different OS.

I'm afraid that such configuration is not yet officially supported, our software needs to have files fully locally available to be able to actually upload them.
I'm forwarding your message to our R&D guys, we'll see if it will be possible to implement such functionality in the nearest future.

Is the backup operator user an admin on that machine or just a regular user?
This seems to be related to Windows UAC limitations. Even during system state restore user folders(and you seem to be restoring that file to one) can appear empty due to permission issues despite backup operator being used.

Restoring to any other folder should work fine.

If the backup operator user is not an admin I suggest to simply add administrator account to backup operators group.
You can also modify permissions for that user folder manually.

If that still fails or the original backup operator is already an admin then we definitely need to see the logs and maybe even discuss this with our devs.

To actually use backup operator after that account is added to backup operators group you need to make sure the option "use backup operator" is selected when creating/editing the plan.

Hello,

Regarding your issue.

1. The error you're seeing during restore is related to NTFS permissions.
Please 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.

It is generally recommended to use local administrator's account name because domain administrator is not always a local admin on the host machine.

Learn more: Backup for Windows - Backup Service explained.

2. AD warning messages can be ignored, they are irrelevant in this case.

3. Regarding the backup prefix(computer name): you can change it by editing your storage account and going to "advanced options" menu. There you can choose computer name. This is used to identify your data on storage.

So to fix the issue you just need to solve the permissions problem by making sure the software uses account that has full access to the files and folders, and then select your preferred backup prefix.

Yes, system-reserved partitions are essential if you want to restore that system to another machine.
If there is no such need you can only select disk C: for that plan.

Is this a SQL backup?
We are aware of such issue with database backup plans, the fix will be released in version 6.0.

At this moment we gathered enough false-positive examples from our clients. All of that data will be used for the fix that is coming with version 5.9(no ETA, but it will be released soon)
After 5.9 is released we'll monitor the behavior of this feature and request false-positive examples if needed.

These lines only show connection problems, the root of these issues is usually in the network environment. It is better to investigate full logs via the ticket system, since everything is properly categorized there. You can send them via tools > diagnostic menu.

If you see 4xx or 5xx(e.g. service unavailable) errors then the issue is on the storage side. B2 often have problems with their services, causing interrupted uploads.

Trial period is extended, as requested.

Just checked and this issue was fixed in 5.8.0.137, so this should work now. Let me know if you need trial extension.

It depends on the issue you were having with file-level restore of that particular backup. If you have a case ID, I could check and see if that particular problem was fixed.

Most likely you're using file name encryption, and those files are not visible in "restore-only" mode.
Files with regular encryption are not affected by this.

As a workaround please use trial version of the software and add account in standard mode, this will allow you to see your data and restore it.

We're planning to fix that in the future, but there's no ETA yet.

Since block-level backups rely on full backups to perform purge you will keep all of those block-level backups performed this day. The next time you run a full backup the software will detect all copies that are older than 1 day and purge them.

One thing to keep in mind: all of the data(FULL + Block-level) need to be older than one day, since FULLs can't be purged separately from DIFFs and vice-versa.

More info can be found here: https://www.cloudberrylab.com/blog/block-level-backup-and-full-backup-explained/

In case Windows native encryption (EFS) is used - you might want to follow the measures described on this page.
Please note that instead of SYSTEM you should use your Backup Service account (usually differs from SYSTEM)
https://superuser.com/questions/1014519/how-do-i-let-the-system-account-use-efs-encryption

In case third party (e.g. application internal) encryption is used - the data should be decrypted first.