I installed a TKLAMP server and used Docker to setup Xibo CMS and db (currently on 1.80 rc2). All good, and the Docker upgrade ran a backup of the database. But how can I schedule regular db backups? I’m somewhat familiar with MySQL, but since the database is in a ‘container’, mysqladmin doesn’t list it as a database. How can I schedule regular database backups of Xibo? Do I just periodically run ./launcher stop, copy out the /home/library/ and /home/xibo-docker-master folders to get a full backup?
The container will automatically dump out a database backup every day for you.
You’ll find it in shared/backup/db/latest.sql.gz
You simply need to backup that file using whatever backup software you currently use. There’s no need to try and use any other tool.
I would’ve thought so, but my /shared/backup/ folder only has the one backup file in it from when I ran the upgrade to 1.8.rc2 on 12/29/16 (it called it db-2016-12-29_20-53-16.sql.gz). I do see that there is a ‘cron’ folder in there but I wonder if it’s not running…is the cron file ‘cms-db-backup’ in the /shared/backup/cron folder what is supposed to be running daily?
It’s the path in the post above
shared/backup/db/latest.sql.gz
That file just gets overwritten each day. The files in the directory below are from upgrades and are kept separately so we know what they are.
Ok, I see…my shared/backup/db/latest.sql.gz file (which is what my cms-db-backup cron file mentions) is called latest.sql.gz but it is not recent, and is only 1 KB. So I think I need to fix my CRON to run daily, and I need to see why the cms-db-backup cron isn’t returning any data.
Please make sure you’re running the latest containers. This is all handled for you inside the containers so there’s no need to try and make changes to cron or anything like that!
I’ve checked here and mine was last edited today and is a reasonable size so this should be working.
Have you changed passwords or something at some point in the container history? If so, you might need to update the password in that cron file, and then destroy/bootstrap the containers
I don’t remember changing any passwords, but something seems off if the container should be handling everything. If I destroy/bootstrap the containers, do I have to reload everything?
Assuming you keep your shared directory and launcher/launcher.env files (ie don’t manually delete those) then a destroy/bootstrap won’t loose any data.
The CMS will come up as before.
Thanks, I’ll make sure I have a good backup, and then do a destroy/bootstrap from here: http://xibo.org.uk/manual-tempel/en/install_docker.html and let you know if that fixes it. Can I manually force the cron job after I do this, or just wait until tomorrow?
The database backup is run using anacron, so if that doesn’t think that the job has been run for some time, it’ll be run as soon as the container starts (to catch up missed jobs). Otherwise if it thinks it has been running, but for whatever reason it isn’t, then you will have to wait 24 hours for it to run again.
I’d delete your latest.sql.gz file too - so you can be sure if it’s been recreated or not.
Sorry - one more quick question - do I need to ./launcher stop before I do the destroy/bootstrap? I couldn’t tell from the documentation.
It will stop for you, but if you have already it won’t do any harm!
Thanks!
It seems to have run correctly, even without stopping first. /shared/backup/db/latest.sql.gz isn’t there yet, but I’ll wait 24 hours to see if it is there tomorrow. Thanks!
root@lamp /home/xibo-docker-master# ./launcher destroy
Reading configuration
Destroying CMS Docker Containers (your data is safe!)
xibo-cms-web
xibo-cms-xmr
xibo-cms-db
xibo-cms-web
xibo-cms-xmr
xibo-cms-db
CMS containers removed. You will need to bootstrap again in order to run the CMS.
root@lamp /home/xibo-docker-master# ./launcher bootstrap
Reading configuration
Bootstrapping CMS Docker Containers
release_1.8.0-rc2: Pulling from xibosignage/xibo-cms
Digest: sha256:3d497a03637b277bdb9702f2230ee82c41c5e5b7f8868fdd36b5b92bfbe98ef2
Status: Image is up to date for xibosignage/xibo-cms:release_1.8.0-rc2
release_1.8.0-rc2: Pulling from xibosignage/xibo-xmr
Digest: sha256:8c1a85e53515bf90ea2ab488f4394ff41460504093d3c4c65a6e41aa94f34646
Status: Image is up to date for xibosignage/xibo-xmr:release_1.8.0-rc2
5.6: Pulling from library/mysql
Digest: sha256:afbd1708374fb8e5fa68c11c23be53a43a797ede4c04d399dd04b8893b2e75e2
Status: Image is up to date for mysql:5.6
2bc4c2cc0c92c17dfaf762b49b26e6776d80b18c999cad27b1897d9e7efaf355
23aed5a01db7ba5d47dea59cde54a20b9662a16c930f1a44e72423b35d303a77
bbad9fcbb5c4415dc18616e077f7c937b1d285342b40013fb2fad536b1d27018
CMS is starting. It may take a few moments to be fully running
root@lamp /home/xibo-docker-master#
Excellent. That all looks good.
It’s worth checking that the credentials in your shared/backup/cron/cms-backup-db file match those in the launcher.env file.
Specifically check that PASSWORDHERE in this line in cms-backup-db:
/usr/bin/mysqldump -u cms -pPASSWORDHERE -h mysql -P 3306 cms | gzip > /var/www/backup/db/latest.sql.gz
matches the CMS_DATABASE_PASSWORD value in launcher.env
If it doesn’t, correct the cms-backup-db file and then destroy/bootstrap again to bring that change in.
Maybe that’s my problem. The password is fine, but the rest isn’t (I put ****** instead of my actual password).
cms-backup-db shows this:
#!/bin/bash /bin/mkdir -p /var/www/backup/db /usr/bin/mysqldump -u root -p********* -h localhost -P 3306 cms | gzip > /home/xibo/library/shared/backup/db/latest.sql.gz
The CMS_DATABASE_PASSWORD in launcher does match the password in the cms-backup-db file.
Do I need to change the -u from root to cms, and the -h from mysql to localhost?
#!/bin/bash
/bin/mkdir -p /var/www/backup/db
/usr/bin/mysqldump -u cms -p********* -h mysql -P 3306 cms | gzip > /var/www/backup/db/latest.sql.gz
It should look like that.
If you correct that file, then destroy/bootstrap again, it should roll that change in.
Did you edit that file before at all? I see no way that /home/xibo/library/shared/backup/db/latest.sql.gz could have got in there if you hadn’t since the path above is hardcoded in as it never needs to change.
I’m new to Docker, so I probably tried something and messed with it before. I just edited that file to match what you have, but with my password. I destroyed/bootstrapped again, and it all looked good on the command line. It didn’t create a latest.sql.gz file yet, the /home/xibo/library/shared/backup/db is still empty, so I’ll see tomorrow if it runs.
The destoy/bootstrap…was it supposed to delete and recreate the folders in the /home/xibo-docker-master folder? Those files/folders still have older dates on them (12/29/16), but maybe that’s how it’s supposed to look.
All it will do is delete the containers - it won’t touch any files in your working directory.
I’m surprised it hasn’t created a latest.sql.gz file at startup. I would have thought in that scenario it would do. You definitely corrected the path in the cron file to be /var/www/backup/db/latest.sql.gz as well as the other changes?
Yes, here is my new /home/xibo/library/shared/backup/cron/cms-db-backup file contents:
#!/bin/bash
/bin/mkdir -p /var/www/backup/db
/usr/bin/mysqldump -u cms -p********* -h mysql -P 3306 cms | gzip > /home/xibo/library/shared/backup/db/latest.sql.gz
After doing that, I ran the destroy/bootstrap. Should the /home/xibo-docker-master/containers subfolders get removed and recreated during the destroy/bootstrap? Because I don’t think they are.
That’s still wrong!
The final line needs to be /var/www/backup/db/latest.sql.gz not the path as you see it. This is run from inside the container.
Please correct that per my example and then destroy/bootstrap. The only difference between what’s shown below and your file should be replacing the ********** with your actual password.
#!/bin/bash
/bin/mkdir -p /var/www/backup/db
/usr/bin/mysqldump -u cms -p********* -h mysql -P 3306 cms | gzip > /var/www/backup/db/latest.sql.gz
It’s handled that way for legacy reasons. I’m just in the process of removing that file being editable so this can’t happen in future.