BEFORE YOU BEGIN
Check before you begin
MariaDB is a separate engine with lin_mariadb, mariadb_dump and mariadb_binlog selections. Do not assume MySQL tool, GTID or restore compatibility. MariaDB-specific routing was not verified in the inspected generic Backup List restore template; the MySQL form is not MariaDB support evidence.
Verification limit: these guides are based on local agent and restore templates. No new MariaDB/MongoDB application screen was captured in this inspection; MySQL/PostgreSQL screenshots were not substituted. Source discovery, dump/log chains and destination data acceptance require separate validation in the installed release. No instance/policy, backup, restore, binlog purge or oplog replay was executed.
- 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. Find the source engine and method record
In Backup List compare the MariaDB source host, instance/database, method and time. Distinguish Full dumps from binlog chains. A Not Yet Backup record is not a usable point; do not substitute another engine’s catalog for this restore path.
Expected resultEngine, method and acceptance evidence are recorded.
022. Validate the Full base and dependent logs
In Action → Restore jointly check the requested point, Full identity, required incremental files and repository access. Dump-only returns to one dump time; log mode needs the complete required range and order. A calendar or Incremental label alone is not PITR evidence.
Expected resultEngine, method and acceptance evidence are recorded.
033. Validate the engine’s actual target routing
MariaDB-specific sql_type/target routing was not verified in the inspected generic Backup List template. Do not use the MySQL Different Location form as a MariaDB target screen. Do not start final Restore or alternative-command writes before agreeing the installed backend, method and isolated-destination procedure with the technical team.
Expected resultEngine, method and acceptance evidence are recorded.
044. Define the isolated destination and data effects
With the DBA compare target MariaDB release, tools, charset/collation, sql_mode, users/grants and routines/events. Separately plan Galera/replica and GTID effects; do not assume MySQL compatibility. Stop if same-name database or log-replay collisions are unclear.
Expected resultEngine, method and acceptance evidence are recorded.
055. Review Summary and the final action
Compare source method, database/alldb scope, Full/log identities, destination instance and data effects. Do not assume a time field or automatic log finalization where unverified. Execute final Restore only in a test plan with validated destination and effects; no Restore was submitted while preparing this guide.
Expected resultEngine, method and acceptance evidence are recorded.
066. Check engine state and content acceptance
Compare EraBackup task results with MariaDB logs and destination database access. The DBA must assess table integrity, sample queries and binlog/GTID effects. Do not blindly resubmit to the same target after partial failure.
Expected resultEngine, method 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.