I'd like to report a couple of bugs within the new backup specifically when pointing the backup repository to S3 / Cloudflare R2 or any other S3 bucket.
[root@cwp cwp-cloudflare]# grep -o '[0-9.]\+' /usr/local/cwpsrv/htdocs/resources/admin/include/version.php
1.30.5
[root@cwp cwp-cloudflare]# cat /etc/redhat-release
AlmaLinux release 8.10 (Cerulean Leopard)
[root@cwp cwp-cloudflare]# uname -r
4.18.0-553.176.1.el8_10.x86_64
1. When using test connection button the check fails.
(https://s3.praetorian.cloud/ShareX/2026/11/msedge_5v7JKbcXcR.png)
But if you remove https:// from endpoint URL the test works and connects to S3.
(https://s3.praetorian.cloud/ShareX/2026/11/msedge_1c2gNrsl9w.png)
Although if you save the backup job with those settings (no https:// in front of endpoint url), the actual backup job will fail due to non specified https:// protocol error seen in the log.
So, you need to save backup job with https:// in endpoint url even though its counter-intuitive since then the self test fails. This will ensure the backup will work regardless of failed test in backup job wizard.
(https://s3.praetorian.cloud/ShareX/2026/11/msedge_6wIW7nKPf3.png)
2. When trying to test a restore account, the S3 repository used in backup job can't be accessed by CWP and it doesn't let us select an account to restore.
(https://s3.praetorian.cloud/ShareX/2026/11/msedge_LVCETsniMQ.png)
If the backup is saved locally, the restore works as intended.
Which means the issue is that CWP doesn't see the files it actually did upload to the S3 bucket 8)
I assume there is another config file responsible for restore jobs which is not visible in the web panel and might be using wrongly formatted api/secret key or endpoint url etc...
2026-11-08 12:29:00 S3 RESTORE: listing failed: An error occurred (NoSuchKey) when calling the ListObjectsV2 operation: The specified key does not exist.
It feels as if the folder/location in bucket is appended to the query which then searches for location different than what the backup job used.