innobackupex doesn't backup to nfs mount point

[Michael Dodwell]

When trying to run:

TheSlave$ innobackupex --user=yourDBuser --password=MaGiCiGaM /
          --slave-info /path/to/backupdir

The script tries to run 'cp -p' on Myisam datafiles which isn't allowed to nfs.

--stream=tar is required if you wish to backup to nfs mount points.

[Alexey Kopytov (akopytov)]

Michael,

Can you please give more details on how 'cp -p' fails on NFS? The Linux man page for 'cp' does not specify cp behavior in case it cannot change file attributes. The BSD man page says:

           If the user ID and group ID cannot be preserved, no error message is displayed and the exit value is not altered.

[Launchpad Janitor (janitor)]

[Expired for Percona XtraBackup because there has been no activity for 60 days.]

[Brad Lang (lontra-provocax)]

I can confirm that xtrabackup can't preserve file rights accross NFS and that this stops xtrabackup from copying .frm files, etc - tho it keeps running and never stops "log scanned up to ..." Here's the cleaned up output:

(copying tables here)
...
Continuing after ibbackup has suspended
Starting mysql with options: --defaults-file='/etc/mysql/my.cnf' --password=xxxxxxxx --user='username' --unbuffered --
Connected to database with mysql child process (pid=20849)
Starting to lock all tables...
All tables locked and flushed to disk
Starting to backup .frm, .MRG, .MYD, .MYI,
 .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV and .opt files in
subdirectories of '/companydir/mysql/databases'
Backing up files '/companydir/mysql/databases/game_accounts_live/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (11 files)
cp: failed to preserve ownership for `/mnt/nfsshare/2012-11-12_17-14-13/game_accounts_live/table_name.frm': Remote I/O error
Error: Failed to copy file 'table_name.frm': Inappropriate ioctl for device at /usr/bin/innobackupex line 374.

I'm using xtrabackup 2.0.2

However, trying to do this today and I found this via your docs:

innobackupex --compress --stream=xbstream /doesntneedtoexist | ssh user@otherhost "xbstream -x -C /root/backup/"

and after setting up rsa ssh keys, it can send the data to another server unpacked. So, I'm not going to bother with NFS anymore, especially since I can do the apply log step on the target now since the checkpoint file is correctly created.

[Alexey Kopytov (akopytov)]

Apparently 'cp -p' does fail on Linux when it fails to preserve ownership. Indeed, that requires root, and most NFS configurations map root to another user.

I see multiple ways to fix this:

- do not try to preserve any file attributes, i.e. just use 'cp' instead of 'cp -p'. This is probably acceptable, especially given the fact that InnoDB files (i.e. those copied by the xtrabackup binary) do not have their attributes preserved in a backup. Neither do streaming backups

- preserve only attributes that do not require root (i.e. mode and timestamp). This would imply using 'cp --preserve=mode,timestamp' which would break compatibility with any non-Linux systems like OSX, BSD and Solaris. While we don't officially support them, I'm not sure fixing this specific case is worth breaking compatibility.

- leave the code intact, but document that:
  1. in case of local backups, innobackupex should be invoked either as the same user which is the owner of files in the server data directory, or as root. Otherwise 'cp -p' may fail on Linux.
  2. when backing up to an NFS mount, NFS should be configured appropriately to allow changing ownership (or it must map remote clients to the same user as the owner of the files in server data directory, so no ownership changes are required).

Setting the bug status to Opinion to collect feedback.

[David Sickmiller (davidsickmiller)]

This problem also affects cifs mounts (Windows file servers).

It might be nice to not bother preserving file attributes, Alexey's first option.

[Alexey Kopytov (akopytov)]

OK, let's fix this by removing '-p' from the 'cp' command line in innobackupex.

By the way, currently innobackupex --rsync does not preserve ownership and permissions either, as it calls rsync as just "rsync -t \"$source_dir\" --files-from=\"$rsync_file_list\" \"$backup_dir\"".

[Raghavendra D Prabhu (raghavendra-prabhu)]

Alternatively, adding --no-preserve=ownership should fix this (which preserving other attributes like timestamps).

[Alexey Kopytov (akopytov)]

Yes, I guess "--no-preserve=ownership" is equivalent to "--preserve=mode,timestamp" which is mentioned in comment #4.

[Shahriyar Rzayev (rzayev-sehriyar)]

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