# Faulty backups problem **URL:** \ **Category:** Percona XtraBackup\ **Created:** [June 23, 2016, 3:30pm UTC](https://forums.percona.com/t/faulty-backups-problem/4940 "2016-06-23T15:30:26Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![kylereese](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/kylereese/32/1022_2.png) [@kylereese](https://forums.percona.com/u/kylereese)\ **Post date:** [June 23, 2016, 3:30pm UTC](https://forums.percona.com/t/faulty-backups-problem/4940/1 "2016-06-23T15:30:26Z")
I am having issues taking reliable backups using innobackupex. The database is good sized at ~2.2 TB using the following command for backup: innobackupex --defaults-file=/etc/my.cnf --host=127.0.0.1 --user=USERNAME --password=PASSWORD --parallel=4 --compress --compress-threads=2 --no-timestamp --slave-info --safe-slave-backup --tmpdir=/tmp /mysqlbackups The backup completes in just about 3 hours and 20 minutes. I have made multiple attempts at restoring this backup to another server, however it crashes miserably. Below is a snapshot of the errors on the new server. 160623 17:39:27 mysqld\_safe Starting mysqld daemon with databases from /var/lib/mysql 160623 17:39:32 [Note] Plugin ‘FEDERATED’ is disabled. 160623 17:39:32 InnoDB: The InnoDB memory heap is disabled 160623 17:39:32 InnoDB: Mutexes and rw\_locks use GCC atomic builtins 160623 17:39:32 InnoDB: Compressed tables use zlib 1.2.3 160623 17:39:32 InnoDB: Using Linux native AIO 160623 17:39:32 InnoDB: Initializing buffer pool, size = 35.0G 160623 17:39:51 InnoDB: Completed initialization of buffer pool 160623 17:39:53 InnoDB: Log file ./ib\_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib\_logfile0 size to 1024 MB InnoDB: Database physically writes the file full: wait… InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 160623 17:39:57 InnoDB: Log file ./ib\_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib\_logfile1 size to 1024 MB InnoDB: Database physically writes the file full: wait… InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000 160623 17:40:01 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib\_logfiles! 160623 17:40:10 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer… 160623 17:40:13 InnoDB: Error: page 7 log sequence number 4551671899677 InnoDB: is in the future! Current system log sequence number 4476102782476. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: [url][http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html[/url]](http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html%5B/url%5D) InnoDB: for more information. The page log sequence errors continue on for quite some time, hundreds of them. At some point the following: InnoDB: Last MySQL binlog file position 0 538520993, file name /binlogs/signnow-bin.002470 InnoDB: Cleaning up trx with id 6167655F6E756D62 InnoDB: Cleaning up trx with id 2272657175697265 InnoDB: Cleaning up trx with id 19068005B InnoDB: Cleaning up trx with id 1905EC85C The host server is a slave server and is running CentOS 6.5 with Percona 5.5.49 with xtrabackup is 2.3.4. Below is the configuration in my.cnf. [mysqld] datadir = /var/lib/mysql server-id = 102 read\_only = 1 performance\_schema = on innodb\_file\_per\_table = 1 innodb\_buffer\_pool\_size = 50G innodb\_additional\_mem\_pool\_size = 32m innodb\_log\_file\_size = 1024m innodb\_log\_buffer\_size = 64m innodb\_flush\_log\_at\_trx\_commit = 1 innodb\_flush\_method = O\_DIRECT read\_buffer\_size = 1m sort\_buffer\_size = 1m key\_buffer\_size = 8m max\_connections = 200 max\_allowed\_packet = 128m query\_cache\_size = 1024 query\_cache\_type = 1 query\_cache\_strip\_comments = 1 tmp-table-size = 256M max-heap-table-size = 256M thread-cache-size = 50 table-open-cache = 2048 binlog\_format = row log-bin = /binlogs/signnow-bin expire\_logs\_days = 7 relay\_log = /binlogs/mysql-slave0-relay-bin relay\_log\_index = /binlogs/mysql-slave0-relay-bin.index auto\_increment\_offset = 1 auto\_increment\_increment = 2 long\_query\_time = 1 slow-query-log = 1 slow\_query\_log\_file = /mnt/mysql/log-slow-queries.log log\_slave\_updates = true [mysql] max\_allowed\_packet = 128m [mysqldump] max\_allowed\_packet = 128m The new server config matches the above except that it’s not a slave, so a different server-id and has less RAM so smaller buffer\_pool\_size. The database is getting restored with the following: /usr/bin/innobackupex --defaults-file=/etc/my.cnf --parallel=4 --decompress --no-timestamp --slave-info --safe-slave-backup --tmpdir=/mnt /mnt2/ Interestingly, using --defaults-file or not it will only decompress into the current location and not to /var/lib/mysql. However using rsync I copy the files to their location, though I have also tried mounting the drive at /var/lib/mysql to no avail.