How to Back Up and Restore MongoDB on a VPS

To back up MongoDB on a VPS, create a compressed archive with mongodump, copy it off the server, and test it with mongorestore. Keep the archive outside the live database directory and use a separate database for the restore test.

This guide covers small, self-managed deployments suited to command-line backups. Larger replica sets, sharded clusters, strict recovery point objectives, or compliance requirements may call for coordinated snapshots or managed backup tooling. Choose a method that meets your acceptable data-loss and recovery-time limits.

Key takeaways

• Use mongodump to create the backup and mongorestore to test it.
• Prefer a timestamped archive file so each run is easy to identify.
• Do not keep the only copy on the same VPS as the database.
• Avoid putting database passwords directly into shell history.
• Test a restore into a separate database or disposable environment before trusting automation.
• For help planning backups and maintaining the server, see VPS backups, backup FAQs, systemctl basics, and VPS security.

Before you start

Confirm five things before running a production MongoDB backup:

1. Which database or instance you need to back up.
2. Which user has backup permissions.
3. Where the temporary backup file will be written.
4. Where the off-server copy will live.
5. How you will test the restore.

Also check free disk space. A dump can be large, and compression is not a replacement for capacity planning. If the VPS is already low on disk space, copying a large database into the same filesystem can make the incident worse.

Step 1: create a timestamped backup directory

Create a predictable place for the backup artifacts. The example uses a home-directory path so it does not depend on a distribution-specific backup layout.

mkdir -p ~/backups/mongodb
BACKUP_FILE=~/backups/mongodb/app-$(date +%F-%H%M).archive.gz

The timestamp helps distinguish runs and match each file to logs and deployments. This example uses minute precision, so choose a different filename if you run it again within the same minute.

Step 2: run mongodump with archive and gzip

For a local MongoDB instance, use a connection string and a compressed archive:

mongodump --uri="mongodb://backup-user@localhost/app" --archive="$BACKUP_FILE" --gzip

Replace backup-user, localhost, and app with your real user, host, and database name. If your credentials require an authentication database, include it in the URI or add the appropriate authentication option from your MongoDB configuration.

The --archive option writes one archive file instead of a directory of BSON files. The --gzip option compresses the output. That combination is convenient for VPS backups because the result is a single file you can checksum, copy, rotate, and test.

Step 3: verify the backup file exists

After the command finishes, check the file:

ls -lh "$BACKUP_FILE"

Check that the dump command succeeded and the file has a plausible size. This can reveal a wrong path or a failed write; it cannot establish that the data will restore. Record the size and timestamp in your maintenance notes.

You can also create a checksum:

sha256sum "$BACKUP_FILE" > "$BACKUP_FILE.sha256"

Keep the checksum with the backup so you can detect corruption after transfer.

Step 4: copy the backup off the VPS

Do not leave the only MongoDB backup on the same server as the database. If the VPS disk fails, the account is compromised, or the filesystem is damaged, the local backup may disappear with the live data.

Copy the archive to another server, object storage bucket, backup service, or secure workstation. Use the storage location your organization already trusts. The exact transport can be scp, rsync, an object-storage CLI, or a backup agent, but the rule is the same: the recovery copy must survive the loss of the VPS.

Step 5: restore-test the backup

Run a restore test to check that the archive can be read and the recovered data is usable. Use a separate database name or disposable environment.

mongorestore --uri="mongodb://restore-user@localhost/restore-test" --archive="$BACKUP_FILE" --gzip --nsFrom="app.*" --nsTo="restore-test.*"

The namespace mapping example restores documents into a different database name so you do not overwrite production data. Adjust it to match your database and test environment. Do not add destructive restore options unless you understand exactly what will be dropped or replaced.

After the restore, check collection counts, important indexes, application startup, and a few representative records. For production change control, record the restore command, result, test time, and cleanup steps.

Step 6: automate only after the manual run works

Once the manual backup and restore test pass, automate the workflow. Automation should include:

• A dedicated backup user with the minimum required permissions.
• A timestamped filename.
• A destination outside the live database directory.
• Off-server transfer.
• Rotation or lifecycle rules.
• Logging for success and failure.
• Alerting when a backup is missing or too small.
• A scheduled restore test.

Do not automate a command you have not tested manually. Automation will faithfully repeat a bad path, missing credential, or broken restore process.

Credential safety

Avoid typing passwords directly into commands that will be saved in shell history. Prefer protected connection strings, environment handling, configuration files with tight permissions, or your existing secret-management workflow. If you must run an emergency command interactively, clean up history according to your company policy and rotate credentials if they may have been exposed.

Also restrict backup files. A database dump can contain customer data, API tokens, sessions, emails, billing records, or internal notes. Store it with the same care you apply to the live database.

Common MongoDB backup mistakes

Keeping only local backups

Local backups are convenient but fragile. Always move a copy away from the VPS.

Never testing restores

A restore test can uncover an unreadable archive, missing credentials, or an incompatible target version before an incident makes recovery urgent.

Backing up during risky maintenance without notes

If a backup happens immediately before a migration, schema change, or import, note that context. Recovery decisions depend on knowing what state the backup represents.

Treating mongodump as the only production strategy

MongoDB documents mongodump and mongorestore as useful tools, especially for small deployments, but larger production systems may require a more robust backup architecture. Match the method to the recovery requirement.

MongoDB backup checklist for VPS admins

Before you call the job complete, confirm:

1. The dump command completed successfully.
2. The archive file has the expected timestamp and a plausible size.
3. A checksum was created or another integrity check exists.
4. A copy was stored off-server.
5. A restore test ran in a safe target environment.
6. The restore result was documented.
7. Automation alerts when a backup fails or is missing.

FAQ

What command creates a MongoDB backup?

Use mongodump. For a single compressed archive, use mongodump --archive="file.archive.gz" --gzip with the correct connection details.

How do I restore a mongodump backup?

Use mongorestore with the archive and compression options that match the backup. Restore into a test database first when you are validating a backup.

Is a local VPS backup enough?

No. Keep an off-server copy. A local-only backup can be lost with the same disk, account, or server incident that damages the database.

Should I automate MongoDB backups immediately?

Automate after a manual backup and restore test works. Otherwise, automation may repeat an unproven or broken process.

Summary

Once a manual dump, off-server transfer, and restore test succeed, schedule the workflow and monitor its results. Repeat restore tests as the database, tools, and application change, and record how long recovery takes. Those results help you decide whether this approach still meets your recovery requirements.