I've followed these simple instructions in order to backup and restore an LXC container:
https://stackoverflow.com/a/34194341
The backup and restore procedure go well. I've made triple sure I use the --numeric-owner flag when tar and untar'ing, and the container starts up fine. However, MySQL in the container barfs all over the place with the following errors, when doing service mysql restart (output from journalctl -xe):
[ERROR] InnoDB: Unable to lock ./ibdata1, error: 11
and
[ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
I can get it to start up if I delete the following files, so that mysql recreates them:
/var/lib/mysql/ibdata1
/var/lib/mysql/ib_logfile*
/var/lib/mysql/aria_log_control
"Solution" gleaned from https://bbs.archlinux.org/viewtopic.php?id=160277
But this royally messes up my site database.
What is going on here?
It seems to me that file permissions, or something along those lines have gone awry - but when I compare ownership and rights between the original, working container and my restored copy, it all looks identical.
For anyone who might bump into this: Typical n00b error on my part.
I had forgotten to update the rootfs path in my config file for the container.
As I was doing a restore test of an existing container, I had untar'ed my backup to another directory in /var/lib/lxc - e.g. /var/lib/lxc/restored - but hadn't updated the config in /var/lib/lxc/restored/config to point to the correct path.
This resulted in the container using the same rootfs as my original - still running - container. This the problems with Mysql.
Interesting to note that you can spin up two containers sharing the same rootfs. Maybe there's some applications for this "feature" somewhere.
LXC is awesome.