Case #07103527
Problem in short:
Before upgrade from 11a latest all logshipping via PowerShell Direct (PSD) work's OK. My understanding of the process is as follows: PSD Guest Interaction-->BAK Files created in VM-->BAK files tranferred to Hyper-V host via PSD--> Hyper-V host transfer of BAK files directly to repository
After the upgrade to 12.1 we see new behavior(?):
PSD Guest Interaction-->BAK Files created in VM-->BAK files tranferred to Hyper-V host via PSD--> Hyper-V host transfer of BAK files to VBR server??? --> VBR server transfer BAK file to repository.
To get this running after the upgrade we had to open ports 2500-3300 from Hyper-V hosts to VBR server.
Please clarify the correct steps of the SQL log shipping process using PSD
Regards
/Einar
-
- Service Provider
- Posts: 18
- Liked: 3 times
- Joined: Jan 08, 2021 1:15 pm
- Full Name: Einar Sivertsen
- Contact:
-
- Veeam Software
- Posts: 3463
- Liked: 580 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: Problems with SQL log shipping via PowerShell Direct after upgrade to 12.1
Hi Einar,
I'm discussing the issue with our Devs, I'll update the topic as soon as I have more details.
Thanks!
I'm discussing the issue with our Devs, I'll update the topic as soon as I have more details.
Thanks!
-
- Veeam Software
- Posts: 3463
- Liked: 580 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: Problems with SQL log shipping via PowerShell Direct after upgrade to 12.1
Hello,
@sivein In v12, we made an optimization to put logs on the disk of the Hyper-V host with the most free space. After that, logs are transferred to the backup server via Data Movers, that's why you need to open ports. Before the optimization, logs were stored on the admin$ and the backup server could fetch them without Data Movers. We're speaking about the side-effect of the optimization, in general, I agree that we need to avoid opening ports whenever possible.
In fact, the usage of the backup server in the log shipping schema on Hyper-V is due to some low-level architectural specifics. However, I believe that your request fully makes sense and we can improve this piece of architecture in one of our future releases. I think in the on-host mode, the source host itself should be a log shipping server and logs should be sent directly to the repository. In the off-host mode, logs should be sent from the proxy to a repository while the proxy plays the role of the log-shipping server as well.
By the way, we have the recommendation to open ports on the backup server, you may check this page.
Thanks!
@sivein In v12, we made an optimization to put logs on the disk of the Hyper-V host with the most free space. After that, logs are transferred to the backup server via Data Movers, that's why you need to open ports. Before the optimization, logs were stored on the admin$ and the backup server could fetch them without Data Movers. We're speaking about the side-effect of the optimization, in general, I agree that we need to avoid opening ports whenever possible.
In fact, the usage of the backup server in the log shipping schema on Hyper-V is due to some low-level architectural specifics. However, I believe that your request fully makes sense and we can improve this piece of architecture in one of our future releases. I think in the on-host mode, the source host itself should be a log shipping server and logs should be sent directly to the repository. In the off-host mode, logs should be sent from the proxy to a repository while the proxy plays the role of the log-shipping server as well.
By the way, we have the recommendation to open ports on the backup server, you may check this page.
Thanks!
Who is online
Users browsing this forum: blakeshef and 2 guests