Duplicate Key when restoring from manual Backup and How-To Restore from PITR

When restoring from a manual Backup following the tutorial I am getting:

Status:
  Error:  set resync backup list from the store: copy current backups meta from pbmBackups to pbmBackups.old: insert: write exception: write errors: [E11000 duplicate key error collection: admin.pbmBackups.old index: _id_ dup key: { _id: ObjectId('xyz') }]

Restore seems to have worked fine. I tested it redundantly and found now problems. I could’t find that key without more extensive troubleshooting.

I have a few questions:

1.) What could be the root cause of the the Dup Key issue? Does one have to delete the old databases before doing the restore? The article does not mention such, if so.

2.) Do by default all databases running on that psmdb-db get backuped?

3.) In my backup bucket I see the PITR also being created. How to test restore from a PITR backup? The article does not provide information on this.

Appreciate any insight on some of these questions.

1 Like

Hello, Which version of percona backup are you using?

  1. When doing a restore, the tool will append data into the collections, so if you already have data you might hit duplicate key errors. I am not sure about your issue since it is in one of the pbm internal collections it might be a bug.
  2. The tool will backup all collections
  3. to test point in time restore simply specify a time as follows (you need to disable pitr before restore):
pbm config --set pitr.enabled=false
pbm restore --time="2022-01-23T15:05:48"```
1 Like

Percona Version is 1.10.1

  1. I understand. So one should ideally drain the DB completely before restoring?
  2. You mean databases not collections I presume? We have multiple DB in one perocona instance
  3. I want to try that, but how to achieve within a Kubernetes environment (using official helm charts)
1 Like

Hello, for 1) it depends on what you want. If the goal is to discard all existing data and go back to the snapshot then yes.
2) yes I mean all db and all collections within them
3) sorry I missed you were running in K8s. Please check this page Providing Backups for instructions

2 Likes

Thanks for your reply! Regarding 1: How are colllections inserted back when restoring? Delete existing keys? Are there any downsides if not deleting the db before restoring? What specifically needs to be deleted if we want a clean restoration? I noticed that new keys which got inserted after backup taking were gone after restoration of backup.

1 Like

Basically collections that are part of the backup will be dropped as part of a restore. There are no downsides if you don’t delete them as the process will do it for you. If you want a clean restoration you can delete all user collections and databases before doing the restore, or simply restore to a different mongodb instance. You can check this page for a bit more info on these topics.

2 Likes