Details
-
Improvement
-
Resolution: Done
-
Major
-
7.1.0
Description
At the moment, cbbackupmgr doesn't support resuming restores; if a restore fails midway through, you must start from the beginning and rely on conflict resolution.
For large restores it makes sense to be able to resume restoring similar to how we support resuming backups.
This will be an important addition for cloud restore because a restore could fail for a multitude of different environmental reasons and we know that pulling data from S3 is far more expensive than uploading.
This may become quite important for collection aware restores now that cbbackupmgr auto-remaps scopes/collections it creates. Lets imagine this case (which can currently happen):
1) User backs up a collection aware cluster (that has a decent amount of collections).
2) User deletes/flushes target bucket
3) User then restores to the target bucket (cbbackupmgr creates all the scopes/collections)
4) cbbackupmgr crashes/errors out for some reason
5) User attempts to continue the restore
6) cbbackupmgr will complain/error out stating that scopes/collections exist on the target cluster with a different id than in the backup.
This is extremely inconsistent and likely would be confusing to users e.g. why would it moan this time, and not when they first started the restore. Obviously, that's logical to cbbackupmgr since the plan is not persisted on a restore (meaning, the second time they try the restore, we have no way of knowing that we created those collections).
Attachments
Issue Links
- blocks
-
MB-48338 [CBM] Correctly handle the creation of the '.restore' directory in existing archives
- Closed
-
MB-47915 [CBBS] Use the '--purge' flag when running restores
- Closed
- depends on
-
MB-37023 [CBM] Tidy up/fix the data range logic
- Closed
-
MB-47643 [CBM] The restore worker pool/operations should have access to vbID/document
- Closed
- relates to
-
MB-43247 cbbackupmgr TEMP_OOM failures should be accounted for in retries
- Closed
-
MB-45879 Restore worker pool has slightly different behavior regarding temprorary failures
- Closed
-
MB-42946 cbbackupmgr should handle user data in the plan/or not collect it when collecting logs
- Resolved