<div>
Log shipping and transaction replication both are using the history of changes. DR server restored from backups of main server, but it has its own history. In the real DR you will not be able to complete TAIL LOG BACKUP. You cannot use the history of main server as a history of DR server. I think that after restore of DR server you should install log shipping and transactional replication starting from initial synchronization.&nbsp;
</div>

Senior Database Architecture 

marrowyung

<div>
hi, tks. <blockquote>I think that after restore of DR server you should install log shipping and transactional replication starting from initial synchronization. &nbsp;</blockquote> This mean transactional replicate and log shipping has to setup again on the new restored DR SQL server? I know scripting out transactional replication and log shipping configuration and reapply to the DR server is not going to work ? so in this case, dbatools can't help? I think the start-migration powershell command will take care of it? 
</div>

<div>
hi, any update for me ? 
</div>

<div>
<blockquote>Yes, dbatools can help in SQL Server instance level migration without Replication configured out.</blockquote> this is what I am worrying about! <blockquote>Publisher Replication will be lost after you migrate an instance to another server and you would need to reconfigure Replication.</blockquote> from time to time I found scripting out replication is not working. please detail the steps here BTW, how success you tried to backup and restore replication to another SQL server in terms of DR ? replication migration very tough! <blockquote>A better way would be to try using Always On Availability groups as explained in the article below.. <a href="https://www.jpaul.me/2013/09/ms-sql-alwayson-availability-groups-a-better-way-to-cluster/" rel="ugc">https://www.jpaul.me/2013/09/ms-sql-alwayson-availability-groups-a-better-way-to-cluster/</a>&nbsp;</blockquote> we have transactional replication to a BI server which is also SQL 2016 standard FCI, we are not in AG and we will not do this in short time. <blockquote>transactional replicate and log shipping </blockquote> but from DR point of view, each time we do it the RPO and RTO dynamically increase as we have so much to do.. ?&nbsp; 
</div>

<div>
<blockquote>May I know the type of issues you are facing in Replication so that I can guide accordingly..</blockquote> noon , I just want to create DR plan for 2 x SQL servers, now we have transaction replication and log shipping from OLTP to BI DB, and I want to create DR plan for both server, not any existing replication problem. <blockquote>We have tried with 4 Servers, Source Publisher and Subscriber and DR Publisher and Subscriber with Database Mirroring configured between Source Publisher and DR Publisher. Whenever we switch to DR Publisher, then we have scripts available to reconfigure Replication from DR Publisher to Subscriber servers..&nbsp;</blockquote> we have 2 x PROD SQL servers,we have transaction replication and log shipping from OLTP to BI DB, so we need to plan for the DR for both server so that when any/both server off line as PROD site down we have to make sure that both server in DR site up and has the same replication and log shipping up -- SAME thing Up and running. please guide me through , high level steps, e.g. what DB to backup (I backup all), how to generate the replication script. what is the sequence of database restore and script to restore. tks. 
</div>

<div>
&gt;&gt; now we have transaction replication and log shipping from OLTP to BI DB, and I want to create DR plan for both server Instead of transactional replication with log shipping, try using transactional replication with Database Mirroring configured from Principal Publisher to Mirrored Publisher and Principal Subscriber to Mirrored Subscriber. I've tried this one long time back but avoided this approach as I got some strange errors but can be achieved if done very carefully. During the failover from Production to DR node, we need to make sure that Database Mirroring doesn't have any pending logs to be applied out across both Publisher and Subscriber nodes. Or else, you would need to have AlwaysOn Availability configured as given in the link earlier which you don't have it currently. Otherwise you should have Storage Replication from Production to DR sites
</div>

<div>
<blockquote>Instead of transactional replication with log shipping, try using transactional replication with Database Mirroring configured from Principal Publisher to Mirrored Publisher and Principal Subscriber to Mirrored Subscriber. &nbsp;</blockquote> we use both because some DB do not have necessary key so LS is needed instead of transactional replication. and the target is for report purpose and mirroring can't serve this purpose. <blockquote>h as I got some strange errors but can be achieved if done very carefully.</blockquote> this mean it is not safe and we can't do it. if you do it again you know how to fix it ? <blockquote>Or else, you would need to have AlwaysOn Availability configured as given in the link earlier which you don't have it currently. </blockquote>this is a big change and we didn't do it, we also only have SQL server 2016 standard edition and that AG can only have 2 x nodes! the BAG. so what is the correct sequence of the backup and restore if our case for the DR ? 
</div>

<div>
hi, let me have a summary on that at high level: Backup 1) we need to backup all system database, user database, and the distribution database ( the Publisher Database) of the OLTP and report DB. 2) &nbsp;Scripting the individual components like Configure Distribution, Configure Publication regularily. ( how to script it out CORRECTLY?) When DR is needed. 1) Restore latest Full Backup to DR respective server (PROD OLTP to DR OLTP, PROD report DB to DR report DB) &nbsp; &nbsp;what is the sequence of restoration &nbsp;? distribution DB first? then master, then msdb and the user database in any order? 2) and Configure Subscription can help out with few minor human interactions involved out. once restore all system and user database, we apply back the script from item2 in backup session ? " We have tried with 4 Servers, Source Publisher and Subscriber and DR Publisher and Subscriber with Database Mirroring configured between Source Publisher and DR Publisher. Whenever we switch to DR Publisher, then we have scripts available to reconfigure Replication from DR Publisher to Subscriber servers.." we already have LS, we can't configure with extra mirroring, right? dangerous? 
</div>

<div>
hi, any update for me?
</div>

<div>
hi, tks. <blockquote>To script out, you can simply Right click on Replication and Click Generate Scripts to generate Distribution and Publication configuration.</blockquote> but we can't log shipping in this way! how you handle that? or you just simple use mirroring and no log shipping, so it won't apply to you ? <blockquote>Yes, you might try replacing LS with Mirroring as they can't be configured on top of the same database.</blockquote>we use LS as we want to replicate the database without any key to another repository for report purpose, so can't do it at this stage, change to AG is not an option right now as they use SAN as the shared storage. so just script out the LS job and recreate the LS job on the DR OLTP and report server? &nbsp;ONLY recreate the job as save the ass ? <blockquote>4. Configure Subscription</blockquote>it is about the script out of replication configuration you coach above ? so finally when restore: 1. restore using full backup of system databases 2. restore using full backup of Distribution database 3. &nbsp;restore using full backup of user databases 4. apply export "Configure Subscription" script you coach above on the DR OLTP? we do the same thing for the LS target and transactional replication subscriber ? usually for 1-4, any difference in steps on LS target and transactional replication subscriber ? 
</div>

<div>
&gt;&gt; but we can't log shipping in this way! how you handle that? or you just simple use mirroring and no log shipping, so it won't apply to you ? As I mentioned earlier, we have implemented with Mirroring and haven't tried with Log Shipping. Whether it is Database Mirroring or Log Shipping, we will be able to script out the Replication components by Right Clicking on Replication node and script out Distributor and Publisher &gt;&gt; so just script out the LS job and recreate the LS job on the DR OLTP and report server? &nbsp;ONLY recreate the job as save the ass ? With Mirroring, once you do the failover to current DR Server, Mirroring server will become Principal Server and hence no need to do Mirroring again. However, in case of Log Shipping you would need to reconfigure it out. &gt;&gt; usually for 1-4, any difference in steps on LS target and transactional replication subscriber ? Log Shipping or Mirroring cannot be performed on System databases and can be done only for user databases. To answer your question, you need to make sure that the Source and DR system databases are in sync via Backup or other purposes and the user databases you would need to configure it again.
</div>

<div>
<blockquote>As I mentioned earlier, we have implemented with Mirroring and haven't tried with Log Shipping.</blockquote> I know, but just want to say, we are not using mirroring. But as far as I know mirror + log shipping + transactional replication is going to fail. <blockquote>we will be able to script out the Replication components by Right Clicking on Replication node and script out Distributor and Publisher</blockquote>yes I knew, but for log shipping, in our case, we can't script out log shipping configuration and just reapply the script to the DR source DB, right? <blockquote>However, in case of Log Shipping you would need to reconfigure it out.</blockquote> ok, this difficult, redo everything again. how about if the DR source already has DB restoring and in standby mode ? reconfiguring it seems has to kill existing restored DB on DR source, right? one thing, if I only concern about backup and restore, can dbatools migration the difference in data to the DR source server ? <blockquote>you need to make sure that the Source and DR system databases are in sync via Backup or other purposes and the user databases you would need to configure it again. </blockquote> backup will be ready all the time, so no worry. but if DR source already has log shipping, restore last time we do DR drill( just an example) , we still need to destory the existing log shipping configuration and recreate a new one ? from my point of view, LS seems need to create once in DR source and DR BI server, when we do DR drill AGAIN, we can simply just backup and restore all DB from backup to DR source and BI server and LS will keep running? even DR already has transactional replication setup, when doing DR drill, transaction replication (assuming no change in transaction replication setting on the PROD, still need to recreate and reapply in DR site ? 
</div>

<div>
&gt;&gt; But as far as I know mirror + log shipping + transactional replication is going to fail. Yes, for sure, it will have problems one or the other way around.. &gt;&gt; but for log shipping, in our case, we can't script out log shipping configuration and just reapply the script to the DR source DB, right? Yes, you can't script it out and you need to reconfigure it out. &gt;&gt; ok, this difficult, redo everything again. how about if the DR source already has DB restoring and in standby mode ? reconfiguring it seems has to kill existing restored DB on DR source, right? If the DR source is in restoring state, then you would need to apply the latest Logs and bring it to Online status manually and then configure Log Shipping back from existing DR to current Production. &gt;&gt; one thing, if I only concern about backup and restore, can dbatools migration the difference in data to the DR source server ? I won't recommend to do this one as identifying changes in data with dbatools or any tool will take lots of time depending upon the Database size and you won't be able to predict your RTO at all. &gt;&gt; we still need to destory the existing log shipping configuration and recreate a new one ? Yes, I'm afraid this will happen most of the times.. &gt;&gt; transaction replication (assuming no change in transaction replication setting on the PROD, still need to recreate and reapply in DR site ? Yes, you might if there are any records skipped during the failover, then you will end up in re configuring Replication.
</div>

<div>
<blockquote> Yes, for sure, it will have problems one or the other way around..</blockquote>so we can't do EXACTLY your way. <blockquote>Yes, you can't script it out and you need to reconfigure it out.</blockquote>In this case, seems that we need to setup the log shipping for the first time AFTER OLTP DR SQL server have all db restored to DR OLTP, and DR BI DB do not have any DB yet . then setup LS on DR OLTP and let this DR OLTP LS to DR BI server. then we do not setup LS AGAIN anymore NEXT Time do we the DR drill but just restore PROD OLTP to DR OLTP server and let existing DR site LS SQL job we setup above do the SAME job for us ? but seems not working as the new PROD OLTP and &nbsp;DR OLTP content will be different, and the log LSN on DR OLTP and DR BI DB is different too, so the pre created LS job is not going to work anyway? <blockquote>If the DR source is in restoring state, then you would need to apply the latest Logs and bring it to Online status manually and then configure Log Shipping back from existing DR to current Production.</blockquote> so LS need to recreate EVERY TIME we do DR drill ? <blockquote>I won't recommend to do this one as identifying changes in data with dbatools or any tool will take lots of time depending upon the Database size and you won't be able to predict your RTO at all.&nbsp;</blockquote>so dbatools can't just restore the difference technically ? <blockquote>Yes, you might if there are any records skipped during the failover, then you will end up in re configuring Replication.</blockquote> so it can be very time consuming EACH TIME we do DR drill. so overall what we need is : 1) backup distribution DB from PROD OLTP. 2) backup all system dB from PROD OLTP . 3) backup all user database from PROD OLTP. 4) script out transactional replication configuration. when doing DR/DR drill. 1) restore PROD OLTP distribution DB to DR OLTP. 2) restore PROD OLTP system DB to DR OTLP 3) restore PROD OLTP user database to DR OLTP. DR BI DB do not have anything yet 4) reapply the scripted out transactional replication to the DR OLTP DB. then transaction replication will create the necessary DB copy in DR BI DB? then we just wait? and we just manually recreate the LS from DR OLTP To DR BI DB? anything else missed? 
</div>

<div>
&gt;&gt; so LS need to recreate EVERY TIME we do DR drill ? Yes, I guess so since I haven't tested with Log Shipping before.. &gt;&gt; so dbatools can't just restore the difference technically ? Technically can, but we can't identify the RTO or RPO times for you to keep the business users updated exactly. &gt;&gt; then transaction replication will create the necessary DB copy in DR BI DB? then we just wait? We need to reconfigure Transactional Replication using the scripts and create a new Snapshot or via Backup approach. &gt;&gt; and we just manually recreate the LS from DR OLTP To DR BI DB? Why do we need to have LS from DR OLTP to DR BI DB since you have Replication configured, LS might not be required.
</div>

<div>
<blockquote>Technically can, but we can't identify the RTO or RPO times for you to keep the business users updated exactly.</blockquote> man, dbatools do not have the design in mind to ONLY migrate the change of data after the last run ? Then this tools is not in good design, and it means people use it to only migrate once ? migrate ONLY the difference should take much less time ? <blockquote>Why do we need to have LS from DR OLTP to DR BI DB since you have Replication configured, LS might not be required.</blockquote> some DB, tables do not have any key, so replication setup will fail, that's why .. and that's why I also said, mirroring is not for us! &nbsp;both LS and transaction replication make sure we have a copy in the BI server for user to read report. <blockquote>We need to reconfigure Transactional Replication using the scripts and create a new Snapshot or via Backup approach</blockquote> what backup approach..? and so my steps still correct? <blockquote>so overall what we need is : 1) backup distribution DB from PROD OLTP. 2) backup all system dB from PROD OLTP . 3) backup all user database from PROD OLTP. 4) script out transactional replication configuration. when doing DR/DR drill. 1) restore PROD OLTP distribution DB to DR OLTP. 2) restore PROD OLTP system DB to DR OTLP 3) restore PROD OLTP user database to DR OLTP. DR BI DB do not have anything yet 4) reapply the scripted out transactional replication to the DR OLTP DB. then transaction replication will create the necessary DB copy in DR BI DB? then we just wait? and we just manually recreate the LS from DR OLTP To DR BI DB? </blockquote> ? 
</div>

<div>
&gt;&gt; Then this tools is not in good design, and it means people use it to only migrate once ? migrate ONLY the difference should take much less time ? To clarify, dbtools was created with the purpose to automate most commonly faced scenarios using Powershell and it obviously meets that particular requirement. What I was trying to clarify is, dbtools can help you identify the data changes across 2 databases and help you migrate the differences but the time taken to identify the differences from one database to other database depends upon the following factors. 1. Size of your database 2. No. of tables in your database. Since the script used to compare the data changes across 2 tables depends upon these 2 criteria, you can't estimate the RPO and RTO to migrate the differences in data. &gt;&gt; some DB, tables do not have any key, so replication setup will fail, that's why .. Reason I've asked is because in ideal Architecture design, OLTP and BI(OLAP) database structures will be different and not same and BI database dimensions or fact tables should have a Primary or Surrogate key. &gt;&gt; and that's why I also said, mirroring is not for us! &nbsp;both LS and transaction replication make sure we have a copy in the BI server for user to read report. Okay, however we can have the BI Server with slightly denormalized tables for faster Reporting instead of having normalized tables which might suffer in Report generation performance. &gt;&gt; then transaction replication will create the necessary DB copy in DR BI DB? then we just wait? and we just manually recreate the LS from DR OLTP To DR BI DB? Yes, kindly try as it should work out and identify the RTO and RPO values during your testing once.
</div>

<div>
<blockquote>migrate ONLY the difference should take much less time ?</blockquote> like differential and increment backup and restore. when restore , full backup restore + differential + t log restore! restoring only is faster than full restore, right? <blockquote>What I was trying to clarify is, dbtools can help you identify the data changes across 2 databases and help you migrate the differences but the time taken to identify the differences from one database to other database depends upon the following factors. 1. Size of your database 2. No. of tables in your database.</blockquote> yeah, then must use t log + differential backup to speed that up right? no need to check in that case. but one of the requirement is, automate as much task as possible. <blockquote>Reason I've asked is because in ideal Architecture design, OLTP and BI(OLAP) database structures will be different and not same and BI database dimensions or fact tables should have a Primary or Surrogate key.</blockquote> Yeah I udnerstand and when I come onboard the SQL already this and change to AG is not possible. no one will do the change and customer is keep saying no money! Then let's do sth do not involve a lot of money , &nbsp;keep the existing one. but one thing, we do not use MS report server report engine, we use our own engine, and we just need data from OTLP so we replicate / log shipping to BI server. <blockquote>Okay, however we can have the BI Server with slightly denormalized tables for faster Reporting instead of having normalized tables which might suffer in Report generation performance.</blockquote> yeah, I focus on the MAXDOP, tempdb and COP to tune it! and of course the same DB in BI server has the index to speed things up. <blockquote>To clarify, dbtools was created with the purpose to automate most commonly faced scenarios using Powershell and it obviously meets that particular requirement.</blockquote> do you still remember that dbatools command to only transfer the change to DR server? &nbsp;please&nbsp; share if you can. 
</div>

<div>
so this steps already good? 1) backup distribution DB from PROD OLTP. 2) backup all system dB from PROD OLTP . 3) backup all user database from PROD OLTP. 4) script out transactional replication configuration. when doing DR/DR drill. 1) restore PROD OLTP distribution DB to DR OLTP. 2) restore PROD OLTP system DB to DR OTLP 3) restore PROD OLTP user database to DR OLTP. DR BI DB do not have anything yet 4) reapply the scripted out transactional replication to the DR OLTP DB. 
</div>

<div>
One thing, is the replicated DB on the DR BI server has to backup and restore first before reapplying the scripted out transactional replication to the DR OLTP DB.? if I don't do that when replication script reapply, it can't see the target replicated DB and the script will fail on creating when apply on &nbsp;DR PRIMARY ? or once the replication script applied on the DR primary, the new replicated DB will be create automatically? but this takes a long long time? and in terms of log shipping, the log shipping target DB in the target server should not be restored in advance as we need to log shipping everything anyway so just follow normal LS procedure on DR AT DR TIME: 1) backup the DB and restore to the log shipping DR target, mark it in none recovery mode. 2) use normal log shipping procedure to ship log to the log shipped DB to DR target. this is it? and we assume on DR drill, replicated DB on the DR BI server and log shipping target DB on DR BI server is not existing at all ? once DR drill done, we delete all replicated DB and log shipped DB in target BI DB server to prepare for the next DR drill ? 
</div>

<div>
Sorry for the delay, got stuck in lot of Prod issues.. &gt;&gt; if I don't do that when replication script reapply, it can't see the target replicated DB and the script will fail on creating when apply on &nbsp;DR PRIMARY ? Yes, if the database isn't available, then the scripts will fail for sure. &gt;&gt; 1) backup the DB and restore to the log shipping DR target, mark it in none recovery mode. 2) use normal log shipping procedure to ship log to the log shipped DB to DR target. Yes, LS might fail if there are any breakages in LSN identified and hence it would be better to configure the LS after all the Main databases are restored out. &gt;&gt; and we assume on DR drill, replicated DB on the DR BI server and log shipping target DB on DR BI server is not existing at all ? Kindly confirm as I got confused now whether you have DR BI Replication and LS currently available or not since you have asked it as a question. Either you have the DR OLTP to BI Server Replication and LS configured currently or not, it would be better to try once by reconfiguring Replication and LS and it would be more better..
</div>

<div>
<blockquote>Yes, LS might fail if there are any breakages in LSN identified and hence it would be better to configure the LS after all the Main databases are restored out. &nbsp;</blockquote> So for this kind of very manual DR drill, as originally we have LS keep shipping log from primary to DR and when DR happen (drill or not drill), it seems if we backup and restore DB from PROD LS target to DR LS target, the LSN number should still be very close and updated ? so restore the DB from PROD LS target to DR LS target and just kick start the LS job restore should be ok ? of course RECREATE the LS in DR Site is the last sort of action. <blockquote>Kindly confirm as I got confused now whether you have DR BI Replication and LS currently available or not since you have asked it as a question.</blockquote> not yet, we are only draft a procedure but I will test it. but we are assuming PROD site all down, and must be kick off the DR site with latest DB backup. <blockquote>&nbsp;it would be better to try once by reconfiguring Replication and LS and it would be more better.. </blockquote> trial run it you mean ? currently we have backup ONLY on PROD OLTP but not BI DB (replication and LS target), in order to restore the BI DB quickly it seem we need to setup backup job on PROD BI DB also do that both DR OLTP and DR BI DB can be restore together to save time ? 
</div>

<div>
Hi, one thing, it seems right now we have to prepare for the DR drill when PROD site all down, so this mean dbatools to migration everything in advance is not making any sense at all! when PROD site is all down we can only backup and restore using full + t log backup, and there are no ways to automate that right? or any tools you used to automate the full and t log restore ? 
</div>

<div>
hi, please help to answer this : <a href="https://www.experts-exchange.com/questions/29223350/Log-shipping-job-failed-as-one-trn-file-is-not-in-good-format-how-to-fix-it-asap.html" rel="ugc">https://www.experts-exchange.com/questions/29223350/Log-shipping-job-failed-as-one-trn-file-is-not-in-good-format-how-to-fix-it-asap.html</a> 
</div>

<div>
Sorry for the delay, got stuck in some Prod issues and didn't have time at all.. &gt;&gt; so restore the DB from PROD LS target to DR LS target and just kick start the LS job restore should be ok ? Yes, that's right, configure LS from Prod to DR once you do the DR failover.. &gt;&gt; but we are assuming PROD site all down, and must be kick off the DR site with latest DB backup. Either you can take Prodution Servers down or move it to another Subnet /VLAN without access to Production network and test it out.. &gt;&gt; trial run it you mean ? yes, that's correct.. &gt;&gt; currently we have backup ONLY on PROD OLTP but not BI DB (replication and LS target), in order to restore the BI DB quickly it seem we need to setup backup job on PROD BI DB also do that both DR OLTP and DR BI DB can be restore together to save time ? If you take a Full backup, you might spend a lot of time, instead you can configure for a Full and Differential backup to speed up the process or save time. &gt;&gt; when PROD site is all down we can only backup and restore using full + t log backup, and there are no ways to automate that right? As I mentioned above, either we can take it offline or just move to another network. If moved to another network then we can still access the data but can't automate this..
</div>

<div>
<blockquote>Yes, that's right, configure LS from Prod to DR once you do the DR failover.. </blockquote> as according to the other ticket. it seems I have to remove the existing LS relationship and add it back, just copy and use the existing LS job is not going to make LS go back to work. and when failover to DR, must we full backup the DR LS primary DB to the DR LS secondary DB or simple just backup PRIMARY LS secondary DB back to DR LS secondary and recreate the log shipping? <blockquote>&nbsp;If you take a Full backup, you might spend a lot of time, instead you can configure for a Full and Differential backup to speed up the process or save time.&nbsp;</blockquote> currently we have only full + t log backup. <blockquote>&nbsp;As I mentioned above, either we can take it offline or just move to another network. If moved to another network then we can still access the data but can't automate this..&nbsp;</blockquote> but as PROD site down totally, how can we access it ? so just can't automate that as PROD site all dead ? 
</div>

<div>
hi, May I know if there is any update for me ?
</div>

<div>
hi, please also help on this, this time the scene is about SAN replication: <a href="https://www.experts-exchange.com/questions/29231587/setup-SQL-server-2016-DR-site-by-SAN-replication.html?anchorAnswerId=43379615#a43379615" rel="ugc">https://www.experts-exchange.com/questions/29231587/setup-SQL-server-2016-DR-site-by-SAN-replication.html#a43379615</a> 
</div>

<div>
we haven't have resource to try this out yet and I'd like to close this ticket for now. 
</div>

<div>
<div class="content wysiwyg-content fr-view">
hi, we are using bare metal to run SQL server and we are now trying to setup a DR procedure for it. At this moment we are consider other solution, like convert the bare metal SQL server to VM and failover using SRM. but before this we want to draft a DR procedure by just backup and restore system and user database from the bare metal SQL server to another SQL installed in other VM, however the existing SQL server has transactional replication and log shipping setup, how can we simply also BACKUP and restore both configuration to the DR SQL serve standalone box ? using dbatools ?<a href="https://dbatools.io/migration-enhancements/" rel="ugc">https://dbatools.io/</a> ? &nbsp;from my past experience, backup and restore the SQL replication configuration is not going to work, right? the PROD SQL server has one replication partner, which is the report server. So once backup and restore the PROD data to the DR SQL server, the replication and log shipping should work again. any suggest what can we do on this kind of DR solution. 
</div>
</div>


hi,
we are using bare metal to run SQL server and we are now trying to setup a DR procedure for it.
At this moment we are consider other solution, like convert the bare metal SQL server to VM and failover using SRM.
but before this we want to draft a DR procedure by just backup and restore system and user database from the bare metal SQL server to another SQL installed in other VM, however the existing SQL server has transactional replication and log shipping setup, how can we simply also BACKUP and restore both configuration to the DR SQL serve standalone box ?
using dbatools ?
https://dbatools.io/
?  from my past experience, backup and restore the SQL replication configuration is not going to work, right?
the PROD SQL server has one replication partner, which is the report server. So once backup and restore the PROD data to the DR SQL server, the replication and log shipping should work again.
any suggest what can we do on this kind of DR solution.

DR procedure for SQL server with log shipping and transaction replication setup

Disaster Recovery is the planning for and creation of policies and procedures related to the resumption or continuation of an organization's functions following a catastrophic event. The term is most frequently used in relation to failure of networks, but DR preparations also include other business systems and personnel considerations.

Disaster Recovery

Microsoft SQL Server is a suite of relational database management system (RDBMS) products providing multi-user database access functionality.SQL Server is available in multiple versions, typically identified by release year, and versions are subdivided into editions to distinguish between product functionality. Component services include integration (SSIS), reporting (SSRS), analysis (SSAS), data quality, master data, T-SQL and performance tuning.

Microsoft SQL Server

SQL (Structured Query Language) is designed to be used in conjunction with relational database products as of a means of working with sets of data. SQL consists of data definition, data manipulation, and procedural elements. Its scope includes data insert, query, update and delete, schema creation and modification, and data access control.