XtraBackup requires --incremental-dir to be writeable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Triaged
|
Low
|
Unassigned | ||
2.0 |
Won't Fix
|
Low
|
Unassigned | ||
2.1 |
Triaged
|
Low
|
Unassigned | ||
2.2 |
Triaged
|
Low
|
Unassigned | ||
2.3 |
Triaged
|
Low
|
Unassigned |
Bug Description
Command
xtrabackup --use-memory=3G --prepare --apply-log-only --target-
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://
xtrabackup: Warning: cannot open /media/
In my environment /media/
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)
Changed in percona-xtrabackup: | |
importance: | Undecided → Low |
status: | Confirmed → Triaged |
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.