Restore HumHum App on different server

[NCKNE]

I need to move an app (HumHub) from one server to another. The domain is registered on both servers and I installed the HumHub Package (same Version 1.9.4) on the new server with the same domain. Both Servers are running latest Cloudron 9.2. When restoring the backup I get the errors in the uploaded log file: https://download.plaxon.consulting/HumHubBackupImport.log

The memory settings for mysql and for the app itself are set to an insane high value for this small app, so this should not be the problem.

Could there be an issue in the restore process itself?

[fbartels]

Having a quick glance at the log, it says the import to the database fails. Have you also increased the memory for the MySQL service?

[NCKNE]

@fbartels sagte:

Having a quick glance at the log, it says the import to the database fails. Have you also increased the memory for the MySQL service?

Yes, it's at 12GB on both servers and less than 2% used. The app backup itself is only 110 MB. Seems more like an issue with the MySQL dump/import.

[fbartels]

Right you actually wrote that already. My next step would be to try to import the mysql directly from the shell.

The memory angle could also point to the host ram (any oom in dmesg?) or disk space issues. Although its not running long, so it cant be that big of a sql dump.

Anything in docker logs mysql?

[NCKNE]

The MySQL shell for the app is only available when the app is started. Die to the unsuccessful restore, it cannot be started. I guess a complete manual backup of all files and folders (/app/data) and a manual MySQL dump and restore might be possible, but maybe there is an easier way to fix this? I will check the MySQL logs tomorrow. I doubt it is an OOM problem.as the limits are set very high and the server has plenty of resources available.

The MySQL shell for the app is only available when the app is started. Due to the unsuccessful restore, it cannot be started. I guess a complete manual backup of all files and folders (/app/data) and a manual MySQL dump and restore might be possible, but maybe there is an easier way to fix this? I will check the MySQL logs tomorrow. I doubt it is an OOM problem as the limits are set very high and the server has plenty of resources available.

[fbartels]

yes. I would not be surprised if the hickup comes from somewhere in the sql file. For the restore test you should first reset the failed migration to its previous state and extract the sql file from the old backup. There are instructions in the cloudron documentation for this.

[joseph]

@nckne sometimes you will find the import error in the Service -> MySQL logs . Can you check if you see anything there when importing?

[NCKNE]

The mysql logs surfaced the problem during the restore:

Aug 07 14:22:38 [POST] /databases
Aug 07 14:22:38 add: adding database e24ab7ec3e6f531b
Aug 07 14:22:38 [POST] /databases/e24ab7ec3e6f531b/clear
Aug 07 14:22:38 clear: database e24ab7ec3e6f531b
Aug 07 14:23:07 [POST] /databases/e24ab7ec3e6f531b/restore
Aug 07 14:23:07 restore: restoring database e24ab7ec3e6f531b
Aug 07 14:23:07 pipeRequestToProcess: stderr: ERROR 6125 (HY000) at line 2047: Failed to add the foreign key constraint. Missing unique key for constraint 'fk-translator_history-translator_cache' in the referenced table 'translator_cache'
Aug 07 14:23:07 pipeRequestToProcess: process exited with code 1
Aug 07 14:23:07 backupPrefix: Failed to restore database e24ab7ec3e6f531b Error: process exited with code 1
Aug 07 14:23:07 at pipeRequestToProcess (file:///app/code/node_modules/@cloudron/pipework/index.js:127:15)
Aug 07 14:23:07 at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
Aug 07 14:23:07 at async restore (file:///app/code/service.js:255:9)

Interesting that this does not prevent the app from starting on the current server.

I will check the HumHub app for ways to clear this.

If not successful, I suppose I need to check how extract the mysql dump from the backup file, repackage it and try to import it again.

[joseph]

@nckne I can check the schema in our HumbHub .

[joseph]

@nckne we don't even have a table named translator_cache . Could it be this comes from some module/plugin? Maybe you disabled it and afterwards may be migrations are not run ? Most likely it is because 8.4 MySQL is not accepting something that previous MySQL accepted.

[NCKNE]

@joseph sagte:

@nckne we don't even have a table named translator_cache . Could it be this comes from some module/plugin? Maybe you disabled it and afterwards may be migrations are not run ? Most likely it is because 8.4 MySQL is not accepting something that previous MySQL accepted.

Yes - the table comes from the "translator" module (plugin).

I made the mistake to restore a previous backup on the primary host of the app and now it does not start there with the same error during the restore again. So I have no running instance of the app anymore now . I figure getting this up and running again now involves extracting the mysql database from the backup file (which needs to be decrypted first) altering the table definitions and repackaging it to a new backup file...

Or is there any another way? Does the restore process drop the database/tables before they are imported again? If not, is there a way to set the app as "restored" manually by cli / editing files on the box? I cannot access the MySQL credentials for the app without the app starting so I cannot connect to the apps database for further evaluations...

Or can the mysql version be downgraded to the previously used version? I migrated all other apps to another server so this would not cause any regressions for other apps and might be the easiest way.

[joseph]

@nckne correct, the restore process always starts from scratch. But there is a workaround.

Once the restore has failed, ssh into the server and edit the mysql dump directly. This file is /home/yellowtent/appsdata/<appid>/mysqldump . Specifically, from the error message it seems this is around line 2047. Maybe comment out that line?

After that, using the CLI tool (on your laptop and not on the server), run cloudron import --in-place --app humhub. This does a restore of the app without redownloading the backup. So, it will reimport your modified sql dump.

[NCKNE]

Excellent! Thank you very much @joseph (and also @fbartels)! I was able to alter the mysql dump file in the appsdata directory on the server and restarted the restore. The app started and I was able to fix all other database bugs in the dump directly in the apps database which then was up and running. Now the app has been restored on the new server and everything is working again. Thanks for the support and especially the note about the /home/yellowtent/appsdata/<appid>/mysqldump location.