• State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 9194 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
    Not sure how I missed this but that's what I was trying to verify above. Using MSSQL and IIS pointing both to drive D: for example, if I simply start up the outdated server at SiteA, then issue a failback of the D: drive, then a user immediately starts up our SQL in-house application to access data, will we have to wait for the ENTIRE 500GB database structure to restore, just the entire DATABASE the requested data resides on, or will it pull the block information the user is specifically asking for first? With 500GB of data needing to come down the WAN ultimately, that severely impacts our RTO. If it can pull SQL data back as it's requested at the block-level, that would be acceptable. If we have to restore an entire DB or the entire SQL database structure before being able to access our data, that will require a different recovery plan entirely.

    I know this is getting down to the nitty-gritty, but it's the most important "issue" of the "feature" called Live Recovery for us. On a LAN this is hardly an issue, but over a WAN it can make or break an entire DR plan.
Reply
  • 0 over 7 years ago
    Not sure how I missed this but that's what I was trying to verify above. Using MSSQL and IIS pointing both to drive D: for example, if I simply start up the outdated server at SiteA, then issue a failback of the D: drive, then a user immediately starts up our SQL in-house application to access data, will we have to wait for the ENTIRE 500GB database structure to restore, just the entire DATABASE the requested data resides on, or will it pull the block information the user is specifically asking for first? With 500GB of data needing to come down the WAN ultimately, that severely impacts our RTO. If it can pull SQL data back as it's requested at the block-level, that would be acceptable. If we have to restore an entire DB or the entire SQL database structure before being able to access our data, that will require a different recovery plan entirely.

    I know this is getting down to the nitty-gritty, but it's the most important "issue" of the "feature" called Live Recovery for us. On a LAN this is hardly an issue, but over a WAN it can make or break an entire DR plan.
Children
No Data