cat: '/tmp/restore.1/*': No such file or directory

[AxelGuignard]

When restoring a backup, I get the message "cat: '/tmp/restore.1/*': No such file or directory".

Here is my docker-compose config:

mysql-restore:
    image: databack/mysql-backup
    volumes:
      - "./db:/db"
    networks:
      - backend
    environment:
      - DB_SERVER=mysql
      - DB_USER=${DB_BACKUP_USER}
      - DB_PASS=${DB_BACKUP_PASSWORD}
      - DB_RESTORE_TARGET=/db/daily/backup_D_2023-09-07.gz
      - RUN_ONCE=true

(The target is temporary set with a fixed value, it should be a variable)

Here is a fragment of the result of the command docker compose run -e DB_DUMP_DEBUG=true mysql-restore that seems to be the cause of the error:

+ DB_PORT=3306
+ COMPRESS=
+ UNCOMPRESS=
+ case $COMPRESSION in
+ COMPRESS=gzip
+ UNCOMPRESS=gunzip
+ EXTENSION=tgz
+ TMPDIR=/tmp/backups
+ TMPRESTORE=/tmp/restorefile
+ declare -A uri
+ [[ -n /db/daily/backup_D_2023-09-07.gz ]]
+ '[' -d /scripts.d/pre-restore/ ']'
+ uri_parser /db/daily/backup_D_2023-09-07.gz
+ uri=()
+ full=/db/daily/backup_D_2023-09-07.gz
+ full=/db/daily/backup_D_2023-09-07.gz
+ full=/db/daily/backup_D_2023-09-07.gz
+ [[ / == \/ ]]
+ full=file://localhost/db/daily/backup_D_2023-09-07.gz
+ [[ file://l == \f\i\l\e\:\/\/\/ ]]
+ pattern='^(([a-z0-9]{2,5})://)?((([^:\/]+)(:([^@\/]*))?@)?([^:\/?]+)(:([0-9]+))?)(\/[^?]*)?(\?[^#]*)?(#.*)?$'
+ [[ file://localhost/db/daily/backup_D_2023-09-07.gz =~ ^(([a-z0-9]{2,5})://)?((([^:\/]+)(:([^@\/]*))?@)?([^:\/?]+)(:([0-9]+))?)(\/[^?]*)?(\?[^#]*)?(#.*)?$ ]]
+ full=file://localhost/db/daily/backup_D_2023-09-07.gz
+ uri[uri]=file://localhost/db/daily/backup_D_2023-09-07.gz
+ uri[schema]=file
+ uri[address]=localhost
+ uri[user]=
+ uri[password]=
+ uri[host]=localhost
+ uri[port]=
+ uri[path]=/db/daily/backup_D_2023-09-07.gz
+ uri[query]=
+ uri[fragment]=
+ [[ file == \s\m\b ]]
+ [[ -n '' ]]
+ return 0
+ [[ file == \f\i\l\e ]]
+ cp /db/daily/backup_D_2023-09-07.gz /tmp/restorefile
+ [[ -f /tmp/restorefile ]]
+ '[' '' = true ']'
+ DBDATABASE=
+ workdir=/tmp/restore.1
+ rm -rf /tmp/restore.1
+ mkdir -p /tmp/restore.1
+ gunzip
+ tar -C /tmp/restore.1 -xvf -
./
+ cat '/tmp/restore.1/*'
+ mysql -h mysql -P 3306 -u####### '-p###########'
cat: '/tmp/restore.1/*': No such file or directory
+ rm -rf /tmp/restore.1
+ /bin/rm -f /tmp/restorefile
+ '[' -d /scripts.d/post-restore/ ']'

[deitch]

Can you add a few earlier lines? The section of the restore is here. You have the debug from some of it. I find it strange that it successfully downloaded the restore file, but then has this line:

+ gunzip
+ tar -C /tmp/restore.1 -xvf -
./

What is that ./? Where is the TMPRESTORE?

[AxelGuignard]

Hi, thanks for responding.
I've updated the result of the command to include previous section where the TMPRESTORE variable is set.
I don't know about the ./, but it is part of the normal output (without debug)

[AxelGuignard]

From what I see in the entrypoint script, TMPRESTORE is the name of the restore file, copied from the mounted directory.
As we entered the bloc

if [[ -f "$TMPRESTORE" ]]; then
  ...
fi

it seems the file was correctly copied.
The connection to the database works (I tested it from the container)
I think the issue comes from the decompression of the restore file and/or when it is passed to mysql.

It may be important to specify that the backup was generated with the parameter DB_DUMP_BY_SCHEMA=true. If I understand correctly, it means that there are multiple backup in the compressed archive, one for each schema? If that is the case, does the restore function handles that?

[AxelGuignard]

In fact, it seems the problem actually comes from the backup itself. The backup files outputted by the container only weight 1KB and contain only one line.
I tried to manually uncompress a file with the command tar -C /tmp/ -xvf daily/backup_D_2023-09-07.gz. It outputs ./ and doesn't create a file in /tmp.
I think the tar command does not work because the file is not in a tar format.

I will investigate on why my backup files are faulty.

[AxelGuignard]

My issue was indeed caused by faulty backup files.

It was because mysql didn't have the right permissions to dump the database, and for some reason it wasn't giving any error due to the variable DB_DUMP_BY_SCHEMA being to true.
After disabling this variable, I got the error Access denied; you need (at least one of) the PROCESS privilege(s) for this operation, and long story short it was caused by mysql roles.

Everything works now, so I can close this issue.

[deitch]

Glad to hear it. If you can recreate the dump problem, I would like to get a fix in so that it reports an error, so open a new issue there.