Point-in-Time Database Restoration in Microsoft Dynamics 365 Business Central Online

Microsoft Dynamics 365 Business Central Online offers a robust point-in-time restoration feature, allowing administrators to revert a database to a specific point in time within the past 28 days. This capability supports recovery from data errors, testing in isolated environments, and operational continuity. This post outlines the technical process, considerations, and limitations of restoring environments in Business Central Online.

Restoration Process

To initiate a point-in-time restoration, administrators must access the Dynamics 365 Business Central Admin Center and follow these steps:

• Navigate to the Admin Center: Log in to the Dynamics 365 Business Central Admin Center.
  

  

• Initiate Restore: Select the “Restore” option.

  

• Configure Restore Parameters:
  1. Date and Time: Specify the exact date and time for restoration, down to the minute, within the 28-day retention period. The displayed time aligns with the user’s local time zone, as indicated in the interface.
  2. Environment Type: Choose the target environment type (Production or Sandbox).

• Environment Name: Assign a unique name to the restored environment.
• Advanced Options: Select additional settings, such as bypassing the cleanup of integration data (discussed below).
• Execute Restore: Confirm selections and click the “Restore” button to create the new environment.

Use Cases

Point-in-time restoration serves multiple purposes, including:

1. Data Recovery: Revert accidental postings, deletions, or corrupted data caused by faulty extensions.
2. Testing: Create a Sandbox environment to simulate scenarios without affecting production data.
3. Operational Continuity: Restore a Production environment to minimize downtime after critical errors.

Technical Considerations and Limitations

The restoration process is subject to specific constraints and operational requirements:

Subscription and Quota

1. A paid Business Central subscription is required to perform restorations.
2. Each environment is limited to 10 restorations per calendar month.
3. Restored environments contribute to the subscription’s capacity calculation. Exceeding the production environment quota may require deleting unnecessary environments post-restoration.

Environment Type Restrictions

1. Production environments can be restored to either Production or Sandbox environments.
2. Sandbox environments can only be restored to another Sandbox environment.
3. Restorations must occur within the same Azure region and country as the original environment.

Data and Extension Handling

1. Integration Data Cleanup: By default, setups and integration data (e.g., external service connections) are cleared during restoration to prevent unintended interactions. Administrators can bypass this cleanup via the Advanced Options in the Admin Center.

2. Extension Behavior:

• Development extensions published directly from Visual Studio Code are not included in restored environments, even if they existed at the selected restore point.
• Per-tenant extensions dependent on these development extensions are also excluded.
• All AppSource and Business Central apps in the restored environment are automatically updated to the latest available hotfix version.

Environment Naming

Restored environments require unique names. To reuse the original environment’s name, rename the source environment before restoration or adjust names post-restoration for review purposes.

Operational Precautions

For Production restorations, consider pausing external integrations, job queues, or user access during the process to avoid conflicts.

Restored environments are treated as new instances, requiring validation before resuming operations.

Additional Considerations

1. Pre-Restoration Planning:
   • Verify the target restore point (date and time) to ensure it aligns with the desired state.
   • Assess whether integration data cleanup should be bypassed based on the use case.
   • Confirm available capacity to avoid exceeding environment quotas.
2. Post-Restoration Validation:
   • For Production restores, validate data integrity and reconfigure integrations as needed.
   • For Sandbox restores, test extensions and configurations before deployment.
3. Quota Management:
   • Monitor restoration frequency to stay within the 10-restore monthly limit.
   • Delete temporary environments promptly to optimize capacity.

Conclusion

The point-in-time restoration feature in Microsoft Dynamics 365 Business Central Online provides a powerful mechanism for data recovery and testing. By understanding the process, and limitations administrators can leverage this capability to minimize downtime, recover from errors, and maintain operational stability.

Note: This post assumes familiarity with the Dynamics 365 Business Central Admin Center.

---