locked
what sharepoint specific steps are needed if restoring sharepoint sql server tables to a backup RRS feed

  • General discussion

  • We have a vm running sharepoint 2007 on a vm - farm A.

    We shut down the vm, cloned the vm, and while down, had the sql server team perform a backup of farm A's sharepoint tables that are stored on shared server D.

    Then, against the cloned vm we applied the latest service pack.

    Due to some unexpected behaviors on the machine, we want to restore things back to the point in time when the clone/backup occurred.

    Initially, my expectation was that restoring the sql server backup files to server D, then starting up the original vm image, should return the site back to the way it was at the point where we shut things down.

    I don't see anything obvious, during my web searches, about specific steps that need to take place after the tables have been restored.

    However, we tried this, things appeared to be working, we did some more work, and have just noticed in the past few days some error events 7888 and 555 that talk about duplicate site ids and possibling restoring a content database from one farm into another farm.

    We never did that. We restored farm A's backup of server D's tables to server D.

    Is there something else that needs to happen in this case? 

    Conceptually, things should be exactly as they were during the time the machine was down and the backups were taken, etc.

    Note - the restore planned is not to a different server or instance, but to the same machine and instance where the farm is currently expecting to find the data.
    • Edited by lvirden Friday, June 8, 2012 2:40 PM
    Friday, June 8, 2012 2:01 PM

All replies

  • I'm confused -- please correct me if I'm wrong:

    1. You shut down the VM running farm A
    2. You cloned this VM, now you have farm B
    3. You backed up the databases for Farm A and stored in server D
    4. You updated farm B to SP3 (the latest as of this writing)
    5. Things did not go as expected
    6. You shut down farm B
    7. You turned on Farm A and restored the backup made to server D to the farm?

    I don't understand why you restored the tables you backed up, if nothing on farm A was changed during this process?

    As I think about this, I am afraid you have actually done the following:

    1. You shut down the VM running SharePoint Server A (Server D is SQL and is still running)
    2. You cloned server A, now you have Server B (an exact clone of A)
    3. You backed up the databases from D
    4. You updated farm B to SP3 (the latest as of this writing). This then updates the databases in server D (this is key)
    5. Things did not go as expected
    6. You shut down farm B
    7. You turned on Farm A, whcih is now connecting to D that has updated databases. You then restored the backups from step 3.

    Here's the part where I tell you that cloning SharePoint servers in the way you described is not supported. In theory if you made a backup and restored all the databases back to D things should work in A. If even one database was not backed up and restored you may be in an unsupported state.


    Jason Warren
    Infrastructure Specialist

    Wednesday, June 13, 2012 11:28 PM
  • I'm confused -- please correct me if I'm wrong:

    1. You shut down the VM running farm A
    2. You cloned this VM, now you have farm B
    3. You backed up the databases for Farm A and stored in server D
    4. You updated farm B to SP3 (the latest as of this writing)
    5. Things did not go as expected
    6. You shut down farm B
    7. You turned on Farm A and restored the backup made to server D to the farm?

    I don't understand why you restored the tables you backed up, if nothing on farm A was changed during this process?

    Not quote. At step 3, the backup files of the database were set aside to use if we needed to restore.

    When we cloned A -> B, it kept the same farm name, same database  name, etc. 

    In your "what I fear you did" scenario, we didn't turn farm A back on until after the database backup was restored back to D.

    We were attempting to return things to the state at which the clone/backup was taken.

    The database team has stated they backed up, and later restored, all the Sharepoint databases.  

    Thursday, June 14, 2012 9:37 AM
  • OK, let's clarify the set up. Will you please list and describe the servers in both farm A and B?

    Jason Warren
    Infrastructure Specialist

    Thursday, June 14, 2012 2:03 PM
  • The farmis a small VM - server A - running windows 2003 and sharepoint 2007 sp1. Its sql server data is stored on a shared sql server D. That's all there is to the "farm".

    When we prepared to upgrade, the vm admins shut down vm server A, cloned it. The clone I call B. While the farm is down, the database adms took a backup of the SharePoint databases for server A. They sat the backup files aside for use later.

    Once that work was completed, the vm admins booted vm server B. At this point, B is identical to A - including pointing at the shared sql server D.

    I apply SP3 to vm server B.

    We hit a problem, and so I requested that vm server B be shut down. I requested database admins restore using the special backup files of the SharePoint database. Once that was complete, I requested that vm server A be booted.

    At this point, it seemed to all of us, that vm server A is pointing to SharePoint databases which are identical to what they were when all of this started.

     

    Whew! I am not certain there's a human language ideal for describing all of this.

    Thursday, June 14, 2012 3:32 PM
  • OK, I think I'm understanding now. 

    So as you likely know, SharePoint stores the majority of its data -- configuration and content -- in databases. When you cloned Server A to Server B and updated this new farm, you updated all of the databases to SP3. There is no supported method for uninstalling a service pack. In other words, once the databases are upgraded, they can't be rolled back (in a supported way).

    Now, that said. The official roll-back strategy of a failed upgrade is to restore all of the databases. Did you restore every database in the farm? What type of database restore did you perform?

    From the errors you are seeing, it sounds like the restore either did not include everything, or it did not overwrite the existing data with the original data, causing duplicates.


    Jason Warren
    Infrastructure Specialist

    Thursday, June 14, 2012 5:32 PM