1.8 Docker Backup Not Current, Won't Run, Upgrading to 1.8.2

Looking to upgrade Docker version 1.8 to 1.8.2. The backup/db/latest.tar.gz is not current and looks to have run last when it was installed. Task are not functioning correctly, so, no current backup. The upgrade instructions say to seek help if the backup is not current before doing the upgrade.

How should i proceed?

If I look at this post:

I also see that the library looks correct, and the ib_logfile0, ib_logfile1, ibdata1 files all have today’s date.

Should I be safe to proceed if I have a back up of these, and the other said files in the instructions?

That’s rather odd, could you remind me what OS are you using (Linux / Windows)?

Are you on 1.8.0 or 1.8.1 at the moment, I believe there was a problem with it in 1.8.0 (fixed in 1.8.1).

Hi Peter,

Version is 1.8.1. We are on Linux using Docker

Edit:

Ok… after looking at the post you linked to, I decided to run
cat /etc/cron.daily/cms-db-backup
I noticed that there is not a space between -p and the actual password. I installed vim and edited cms-db-backup to add the space. After doing so when trying to run cat /etc/cron.daily/cms-db-backup it would then prompt me for the password. I type it in, and it is correct, but it still rejects the password. I think that some of the characters on the password are messing with the authentication. The password does contain symbols like “$” and “@”. Any suggestions on what to try next?

Edit2:
Seems no space between -p and the password is correct.

I got the idea to remove the password and let the terminal prompt me. Bingo! It then accepted the password and performed the backup.

Before I try the upgrade, is there anything else I should take into consideration?

Also does the updated 1.8.2 Docker version, correctly escape special characters in passwords for the cron task? If not, I will surely be repeating this. In addition, how secure is storing the master SQL password in the nonencrypted text file? Maybe something like this would add ad extra layer of security, but truly how much seeing how the container is configured to only run limited items, thus reducing it’s exposure.

Hi Colin

No space is indeed correct in that command. The instructions in config.env do suggest using an alpha numeric password only - and indeed link you to a password generator that generates something in the correct format.

I’d suggest changing that password to something that meets that specification to avoid ongoing issues with this.

To do so, you’d need to connect to the MySQL container, and change the password there directly, then change the password in config.env, and then rebuild the containers (with a down/up command).

Instructions for connecting to MySQL are here:

The way Docker works involves passing those secrets in to the container as environment variables, so sure we could move where the password is stored for the backup, but it would still be available in the environment variables, so I don’t think we gain anything adding that extra complexity.

Attempting any kind of encryption would be pointless as the code is open, and that would need to decrypt the password to use it, so it would be trivial for anyone to recover the password outright who had access to the container.

Thank you Alex for the explanation of the problem, and instructions on how to correct my mistake. This would also explain the issue of the maintenance task not working for us as well.

Also thank you for the in site on why it does’t really matter that the password is stored in the manor they are.

1 Like

Ok, I finally found a good time to change the database password. After doing so everything looks good and seems to have close to the same functionality. All task now say they are running… but some are not really. Also now when I run cat /etc/cron.daily/cms-db-backup it finishes in half a second and the file is not updated.

Did I miss changing the password somewhere?

UPDATE: Sorry, false alarm, after a while, the backup file finally appeared, Not sure what took so long.

Update2: Our system has been successfully updated on a Synology box DSM6. Downside to DSM6 is that there is no way, so far that we can tell, to transder the config.env file from the old to the new container. Also the upgrade wizard did appear but had no problem running.

Thank you Alex for your help, everything you suggested to do was spot on and worked no problem.(Except for that little delay, but nothing to do with your instructions.)

2 Likes

Hello!

I have the same problem, but I dont’t have any file in /backup/db/.
I suppose there is a problem with my password too, because there is character & and ).

I would like to change the password like you told : “To do so, you’d need to connect to the MySQL container, and change the password there directly, then change the password in config.env, and then rebuild the containers (with a down/up command).”

But I don’t know how to do that. I can connect me to mysql, but after, I don’t know what to do.
Can you help me?

Thank’s.

I presume you left the database username as default?

If so, you’d connect to MySQL inside the container, and then run:

SET PASSWORD = PASSWORD('newpassword');

Please ensure the password you choose is alpha numeric per the requirements.

Once you’ve done that, disconnect, and then edit config.env to match your new password, then “up” the containers again.

The backup should appear within 24 hours.

Thank you so much!
I have a file which is created now.

I’ll be able to try to update.