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. Identify the engine and topology
With the DBA, record MariaDB server/client and agent/master releases, host/port, instance and test database. Inventory charset/collation, table engines, replica/Galera and GTID dependencies separately; do not test MariaDB under a MySQL identity.
Expected resultEngine, method and acceptance evidence are recorded.
022. Check agent, tool and privilege access
Validate the Linux agent, mariadb/mariadb-dump/mariadb-binlog tools and registered instance credential access. Check repository capacity and required DB/OS privileges with the DBA. Keep passwords and connection secrets out of screenshots; responsive status is not dump/binlog acceptance.
Expected resultEngine, method and acceptance evidence are recorded.
033. Select the correct SQL engine and method
Select Agent, Policy Name and Storage in Agent Policy → Create Agent Policy. Under SQL → MariaDB match MariaDB Dump Full Only (mariadb_dump) or MariaDB Dump Full + Binary Log Incremental (mariadb_binlog) to the plan. Default binlog mode does not satisfy source prerequisites.
Expected resultEngine, method and acceptance evidence are recorded.
044. Validate Clients and data scope
Open the registered MariaDB instance and select only the test database. Compare Single Transaction and Routines & Events with table engines, concurrent DDL, routines/triggers/events and user/grant scope. Do not assume automatic consistency for nontransactional tables; verify the summary matches the selected database.
Expected resultEngine, method and acceptance evidence are recorded.
055. Complete log-chain and retention prerequisites
For mariadb_binlog validate log_bin, server_id and binlog retention. Dump coordinates must align continuously with subsequent log files/positions or the MariaDB GTID chain. Do not assume identical MySQL GTID/binlog behavior; plan chain and restore acceptance before changing source purge settings.
Expected resultEngine, method and acceptance evidence are recorded.
066. Plan scheduling and initial backup acceptance
Check scheduling and retention actually exposed for the engine/method in Advanced Settings and Schedules. Compare Full-base and dependent log/differential/incremental-chain retention with capacity; do not assume every method applies to each engine. In an approved small test, record task result, repository output and catalog method together.
Expected resultThe selection and relevant acceptance evidence are recorded.
077. Complete database and application acceptance
Use the separate engine restore guide to validate database startup, schema, sample queries, row counts and application access on an approved isolated target. Active, Last Backup or a success notification alone is not content acceptance. Record backup identity, method, time and the required chain in the report.
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.