I can't restore the SQL dump, but the other files are being restored.

[rrakso]

Thank you for the plugin and for maintaining it 💖!

After digging in, I found that I was unable to restore the contents of my backup. I discovered that the command being executed was /usr/bin/mysql --user='kimaiuser' --password='kimaipassword' --host='sqldb' --port='3306' 'kimai' \< /opt/kimai/var/easy_backup/2025-04-08_164005/database_dump.sql and should be /usr/bin/mysql --user='kimaiuser' --password='kimaipassword' --host='sqldb' --port='3306' 'kimai' < /opt/kimai/var/easy_backup/2025-04-08_164005/database_dump.sql (The output of the wrong command was just a help text of mysql, not an error message. This is why everything looked fine in the logs. 🥹)

The change is in the character < being escaped to the \<.

I've also found that I can temporarily remove escapeshellcmd from Service/EasyBackupService.php, and it started working!

P.S.
Is it possible to add a spinner or pop-up when the restore button is clicked? The harder one would be the feature of allowing uploads of backups.

Again! Thank you!

[machinas-achim]

I can confirm this is still reproducible with:

• Kimai 2.62.0
• EasyBackup 2.0.5
• Official Docker deployment

During testing I observed the same behaviour. The restore appears to succeed, files are restored, but the database remains unchanged because the < redirection appears to be escaped.

We verified this by restoring a backup containing a known database state and comparing row counts before and after the restore. The database was unchanged.

Extracting database_dump.sql from the backup archive and restoring it manually with:

docker exec -i kimai_db sh -c '
mysql \
  --user=root \
  --password="${MYSQL_ROOT_PASSWORD}" \
  kimai
' < database_dump.sql

restored the database correctly.

So this issue is still present in the current release.

Possible fix

Since the restore command intentionally contains shell syntax, it probably should not be passed through escapeshellcmd(). Removing that escaping appears to resolve the issue, as already reported above.

A more robust long-term approach would be to avoid shell redirection entirely by invoking mysql directly and supplying the SQL dump via stdin (for example with Symfony’s Process component or proc_open()).

It would also be helpful to check the exit status of the restore command and report a restore failure instead of logging a successful database restore when the SQL import did not actually run.