MongoDB backups that are restored on a schedule

SafeGrd backs up MongoDB 7 and 8 with mongodump --archive, streaming the archive straight into an encrypted snapshot on your host. The snapshot is written to S3-compatible storage under Object Lock and restored on a schedule, and every collection's document count is checked against the one mongodump recorded.

Run your first Fire Drill Read the install guide

curl -fsSL https://safegrd.dev/install.sh | sh
safegrd backup --database-url "mongodb://backup:$DB_PASSWORD@db.internal:27017/app?authSource=admin" --retention-days 14

What each backup holds

• A standard mongodump archive. Once decrypted, it loads with mongorestore, with or without SafeGrd.
• Indexes and view definitions, recreated on restore.
• Checked as it streams. Document counts and collection checksums are validated while the archive streams through.
• No connection string on a command line. It goes to mongodump in an owner-only file. Both mongodb:// and mongodb+srv:// URLs work.

What a Fire Drill checks

An in-memory drill reads the archive to its end and matches document counts and collection checksums with the values mongodump recorded. A sandbox drill restores the archive into a temporary database with mongorestore, counts each collection there, and drops the temporary collections when it is done. Each result is signed and added to your record, and a failed drill alerts your team.

What to know before you rely on it

• Each collection is read consistently, but a database-scoped dump does not capture the oplog, so two collections can reflect slightly different moments if they are written during the backup.
• Users and roles are server-wide and are not part of a single database's archive. Keep them in your provisioning code.
• A restore goes into an empty database, under any name. If one fails partway, drop the target database before you run it again.

How to restore

Point the restore at an empty database, under any name, on a host that has the CLI, the MongoDB Database Tools and the key.

The target has to be empty: the restore refuses a database that already holds collections. If a restore fails partway, drop the target database before you run it again.

The restore loads the archive with mongorestore and counts each collection against the manifest written at backup time (Restore and Fire Drills).

Questions

What does the host need?

The MongoDB Database Tools (mongodb-database-tools) and a network path to the server. SafeGrd only reads, so the backup user needs no write role.

Can I restore it without SafeGrd?

The CLI is source-available and restores from your own bucket with or without an account. After it decrypts a snapshot, the archive inside is the format mongorestore reads.

Who holds the decryption key?

You choose when the key is made. With a SafeGrd-managed key, SafeGrd keeps your key sealed and releases it only to your enrolled hosts, so you can restore even after losing a host. With a customer-managed key, only you can decrypt these backups.

Related

• Backup file checker: does a mongodump archive end where it should
• Backup verification: what each kind of check proves
• Databases: every option, for MongoDB