# Unable to restore from point-in-time physical backup **URL:** \ **Category:** Percona Server for MySQL 8.0\ **Created:** [March 21, 2025, 1:35am UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291 "2025-03-21T01:35:33Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![john.a](https://avatars.discourse-cdn.com/v4/letter/j/dbc845/32.png) [@john.a](https://forums.percona.com/u/john.a)\ **Post date:** [March 21, 2025, 1:35am UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/1 "2025-03-21T01:35:33Z")
Hi, Trying to do a test backup and restore from a point-in-time storage snapshot and Percona MySQL 8.0 is failing to start with the following error: 2025-03-21T01:26:13.004557Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2025-03-21T01:26:15.355486Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:7982:err == DB\_SUCCESS thread 140551824635456 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](http://bugs.mysql.com). InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: [http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html](http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html) InnoDB: about forcing recovery. 2025-03-21T01:26:15Z UTC - mysqld got signal 6 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. BuildID[sha1]=a32bfce59229782139dde88004d464c063c13240 Server Version: 8.0.37-29 Percona Server (GPL), Release 29, Revision 30dc4e71 Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong… stack\_bottom = 0 thread\_stack 0x100000 /usr/sbin/mysqld(my\_print\_stacktrace(unsigned char const\*, unsigned long)+0x41) [0x15e94f1] /usr/sbin/mysqld(print\_fatal\_signal(int)+0x3e7) [0xde1447] /usr/sbin/mysqld(my\_server\_abort()+0x6d) [0xde14cd] /usr/sbin/mysqld(my\_abort()+0xe) [0x15ded2e] /usr/sbin/mysqld(ut\_dbg\_assertion\_failed(char const\*, char const\*, unsigned long)+0x16f) [0x17bc71f] /usr/sbin/mysqld(fil\_aio\_wait(unsigned long)+0x230) [0x18d3de0] /usr/sbin/mysqld() [0x1706dca] /usr/sbin/mysqld() [0x17076b9] /lib64/libstdc++.so.6(+0xdbad4) [0x7fd4d4647ad4] /lib64/libc.so.6(+0x897f2) [0x7fd4d42f87f2] /lib64/libc.so.6(+0x10e880) [0x7fd4d437d880] Please help us make Percona Server better by reporting any bugs at … MySQL version: mysql Ver 8.0.37-29 for Linux on x86\_64 (Percona Server (GPL), Release 29, Revision 30dc4e71) /etc/my.cnf [mysqld] datadir = /data/mysql socket = /var/lib/mysql/mysql.sock log-error = /var/log/mysqld.log pid-file = /var/run/mysqld/mysqld.pid auto\_increment\_increment = 2 auto\_increment\_offset = 1 binlog\_transaction\_compression = ON innodb\_dedicated\_server = ON innodb\_io\_capacity = 5000 innodb\_io\_capacity\_max = 10000 innodb\_redo\_log\_capacity = 32G gtid\_mode = ON enforce\_gtid\_consistency = ON read\_only = ON replicate-wild-ignore-table = mysql.% server\_id = 10 * * * VM Instance size is 32 cores, 48 GB Mem, DB size is roughly 230G. Any help that would point to the cause of that assertion failure would be greatly appreciated. Thanks ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 21, 2025, 1:47am UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/2 "2025-03-21T01:47:49Z")
> [@john.a](#): > > Trying to do a test backup and restore from a point-in-time storage snapshot What exactly does this mean? Please provide details on how the backup was taken, what tools were used, what commands, output of those commands, all the steps, etc. ---
**Author:** ![john.a](https://avatars.discourse-cdn.com/v4/letter/j/dbc845/32.png) [@john.a](https://forums.percona.com/u/john.a)\ **Post date:** [March 21, 2025, 2:39am UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/3 "2025-03-21T02:39:54Z")
Apologies, missed that in my post. Using Veeam Backup and Restore via vSphere to take a backup of the entire virtual machine. It snapshots the virtual machine disk at a point in time for consistency, similar to how one would use an LVM snapshot to create a backup. Thanks Edit: For Backup & Restore steps just followed standard Veeam Backup & Restore: > **[Creating Backup Job - Quick Start Guide for VMware vSphere](https://helpcenter.veeam.com/docs/backup/qsg_vsphere/backup_job.html?ver=120)** > > Before You Begin Make sure that all backup infrastructure components that take part in the backup process are added to the backup infrastructure. These components include ESXi hosts on which VMs are registered,... > **[Restoring Entire VM - Quick Start Guide for VMware vSphere](https://helpcenter.veeam.com/docs/backup/qsg_vsphere/vm_restore.html?ver=120)** > > If a VM fails, you can restore it from a backup file. You can restore a single VM or multiple VMs to the original or new location. In this section, you will learn how to restore a VM to the original location.... ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 21, 2025, 6:10pm UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/4 "2025-03-21T18:10:02Z")
We would need to see some logs from the backup process itself. If MySQL is not flush-locked during the backup, then partially written pages could be snap’d by Veeam, and then those corrupt pages get restored. You should be configuring “MySQL backups”, not “VM” backups. ---
**Author:** ![john.a](https://avatars.discourse-cdn.com/v4/letter/j/dbc845/32.png) [@john.a](https://forums.percona.com/u/john.a)\ **Post date:** [March 24, 2025, 10:41pm UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/5 "2025-03-24T22:41:52Z")
I see. I was under the impression Veeam MySQL backups used the same storage snapshot mechanism. > **[MySQL Backup - Veeam Agent for Linux User Guide](https://helpcenter.veeam.com/docs/agentforlinux/userguide/mysql_backup.html?ver=60#how-mysql-processing-works)** > > You can use Veeam Agent for Linux to create transactionally consistent backups of Veeam Agent machines that run the MySQL database system. Requirements and Limitations of MySQL Processing Veeam Agent for Linux... Our current issue is that we lost the primary mysql DB due to a host crash and are currently running on the replica. I’m trying to create a copy of the data but not having much success so far. It looks like the backup mechanism for MySQL 8.0 changed because when I try to backup via xtrabackup or mysqldump, it causes “Waiting for table metadata lock” on application processes which impacts prod. Would you be able to recommend a way I can backup this DB in order to rebuild our replica? ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 25, 2025, 3:28am UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/6 "2025-03-25T03:28:24Z")
Do you have any MyISAM tables in use? If every table is InnoDB, you should be able to take a hot, non-locking, backup with Xtrabackup. If you want to use mysqldump, try enabling --single-transaction or use [mydumper](https://github.com/mydumper/mydumper) as a better alternative to mysqldump. ---
**Author:** ![john.a](https://avatars.discourse-cdn.com/v4/letter/j/dbc845/32.png) [@john.a](https://forums.percona.com/u/john.a)\ **Post date:** [March 25, 2025, 4:04am UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/7 "2025-03-25T04:04:23Z")
All the tables are InnoDB. > If every table is InnoDB, you should be able to take a hot, non-locking, backup with Xtrabackup That was my understanding as well, alternatively, the process could be killing throughput. Our production instance is 1.3TB in size… ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 25, 2025, 12:55pm UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/8 "2025-03-25T12:55:51Z")
> [@john.a](#): > > Waiting for table metadata lock” You should not see this message when using Xtrabackup. How exactly are you executing PXB? You could try `--no-lock`. ---
**Author:** ![liz.rea](https://avatars.discourse-cdn.com/v4/letter/l/ecd19e/32.png) [@liz.rea](https://forums.percona.com/u/liz.rea)\ **Post date:** [March 28, 2025, 3:44pm UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/9 "2025-03-28T15:44:59Z")
Hi, If there are MyISAM tables, you could try running xtrabackup with --rsync (it’s undocumented, but it is there) - I have just recently had great success with mixed tablespace backups using --rsync. Even on large datasets the lock time is only a couple of seconds. For our loads that is ok, your mileage may vary. Cheers, Liz ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 28, 2025, 6:36pm UTC](https://forums.percona.com/t/unable-to-restore-from-point-in-time-physical-backup/37291/10 "2025-03-28T18:36:20Z")
Hi @liz.rea, above he says all tables are InnoDB. Also, the `--rsync` flag is a [fully documented](https://docs.percona.com/percona-xtrabackup/8.0/xtrabackup-option-reference.html#rsync) option.