[DOCS-9169] Ops Manager documentation for restoring a backup manually is problematic for processes managed by automation Created: 18/Oct/16  Updated: 06/Mar/17  Resolved: 01/Mar/17

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Timothy Olsen (Inactive) Assignee: Anthony Sansone (Inactive)
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents DOCS-8154 Stop all Automation Agents when resto... Closed
documents DOCS-8155 Start Automation Agent manually Closed
Duplicate
is duplicated by DOCS-9745 Reconcile Ops Manager Restore Sharded... Closed
Related
related to DOCS-9262 Ensuring Replica Set Settings from Ol... Closed
Participants:
Days since reply: 6 years, 49 weeks, 2 days ago
Epic Link: C/OM Backup

 Description   

The documentation for manually restoring from an Ops Manager backup does not fully take into account what will happen if the user attempts to manually restore a backup into a replica set managed by automation.

The documentation tells the user to use automation to shut down processes when it is time to do so but the documentation then proceeds to tell the user to start up the primary and/or secondary manually. This will result in automation shutting down the process that the user has started manually.

My opinion is that the best way to manually restore into a replica set that is managed by automation is to:

  1. unmanage the replica set
  2. follow the steps for manually restoring an unmanaged replica set
  3. reimport the replica set into automation

cailin.nelson Thoughts?



 Comments   
Comment by Githook User [ 06/Mar/17 ]

Author:

{u'username': u'atsansone', u'name': u'Tony Sansone', u'email': u'tony.sansone@mongodb.com'}

Message: (DOCS-9169,9700): Update manual sharded cluster restore.
Branch: master
https://github.com/10gen/mms-docs/commit/92b2c873e5aff4c98daaebce586a517b751a110f

Comment by Githook User [ 06/Mar/17 ]

Author:

{u'username': u'atsansone', u'name': u'Tony Sansone', u'email': u'tony.sansone@mongodb.com'}

Message: (DOCS-9169,9700): Update manual sharded cluster restore.
Branch: v3.4
https://github.com/10gen/mms-docs/commit/55e31936c6c6f24a757f1df65a7b00864f7fa0b4

Comment by Timothy Olsen (Inactive) [ 28/Feb/17 ]

Yes, the same thing applies to DOCS-9700.

Comment by Emilio Scalise [ 26/Jan/17 ]

Hi All,

I would like to add some considerations to this.

If authentication is involved and the customer is going to restore a backup of a snapshot taken from a cluster/replica set managed in a different group, he needs to address manually a number of issues with mms-* users and passwords. This is discussed in PRODUCT-288.

Automated restores across different users are not possible yet (see MMS-1904).

In our docs we are not dealing at all with these authentication aspects. It looks like many big customers wants to be able to restore production snapshots to QA/testing environments, and often (as we suggest) production and QA/testing are registered on different Ops Manager groups.

I am working on writing down and testing such procedure, and I'm going to raise soon a help ticket to validate it. This could be an input for a more comprehensive docs page.

Kind regards,
Emilio

Comment by Cailin Nelson [ 18/Oct/16 ]

I agree. Now that we have automated restores, this should be the preferred method for restoring to a managed replica set.

For the remaining edge-case of "manual restore to an automated replica set" Tim's suggestion is much more straightforward.

Generated at Thu Feb 08 07:57:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.