# xtrabackup do not backup frm files **URL:** \ **Category:** Percona XtraBackup\ **Created:** [August 25, 2013, 12:01pm UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905 "2013-08-25T12:01:23Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![glb\_ussr](https://avatars.discourse-cdn.com/v4/letter/g/87869e/32.png) [@glb\_ussr](https://forums.percona.com/u/glb_ussr)\ **Post date:** [August 25, 2013, 12:01pm UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/1 "2013-08-25T12:01:23Z")
Hello. I am use xtrabackup 2.1.4 on FreeBSD 9.1. When a make backup xtrabackup\_56 --defaults-file=/etc/my.cnf --datadir=/var/db/mysql --target-dir=/home/backup/ --backup, in target directory I see only idb files. After I make restore procedure like xtrabackup\_56 --prepare --target-dir=/home/backup/, in target dir steel only idb files. After that, I try to copy my restored data base to MySQL data dir, and change owner, and restart… but mysql\> use exchanger; Database changed mysql\> show tables; Empty set (0.00 sec) mysql\> exit What I do not right ? ---
**Author:** ![mirfan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/mirfan/32/16890_2.png) [@mirfan](https://forums.percona.com/u/mirfan)\ **Post date:** [August 26, 2013, 3:39am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/2 "2013-08-26T03:39:13Z")
Hi, Can you please share backup command and logfile for that to identify the problem. ---
**Author:** ![glb\_ussr](https://avatars.discourse-cdn.com/v4/letter/g/87869e/32.png) [@glb\_ussr](https://forums.percona.com/u/glb_ussr)\ **Post date:** [August 26, 2013, 4:51am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/3 "2013-08-26T04:51:33Z")
Backup file it is a xtrabackup\_logfile ? My backup command is xtrabackup\_56 --defaults-file=/etc/my.cnf --datadir=/var/db/mysql --target-dir=/home/backup/ --backup ---
**Author:** ![glb\_ussr](https://avatars.discourse-cdn.com/v4/letter/g/87869e/32.png) [@glb\_ussr](https://forums.percona.com/u/glb_ussr)\ **Post date:** [August 26, 2013, 5:32am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/4 "2013-08-26T05:32:21Z")
log from stdout [log.zip](https://forums.percona.com/uploads/short-url/zVajGXOuvK8SumxdVv2MUAD5zim.zip) (4.3 KB) ---
**Author:** ![mirfan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/mirfan/32/16890_2.png) [@mirfan](https://forums.percona.com/u/mirfan)\ **Post date:** [August 26, 2013, 7:41am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/5 "2013-08-26T07:41:20Z")
Hi, Sorry, previously i overlooked into it. Xtrabackup copies only the InnoDB data and logs. It does not copy table definition files (.frm files). It’s docuemented. You can read more about it here [url][Percona XtraBackup](http://www.percona.com/doc/percona-xtrabackup/2.1/xtrabackup_bin/limitation.html%5B/url%5D) I suggest to use innobackupex which is wrapper script for the xtrabackup. It provides more functionality including copy of schema definitions. Check on the following link for the full documentation of innobackupex. [url][Percona XtraBackup](http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html%5B/url%5D) ---
**Author:** ![glb\_ussr](https://avatars.discourse-cdn.com/v4/letter/g/87869e/32.png) [@glb\_ussr](https://forums.percona.com/u/glb_ussr)\ **Post date:** [August 26, 2013, 8:32am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/6 "2013-08-26T08:32:09Z")
Can i copy on runing mysql .frm files ? ---
**Author:** ![przemek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/przemek/32/3_2.png) [@przemek](https://forums.percona.com/u/przemek)\ **Post date:** [September 4, 2013, 10:28am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/7 "2013-09-04T10:28:06Z")
That is why innobackupex script was developed, to manage .frm and all other non-transactional files copy properly. [url][Percona XtraBackup](http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html%5B/url%5D) There are plans though to implement this functionality into xtrabackup. ---
**Author:** ![machielr](https://avatars.discourse-cdn.com/v4/letter/m/9fc29f/32.png) [@machielr](https://forums.percona.com/u/machielr)\ **Post date:** [November 13, 2013, 8:46am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/8 "2013-11-13T08:46:28Z")
Hi guys, I am also experiencing the same problem. I am actually using the innobackupex script and yet, it is still only copying the ibd files and it also seem to get stuck on "scanned up to log " entries and after 2 days of running on a 226Gb database it has not made any progress. I have searched every forum and link I can find but nothing seems to make a difference at all. ---
**Author:** ![machielr](https://avatars.discourse-cdn.com/v4/letter/m/9fc29f/32.png) [@machielr](https://forums.percona.com/u/machielr)\ **Post date:** [November 13, 2013, 9:09am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/9 "2013-11-13T09:09:47Z")
sorry just to clarify, the innobackupex scripts is run simply by invoking "innobackupex " , the scripts copied over all .ibd files and also scan logs. problems I seem to be encountering is that there are no .frm files,etc… copied, nothing from the mysql database (system tables) are being copied, and after the ibd files are finished copying, the scanned logs goes into a continuous cycle until I manually delete the xtrabackup\_suspended file. ---
**Author:** ![jynus](https://avatars.discourse-cdn.com/v4/letter/j/e36b37/32.png) [@jynus](https://forums.percona.com/u/jynus)\ **Post date:** [November 16, 2013, 12:39am UTC](https://forums.percona.com/t/xtrabackup-do-not-backup-frm-files/2905/10 "2013-11-16T00:39:41Z")
machielr: your copy process may be blocked by large on-going transactions, that have to finish before the non-innodb bits are copied (mysql tables and .frms). There are some things that you can try, depending on the situation. First one, would be to avoid long open transactions while the last part of the backup happens (the non-transactional copy). Second, using --rsync (that will not avoid the locking but you may have copied most of the non-transactional bits before the locking, so if you cancel the copy, you may still save something, although in a non consistent way). You can use --no-lock, that will avoid the process to be blocked, but if you execute an ALTER TABLE or update a non-InnoDB table during the copy process, the backup may not be consistent. The real solution will probably come by using the new features in the latest releases of xtrabackup: [url][Percona XtraBackup](http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/improved_ftwrl.html%5B/url%5D) with --lock-wait-timeout or --kill-long-query-type you can control the specific behaviour of the backup process: making it fail immediately and retry later or kill the offending queries to allow the backup to continue. Obviously, use both options with caution. Regards,