2

I had my principal database in a SQL server that was scheduled to back up at 9 AM and 3 PM. A second server contained these backups in case of failure. The main server went down yesterday at about 2 AM, and the most recent backup was at 3 PM the day before. I was able to recover from the backup on the backup server, but users began work without realizing that there were changes made between the last backup and the start of morning work that did not make it into the restored DB.

They're still working today, but I want to transfer the transactions made against the backup server to the original server, which I have now recovered. Is there a way to migrate the transactions made to the backup to the original server? There are lots of transactions that were made, and a mass insertion doesn't work because there are modifications, insertions, deletions, etc.

1
  • Normally questions on ServerFault are posted in English, simply because the vast majority of the users are fluent in that language. We don't normally frown on Google translations as long as they make sense (if you translate back and forth and the Spanish that came back out looked sane the English is probably fine too :)
    – voretaq7
    Jun 2, 2011 at 20:13

1 Answer 1

2

Assuming my translation is right you've had a DB failover and want to get your environment back to its original configuration.

The path to recovery from a fail-over condition like you described is pretty simple: Your old secondary server (B) is now running as your primary, so you need to rebuild your old primary server (A) as a new secondary and fail back (or just leave it that way as you'll have your redundancy back...)

If there are "missing" transactions in the gap period that you absolutely need to recover you will want to manually grab those and apply them to the currently-running DB first -- it's pretty much a manual sifting job to pick them out though as you can't apply the transaction logs from the old server to the current one - there could be conflicts that would cause major trouble.
(Doing a more real-time replication in the future will avoid this kind of problem -- If you tell us what kind of DB server you're running someone may be able to give you pointers on that).

2
  • Looks like my translation was pretty close based on Mr. Jefferson's reply. Unfortunately that means you have to fight with the recovery process because it's not easy to get data from your old DB into the new one once transactions have started happening on the new DB.
    – voretaq7
    Jun 2, 2011 at 20:21
  • 1
    Many tnks to all. Well, manually will be the challenge!!! Jun 3, 2011 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .