Our #1 SaaS Data Protection is now available for ServiceNow! Learn more.
When it comes to the data you store in the cloud, accidental loss and corruption can occur in a variety of ways. While Microsoft does offer a native backup and restore capability for Dynamics 365 and Power Platform users, depending on your organization, industry regulations may require the need for a more comprehensive solution in order to be able to meet governance and compliance requirements. A more holistic tool can also help you to free up employee bandwidth by preventing the rework commonly associated with manual data recovery efforts.
Let’s look at some more reasons why you may need a more comprehensive backup solution than Microsoft provides.
When selecting ‘Backups’ in your Microsoft Power Platform Admin Center (PPAC) environment, you can view both manual and system backups. In both cases however, you cannot see all of the necessary details about your data.
With manual backups, you can only see the name of the backup, the date and time it was issued, who created the backup, and when it expires. When a user selects a specific backup, their only option is to either restore or delete it–there is no way to see the contents of the backup without first issuing a restore job.
This is problematic because there’s no way for users to know if they have selected the right backup containing the data needed for restoration. Instead, admins have to first issue a restore job and then spend time digging through the data to confirm if they have the right backup.
With a system backup, you get even less information–only the time and date the backup was issued. You’ll also see that the dates are grayed out if the data loss or corruption has occurred outside of the retention period. If this occurs in a sandbox environment, the retention period is only seven days, versus 28 days for production environments. Users can then choose a point in time recovery, which is based on the transaction logs of the Azure SQL Database that is supporting this Dataverse environment.
When a data loss inevitably occurs, there are two fundamental metrics that organizations must be able to assess: Recovery Point Objective and Recovery Time Objective.
Your RPO determines how far back in time you must be able to reach in order to recover critical data. Microsoft’s native solution indicates an ability to retain backup data up to 28 days for production, and seven days for sandboxes. When restoring a backup to an environment in the PPAC, users can only issue a full database restore into a sandbox, not into a production environment.
This means your applications will not be working while you work to recover the right data. In disaster scenarios, IT professionals will work around the clock to ensure data that has been lost or corrupted is restored in a timely manner to minimize the cost burden of your business apps being down.
Configurable backups, often scheduled before new feature releases like the April 1st Release Wave, are a best practice for preventing data loss and corruption. Automated backup schedules are especially handy during migrations and implementations. For regulated industries like financial services and healthcare, automated backup schedules allow you to not only meet compliance requirements and avoid hefty fines, but also prevent any negative PR that might accompany a data loss scenario.
Your RTO refers to the time margin for how quickly an organization can recover their mission critical data in the event of a data loss or corruption scenario. RTO is often the biggest indicator of any financial impacts on your organization’s bottom line. The longer your Business Apps are down, the greater the cost burden. When it comes to low code/no code apps like power apps, staying up and running is key. Which isn’t possible if you have to bring production down.
One way to improve your RTO is by having a backup tool that can proactively alert you of a data anomaly, a capability that Microsoft’s native backup tools do not currently provide. Being able to quickly identify when a data loss or corruption has occurred will increase your organization's time to action and ultimately allow you to minimize the absorbed cost burden. After all, how can you respond in a timely fashion if you don’t even know that a data loss has even occurred in the first place?
At OwnBackup, we help you keep your data safe and uphold your part of the shared responsibility model. Our market-leading backup and recovery solution, OwnBackup Recover, has built-in anomaly alerting and proactively monitors your data through the use of Smart Alerts. Once the Smart Alerts have identified changes to your data, you can easily use our search, analyze and visual compare feature to see only the data that was changed or deleted.
Then, once the changed data has been identified, you can leverage OwnBackup’s Precision Repair capability which allows you to restore on a data set, row or a field level. With a single click, you can restore just the data that’s missing and avoid having to invoke the painstakingly long, full restore job.