Performance issues when restoring a site in SPO to an empty site

[geirvee]

This issues related to Case #05988232.

When backing up (and restoring?) SP Online, there is a recommendation to increase auxilliary backup applications to increase performance and stability for the backup.
I did this for my SPO site (consisting of 45 gbyte and 40000 objects) and it did indeed increase the speed and stability of the backup from more than 2 hours down to 31 minutes. However when running the restore operation, it seems like this will take maybe close to 10 hours(!) (running as I write this message). I found no similar configuration for restore as to what I had in backup, but maybe I did not spot something? When starting the restore, I was asked to create and confirm a restore application in M365 by Veeam. A restore speed of around 5 gbyte/hour means that I then cannot use Veeam for M365 as a tool for disaster recovery as it will take me 1000 hours to restore 5 tbyte.

Please advise.

[Mildur]

Hello Geir

Please note that additional backup applications should not be used without the guidance of the experts in our support team: https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=70

I suggest to let support analyzing the logs files. You may be affected by throttling (error 429) in Microsoft M365 environment..

To regain access to your files in a DR scenario, you can always restore important data to a local hard drive instead to SharePoint. We can only restore data back to SharePoint as fast as Microsoft endpoints will allow it.

Best,
Fabian

[geirvee]

Thx Fabian.

Let's hope that MS endpoints support higher restore speed than around 5 gbyte/hour. Yes, I suspected there may be some throttling to do also in restore as it for sure was in the backup. However I could not locate any information on how to configure more applications for restore.

Having to restore SPO data temporarily to a local hard drive because of performance does not seem like a good option. The thing is that if you run a backup on M365 data in case of a DR-scenario, then you need a certain performance to be in line with your SLA requirements. If these cannot be fulfilled, the point of running a backup of these data can be questioned if it is for DR purpose. This customer has almost 25 tbyte in a single site. If the restore speed is 5 gbyte/hour, a complete restore will take 5000 hours or a whopping 208 days. It may as you say be an MS problem, meaning all backup vendors will face the same issue. But then you should ask yourself: If the purpose of your backup is to cover a DR scenario, is a restore time of 208 days for 25 tbyte ok? If not, you need to find another solution/design to cover for a DR scenario. Or you have to assume that nothing bad will ever happen to your SPO site requiring a restore from a third part application.

[geirvee]

OK. So my restore of a complete 45 gbyte SPO site have now been running for 13 hours. Indications are currently that it will run for more than 20 hours .That gives an "amazing" restore speed of 0,6 mbyte/sec. Don't know if this is an MSFT issue, some non-optimal use of the APIs or simply me doing backup and restore the wrong way. If this is a generic issue, it makes you wonder if nobdy is testing restore performance of larger amounts of data when deploying a backup solution/design......? Currently this backup as it runs in my setup cannot be used as a DR backup, unless my SPO Site size is in the gbyte range and not in the tbyte range.

[Mildur]

Hi Geir

I understand that Restore is the most important task for a backup solution.
You create the backups to be able to restore in case something goes wrong.
We always try to optimize and enhance the restore speed with each version.
I'll share your feedback with my the team.

Let's see if using the recommended hardware requirements will allow you to have better restore speed in your POC.

Best,
Fabian