After a recent 'emergency migration' of a RS cloud server, the mysql databases on our server snapshot image proved to be days out of date from the backup date. And yet files that were uploaded through the impacted webapp had been written to the file system. Related metadata that was written to the database was lost, but the files themselves were backed-up.
Once I was able to manually access the mysql data files before the mysql server started (server was configured to start mysql on boot), I was able to see that the update time for ib_logfile1, ib_logfile0 and ibdata1 was days old.
As with this poster, mysql data loss after server crash, it's as if some caching controller had told the OS / mysql server that it had committed data that was still in cache, and it was lost instead of flushed.
I can't quite wrap my head around how the uploaded files got written but the database data did not. I would have thought that any cache would have flushed system wide, rather than process by process.
Any suggestions as to how this might have happened?
See my answer below that explains what happened.
Config details, as requested.
RackSpace Cloud Server Details: OS: Ubuntu 10.04 LTS (Lucid) RAM: 1024 MB Disk Space: 40 GB Datacenter: ORD1 Service Level: unmanaged
root@restore-testing:~# dpkg -s mysql-server ... Architecture: all Source: mysql-dfsg-5.1 Version: 5.1.61-0ubuntu0.10.04.1 ...
root@restore-testing:~# cat /etc/fstab proc /proc proc defaults 0 0 /dev/xvda1 / ext3 defaults,errors=remount-ro,noatime 0 1 /dev/xvdc1 none swap sw 0 0