Restoring to new server

MongoDB Percona Backup for MongoDB
1

Every 6 months, I restore a PBM backup to verify that it’s “restorable”. I do this by creating a new VM and installing MongoDB and PBM. I use the same pbm-config.yaml file that I used to configure the production nodes. It’s a system that’s worked well in the past, but now it’s not. The agent does not seem to be reading the remote storage (and the replica set names are identical). In fact, the agent doesn’t seem to be doing anything (this is what I’m seeing in the agent log):
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: 2021-12-28T00:20:19.000+0000 I pbm-agent:
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: Version: 1.6.1
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: Platform: linux/amd64
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: GitCommit: aebbc24a03f21f9ddee6ebb72f510ff1d1c58fdc
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: GitBranch: release-1.6.1
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: BuildTime: 2021-11-03_12:09_UTC
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: GoVersion: go1.16.9
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: 2021-12-28T00:20:19.000+0000 I node: mongo-prod-set/127.0.0.1:27017
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: 2021-12-28T00:20:19.000+0000 I listening for the commands
Dec 28 00:20:19 ip-172-31-59-0.us-west-2.compute.internal pbm-agent[2122]: 2021-12-28T00:20:19.000+0000 I starting PITR routine

pbm status yields (I’ve redacted the S3 bucket name):
Cluster:

mongo-prod-set:

  • mongo-prod-set/127.0.0.1:27017: pbm-agent v1.6.1 OK

PITR incremental backup:

Status [OFF]

Currently running:

(none)

Backups:

S3 us-west-2 s3://XX-XXXX-XXX/pbm-backup
(none)

Any insights? Thanks

2

I’ve figured out the issue. The older json files had been placed into S3 Deep Archive, and therefore were unreadable by PBM, so it was erroring out.

As a feature request, I would suggest that when PBM encounters a 403 error when retrieving from S3 that it skips the file and moves on to the next, rather than erroring out and stopping.

1 Like