You are creating a strategy for backing up MySQL using a cold binary backup. The MySQL instance is a replication master with global transaction identifiers (GTIDs) enabled and it uses Transparent…

Question

Options

• AInclude the keying data and/or configuration in the backup.
• BRestore the backup to a clean MySQL instance.
• CCopy the backup to a remote host.
• DInclude the MySQL socket file in the backup.
• EInclude the ibtmp1 file in the backup.
• FInclude the relay logs in the backup.
• GInclude the operating system disk encryption key in the backup.
• HInclude the MySQL PID file in the backup.
• IInclude the binary logs in the backup.

• B
  8% (3)
• C
  65% (24)
• F
  3% (1)
• H
  19% (7)
• I
  5% (2)

Explanation

Note: This is a "choose four" question, but the source only marks C - the full correct set is A, C, I, and B, which together satisfy all three requirements.

C is correct because the requirement to "allow for a catastrophic hardware failure" means the backup cannot live on the same physical host as the data - copying it to a remote host is the only option that survives total hardware loss. A is correct because TDE uses MySQL's keyring plugin to encrypt InnoDB data files; without the keying data/configuration, the backed-up files are permanently unreadable - you cannot rebuild the instance. I is correct because the instance is a GTID-enabled replication master, and binary logs carry the full GTID history; without them, you cannot re-establish replication or perform point-in-time recovery after restore. B is correct because the requirement "it must be possible to rebuild the instance" is only verified by actually restoring to a clean instance - an untested backup cannot be considered valid.

The remaining choices are all distractors: D (socket) and H (PID file) are runtime artifacts MySQL recreates at startup; E (ibtmp1) is a temporary tablespace that holds no persistent data and is also recreated at startup; F (relay logs) belong to replication slaves/replicas, not masters; and G (OS disk encryption key) is irrelevant - TDE is a MySQL-layer feature using its own keyring, entirely separate from OS-level disk encryption.

Memory tip: Runtime files never travel with backups (socket, PID, temp tablespace). For TDE, think "keys travel with the lock" - back up the keyring or the data is forever unreadable. Relay logs are a slave's concern, not a master's. And an unverified backup isn't a backup - always include the restore test.

No community discussion yet for this question.