red exclamation mark "cannot confirm integrity"?

[parajbs]

Hello

I made two backups that are stored locally! (1.3 GB per backup) So far, but in the Issue column there is a red exclamation mark "cannot confirm integrity" What does the red exclamation mark "cannot confirm integrity" mean?

I found no nextcloud error logs!

I think the backups are complete! But haven't tried a restore yet! I really wanted to know what the red exclamation mark means and whether the backups are ok!

I need HELP urgently !!!!!!

my data: root server 1TB ssd nginx docker-image as reverse-proxy

Nextcloud 23 ogrinal docker-image: apache2 / stable-security, now 2.4.51-1 ~ deb11u1 amd64 [installed] Apache HTTP Server

php --version PHP 8.0.13 (cli) (built: Dec 2 2021 13:29:44) (NTS) Copyright (c) The PHP Group Zend Engine v4.0.13, Copyright (c) Zend Technologies with Zend OPcache v8.0.13, Copyright (c), by Zend Technologies

mysql --version mysql Ver 15.1 Distrib 10.5.6-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

[mastermns]

Hey,

the backup script should also run a verification of the backup this did not work for you. Either the script did not run or ran into an issue.

To check the integrity of the backup you can simply run " occ backup:point:scan" for the backup to be checked (this will take a while)
You should see a php job which consumes a lot of CPU performance .

Advantage of running it via console is that you will get an output :)

Cheers

[parajbs]

Hello Meisterwerke,

No error occurred with either backup! (no errors in the log)

I just executed the command "occ backup: point: scan" and it ran without errors in about 15 seconds! I executed the command a second time! It also ran for about 15 seconds!

There is still a red exclamation mark "Cannot confirm integrity" in the Issue column! Nothing has changed!

Or do I have to create a backup afterwards?

I will only create a new backup, if it still shows errors, then I will update to the new version 1.01 and try everything again!

If you can help with the problem, you can continue to write here!

[mastermns]

Good morning,

please send the outcome of "sudo -u www-data php occ backup:point:list"

Thanks

[parajbs]

Hi Sorry that it took so long! I updated to 1.0.1 first, then to 1.0.2, but both updates were broken! Now I have updated to 1.0.3, then I entered all local commands as the user www-data in the console!

1. ./occ backup: point: create 2 ./occ backup: point: scan 3 ./occ backup: point: list
2. ./occ backup: point: details 20211217004819-full-3NjU6xhzI6pQSJ5 5 ./occ backup: point: pack 6 ./occ backup: point: scan 7 ./occ backup: point: list
3. ./occ backup: point: details 20211217004819-full-3NjU6xhzI6pQSJ5
4. ./occ backup: point: upload 20211217004819-full-3NjU6xhzI6pQSJ5

Between each step I checked the website to see if the red exclamation mark "cannot confirm integrity" is set!

The red exclamation mark "cannot confirm integrity" comes after the 9th step!

Here step 9 output:

./occ backup: point: upload 20211217004819-full-3NjU6xhzI6pQSJ5

• uploading 20211217004819-full-3NjU6xhzI6pQSJ5 to external folders
• checking external folder 3: bak55

restoring point not found

• Creating Restoring Point on external folder: ok

restoring point created

• initiating health check

Health status: 0 correct, 19 missing and 0 faulty files

• Uploading data / data-d7c0c14b-c860-4982-a404-1364a069b5ba / 00001-2KSXq1sHfCmV6M7: ok
• Uploading nextcloud / nextcloud-a61ab80b-235b-47f7-aaca-8aa67391a382 / 00001-cSLXUyn6fUYsr4Q: ok
• Uploading nextcloud / nextcloud-a61ab80b-235b-47f7-aaca-8aa67391a382 / 00002-eUdSNtgghBOSyuK: ok
• Uploading nextcloud / nextcloud-a61ab80b-235b-47f7-aaca-8aa67391a382 / 00003-GKRjkz2i8DVYWUj: ok
• Uploading nextcloud / nextcloud-a61ab80b-235b-47f7-aaca-8aa67391a382 / 00004-C43aX2hEB8lGc66: ok
• Uploading nextcloud / nextcloud-a61ab80b-235b-47f7-aaca-8aa67391a382 / 00005-t1VgM6PuiyrJzVG: ok
• Uploading nextcloud / nextcloud-a61ab80b-235b-47f7-aaca-8aa67391a382 / 00006-85E75LLOUJ3yhv9: ok
• Uploading apps / apps-0c73d133-c162-4b0f-9f32-616a37f5b384 / 00001-r67Er5haHOBUZsx: ok
• Uploading config / config-4b3d2b9f-b1bc-4a88-a202-37794a950a53 / 00001-ctWwIIkP8WGZXJ5: ok
• Uploading apps-apps-2a858c4c / apps-apps-2a858c4c-455a30a6-b4a8-4c31-8b44-7f511f248f92 / 00001-HcHpIUuFqSLJNgy: ok
• Uploading apps-custom_apps-9081f5ee / apps-custom_apps-9081f5ee-89126272-bdbc-4b3b-acda-1408fbbe8677 / 00001-xLgeAr7cW12IHA8: ok
• Uploading apps-custom_apps-9081f5ee / apps-custom_apps-9081f5ee-89126272-bdbc-4b3b-acda-1408fbbe8677 / 00002-T29RLbhNEYRg5ni: ok
• Uploading apps-custom_apps-9081f5ee / apps-custom_apps-9081f5ee-89126272-bdbc-4b3b-acda-1408fbbe8677 / 00003-aCA4bdOkrvVrkTU: ok
• Uploading apps-custom_apps-9081f5ee / apps-custom_apps-9081f5ee-89126272-bdbc-4b3b-acda-1408fbbe8677 / 00004-AcpWVCZO1sDMgt8: ok
• Uploading apps-custom_apps-9081f5ee / apps-custom_apps-9081f5ee-89126272-bdbc-4b3b-acda-1408fbbe8677 / 00005-UuaAU9LCLniT7bf: ok
• Uploading apps-custom_apps-9081f5ee / apps-custom_apps-9081f5ee-89126272-bdbc-4b3b-acda-1408fbbe8677 / 00006-HF8arAjzoj45cN4: ok
• Uploading internal / app.zip: ok
• Uploading internal / restore.php: ok
• Uploading sqldump / sqldump-b7e8165f-748d-4d55-9876-c2420039535f / 00001-k4fGPqfUeqd8eQM: ok

###########################################################

The only thing I noticed: Health status: 0 correct, 19 missing and 0 faulty files

What does this mean? Otherwise there were no errors, except for the error on the website red exclamation mark "cannot confirm integrity"!

I also tested everything on local storage, with the same error!

[parajbs]

Hallo mastermns

Here: ./occ backup: point: list

• Retreiving data from local

found RestoringPoint 20211217004819-full-3NjU6xhzI6pQSJ5

• retreiving data from external: 3

found RestoringPoint 20211217004819-full-3NjU6xhzI6pQSJ5

• -------------------------------------- + ---------- ----------- + ----------- + ---------- + -------- + ------ --- + ----------------------------- + ------------ + --- ------ + - + | Restoring Point | Date | NC | Database | Parent | Comment | Status | Instance | Health | |
• -------------------------------------- + ---------- ----------- + ----------- + ---------- + -------- + ------ --- + ----------------------------- + ------------ + --- ------ + - + | 20211217004819-full-3NjU6xhzI6pQSJ5 | 2021-12-17 00:48:19 | 23.0.0.10 | mysql | | | packed, compressed, encrypted | local | 38M ago | | | | | | | | | packed, compressed, encrypted | external: 3 | 36M ago | |
• -------------------------------------- + ---------- ----------- + ----------- + ---------- + -------- + ------ --- + ----------------------------- + ------------ + --- ------ + - +

[mastermns]

Health status: 0 correct, 19 missing and 0 faulty files

What does this mean? Otherwise there were no errors, except for the error on the website red exclamation mark "cannot confirm integrity"!

I also tested everything on local storage, with the same error!

This only means that your external folder did not have any data yet, the command "./occ backup: point: upload 20211217004819-full-3NjU6xhzI6pQSJ5" will trigger the upload process again.

From the outcome of "./occ backup:point:list" i would say everything looks good - is the red exclamation mark still there ?

[ArtificialOwl]

Side note: the :scan command will only add a backup to the list, this can be used when having a backup in your appdata that is not available in the list.

The :details command should recreate an health check so you can see which file have be correctly uploaded.

Your metadata are signed to confirm its integrity. If after everything you still have an error, it might comes to the fact that you have a different key-pairs. Might also mean that you have a different encryption key, this is why you should export the setup of your backup apps.

[mastermns]

Hello,

I just ran into the same issue. The health check for the local backup is fine, but for the external storage I receive (cannot confirm integrity)

"webdav::[email protected]//users/ - (cannot confirm integrity)"

I tried running the details command with --external but this ran into a different error

"sudo -u www-data php occ backup:point:details --external external:30 20220107003456-differential-L9ViVpOq5KPOOrB

In ExternalFolderRequestBuilder.php line 108:

[OCA\Backup\Exceptions\ExternalFolderNotFoundException]

Exception trace: at /var/www/html/nextcloud/apps/backup/lib/Db/ExternalFolderRequestBuilder.php:108 OCA\Backup\Db\ExternalFolderRequestBuilder->getItemFromRequest() at /var/www/html/nextcloud/apps/backup/lib/Db/ExternalFolderRequest.php:102 OCA\Backup\Db\ExternalFolderRequest->getByStorageId() at /var/www/html/nextcloud/apps/backup/lib/Service/ExternalFolderService.php:146 OCA\Backup\Service\ExternalFolderService->getByStorageId() at /var/www/html/nextcloud/apps/backup/lib/Command/PointDetails.php:157 OCA\Backup\Command\PointDetails->execute() at /var/www/html/nextcloud/3rdparty/symfony/console/Command/Command.php:255 Symfony\Component\Console\Command\Command->run() at /var/www/html/nextcloud/core/Command/Base.php:168 OC\Core\Command\Base->run() at /var/www/html/nextcloud/3rdparty/symfony/console/Application.php:1009 Symfony\Component\Console\Application->doRunCommand() at /var/www/html/nextcloud/3rdparty/symfony/console/Application.php:273 Symfony\Component\Console\Application->doRun() at /var/www/html/nextcloud/3rdparty/symfony/console/Application.php:149 Symfony\Component\Console\Application->run() at /var/www/html/nextcloud/lib/private/Console/Application.php:211 OC\Console\Application->run() at /var/www/html/nextcloud/console.php:99 require_once() at /var/www/html/nextcloud/occ:11

backup:point:details [--output [OUTPUT]] [--remote REMOTE] [--external EXTERNAL] [--] <pointId>

Please check Thanks

[jxmx]

I am having this issue too. All backups are marked with the red exclamation mark. A backup:point:scan does not resolve the issue.

[kaibae19]

I am having this issue as well.

I set this up new a few days ago and it appears the backup job is running as expected and creating the restore point. I have mine saved to a SCP/SFTP server location. This appears to be executing as expected. The issue comes up in the verification of the data which, as I'm seeing a sshd login failure from my storage server from the Nextcloud Admin shell user, I am assuming the scripts are launching to run the verification and as the user does not align on the storage server, the login request is failing.

I am going to see about editing the cron job for my nextcloud admin to specify the user that I want it to connect as - however, it would seem that the solution here is to allow for users to configure the verification user creditials - or pick them up from the backup point configuration.

[jxmx]

See Bug #184. The external storage code doesn't have any validation function yet.

[XenonOrion]

Same issue here, hope this gets resolved soon 👍

[parajbs]

Hello XenonOrion

I don't think so. But one can hope. I have the problem even when I mount a local folder on the server as an external drive in Nextcloud. I've also tried smb, but the same problems appear. I could imagine that the bug is in the Nextcloud "external" module. Furthermore, the external storage providers must support the functions that are essential for integrity.

So I think it will take time to fix this bug. So far nothing has improved.

However, I looked at the code and made my own bash script. There is a new app in the apps store that can transfer user data to other servers. Haven't tested it myself, but sounds interesting.