directory premission and backup failure

Reported by SingerWang on 2010-10-22
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona XtraBackup
High
Alexey Kopytov
2.0
High
Alexey Kopytov
2.1
High
Alexey Kopytov

Bug Description

Consider the following case on a RHEL System
- MySQL is running as mysql:mysql
- backup is running as bacula user (bacula:bacula but also part of the mysql group)

- the is a new database created and the corresponding directory is set as 0700 for premissions and mysql:mysql for ownership
- inside the new database the there are both MyISAM and InnoDB Tables (file per table is set)

- when innobackex/xtrabackup is run the database is skipped obviously due to premission issue but no warning or error is produced by innobackex/xtrabackup
- the output of innobackex/xtrabackup is 100% fine and says that the backup is completed without issues where it should produce an error

Valentine Gostev (longbow) wrote :

Tried with the latest 1.6:

~$ innobackupex --user=root /home/gval/
...snip...
xtrabackup Ver 1.6 Rev 245 for 5.1.55 unknown-linux-gnu (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /
xtrabackup: innodb_data_file_path = var/lib/mysql/ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 5242880
110502 14:53:59 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name /var/lib/mysql/ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Error in opening /var/lib/mysql/ibdata1
110502 14:53:59 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
xtrabackup: Could not open or create data files.
xtrabackup: If you tried to add new data files, and it failed here,
xtrabackup: you should now edit innodb_data_file_path in my.cnf back
xtrabackup: to what it was, and remove the new ibdata files InnoDB created
xtrabackup: in this failed attempt. InnoDB only wrote those files full of
xtrabackup: zeros, but did not yet use them in any way. But be careful: do not
xtrabackup: remove old data files which contain your precious data!
innobackupex: Error: ibbackup child process has died at /usr/bin/innobackupex line 342.
~$ echo $?
2

Can you please also try if you can reproduce the issue with XtraBackup 1.6?

Changed in percona-xtrabackup:
status: New → Invalid
Alexey Kopytov (akopytov) wrote :

Verified as described in the bug report: when using innodb_file_per_table and creating a new database on the server, and xtrabackup does not have access to the new database's dir, it reports successful backup, though no tables from that database are actually backed up.

Changed in percona-xtrabackup:
status: Invalid → New
assignee: nobody → Valentine Gostev (core-longbow)

xtrabackup was created by cut & paste from InnoDB handler.
Because InnoDB ignores return code of fil_load_single_table_tablespaces(), xtrabackup also currently.c

calling fil_load_single_table_tablespaces() should be

like "if (fil_load_single_table_tablespaces() != DB_SUCCESS) {....;exit(EXIT_FAILURE);}"

Changed in percona-xtrabackup:
status: New → Confirmed
importance: Undecided → Low
Haidong Ji (haidong-ji) wrote :

This bug is not just related to innodb_file_per_table. I've just experienced it without that setting. In fact, I was doing some testing with a brand new server, brand new install of the latest Percona server and Xtrabackup, and I experienced the same problem.

Valentine Gostev (longbow) wrote :

the attached branch contains ib_permissions and xb_permissions tests, which expect XtraBackup to fail when it meets dir it cannot read.

Suggestion for fix: an option should be added (say --skip-warnings) for cases when users want to keep dirs with specific permissions in datadir, but do not want XtraBackup to fail.

Changed in percona-xtrabackup:
assignee: Valentine Gostev (longbow) → Stewart Smith (stewart)
Stewart Smith (stewart) on 2012-06-15
Changed in percona-xtrabackup:
assignee: Stewart Smith (stewart) → nobody
status: Confirmed → Triaged
Alexey Kopytov (akopytov) wrote :

Bug #1054441 was marked as a duplicate of this one.

tags: added: i26401
Manoj Kukreja (manoj-kukreja) wrote :

Is there a time frame on when this bug will be fixed?

Alexey Kopytov (akopytov) wrote :

Thanks for reminding about this bug. I think it's a rather high priority issue, so I'm updating Importance to High. I think we should target it to the next release (2.0.6, the current estimate date is Mar 01).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers