• State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 6046 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

Live DB Recovery

Corrigun
over 8 years ago

Hi All,

We have a 2008r2 server on which a PSQL DB and the application that uses it coexists on the same non O/S partition. It is in use 24/7/365.

Is it reasonable to believe that a "live recovery" of this partition would work as advertised in the event that it was compromised? That is to say recover it on the fly while the users continued unaware?

I would agree that testing would be beneficial but short of building a lab and purchasing additional licenses it's just not practical.

Thanks In Advance

Parents
  • 0 over 8 years ago
    I would guess the answer would be, kinda, maybe. A live recovery restore on a SQL DB probably wont work simply because the SQL service wont start (as the DB's are not there) I don't know if live recovery would help at all. I was thinking that it would, since it's whole purpose is to push requested files to the front of the restore queue, but I don't know that SQL would "request" its necessary files.

    If trying to start SQL would request these files, then live recovery would probably speed up your restore (not make it instant) If SQL does not request the files, so they DON'T get pushed to the front of the restore queue, then I don't think it wold help at all.

    If this is a critical server/ application, bring it to management and get whatever needs to be done in place to test. I would assume there is some license policy in place to allow short term testing. As far as hardware, a good option would be to export a snapshot to a vm and test on that.

    I would be interested to know your results/ finding. I have never run into this (we export critical servers vs using live recovery) but someone from Quest may have more info
Reply
  • 0 over 8 years ago
    I would guess the answer would be, kinda, maybe. A live recovery restore on a SQL DB probably wont work simply because the SQL service wont start (as the DB's are not there) I don't know if live recovery would help at all. I was thinking that it would, since it's whole purpose is to push requested files to the front of the restore queue, but I don't know that SQL would "request" its necessary files.

    If trying to start SQL would request these files, then live recovery would probably speed up your restore (not make it instant) If SQL does not request the files, so they DON'T get pushed to the front of the restore queue, then I don't think it wold help at all.

    If this is a critical server/ application, bring it to management and get whatever needs to be done in place to test. I would assume there is some license policy in place to allow short term testing. As far as hardware, a good option would be to export a snapshot to a vm and test on that.

    I would be interested to know your results/ finding. I have never run into this (we export critical servers vs using live recovery) but someone from Quest may have more info
Children
No Data