What I Needed to Solve
I had two on-prem servers with MongoDB installed, but they were not part of a cluster or replica set. The business only updated the source database during the morning and evening windows, so a twice-daily refresh was enough.
- We could not use MongoSyc / native sync to keep the servers continuously aligned.
- The second server still needed a refreshed copy after each update window.
- The right answer was a scheduled refresh, not a real-time replication model.
Why the Schedule Worked
The data only changed during morning and evening update windows, so I did not need always-on replication. I built a PowerShell-driven backup and restore routine that ran twice every day, after the updates had been applied.
| Question | Answer | Why It Mattered |
|---|---|---|
| Do we need real-time sync? | No | Updates only happened in scheduled windows. |
| How often should the copy refresh? | Twice daily | Morning and evening after updates. |
| Should we cluster the servers? | No | The servers were standalone and the requirement was operational refresh. |
| Should MongoTools be used? | Yes | Keep the process internal and supportable. |
How I Built It
The refresh path is simple: the source server produces the backup, the shared path carries the file, and the target server gets restored after each update window.
How I Automated It
I used PowerShell to orchestrate the backup on the first server, copy it to a shared path, and restore it on the second server. The goal was consistency and repeatability, not manual file movement.
$source = "SERVER1"
$target = "SERVER2"
$backupRoot = "\\fileserver\mongo-refresh"
$stamp = Get-Date -Format "yyyyMMdd_HHmm"
$dumpFolder = Join-Path $backupRoot "dump_$stamp"
$archive = Join-Path $backupRoot "mongo_$stamp.zip"
# 1) Backup from the source server
mongodump --host $source --db MyAppDb --out $dumpFolder
# 2) Package the dump for transfer
Compress-Archive -Path $dumpFolder -DestinationPath $archive -Force
# 3) Restore on the second server
Expand-Archive -Path $archive -DestinationPath $dumpFolder -Force
mongorestore --host $target --drop (Join-Path $dumpFolder "MyAppDb")MongoTools Commands
Backup
mongodump --host SERVER1 --port 27017 --db MyAppDb --out \\fileserver\mongo-refresh\dump_20260604_0800Restore
mongorestore --host SERVER2 --port 27017 --drop \\fileserver\mongo-refresh\dump_20260604_0800\MyAppDbRefresh Schedule
The job was scheduled twice every day, after the source database had already received the morning and evening updates. That timing avoided copying half-finished data and reduced unnecessary restore churn.
- Morning job: run after the first update window closed.
- Evening job: run after the second update window closed.
- Both jobs used the same PowerShell flow so behavior stayed predictable.
- The schedule was intentionally simple because the data only changed twice daily.
Validation I Added
| Check | Purpose |
|---|---|
| Backup file exists | Proves the source server dump completed. |
| Restore log has no errors | Proves the second server received the refresh. |
| Record counts match | Confirms the copy is complete enough for the use case. |
| Timestamp matches the update window | Shows the refresh happened after the morning or evening update. |
Real Scenario: Freshness Window Matters
At one point, the second server had to be used right after the morning update. The refresh had not yet run, so the team would have seen stale data if the schedule had not been set correctly. That is why the refresh had to happen twice a day, after the source updates were finished.
- If the restore is too early, you copy incomplete or stale data.
- If the restore is too late, the second server falls behind the intended window.
- The schedule kept the second server aligned with the operational rhythm of the source system.
Delivery Lessons
- When the data changes in fixed windows, scheduled refresh is often simpler than continuous sync.
- PowerShell is enough when the environment is constrained and the workflow is repeatable.
- Internal MongoDB tools keep the process supportable and familiar to administrators.
- The schedule should match the business update pattern, not the other way around.