Problem with restore with --replset-remapping

Hl, I’m testing new PBM version (2.0.2) to prepare upgrade from 1.8.1 and I have problem with restoring to new cluster. My procedure:

  1. Prepare new cluster
  2. Change prefix for s3 (minio) pointing to current cluster from which we want to restore (with force reconfig)
  3. Call pbm restore with --replset-remapping

Restore starts but finishes with error:

mongorestore: restore mongo dump (successes: 0 / fails: 0): I/O failure reading beginning of archive: compose: metadata: read: download 'my-bucket/2022-11-15T23:13:25Z/my-target-cluster/metadata.json': NoSuchKey: The specified key does not exist.
	status code: 404
  • pbm list and status with --replset-remapping work as expected
  • source backup exists in S3: my-bucket/my-source-cluster/2022-11-15T23:13:25Z/my-source-cluster-rs0/
  • restore in place works as expected
  • above procedure works with pbm 1.8.1
  • restoring backup made with pbm 1.8.1 also worked for 2.0.2

Do you have some idea how to solve this problem?

1 Like

Hi!
I have the same problem.
I have

  • sharded cluster cluster_1 as source.
  • sharded cluster_2 as dest cluster.
  • configured PBM on dest cluster for restore.
    pbm list, status - ok.
  1. Call pbm restore with --replset-remapping return error:
2022-12-14T19:03:24Z E [replicaset_name/mdb-name.domain:27017] [restore/2022-12-14T19:02:24.375285868Z] mongorestore: restore mongo dump (successes: 0 / fails: 0): I/O failure reading beginning of archive: compose: metadata: read: download 'bucket_name/2022-12-14T00:00:20Z/replicaset_name/metadata.json': NoSuchKey: The specified key does not exist.
	status code: 404, request id: 4H8<------>G7, host id: Rz6<-------->sreA98=

Source bucket, and path - exist.
Piotr_Krogulec Did you solve the problem?

1 Like

Hi, there is a PR PBM-1003 Fix ability to restore with remapping replicaset names by ziollek · Pull Request #751 · percona/percona-backup-mongodb · GitHub made by my colleague from team and it’s accepted. Only question is, when it will be released.

2 Likes

Unfortunately, I did not see a specific problem. But suddenly it will be useful.

Looked for the problem on my end.

If I do remapping and backups are stored in S3, then the pbm agent tries to download a non-existent backup.

For example:

Source Cluster:

cluster_1

/shard_sorce_1

/shard_sorce_2

dest cluster

cluster_2

/shard_dest_1

/shard_dest_2

On s3 backup

2022-12-17TIME

/shard_sorce_1

/shard_sorce_2

I’am try run


pbm restore 2022-12-17TIME --replset-remapping="shard_dest_1=shard_sorce_1,shard_dest_2=shard_sorce_2"

Agent is trying to download 2022-12-17TIME/shard_dest_1 and 2022-12-17TIME/shard_dest_2. But there is no such path. so we get 404.

as a check, created copies of backups of replicas

2022-12-17TIM:

/shard_sorce_1

/shard_dest_1 (copy from shard_sorce_1)

/shard_sorce_2

/shard_dest_2 (copy from shard_sorce_2)

In this configuration, the restore is works.
sorry for my english :slight_smile:

1 Like