5
Hi,
We are currently migrating from an AX on-prem system to D365FO hosted by Microsoft.
We have regulatory requirements to save and archive data for at least one year.
From what I understand, Microsoft only saves backups from the production data 30 days.
What alternatives do we have to save data for longer periods of time?
Thanks for all inputs on this, can't find much information when searching.
Hi Oskar,
companies can choose to export the backups and store them in their own premises, as indicated earlier. Some companies do this, most likely some don't.
It's also good to look into Microsoft documentation that describes how they handle backups and disaster recovery. You can never be 100% sure - you just need to decide where's the good cost/reliability point for you. Microsoft's backups are safe even if an entire datacenter is hit by a meteorite, or a country disappears. But if the whole Europe would disappear, it might already mean loss of your European D365 data (I'm not sure if the data is stored across continents). How about your own backups?
But this doesn't have much to do with the 30 day retention period anymore. Even if the retention period was 1000 days, you would still need to store your own backups if you would not want to rely only on Microsoft. If you want to have more information about disaster recovery, I suggest to search for relevant documentation, and post a new question if you need help.
Thanks!
Hi André,
It would be interesting to know how other companies do and if t hey make their own backups or if they rely entirely on Microsofts backups?
I think and hope Microsoft does a good job of protecting their systems, but you can never be completely sure and for us this is the most important system and if it disappeared we would have to close down the company.
Hi Oskar,
Can you indicate if your question is now fully answered? Or do you need some more suggestions from the community?
Once you have exported prod database to sandbox, you can export the sandbox database as .bacpac file and store it wherever you want to. And if you want to look at it later, just deploy a new sandbox system, using the same D365 version that you had when the backup was taken, and restore the backup.
Hi,
I really agree that restoring the entire production environment from an old backup is not an option.
But I would like to have the opportunity to see afterwards how it has been and export data if needed.
There can always be “Known unknowns”
In our current on-prem setup we archive everything and save it for one year. If we need to see how something was 6 months ago, I export the virtual machines from backup and start it temporary and look or export what needed.
Will it be the same as copy the prod environment to a sandbox and keep the sandbox? Is it reasonable to have several sandboxes as “archives”? I understand that it will be a cost for this in our own azure tenant. Or should we as André wrote create additional backups from here, and what do you mean with that?
Export the data from Sandbox and keep the data in some archive blob storage for example?
My concern is that we are making a change and we do not discover the issue until after 30 days.
Thanks for sharing the concern. I think it's important to understand what kind of business requirements you're trying to solve by having these older backups available.
I would say that if you made a "bad" setup, and you end up having bad data, you usually recover by some other means than by restoring a database backup in prod system. Can you really imagine wanting to set your prod system database back more than 30 days, and re-entering ALL transactions from that entire time period? How likely it is that you would not introduce new data issues by doing this?
Usually you fix setup mistakes by posting some corrective transactions instead of wiping out all your data from the past 30+ days. And, as Andre pointed out, the primary strategy for dealing with such issues is to test your setup thoroughly so that you don't end up having bad data in the system.
Hi Oskar,
To prevent issues in the database, you need to carefully test the functionality, customizations and settings. Also the outcome should be validated. The validation part is skipped sometimes. E.g. After creating an invoice, it also needs to be verified if the generated ledger transactions are correct. Testing with one order and one line is not a test. You need multiple variations. This will of course not prevent all issues, but you should be able to get confident.
Suppose, you were on an on-premise environment, would you keep backups for more than 30 days?
It would be possible to get a copy of the production environment regularly in a sandbox. From there, you can create additional backups.
In the example you provided, it might be the case that there are indeed data model changes. Anyway, you would not want to go back 30 days in time when you only miss data from e.g. 1 table. Then you could format the data in e.g. an Excel file and import this. (there might be some complex topics to be fixed, though)
Hello Nikolaos and thank you for the response,
My concern is that we are making a change and we do not discover the issue until after 30 days.
I read another article about someone who had problem.
The post from Mark Schurmann “No. The backup and restore capabilities that D365 (Cloud) offer are not sufficient to protect you. We discovered this the hard way in the fall.”
Any thoughts on that?
What are other companies do? As Mark Schurmann write it may not be possible to restore even if you have a backup after some time if the versions of the database/instance changes.
Hi Oskar,
basically the data in the system is stored in the system itself as long as the system exists. So that's one place where you always have the correct data. Once the transactions are posted in D365, they can't be altered, so you have detailed record of what happened during the last year.
The database backup period of 30 days just means that you can't restore the system into older situation than 30 days ago. But in reality you would never want to restore your prod system 30 days in the past.
Anyway, if you need to archive some data outside Dynamics, you have many options such as:
- I assume you create detailed ledger reports as part of your normal bookkeeping process, and you retain them anyway. So your financial records are already archived. Correct?
- You can copy prod database to sandbox, and then export this sandbox database and store it as long as you want to.
- You can export specific data into external database via BYODB (Bring Your Own Database) or Azure Data Lake
- You can print reports of almost any data and store those reports
I think these should cover basically any archival and auditing requirements nicely.
Share
Report
All responses (
Answers (
