BEFORE YOU BEGIN
Check before you begin
This guide covers the inspected Linux SQL → MySQL agent workflow. mysql_dump and mysql_binlog have different prerequisites; MariaDB is a separate engine/method. A menu option is not end-to-end acceptance for every storage engine, GTID/replica topology or arbitrary point-in-time recovery.
Live verification limit: no new MySQL screen was captured in this inspection; PostgreSQL screenshots were not substituted. Steps are based on local Agent Policy and MySQL restore templates. Dump/binlog chains, target forms and data acceptance require separate validation in the installed release. No instance/policy, backup/restore or binlog purge operation was performed.
- Engine, agent/master releases and instance identity
- Database scope, method and access privileges
- Full base, log chain and repository access
- Isolated destination, collisions and application acceptance
011. Identify record method and source identity
Compare host, instance/database, Method and date for the MySQL job in Backup List. A Not Yet Backup entry is not a usable point. Do not handle Full dumps, physical bases and log chains as the same restore method.
Expected resultMethod, selection and acceptance evidence are recorded.
022. Match Full and dependent points
Inspect the correct database and Full point under Action → Restore. Dump-only returns to one dump time. For binlog mode, jointly validate the Full base, log order/coordinates and requested time range; an Incremental catalog label is not proof of chain integrity.
Expected resultMethod, selection and acceptance evidence are recorded.
033. Check the method-specific destination form
The inspected MySQL path offers Original Location and Different Location. The latter form includes Database Name and Instance; a separate Restore Agent selector was not verified for this path. Do not assume different-host recovery or automatic replica attachment. The DBA must validate collision/overwrite effects using a clean isolated test database.
Expected resultMethod, selection and acceptance evidence are recorded.
044. Prepare destination release and data dependencies
Compare destination engine/client releases, charset/collation, sql_mode, users/grants, routines/events and file/capacity dependencies. Do not infer MySQL/MariaDB compatibility from similar names. Isolate replica/GTID and duplicate-transaction effects during binlog replay through the DBA plan.
Expected resultMethod, selection and acceptance evidence are recorded.
055. Validate Summary and the time target
In MYSQL Restore Summary compare method, Full/incremental identities, instance and new database name. A generic MySQL Point In Time target field was not verified here; binlog mode does not guarantee recovery to an arbitrary second. Submit Restore only in a test with validated destination effects; no new Restore was submitted in this inspection.
Expected resultMethod, selection and acceptance evidence are recorded.
066. Compare engine and data state
Compare EraBackup task results with MySQL engine logs, database access and any recovery/replay state. Inspect a partially failed destination with the DBA; do not blindly resubmit restore to the same target. Queueing or a success notification is not data-integrity acceptance.
Expected resultMethod, selection and acceptance evidence are recorded.
077. Document data and application acceptance
With the data owner, compare test queries, schema, sample rows, consistency and application connections. Record actual recovery time and data loss, releases, backup chain and destination identity. Separate standalone-database acceptance from cluster/HA failover acceptance. No production connection or DNS cutover was performed while preparing this guide.
Expected resultThe selection and relevant acceptance evidence are recorded.
COMMON QUESTIONS
Does a successful task mean the application is ready?
Not by itself. Engine integrity, required log chains, data queries and application access need separate validation; HA/topology acceptance is assessed separately.