BEFORE YOU BEGIN
Check before you begin
MongoDump Only and MongoDump + Oplog Incremental are separate methods; single-database and alldb selection scopes also differ. Oplog incremental requires replica set access. Sharded-cluster, arbitrary point-in-time, automatic replica-set reconstruction and full-cluster recovery were not validated in this inspection.
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 MongoDB server/client and agent/master releases, host/port, instance and test database. Record standalone/replica-set/sharded topology, replica set name, authSource/TLS and database scope; do not generalize single-database acceptance to an entire cluster.
Expected resultEngine, method and acceptance evidence are recorded.
022. Check agent, tool and privilege access
Validate the Linux agent, mongodump/mongorestore versions and registered instance connection. Scope database/oplog access with the DBA. Keep URI passwords, TLS keys and secrets out of screenshots. A running agent does not establish replica-set/oplog access.
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 → MongoDB match MongoDump Only (mongodump) or MongoDump + Oplog Incremental (mongodump_oplog) to the plan. Selecting oplog mode does not make a standalone server ready.
Expected resultEngine, method and acceptance evidence are recorded.
044. Validate Clients and data scope
Open the registered MongoDB instance and explicitly select single-database or all-database (alldb) scope. Validate actual collection, index, user/role and application-dependency coverage. Stop on empty discovery or timeouts. Assess alldb using a different restore plan from a single database.
Expected resultEngine, method and acceptance evidence are recorded.
055. Complete log-chain and retention prerequisites
For mongodump_oplog validate replica set access and alignment of the required oplog time range with the Full base. An oplog window shorter than job lag may break the chain; record time, namespace and data scope together. Oplog mode does not guarantee generic sharded-cluster or arbitrary-time recovery.
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.