Various improvements are planned for version 2.6 regarding SMB share functionality. You can send us the diagnostic logs via the feedback menu so that our support team could see if there are any errors during upload.

The files that failed for upload should be visible in the history section of the UI.

Glad to hear that! In case you encounter any other technical issues you can write to supportatcloudberrylabdotcom for further assistance.

What storage provider do you use? In case of S3 the first thing to check is if you have any bucket-side Lifecycle rules set up.

Thanks for the feature request. Passed this information on to our devs for evaluation.

Thanks for the update.

In general, those I/O errors are simply caused by a heavy load on the system, so running the backups during non-business hours should help.

If you've only recently started seeing these disk I/O messages then it may indicate hardware problems, it's probably time to check the HDD health.

More info on the event ID 12298 can be found here:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc734401(v=ws.10)
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd364875(v=ws.10)

Right-click on the "backup service stopped" message in the lower-left corner of the UI and select "start service". If the issue persists it's better to send the logs to our support team via tools > diagnostic menu for additional investigation.

The software uses the default programs that were specified in Windows to open certain files, so you would first need to change that setting in Windows. Not sure I understand what you mean completely, so if I misunderstood you any clarifications would help.

We use gzip with our own proprietary algorithms for compression, so the files can only be recovered either via the backup software or Cloudberry Explorer(currently only for Windows).

Regarding versioning: it's better to disable S3-side versioning, since it could lead to the data being deleted by AWS without our software "knowing" about it or your S3 bucket can generate unnecessary versions of the files which could lead to potential confusion/conflicts during the data restoration.

Block-level option is actually still available if you use "keep bitlocker" option.

That's a very old guide from 8 years ago, so it will be easier to set it up natively in our software using 2 plans to avoid any issues with scheduling on Windows side, at least until we implement separate scheduling for each day of the week.

Do you mean somehow stopping our software by Windows Task Scheduler? Not sure if I understand you correctly and if that would be actually the most efficient way of doing things.

Currently this can only be achieved by using 2 backup plans, but I've filed a feature request to our developers to make it possible to specify schedule for each day of the week separately.

Here's an example of how to set up Mon-Fri schedule for the first plan



For the second plan you would need to simply select the same files and specify similar settings to the ones below:

Backups to Glacier are always considered "full" in the sense that if the files were changed in any way the software will re-upload them, unchanged files will not be re-uploaded.

Unfortunately, this is related to peculiar properties of Glacier storage class, block-level mode is not available for this destination. Perhaps previously you used S3 for your backups.

If you want to utilize block-level backups it's better to use S3. In case of Glacier the files that were not changed will not be re-uploaded, but the files that were changed will be re-uploaded in full.

Hi!

- When this option is enabled, the drive is backed up as is, with BitLocker encryption preserved. As a result, you will not be able to restore individual files from an encrypted volume afterwards. BitLocker encryption will be preserved for a disk image restored from such a backup.

- When this option is disabled, the backup service will decrypt the volume contents during the backup processing. A disk volume copy restored from this backup will not be encrypted as a result. This enables you to restore individual files from an unencrypted image-based backup.

BitLocker encryption is not preserved when backing up individual files and folders.

Ok, I guess it would be better to send us the diagnostic logs via tools > diagnostic menu. You can specify a link to this forum thread in the issue description.

Do you use file name encryption for those files? In that case files are not displayed by design.

This is a legacy functionality and provided "as is", we recommend using Cloudberry Backup to perform such operations.

You can use "custom" or "simple" mode backups to perform file transfers automatically by schedule without any issues.