XtraBackup requires --incremental-dir to be writeable

[Aleksandr Kuzminsky]

Command
xtrabackup --use-memory=3G --prepare --apply-log-only --target-dir=/opt/restore/db1 --incremental-dir=/media/shared-backup/db1/incremental/2011-12-23_21-21-03
fails with error:

incremental backup from 284571416268 is enabled.
xtrabackup: cd to /opt/restore/db1
xtrabackup: This target seems to be already prepared.
111226 12:02:44 InnoDB: Operating system error number 30 in a file operation.
InnoDB: Error number 30 means 'Read-only file system'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
xtrabackup: Warning: cannot open /media/shared-backup/db1/incremental/2011-12-23_21-21-03/xtrabackup_logfile. will try to find.

In my environment /media/shared-backup/ is mounted RO.
I think it would make sense if a directory with backup copies was kept RO because:
* it protects from human/script's mistakes
* it ensures your backup copies are in the same state before any XtraBackup runs (again, to protect against possible bugs)

[Alexey Kopytov (akopytov)]

As discussed on IRC, we do modify xtrabackup_logfile on prepare to 1) update the logfile header with checkpoint info and 2) to expand and align it if necessary, because InnoDB recovery code will bark at redo log if it's smaller than 2 MB.

On the other hand, those modifications can be done right after finishing the backup, so for example, incremental backups could be on a read-only media when merging them to a full one.

[Alexey Kopytov (akopytov)]

See also bug #782850.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-80