TL;DR
Microsoft keeps backups 28 days for production, seven for sandboxes. What a point-in-time restore does, its downtime, and what it never brings back.
People search for a "Dynamics 365 Finance and Operations backup policy" and land on pages about environment tiers, because there is no page called that. The policy exists. It is spread across three Microsoft Learn articles about database movement, and the number most people want is in the first sentence of each: 28 days for production, seven for sandboxes. Everything after that number is the part that decides whether a restore saves your month or costs you a weekend.
For the person who owns the F&O environment and will be asked "can we go back to Tuesday?" 7 minute read.
What Microsoft keeps, and for how long
The retention rule is one sentence, repeated word for word on the point-in-time restore page and the production-to-sandbox restore page (both ms.date 3 April 2026, updated 1 September 2026): "Microsoft maintains automated backups of the business and financial reporting databases for 28 days for production environments and seven days for sandbox environments."
Three things in that sentence matter more than the numbers.
- "Business and financial reporting databases." The backup covers the application database and the Financial Reporting database. It does not cover files in Azure blob storage. Document attachments, custom Office templates and anything else stored as a file live outside the backup window.
- "Automated" is Microsoft's word. You do not schedule these, you cannot extend them, and you cannot download them. The 28 days is the whole window.
- "Sandbox: seven days." A UAT environment that was refreshed last Monday has one week of restore points, not four.
Point-in-time restore: the two directions
Microsoft documents two restores, and they are not the same operation.
| Direction | Where it runs | Who starts it | Downtime |
|---|---|---|---|
| Production to the same production | Lifecycle Services, Environment Details, Maintain, Move database | The environment owner, self-service | "Large downtime for the production environment. Point-in-time restore (PITR) may take multiple hours." |
| Production to a sandbox | Same menu, "Point-in-time restore Prod to Sandbox" | Self-service, "begins immediately" | The target sandbox goes offline the moment it starts and stays offline until it finishes |
The production-to-production restore is described by Microsoft as "not a common lifecycle operation", and the page names the one scenario it is for: recovering from "significant data corruption." It is not a way to undo a bad posting run. Every transaction after the restore point is gone, the restore-point chain is broken, and the page warns about SQL data loss in plain words.
The production-to-sandbox restore is the one you will actually use. It answers "what did the data look like at 14:05 on Tuesday" without touching production.
What a restore does not bring back
This is the list people discover after the fact. Microsoft publishes it on the production-to-sandbox restore page as "data elements that are not copied", and it applies to the sandbox direction in full. Among them:
- All users except the admin are set to Disabled. Nobody can log in to the restored sandbox until someone re-enables them.
- All batch jobs are set to Withhold. Nothing scheduled runs until someone releases it.
- Every Microsoft-encrypted field is cleared, because it cannot be decrypted on a different database server. The page's example is the SMTP password. Any stored credential an integration depended on is gone.
- Files in Azure blob storage are not copied. Attachments, the DocuValue and DocuDeletedValue records that point at them, and document templates.
- Email addresses in LogisticsElectronicAddress and the SMTP relay in SysEmailParameters are removed, so the restored environment cannot accidentally mail a real customer.
- Dual-write configuration is removed and must be re-linked through "Enable Power Platform Integration."
- Business events endpoints must be deleted and reconfigured, and recurring data management import and export jobs must be stopped before the restore starts.
For the production-to-production direction the page is shorter but harder: batch jobs and in-progress data are restored "as is" and need manual review, and files added to blob storage after the restore point still exist in storage but are no longer referenced by the database.
The conditions that stop a restore before it starts
- The restore is refused on Platform update 20 or earlier.
- Source and target must be on the same application release, and Financial Reporting in the target must be the same version or later.
- Source and target must sit in the same Azure geographic region unless Microsoft manages both.
- The source environment's allocated capacity must be below the target's maximum.
- Self-service restore is not supported across regions, nor between Microsoft-managed and self-service environments.
- A restore deletes the original target database. There is no "keep a copy" option.
And one line from the database movement overview page that belongs in every runbook: "these operations can take up to 24 hours to complete, and during the operation there's no way to cancel." The sandbox "goes offline at an undetermined time ... with no warning to end users." Microsoft's advice is to schedule during non-business hours.
Is this moving to the Power Platform admin center?
Not yet, for these two operations. The database movement overview (ms.date 3 April 2026) lists production point-in-time restore to sandbox and to production under Lifecycle Services, with API support marked "Not supported." The only operation on that page marked "Supported in Power Platform admin center" is the production-to-DevTest copy. The unified admin experience overview (ms.date 10 September 2026) maps "Point-in-time restore" to "Restore" in the admin center as the destination, and the environment migration preview published 22 September 2026 says that after migration "copy, backup, restore, servicing, updates, and monitoring" run in the admin center. So the direction is set; for an environment still managed in LCS today, the restore still runs in LCS.
Where we would draw the line
Treat the 28 days as a recovery window for corruption, not as a retention policy. If finance or audit needs a point-in-time copy of production that outlives 28 days, that is a database export or a reporting copy you keep yourself, and Microsoft says in the same breath that "copying production data to a sandbox environment for the purpose of production reporting" is not supported.
If an AI agent is going to run against this environment, this page is also its operating constraint. An agent reads F&O under a user role and often through a stored credential or an endpoint. After any restore to a sandbox, the user is disabled, the encrypted field is empty and the business event endpoint is gone. That is correct behaviour, and it means the agent's sandbox setup has to be re-run after every refresh or restore, which is a step most teams forget the first time.
What to do this week
- Write down the restore window per environment: 28 for production, seven for each sandbox, and the date of each sandbox's last refresh.
- Put the "not copied" list above into the sandbox refresh runbook as a checklist, with the owner of each re-enable step.
- Decide who is allowed to start a production point-in-time restore, and write that it is a multi-hour outage with no cancel.
- Stop recurring data management jobs before any restore, and schedule restores outside business hours.
Sources
- Microsoft Learn, "Database point-in-time restore (PITR)", ms.date 2026-04-03, updated 2026-09-01: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/database/database-point-in-time-restore
- Microsoft Learn, "Point-in-time restore of the production database to a sandbox environment", ms.date 2026-04-03, updated 2026-09-01: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/database/database-pitr-prod-sandbox
- Microsoft Learn, "Database movement operations home page", ms.date 2026-04-03, updated 2026-09-01: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/database/dbmovement-operations
- Microsoft Learn, "Unified admin experience for finance and operations apps", ms.date 2026-09-10: https://learn.microsoft.com/en-us/power-platform/admin/unified-experience/finance-operations-apps-overview
- Microsoft Learn, "Migrate finance and operations environments from Lifecycle Services to Power Platform admin center (preview)", ms.date 2026-09-22: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/lifecycle-services/migrate-lifecycle-services-environments-power-platform-admin-center
All read 22 October 2026.
Share this article
D365 Platform Decisions
Topic Cluster
Which platform carries which capability, what the licence actually covers, and what each release wave changes.
Mudassir Marwat
Founder & CEO, Cognilium AI
Mudassir Marwat
Founder & CEO, Cognilium AI
Mudassir Marwat's argument is that ERP systems record decisions they never optimise.
