1

I am getting crashes when trying to run innobackupex --apply-log. How can I find out what files it's processing at the time? I don't see a relevant option mentioned in the documentation.

  • Supply some more detail, at what point does the crash occur? There will be output. Have you uncompressed all files before apply log? Are you restoring with the same version of Xtrabackup that the backup was made? – eroomydna Nov 27 '14 at 9:27
  • Thanks. Not sure what you mean by uncompressing all files, but it turns out the version difference was the problem. I successfully ran the apply log on the original server. – Wodin Nov 28 '14 at 5:13
  • Xtrabackup can compress as part of the backup routine. The native compression is provided by a program named qpress (per file rather than archive) and I have found myself attempting to --apply-log to a still (partially) compressed backup and it has a similar symptom. – eroomydna Nov 28 '14 at 16:01
2

Check the version you used to backup the data is the same as the one you are trying to use to restore. This can bite.

1

One easy way to do this would be by using strace, for example:

$ strace -e trace=open xtrabackup --prepare --target-dir=2014-11-27_06-06-49

Change 2014-11-27_06-06-49 for the path to your unprepared backup location. I'm using here xtrabackup as it is the lower level tool that innobackupex uses internally.

A poor man's replacement would be to do a polling, with something like this on a different session:

$ while true; do lsof +D ./2014-11-27_06-06-49 ; sleep 0.1; done

Again, change ./2014-11-27_06-06-49 for your backup location and adjust the sleep time if convenient.

  • Thanks. I did try strace -f -o strace.out -eopen innobackupex --apply-log ... but the files it printed out did not lead me to the cause of the crash. As @eroomydna suspected, I was using a different version of Xtrabackup. In future I will make sure to prepare the backup immediately instead of before trying to restore it. – Wodin Nov 28 '14 at 5:18
  • One prospect of prepare immediately after backup is that you will not be able to compress natively. You will need to handle this in another process which can be done but requires extra engineering. – eroomydna Dec 11 '14 at 11:17
  • @eroomydna I do not recommend using built-in compression for long-term storage. That is optimized for low-resource usage, low-compression rate (so, optimized for real-time transmission). A separate node for compression with lz or other algorithms may provide 10x the compression rate. Obviously, these depends on the actual backup workflow, resources, etc. – jynus Dec 11 '14 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.