Database consistency verification ambiguity after YunoHost backup restoration

Answer

YunoHost’s restore command finishes when the orchestration steps (extraction, app recreation, database import, and service start‑up) complete. The official documentation does not state that a database integrity check is performed automatically. Therefore, a successful yunohost backup restore does not guarantee that the underlying tables, indexes or data are free of corruption.

Confirmed facts

• The restore flow imports a logical dump (SQL) into the target database service.
• After the import, YunoHost starts the database service and any app‑specific restore hooks.
• Logs in /var/log/yunohost/* and the database server’s own logs will contain any errors that occurred during the import.

Likely explanation for the ambiguity

Logical dumps can load successfully even if physical corruption exists or if the schema has drifted after a cross‑version upgrade. Because YunoHost’s restore script simply runs the dump command, it will not automatically invoke a database‑specific consistency checker unless the app itself does so.

Recommended verification steps for this case

1. Check the restore logs. Look for warnings or errors in /var/log/yunohost/backup.log and the database server’s log (e.g., /var/log/mysql/error.log or /var/log/postgresql/postgresql.log). Any failures during import should be addressed before proceeding.
2. Run an engine‑specific consistency check.
   • For MariaDB/MySQL:

     mysqlcheck --all-databases --check --user=root --password
     

     – this reports tables that are corrupted or need repair. Avoid --auto-repair on the production copy; run it on a copy if necessary.
   • For PostgreSQL:

     vacuumdb --all --analyze
     

     – this updates statistics and can surface basic corruption issues. If the PostgreSQL installation includes the amcheck extension, you can run SELECT * FROM amcheck.check_table('schema.table'); for deeper checks.
3. Validate application behaviour. Run a quick smoke test (e.g., access the web interface of a restored app) to ensure that the app can connect to its database and that no runtime errors are logged.

Version‑specific considerations

When restoring a backup that originated from an older YunoHost or app release, the restored database may have a schema that is out of sync with the current app version. In such cases, run the app’s upgrade or migration routine (often yunohost app upgrade appname) before performing consistency checks, as the app may create missing tables or indexes during its upgrade path.

Missing diagnostic detail

To tailor the verification precisely, please provide:

• The database engine (MariaDB/MySQL or PostgreSQL) and its major version that was restored.
• Whether the backup was taken from a YunoHost release older than the current one.

These details affect the exact commands and migration steps you should run.