• State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 9195 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Best Practice for site A Fail Back after DR Excersize at Site B with Virtual Standbys

jtrevino
over 7 years ago

Hello,

 

...looking for the best way to do this. Here is the setup (MS Paint still rules!)

 

For the failback operation, we do not want, nor will we have the time to create a seed and ship it back down to Site A. Only ~35GB will have changed and it is a SQL database, files and folders changed, and IIS website data changing.

 

Is there a way to fail back to the Site A source and not have to restore all 500GB? Only 35GB has changed so this could be restored overnight if there is an efficient way. These sites are across the country from each other.

Site A source is currently physical but could be changed to Virtual if needed.

 

*SiteA and SiteB are DL4000 Appliances running 6.1

Parents
  • 0 over 7 years ago
    Thanks Tim. Wow, that really stinks. I found this article which pretty much exactly describes my situation, and it's basically the same as you said:
    support.software.dell.com/.../156009

    What is crazy is the Source Core in Site A has 465GB of good data that does not change but yet all 500GB needs to be restored still. What a huge waste - seems like a huge area of opportunity for improvement. We know the block info when shutting down SiteA, we know firing up SiteB contains the same data, SiteB is being tracked/updated and CoreB knows what has changed, but it can't apply only those changes to CoreA? They are the same "servers"...I'm sure it's more complicated than that but the basics are there. Apply changed blocks regardless of where the server is. I would think that's the whole point of a recovery chain. SQL server can replay only the changes to a different server, why can't Rapid Recovery? I digress.

    Thanks for the help.
Reply
  • 0 over 7 years ago
    Thanks Tim. Wow, that really stinks. I found this article which pretty much exactly describes my situation, and it's basically the same as you said:
    support.software.dell.com/.../156009

    What is crazy is the Source Core in Site A has 465GB of good data that does not change but yet all 500GB needs to be restored still. What a huge waste - seems like a huge area of opportunity for improvement. We know the block info when shutting down SiteA, we know firing up SiteB contains the same data, SiteB is being tracked/updated and CoreB knows what has changed, but it can't apply only those changes to CoreA? They are the same "servers"...I'm sure it's more complicated than that but the basics are there. Apply changed blocks regardless of where the server is. I would think that's the whole point of a recovery chain. SQL server can replay only the changes to a different server, why can't Rapid Recovery? I digress.

    Thanks for the help.
Children
No Data