Views:

Applies to Product - Dynamics 365 Lifecycle Services


What’s happening?
Customers are requesting information on how to access a recent backup of their database and a step-by-step guide for deactivating their environment.


Reason:
The underlying cause for the requests is the need to manage database capacity and prepare for the deactivation of production environments.


Resolution:
Step 1: Accessing a Recent Database Backup

  1. Log in to Lifecycle Services (LCS): The customer must log in to Lifecycle Services (LCS) with appropriate permissions.
  2. Locate the Project: Navigate to the project associated with the environment they want to back up.
  3. Access Environment Details: In the project, select the specific environment (e.g., Sandbox or Production).
  4. Backup Options: Under the environment details, they should see options for creating, viewing, or downloading backups if their environment permits it. Note that only specific environments (typically Sandbox and Production) offer database backup capabilities.
  5. Download Backup: If available, download the most recent backup or create a new backup if needed.
Step 2: Deactivating the Environment
  1. Inform Key Stakeholders: Before proceeding, ensure all relevant teams are notified of the deactivation plan to avoid unintended service disruptions.
  2. Plan for Data Retention: Confirm whether data needs to be retained or archived before deactivation.
  3. Deactivation Process in LCS:
  4. Go to the Environment section in LCS.
  5. Select the environment intended for deactivation.
  6. Look for an option to "Stop" or "Delete" the environment.
  7. Follow the prompts to confirm deactivation. Note that deletion may be irreversible, so proceed with caution.
  8. Verify Deactivation: After deactivation, verify that no resources are consuming licenses or incurring costs.
Additional Information:
  • The database status as of the last check indicated a used space of 98.86 GB with an allocated space of 112.96 GB, and a maximum storage size of 4 TB.
  • It is recommended to schedule database movement operations during off-hours, as these operations can take a significant amount of time and may cause the environment to go offline without warning.