# Do we need to manually backup Binlog encryption keys while restoring from a backup **URL:** \ **Category:** Uncategorized\ **Created:** [February 10, 2026, 7:32am UTC](https://forums.percona.com/t/do-we-need-to-manually-backup-binlog-encryption-keys-while-restoring-from-a-backup/40179 "2026-02-10T07:32:30Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Yash\_Daga](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yash_daga/32/22569_2.png) [@Yash\_Daga](https://forums.percona.com/u/Yash_Daga)\ **Post date:** [February 10, 2026, 7:32am UTC](https://forums.percona.com/t/do-we-need-to-manually-backup-binlog-encryption-keys-while-restoring-from-a-backup/40179/1 "2026-02-10T07:32:30Z")
Hi, We are using Percona XtraDB Cluster 8.0.44 and Percona XtraBackup 8.0.35 via the Percona Operator 1.19.0. Our setup uses `keyring_file` with both `default_table_encryption=ON` and `binlog_encryption=ON`. We use the `--transition-key` option for our backups. We have confirmed that for the base data restore, the transition key works as expected: we do not need the original `INNODBKey` from the source keyring to restore the tablespaces. We wanted to ask about the behavior for **encrypted binary logs** included in the backup? 1. Does XtraBackup re-encrypt the binlogs using the `--transition-key` (similar to how it handles tablespaces)? 2. Or do the binlogs remain encrypted using the original `MySQLReplicationKey` IDs? For Cross-site Disaster Recovery/PITR, we need to know if the transition key is sufficient to apply binlogs on a new site with an empty keyring, or if we are strictly required to also backup and provide the original source `keyring_file` specifically for `mysqlbinlog` to function. @Ege_Gunes Thanks! ---
**Author:** ![Yash\_Daga](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yash_daga/32/22569_2.png) [@Yash\_Daga](https://forums.percona.com/u/Yash_Daga)\ **Post date:** [February 11, 2026, 11:49am UTC](https://forums.percona.com/t/do-we-need-to-manually-backup-binlog-encryption-keys-while-restoring-from-a-backup/40179/2 "2026-02-11T11:49:54Z")
I see that xtrabackup keys also encrypts Binlog’s DEK and we should not require the original master keys while restoring since only having the transition key should be enough according to > > > MySQL 8.0.14 adds binary log encryption. It works similarly to InnoDB > encryptio…n in terms of key management. There is a file password used to > encrypt the binary log file. It is stored in encrypted form in the file > header together with the master key ID and IV (used to decrypt file > password). The encryption key for the file password (master key) is > stored in the keyring. Server never changes the file password. > > When copying the binary log file, xtrabackup makes sure to add the > encryption header size to the binary log position so that binary log > data isn't truncated. > > When transition-key is specified for backup, xtrabackup decrypts the > file password from the binary log header and stores it into the > "xtrabackup\_keys" file with the SPACE\_ID = -1 and IV = > "MYSQL-BINARY-LOG" to distinguish it from the InnoDB keys. > > When generate-new-master-key is specified for the copy-back, xtrabackup > generates new master key, stores it into the keyring, and reencrypts the > binlog file header with the newly generated master key. But when I try to restore after removing old master keys present in vault using the transistion key, the restore job is successful but the prepare job fails with `Binlog has bad magic number; It’s not a binary log file that can be used by this version of MySQL`. logs: ```auto 2026-02-11T11:25:19.289025Z 1 [Note] [MY-000000] [WSREP] Server status change connected → joiner 2026-02-11T11:25:19.289041Z 1 [Note] [MY-000000] [WSREP] wsrep_notify_cmd is not defined, skipping notification. 2026-02-11T11:25:19.289064Z 1 [Note] [MY-000000] [WSREP] Server status change joiner → initializing 2026-02-11T11:25:19.289072Z 1 [Note] [MY-000000] [WSREP] wsrep_notify_cmd is not defined, skipping notification. 2026-02-11T11:25:19.289150Z 0 [Warning] [MY-013712] [Server] No suitable ‘keyring_load’ service implementation found to fulfill the request. 2026-02-11T11:25:19.295403Z 0 [Warning] [MY-011197] [Server] Plugin keyring_vault reported: ‘Probing mysql-keyring for being a mount point unsuccessful - skipped.’ 2026-02-11T11:25:19.368047Z 0 [Warning] [MY-010075] [Server] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 58c11fb1-073c-11f1-87a0-eafd9286b3b4. 2026-02-11T11:25:19.370930Z 3 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2026-02-11T11:25:19.493475Z 3 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2026-02-11T11:25:19.582371Z 3 [Note] [MY-000000] [WSREP] wsrep_init_schema_and_SR (nil) 2026-02-11T11:25:19.597026Z 3 [System] [MY-000000] [WSREP] PXC upgrade completed successfully 2026-02-11T11:25:19.628169Z 0 [ERROR] [MY-010958] [Server] Binlog has bad magic number; It’s not a binary log file that can be used by this version of MySQL. 2026-02-11T11:25:19.628201Z 0 [ERROR] [MY-010041] [Server] Can’t init tc log 2026-02-11T11:25:19.628208Z 0 [ERROR] [MY-010119] [Server] Aborting 2026-02-11T11:25:19.628212Z 0 [Note] [MY-000000] [WSREP] Initiating SST cancellation 2026-02-11T11:25:21.628340Z 0 [Note] [MY-000000] [WSREP] Server status change initializing → disconnecting 2026-02-11T11:25:21.628356Z 2 [Note] [MY-000000] [WSREP] rollbacker thread exiting 2 2026-02-11T11:25:21.628399Z 0 [Note] [MY-000000] [WSREP] wsrep_notify_cmd is not defined, skipping notification. 2026-02-11T11:25:21.628439Z 0 [Note] [MY-000000] [Galera] Closing send monitor… 2026-02-11T11:25:21.628446Z 0 [Note] [MY-000000] [Galera] Closed send monitor. 2026-02-11T11:25:21.628455Z 0 [Note] [MY-000000] [Galera] gcomm: terminating thread 2026-02-11T11:25:21.628467Z 0 [Note] [MY-000000] [Galera] gcomm: joining thread 2026-02-11T11:25:21.628999Z 0 [Note] [MY-000000] [Galera] gcomm: closing backend 2026-02-11T11:25:21.629040Z 0 [Note] [MY-000000] [Galera] PC protocol downgrade 1 → 0 2026-02-11T11:25:21.629047Z 0 [Note] [MY-000000] [Galera] Current view of cluster as seen by this node view ((empty)) 2026-02-11T11:25:21.629202Z 1 [ERROR] [MY-000000] [Galera] Exception: State wait was interrupted 2026-02-11T11:25:21.629280Z 1 [ERROR] [MY-000000] [Galera] View callback failed. This is unrecoverable, restart required. (FATAL) at ../../../../percona-xtradb-cluster-galera/galera/src/replicator_smm.cpp:submit_view_info():2633 2026-02-11T11:25:21.629300Z 1 [Note] [MY-000000] [Galera] ReplicatorSMM::abort() 2026-02-11T11:25:21.629321Z 1 [Note] [MY-000000] [Galera] mysqld: Terminated. /var/lib/mysql/prepare_restored_cluster.sh: line 38: 13 Aborted mysqld --skip-grant-tables --skip-networking ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2) ``` @Ege_Gunes @matthewb ---
**Author:** ![Yash\_Daga](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yash_daga/32/22569_2.png) [@Yash\_Daga](https://forums.percona.com/u/Yash_Daga)\ **Post date:** [February 11, 2026, 6:24pm UTC](https://forums.percona.com/t/do-we-need-to-manually-backup-binlog-encryption-keys-while-restoring-from-a-backup/40179/3 "2026-02-11T18:24:33Z")
Not sure, what was the issue was exactly but the error went away on retrying.