Maybe the software has been installed in user mode, so the plan configuration files are located in your user folder, i.e.: C:\Users\%username%\AppData\Local\CloudBerryLab\CloudBerry Backup

You can actually type *.cbb into your Windows search field, and that should find those config files.

Sorry, no ETA.
The thing is, we are overhauling Archive functionality for Windows client now, this'll be one of our biggest updates. After that we'll get to Mac/Linux versions of the product.

Those are log files with auto-generated names, which means that those will not be considered as versions, but simply as new files with 1 version each. Un-checking "Always keep the last version" option should solve the problem. Note that you might want to set up "delay purge" parameter in this case to make sure that no files are purged by accident.

Hi!

Let me get this straight: you're moving data from one of your machines to S3 bucket and want to access it via mapped drive, is that correct?

If that is the case this setup is fairly easy to achieve by simply adding your storage account in our Drive software, but with 1 BIG caveat: managing 10 TBs of data with Int in real-time would be very stressful for the system.

Perhaps Cloudberry Explorer might be more up to the task. It's not interrogated in Windows Explorer, but it features 2-tab interface similar to Total Commander and it handles large data sets better.

If the files are simply de-selected from the plan they will not be automatically removed on storage side by design. In your case those files will never be purged since the retention policy is applied per plan.

Sorry, I was not clear enough in my latest message. In this case file gets deleted from both sides and that's it. "Track local deletes" only serves its purpose in one case: if you're restoring your data on another machine and select "restore deleted files" option. The software checks which files were deleted from source and restores them.

Yes, you are correct about re-upload. "delete files that have been deleted locally" option helps in these situations.

What David meant, in short, is that nothing changed in the functionality of the software. The options are the same, we just changed the names from FULL to INCREMENTAL to better reflect how the whole procedure works, that's it.

The backup plans need to be recovered from the backup storage tab, Just go there, navigate to the "Backup plans" section, right-click on the plan you want to restore and click "restore".

Can you please provide a screenshot of that pop-up?

First, regarding the backup operators group:
it is a local or global group that contains the user rights you need to back up and restore files and folders. Members of the Backup Operators group can backup and restore files and folders regardless of ownership, permissions or auditing settings. In short, it allow you to bypass permissions for your files.
You can find more info via Google.

As for the "Track local deletes" option, it does what it says in the tool tip:

The software places a special marker in place of a file when it gets deleted, so the next time you restore files on a different PC the application will be aware of that and you're be able to use "Restore deleted files" option. This is basically the only case where this option is needed.

Now, regarding the last question:
Nothing special will happen. Both options will work in conjunction with each other. The files in the cloud will be purged after they get deleted locally, and thanks to "track local deletes" option a special marker will be placed in the cloud to identify deleted files when restoring the data on another machine.

The whole functionality will be re-worked once we implement new archive and GFS features. For now please workaround mentioned in this thread. It'l work without any additional pre-action scripts.

It's a mutual decision that's been a long time coming. ACD might work fine with Explorer, but we can't recommend it for backup purposes.

Thanks for also creating a support ticket. Let's continue our communication there and then we can update this thread with our findings.

3) If you specifically copy a file or a folder within your data set it'll be duplicated, since to the application it'll be a new piece of data to back up, if that's what you're referring to.

If a file has been moved/deleted from source without leaving any copies on source location you will observe the same behavior, but you can enable "delete files that have been deleted locally" option, so the software will delete any files from destination once they've been deleted on source.

There is actually a workaround for that:
First, please stop the backup service by right-clicking on its icon in the lower-left corner of GUI and selecting "stop service'. Close the software now.

1) Navigate to your settings folder(C:\ProgramData\CloudBerryLab\CloudBerry Backup\ by default)
2) Find Enginesettings.list file
3) Open it with Notepad and find the following parameter:
<CostPriceGB>0.03</CostPriceGB>
You can change it to your liking.
4) After changing this string save the changes, re-launch the software and restart the backup service.

We've encountered similar issues before among a couple of other clients. Please do the following:
Go to Tools > Options > Logging and set High level of logging.
After that please reproduce the issue and send us the logs(tools > diagnostic). We'll escalate that ticket to R&D, once we receive that info.

Note that High logging level significantly slows down the software so please make sure you set back Low level after reproducing the problem.

The behavior you described is not normal, but maybe I don't fully understand your setup.

I would also avise against backing up Roaming folder in appdata and make careful selection of the files you want to back up. Appdata contains a lot of temp files and Roaming is a folder that gets recreated every time you log in on a new machine in domain, so it's not necessary to back it up.

Regarding your questions:
1) New files are taken into account automatically, you don't need to change anything, but these changes will be only applied in case the backup actually runs.

2) You can navigate to C:\ProgramData\CloudBerryLab\CloudBerry Backup\, find enginesettings.list file, open it with notepad and modify this parameter:
<RTBBackupInterval>00:15:00</RTBBackupInterval>

You can set this to any interval you want, but mind you system resources when doing that, please.

3) Not sure what you mean by that, but all the changes are picked up every time the software runs the backup plan.

As for your problem, please make sure you're using the latest version of the software(6.2.1.34), since it contains vital fixes related to real-time backup functionality, reproduce the problem, and then send us the diagnostic logs via tools > diagnostic menu. Please add a link to this thread in the issue description.

That is correct, but we're already working on enabling this functionality for hybrid plans, it just takes longer to implement it compared to regular plans.

The first upload will, of course, go through, but if it's a file that has been replaced with an old version then it won't be backed up due to time stamp being older than the one originally backed up.