Open Kh3nsu opened 2 years ago
schroeder-dk
commented
2 years ago Hi, I've got exact same problem. Will now try to send app_data to default internal path to see if it changes anything.
and in the log:
During the backup, I see a lot of errors on . xxxxxxxxxxx/.nobackup and xxxxxxxxxxx/.noindex has no owner
schroeder-dk
commented
2 years ago So, now I changed from app_data mounted on another internal drive to default location and the problem's gone away as well as the backup itself in maintenance mode is 8-10 times faster (no kidding). Will it work if the alternative location is mounted as the default folder? Who knows.
deetuned
commented
2 years ago Will it work if the alternative location is mounted as the default folder? Who knows.
I can confirm this works. I mounted my external drive (originally intended to be local app data storage) directly to {data_dir}/appdata_{instance_id}/backup and the app is none the wiser. Managed to finally create and pack my first backup. Can't tell yet if it's uploading, however.
Kh3nsu
commented
2 years ago I was also able to successfully create, pack and upload my backups but only manually! On automatic backup creation I get those errors:
Error: fread(): Read of 8192 bytes failed with errno=21 Is a directory at /var/www/html/3rdparty/deepdiver/zipstreamer/src/ZipStreamer.php#359
<<closure>>
OC\Log\ErrorHandler::onError()
/var/www/html/3rdparty/deepdiver/zipstreamer/src/ZipStreamer.php - line 359:
fread()
/var/www/html/3rdparty/deepdiver/zipstreamer/src/ZipStreamer.php - line 213:
ZipStreamer\ZipStreamer->streamFileData()
/var/www/html/apps/backup/lib/Service/ChunkService.php - line 460:
ZipStreamer\ZipStreamer->addFileFromStream()
/var/www/html/apps/backup/lib/Service/ChunkService.php - line 353:
OCA\Backup\Service\ChunkService->generateChunk()
/var/www/html/apps/backup/lib/Service/ChunkService.php - line 148:
OCA\Backup\Service\ChunkService->fillChunks()
/var/www/html/apps/backup/lib/Service/PointService.php - line 259:
OCA\Backup\Service\ChunkService->createChunks()
/var/www/html/apps/backup/lib/Cron/Backup.php - line 156:
OCA\Backup\Service\PointService->create()
/var/www/html/apps/backup/lib/Cron/Backup.php - line 126:
OCA\Backup\Cron\Backup->runDifferentialBackup()
/var/www/html/apps/backup/lib/Cron/Backup.php - line 115:
OCA\Backup\Cron\Backup->runBackup()
/var/www/html/apps/backup/lib/Cron/Backup.php - line 97:
OCA\Backup\Cron\Backup->manage()
/var/www/html/lib/private/BackgroundJob/Job.php - line 54:
OCA\Backup\Cron\Backup->run()
/var/www/html/lib/private/BackgroundJob/TimedJob.php - line 60:
OC\BackgroundJob\Job->execute()
/var/www/html/cron.php - line 151:
OC\BackgroundJob\TimedJob->execute()The backup is getting created but never packed or uploaded. Or health checked.
schroeder-dk
commented
2 years ago I have lost faith in the solution, at least for now. Uninstalled and awaiting better fix, hopefully in future build.
deetuned
commented
2 years ago I was also able to successfully create, pack and upload my backups but only manually! On automatic backup creation I get those errors:
The backup is getting created but never packed or uploaded. Or health checked.
Perhaps this might be related to Apache's access to gzip? The module might be active/accessible by PHP in /etc/php/x.y/cli but not through /etc/php/x.y/apache2. Also check script timeouts, max filesize, and memory limits for Apache's PHP in the aforementioned configs.
deetuned
commented
2 years ago I have lost faith in the solution, at least for now. Uninstalled and awaiting better fix, hopefully in future build.
I share the sentiment (still haven't got a single working backup since installing the app 3 weeks ago), though it seems there are external factors impacting the Backup app's functionality* so I'm not holding grievances with the solution itself for now.
By the way, if any devs of the Backup app are reading this, is it possible we could have any opinions or comments on this matter? This app seems like the perfect match for my small-scale scenario and I would appreciate even the knowledge that you're aware of the issue. :)
I'll be leaving the app installed for easy notifications of published updates, though I'll obviously be without a backup for a while longer.
curl and curl's ability to actually operate in this manner (see here). There has been a proposed fix for the Nextcloud v25 beta, though it hasn't yet been merged and I am yet to see any discussion on backporting of the fix to v24. It seems this might also be impacting the file streams on external storages in general, too.
DoumeDuSud
commented
9 months ago I face the same issue. (Debian 11, Nextcloud 25.0.13, Backup Apps 1.2.0
I move the apps data outside of the nextcloud app data on BTRFS drive.
For each Chunk I have this error at the end of encrypting :
cercle-admin@cercle-peer-1:~$ sudo -u nextcloud php /var/www/nextcloud/occ backup:point:pack 20240202222633-full-91uqSUNZiXEqOe5
Packing Restoring Point 20240202222633-full-91uqSUNZiXEqOe5
> lock and set status to processing
> Browsing RestoringData data
> Packing RestoringChunk data-f8265967-4a07-43fb-8bcb-f60d44990d6e: already packed
> Packing RestoringChunk data-1d88a9ff-8a41-498b-a0db-509feee5ca15: already packed
> Packing RestoringChunk data-9ecb7403-59cc-467c-a8e3-fcb6c7049aec: already packed
> Packing RestoringChunk data-db6b2b9d-32b9-456f-911f-1b5b17f95d61: already packed
> Packing RestoringChunk data-01304f74-c16c-4cea-bf90-3fadd6c61938: already packed
> Packing RestoringChunk data-6a39111f-ff7c-40a9-ba58-c18d7ab4087c: already packed
> Packing RestoringChunk data-5c5f30df-0904-400c-89c5-07baa6d193ac: already packed
> Packing RestoringChunk data-5211177d-4b53-4e8a-817b-8e28bb578340: already packed
> Packing RestoringChunk data-0c216a31-bc80-49b5-ab84-305334a9efd5: already packed
> Packing RestoringChunk data-4a9e0441-96b3-40c6-8fd5-01e1aefe5940: already packed
> Packing RestoringChunk data-0d3ea9ee-0336-40da-821d-707ee47ff2fa: proceeding
* copying chunk to temp file /tmp/phpO8E7lr: ok
* compressing /tmp/phpO8E7lr: /tmp/phpPtnhPQ
* spliting /tmp/phpPtnhPQ in parts: 90 part(s)
* encrypting each part
. encrypting /tmp/phpXi96C9: /tmp/phpwO11jg, aes-256-gcmAt the end :
. encrypting /tmp/phpphbZ78: /tmp/php8PXXwp, aes-256-gcm
- storing parts in appdata.......................................................................................... ok
* Removing old chunk file data-0d3ea9ee-0336-40da-821d-707ee47ff2fa.zip
In PackService.php line 210:
issue on chunk data-0d3ea9ee-0336-40da-821d-707ee47ff2fa - SauvegardeNextcloud/SauvegardeInitial/20240202222633-full-91uqSUNZiXEqOe5/data/data-0d3ea9ee-0336-40da-82
1d-707ee47ff2fa/data-0d3ea9ee-0336-40da-821d-707ee47ff2fa.zip has no ownerBut when I made a :
cercle-admin@cercle-peer-1:~$ sudo ls -lah /donnees/@Nextcloud_Sauvegarde/SauvegardeInitial/20240202222633-full-91uqSUNZiXEqOe5/data/data-0d3ea9ee-0336-40da-821d-707ee47ff2fa/
[sudo] password for cercle-admin:
total 18G
drwxr-xr-x 1 nextcloud nextcloud 3.9K Feb 4 17:57 .
drwxr-xr-x 1 nextcloud nextcloud 52K Feb 4 00:39 ..
-rw-r--r-- 1 nextcloud nextcloud 324 Feb 2 22:45 .backup.data-0d3ea9ee-0336-40da-821d-707ee47ff2faI have as result : -rw-r--r-- 1 nextcloud nextcloud 9.0G Feb 2 22:45 data-0d3ea9ee-0336-40da-821d-707ee47ff2fa.zip
So I have the good owner.
And when I restart the packing, the script report that the Chunk as been packed
> Packing RestoringChunk data-0d3ea9ee-0336-40da-821d-707ee47ff2fa: already packedWhere do you think it's come from ?
Hello,
I currently have some problems to pack my backups. I always get this error after the RestoringChunk it currently works on, after I start it again it continues with the next but fails again at the end:
I configured to save the app_data on an external local storage. And upload them to an external ftps server.
I mounted the local Nextcloudbackup over the /etc/fstab like that:
I assigned all the permissions to the folder with
I can normally use and access the files inside the /NextCloudBackup external storage showing in Nextcloud Files. So it can't be a permission problem somehow? Im confused....
Anyone got an idea what it could be?