-
- Service Provider
- Posts: 283
- Liked: 64 times
- Joined: Nov 17, 2014 1:48 pm
- Full Name: Florin
- Location: Switzerland
- Contact:
Restore Portal - Loading data very slowly
We've installed the Restore Portal for M365 recently and it's working fine. But...
Logging in to the portal works flawless, but loading the "Scope" list takes like 10min. Also loading the restore points takes quite some time as well as listing the data afterwards.
Using the normal explorers on the same data is quite fast, even from remote through cloudconnect.
We've installed the Restore Portal (API) on a separate server in a frontend zone. Firewall to the VB365 server (Port 9194) is open.
We have like 40 Organizations in our VB365. However, the account i used for testing is only allowed to access one of them.
Does everyone else encounter such slow performance using the restore portal, or is this an unexpected behavior? Will open a support case if this is abnormal.
Logging in to the portal works flawless, but loading the "Scope" list takes like 10min. Also loading the restore points takes quite some time as well as listing the data afterwards.
Using the normal explorers on the same data is quite fast, even from remote through cloudconnect.
We've installed the Restore Portal (API) on a separate server in a frontend zone. Firewall to the VB365 server (Port 9194) is open.
We have like 40 Organizations in our VB365. However, the account i used for testing is only allowed to access one of them.
Does everyone else encounter such slow performance using the restore portal, or is this an unexpected behavior? Will open a support case if this is abnormal.
-
- Service Provider
- Posts: 24
- Liked: 4 times
- Joined: Jan 09, 2023 6:41 pm
- Full Name: Jürg
- Location: Switzerland
- Contact:
Re: Restore Portal - Loading data very slowly
Hi Florin
Feeling the pain as well. in our case its the actual search when looking for files or folders is so very slow. actually we have a case open - see entry further down in the forum here - that we are not able to find files and/or folders in Sharepoint that we know exist in the backup. Because we can easily find with the admins explorer tool.
Support is giving other infos than the fine people from Veeam in here. Support claims you can not restore Sharepoint data via the restore portal, whereas the Veeam staff in here claim yes you can. anyway, searching is a pain, loading the data when opening folders, subfolders takes ages. near to unusable.
our experience so far -> we regret to have made the restore portal available to our customers, produces more frustration than helping.
cheers
Jürg
Feeling the pain as well. in our case its the actual search when looking for files or folders is so very slow. actually we have a case open - see entry further down in the forum here - that we are not able to find files and/or folders in Sharepoint that we know exist in the backup. Because we can easily find with the admins explorer tool.
Support is giving other infos than the fine people from Veeam in here. Support claims you can not restore Sharepoint data via the restore portal, whereas the Veeam staff in here claim yes you can. anyway, searching is a pain, loading the data when opening folders, subfolders takes ages. near to unusable.
our experience so far -> we regret to have made the restore portal available to our customers, produces more frustration than helping.
cheers
Jürg
-
- Service Provider
- Posts: 311
- Liked: 47 times
- Joined: Jun 30, 2015 9:13 am
- Full Name: Stephan Lang
- Location: Austria
- Contact:
Re: Restore Portal - Loading data very slowly
hey there,
what is the Backup Repo used in the Backupgound? JetDBs or allready on S3??
having the same issues with JetDBs and recommendation is to use S3, and with S3 this should be quicker!
noticed on different customers, that M365 Item/Object Counts make ah huge difference in how fast the restore portal can load items...
its also ah lot faster when no backup job is running... i really feel that the JetDBs are limiting the access to the data... currently we're implementing ah S3 solution in hope this is helping on the speed of the restore portal too!
what is the Backup Repo used in the Backupgound? JetDBs or allready on S3??
having the same issues with JetDBs and recommendation is to use S3, and with S3 this should be quicker!
noticed on different customers, that M365 Item/Object Counts make ah huge difference in how fast the restore portal can load items...
its also ah lot faster when no backup job is running... i really feel that the JetDBs are limiting the access to the data... currently we're implementing ah S3 solution in hope this is helping on the speed of the restore portal too!
-
- Service Provider
- Posts: 283
- Liked: 64 times
- Joined: Nov 17, 2014 1:48 pm
- Full Name: Florin
- Location: Switzerland
- Contact:
Re: Restore Portal - Loading data very slowly
We're on Jet still but plan to build a new platform next year with ObjectStorage as Repo.
What surprises me, is that it's quite fast using the normal explorers but soooo much slower using the Restore Portal. That said, i assume that it's not only the JetDB that limits performance and there should be room for improvement. But if everyone is facing the same issue, then at least it's not a problem in our specific setup.
What surprises me, is that it's quite fast using the normal explorers but soooo much slower using the Restore Portal. That said, i assume that it's not only the JetDB that limits performance and there should be room for improvement. But if everyone is facing the same issue, then at least it's not a problem in our specific setup.
-
- Product Manager
- Posts: 8204
- Liked: 1326 times
- Joined: Feb 08, 2013 3:08 pm
- Full Name: Mike Resseler
- Location: Belgium
- Contact:
Re: Restore Portal - Loading data very slowly
I agree that this is not normal. Can you guys tell me what version you are on? And whether you are using security groups with the scope for the restore operator?
-
- Service Provider
- Posts: 24
- Liked: 4 times
- Joined: Jan 09, 2023 6:41 pm
- Full Name: Jürg
- Location: Switzerland
- Contact:
Re: Restore Portal - Loading data very slowly
We are using V 7.0.0.4388 P20231015. dont know if it was the same with the previous versions, as the customer in pain contacted us after we had 4388 installed.
For this customer we use a security group to assign the restore operators.
Our case is related to the issue my colleague Roger mentioned in another post here (Support Case # 06378699).
Going trough the folder structures in SP is slow, really very very slow and hardly useable.
When doing the same via the SP explorer app as the admin, no problems.
thanks for your help Mike.
For this customer we use a security group to assign the restore operators.
Our case is related to the issue my colleague Roger mentioned in another post here (Support Case # 06378699).
Going trough the folder structures in SP is slow, really very very slow and hardly useable.
When doing the same via the SP explorer app as the admin, no problems.
thanks for your help Mike.
-
- Service Provider
- Posts: 311
- Liked: 47 times
- Joined: Jun 30, 2015 9:13 am
- Full Name: Stephan Lang
- Location: Austria
- Contact:
Re: Restore Portal - Loading data very slowly
When where the offical restore portal released? I think it was in V6 already? Anyway used the first version and it was that bad since then... The next update made it somewhat better but still pretty unusable with "large" customers... And I don't mean user or group wise... For example one of our customers have just below 100users, and only like 7TB active data usage in m365, but we've almost 50tb of recovery points in our environment for them...
Now when the job is running, the restore portal seams to timeout request almost ever...
Yes the recovery wizards works better, but still they are ah pain ... With the need when update on SP side, customers also need to update their recovery wizards...
Now when the job is running, the restore portal seams to timeout request almost ever...
Yes the recovery wizards works better, but still they are ah pain ... With the need when update on SP side, customers also need to update their recovery wizards...
-
- Service Provider
- Posts: 283
- Liked: 64 times
- Joined: Nov 17, 2014 1:48 pm
- Full Name: Florin
- Location: Switzerland
- Contact:
Re: Restore Portal - Loading data very slowly
We're on version 7.0.0.3604 and i am using a single account (my own one) which has only set permission to our own organization. Also tried giving it permission to only a few accounts. But that does not make any difference performance wise. Seems it's always fetching everything. No matter what permissions are set.
-
- Service Provider
- Posts: 11
- Liked: never
- Joined: Jul 25, 2019 1:11 pm
- Full Name: Christophe Niel
- Contact:
Re: Restore Portal - Loading data very slowly
The loading problem started with v7 for us, when they added the calendar option to choose which backup date they wanted to restore. (I assume it's that which made the software run slow, that was the only visible change but I might probably wrong)
we upgraded almost as soon as it was available to get the new features like date picking...
With v6 it was pretty much instant loading (same user, same data, but only last backup available in the portal), and there was no issue when using this portal
I'm not using "backup operator" role were you get access to multiple mailboxes of the tenant, just single user trying to restore in his own mailbox, even that is long to open
We are using file storage, not S3. I don't know if it is the file backend or the months of history on the job that make it so slow to open the portal, or something else
call and ticket were open and the issue is still present. fortunately we didn't have many client using the restore portal v6, so they didn't really notice the change and thinks it's normal for the loading to be long.
we upgraded almost as soon as it was available to get the new features like date picking...
With v6 it was pretty much instant loading (same user, same data, but only last backup available in the portal), and there was no issue when using this portal
I'm not using "backup operator" role were you get access to multiple mailboxes of the tenant, just single user trying to restore in his own mailbox, even that is long to open
We are using file storage, not S3. I don't know if it is the file backend or the months of history on the job that make it so slow to open the portal, or something else
call and ticket were open and the issue is still present. fortunately we didn't have many client using the restore portal v6, so they didn't really notice the change and thinks it's normal for the loading to be long.
-
- Veeam Software
- Posts: 3288
- Liked: 794 times
- Joined: Oct 21, 2011 11:22 am
- Full Name: Polina Vasileva
- Contact:
Re: Restore Portal - Loading data very slowly
@juerg.hirschi
I noticed that your case 06378699 has already been closed. If the issue persists, I'd ask you to reopen the case and provide the latest logs. Support engineers will give it another check and involve RnD if needed.
Thanks!
I noticed that your case 06378699 has already been closed. If the issue persists, I'd ask you to reopen the case and provide the latest logs. Support engineers will give it another check and involve RnD if needed.
Thanks!
-
- Service Provider
- Posts: 24
- Liked: 4 times
- Joined: Jan 09, 2023 6:41 pm
- Full Name: Jürg
- Location: Switzerland
- Contact:
Re: Restore Portal - Loading data very slowly
Thanks Polina, will let my colleague know who is handling the actual ticket.
Jürg
Jürg
-
- Service Provider
- Posts: 311
- Liked: 47 times
- Joined: Jun 30, 2015 9:13 am
- Full Name: Stephan Lang
- Location: Austria
- Contact:
Re: Restore Portal - Loading data very slowly
any news on this topic??
if anyone from veeam says it shouldn't take that long, i'll also open ah ticket...
i'll test just right now, and even after login, when i'm in the "you" scope, loading of the "select restore point" options takes couple of minutes allready! (it even fails, "failed to load resourec: the server responded with ah status of 502 (proxy error)"
the repo is explicit for the customer, and because of the size or object count in this tenant it runs at an average of 75% of CPU Load (12vCPUs), after installing the latest patch of vb365 it changed ah little bit.. its "down" to about 60% now (viewing in weekly view in veeamOne, its spikes more that averages out to 60... anyway)
veeam.archiver.proxy is using 25gig RAM
and right now, if i try to acces the restoreportal its at 100% CPU load
if anyone from veeam says it shouldn't take that long, i'll also open ah ticket...
i'll test just right now, and even after login, when i'm in the "you" scope, loading of the "select restore point" options takes couple of minutes allready! (it even fails, "failed to load resourec: the server responded with ah status of 502 (proxy error)"
the repo is explicit for the customer, and because of the size or object count in this tenant it runs at an average of 75% of CPU Load (12vCPUs), after installing the latest patch of vb365 it changed ah little bit.. its "down" to about 60% now (viewing in weekly view in veeamOne, its spikes more that averages out to 60... anyway)
veeam.archiver.proxy is using 25gig RAM
and right now, if i try to acces the restoreportal its at 100% CPU load
Who is online
Users browsing this forum: No registered users and 5 guests