DOSSIER 04 • CLUSTER-CONSISTENT S3 PITR ARCHIVES

MongoShard Dossier: Percona Backup for MongoDB (PBM) to S3 with Point-in-Time Recovery

Dossier Code
PBM-PITR-BACKUP
WT Cache Metric
Secondary Offload
Eviction Target
10m PITR Oplog Slices
Storage & Compression
Zstd S3 Streaming • Physical WT Restore

In our MongoShard backup architecture guide, we detail why running cron mongodump against a Primary pollutes WiredTiger cache — and how pbm-agent streams consistent Point-in-Time Recovery slices from a Secondary node to S3.

MongoShard Cache Protection: Avoiding Primary Working-Set Eviction During Nightly Backups

Executing raw mongodump against an active Primary forces mongod to scan cold historical collections off disk, evicting hot BSON documents from memory and inflating read IOPS. By deploying Percona Backup for MongoDB (pbm-agent) across every Replica Set member, we allow the cluster to elect a healthy Secondary (or priority-0 hidden node) to compress snapshots with Zstd and upload continuous 10-minute Oplog chunks directly to S3-compatible object storage.

MongoShard rolling local.oplog.rs NVMe retention window and Percona Backup for MongoDB 10-minute S3 PITR slicing diagram (percona-backup-mongodb-s3)
Figure 3 — MongoShard Oplog retention equation: sizing local.oplog.rs for 48–72 hours prevents initial-sync falloff and feeds Percona pbm-agent 10-minute S3 PITR chunks.

MongoShard Production /etc/pbm_config.yaml for S3 & Continuous PITR

MongoShard reference snippet (percona-backup-mongodb-s3) — verify host RAM and XFS mount before restarting mongod.

# /etc/pbm_config.yaml — Apply via: pbm config --file /etc/pbm_config.yaml
pitr:
  enabled: true
  oplogSpanMin: 10
  compression: zstd
storage:
  type: s3
  s3:
    region: sg-sin-1
    endpointUrl: https://sgp1.vultrobjects.com
    bucket: mongoshard-prod-pbm
    prefix: rs0-prod
    credentials:
      access-key-id: "REPLACE_WITH_S3_KEY"
      secret-access-key: "REPLACE_WITH_S3_SECRET"
backup:
  compression: zstd
  compressionLevel: 6

MongoShard Capacity Matrix for DOSSIER 04 • CLUSTER-CONSISTENT S3 PITR ARCHIVES (2026-11-12 Public Rates)

Each hardware tier below follows our MongoShard (RAM − 1 GB) × 0.50 calculation and cites public vendor pricing retrieved on 2026-11-12 from Vultr (https://www.vultr.com/pricing/) and InterServer (https://www.interserver.net/vps/).

Workload Scale / Node Class WiredTiger Cache Active Working Set Fit Reference Host Tier (2026-11-12)
25 GB Dataset (Logical + PITR) ~9 GB Zstd S3 Footprint 1-Node rs0 or 3-Node KVM Hostinger KVM + S3 Bucket
150 GB Dataset (Physical PBM) ~55 GB Zstd S3 Footprint Raw WiredTiger File Copy Vultr VPC + Co-Located Vultr Objects
500 GB+ Dataset (Hidden Backup Node) ~185 GB Zstd S3 Footprint Zero Primary Read Contention UltaHost VDS + InterServer Storage

MongoShard Production Deployment Checklist (PBM-PITR-BACKUP)

  1. Run identical pbm-agent versions as systemd services on every Replica Set node (including Arbiters if used).
  2. Prefer Physical Backups (--type=physical) on Percona Server for MongoDB above 100 GB datasets to avoid slow BSON index rebuilds during restore.
  3. Automate weekly pbm cleanup --older-than=14d -y timers so expired S3 Oplog slices do not accumulate unbounded storage fees.
  4. Execute monthly restore drills into an isolated disposable KVM instance to verify archive integrity and RPO.

Inspect Vultr Specs for MongoShard PBM-PITR-BACKUP ↗ Compare InterServer Rates for MongoShard PBM-PITR-BACKUP ↗ Load Preset in MongoShard Calculator →

MongoShard Technical FAQ: DOSSIER 04 • CLUSTER-CONSISTENT S3 PITR ARCHIVES

Why does MongoShard pair Oplog retention hours directly with PBM PITR configuration?

Continuous Point-in-Time Recovery slices local.oplog.rs every 10 minutes. If a temporary S3 network outage delays uploads during a write burst, a generous 48h–72h local NVMe Oplog ring prevents gap errors before pbm-agent catches up.

Does MongoShard recommend logical or physical PBM backups for 200 GB WiredTiger clusters?

Above 100–150 GB, we recommend physical backups on Percona Server for MongoDB because restoring raw WiredTiger .wt files bypasses single-document BSON insertion and B-Tree index reconstruction.