It's not safe to post your log files here, so I deleted them from the thread. The diagnostic info contains only "Access Denied" messages, they simply refer to the permission errors. Since we don't have any more info on that I'd suggest to contact Filebase support in regards to why this issue occurs.

I guess you're referring to RAIDS, is that correct? There shouldn't be any problems with the backup procedure in that case, so that's why we need the logs.

You can edit the plan and on source selection screen remove the files that cause this problem.

Haven't tested that cloud storage provider, but could you please send us the logs via tools > diagnostic menu? Please add a link to this thread in the issue description while sending the diagnostic info.

Looks like you have NTFS compression enabled on at least one of the volumes, I've only seen the software behaving in such a manner when this option is on. Double-check if that's the case and if nether compression nor encryption is enabled send us the logs for further investigation.

I guess you're referring to "GLOBALROOT" paths our software shows when encountering VSS-related errors. The problem here is that in very rare cases VSS can't upload EFS-encrypted files even with the correct service account. The issue will be fixed in version 6.3.1.

For now, as a workaround, I can suggest to create a separate backup plan for those files and disable "always use VSS" option, that'll solve the problem.

Depending on your cloud storage this error message can refer to time outs while trying to connect to the backup destination or simply that your credentials have expired.

Judging by the error message it's Azure, so more plausible reason is that clock is not correctly synchronized on the machine. Make sure that your time zone is selected correctly and the problem will solve itself.

Well, currently we use only one database, but it tracks file changes per destination, so if you're using 2 plans with each own destination you don't need to perform additional syncing, the software should work fine with the default parameters.

Send the logs from the software(tools> diagnostic) to investigate that properly. Don't forget to add the link to this thread in the issue description.

Hi!

Yes, you need to synchronize the repository database before each run to achieve that.
Go to C:\ProgramData\CloudBerryLab\CloudBerry Backup(that's the default location) find the .cbb file of the plan you want to sync, open it with Notepad, and look for <syncbeforerun> attribute. Change it to true and save the changes. That will be enough.

You can use scheduled restore plans in the backup software to do that.
Simply install it on the machine where you want the files to be restored, add the same backup destination as on the backup machine and select the same backup prefix.

1. Select Save restore plan option during the plan creation

2. SelectLatest Version as your restore point

3. On the database selection screen specify what needs to be restored

4. On the destination step specify if you want to only restore new files or maybe if you need to overwrite some of the old data.

5. Specify encryption pass at the encryption options screen.

6. Finally, specify schedule for your backups and tick the "Synchronize repository before restore"

Save the changes and then your plan will run automatically by schedule. Note that synchronization procedure will make the plan run a little bit longer, but everything will be performed automatically.

Most likely the files you're referring to are "orphaned". The easiest way to fix this would be to start from scratch, to be honest, but I understand that you want to keep as much of your data as possible.

By the way, do you currently use file name encryption? In that case there's another thing I can suggest:
You should see both CBB and ECBB folders on storage side. If you no longer need unencrypted backups you can safely delete CBB_%PREFIX% folder from the cloud and only leave ECBB.
After that you need to do the following:
1) Navigate to the Welcome tab in software GUI

2) Find "Storage Accounts" section, click on the hamburger menu for that storage account and select "Schedule consistency check"


3) Specify the same password you used to encrypt your files and click "Run now"


4)After consistency check finishes its job you should see updated storage.

I have another update from R&D: we no longer provide early builds due to QA decision, unfortunately, but the official release should happen very soon, so for anyone affected, please be patient, we're working on this on top priority.

That's a tricky situation. The files themselves are not really associated with the plans once they are in the cloud. If the data set is exactly the same you can the versions on the backup storage tab.
Overall, the old file versions will be purged according to your retention policy. Again, that is only if the data set is exactly the same with the folder structure kept intact throughout the procedure.

That is usually not required.
For local files simply enabling backup operators option is enough in most of the cases, changing service account is not necessary.

For network shares make sure that your network creds have full access to the files.
If that doesn't help try changing service account to administrator one.

If nothing helps - please create a ticket in our support system.

You can click "I don't have the code" button and use your email to register, that should work.

That's a known problem. Will be fixed in 6.2.1, according to the latest info.

I guess in your case it would be more efficient to investigate this with our Support team. Please send diagnostic logs by going to CloudBerry Drive tray icon, right-click and choose Diagnostic, use "Send to Support" button there. Don't forget to add a link to this forum thread in the issue description.

Sorry, no updates on that so far.

If you switch the view to "Files" you should see the files/folders that cause the problem. Usually simply enabling "Use Backup Operators" option for a plan solves issues like that.