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.

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
Julio Gonzalez V.
  • 21
  • 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 02 '11 at 20:13

1 Answers1

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).

voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • 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 02 '11 at 20:21
  • 1
    Many tnks to all. Well, manually will be the challenge!!! – Julio Gonzalez V. Jun 03 '11 at 17:22