locked
SharePoint 2013 site collection restore is now rigid and inflexible in comparison with SharePoint 2010. Will this be fixed? RRS feed

  • Question

  • I am wondering if anyone noticed that on SharePoint 2013 we have lost a lot of the flexibility in the restore process? Is this a bug?

    On SharePoint 2010 you could and still can restore from one SP20120 server to a another SP2010 server with a different cumulative update/version, once the destination server (where you trying to restore to) does not have a cumulative update that is pre that of which is installed on the source server. In summary site collection backups would restore to SharePoint servers which had equal or newer cumulative updates.

    Example of this...

    You could..
    1. Backup a site collection from Server A with December 2010 CU and then restore to Server B running July 2011 CU.

    2. Backup a site collection from Server A with SharePoint Foundation December 2010 CU and then restore to Server B running SharePoint Server December 2010 CU. (Foundation --> Server)

    3. Backup a site collection from Server A with December 2010 CU and then restore to Server B running December 2010 CU. (Identical servers)

    You could not...
    Backup a site collection from Server A with July 2011 CU and then restore to Server B running December 2010 CU.

    Example 1 & 2 above are no longer available on SharePoint 2013

    We do site collection design and stage site collection on our own servers for period of time for our customers. We then use the restore to package the site collection and move it to another on-premise server. We used to keep our server CU as old as possible so that we had great flexibility in the restore process for our customers.

    Does anyone know if Microsoft plan to fix this in the future? Thanks.




    Thursday, October 3, 2013 8:28 AM

Answers

  • Hi Jonathan,

    some of the result from my research,

    restore and back up sp site, in some way it have relationship with the database table version.

    for example there is a cumulative update from early to higher cumulative update in sharepoint 2010, as i tried, if i backup and restore from lower to higher, it worked, but not from higher to lower as you mentioned, as i check this lies because there are database table update process. latest database may able to contain the early data, but not the early database to contain the latest data.

    at sharepoint 2013, most of the cumulative update includes database updates, so perhaps this is the reason why when you tried at sharepoint 2013, it was failed, and at 2010 it worked.

    we encourage, that for sharepoint 2013, this backup and restore needs to be the same version number to do restore and backup, unless you able to do move feature, that creates a site and you load the site with your move-site sites.

    at the time being i already put your request to our suggestion box, so that some from the product group may take notice and consider it, but i can't make any guarantee regarding the time process that they may need to take for this.


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by Qiao Wei Wednesday, October 23, 2013 6:10 AM
    Tuesday, October 15, 2013 10:14 AM

All replies

  • Hi jbrownetweets,

    For  resolving this issue, I  suggest you back up the content database on SQL Server for the older version SharePoint, and restore it on SQL Server for the upgraded version SharePoint. Make sure your SQL databases are of the same version for both the older and upgraded version of SharePoint.

    Here  is an article for you reference:

    http://www.codeproject.com/Articles/257395/STSADM-Backup-Error-The-backup-is-from-a-different

    I hope this helps.

    Thanks,

    Wendy


    Wendy Li
    TechNet Community Support

    Tuesday, October 8, 2013 9:23 AM
  • Hi Wendy,

    Thanks for your workaround but this does not resolve the root of the issue. I tested the process described by restoring a foundation database to a server database with the same CU and upgrading it. The workaround was a success in this scenario as expected. 

    The issue regarding the restore still exists however. I would consider the restore limitations a massive loss in functionality on SharePoint 2013 especially for developers. I was hoping to get further detail on the subject of the issue. My questions are mainly...

    1. Was the change in restore functionality intentional by Microsoft? 

    2. If so what was the reason behind it so that we can explain it to our clients who are affected mostly by this issue?

    3. If not do Microsoft see this being addressed in future updates and when? 

    Thank you for your assistance in this matter, it is much appreciated.

    Jonathan Browne

    Wednesday, October 9, 2013 6:38 PM
  • You sure you were able to restore Sites from lower version to Higher version farm using the powershell or stsadm tool? We tried this in our environment many times and its failed with Version Mismatch error, its doesnot matter either lower to higher or higher to lower.

    thats why we always use the ContentDB backup and restore.


    Thanks -WS SharePoint administrator, MCITP(SharePoint 2010, 2013) Blog: http://wscheema.com/blog *Please remember to mark your question as "answered"/"Vote helpful" if this solves/helps your problem.*

    Wednesday, October 9, 2013 7:27 PM
  • Hi Jonathan,

    if i may ask, do most of the process that you need is to move/migrate site collection using these steps http://technet.microsoft.com/en-us/library/ee428301.aspx?

    it is recommended to backup and restore to the same version of sharepoint, because as i tried i usually get this issue as the same with waqas105 posted before.

    please have a check of sharepoint 2013 boudaries article:

    http://technet.microsoft.com/en-us/library/cc262787.aspx

    http://technet.microsoft.com/en-us/library/cc263267.aspx


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, October 11, 2013 3:42 AM
  • I can see how that approach would be handy, but at the same time it's useful because it's lazy.

    The goal of a Dev system is to be as close as possible to a production system, this reduces the chances of your customisations failing on a production system because there's idiosyncrasies in one or both of the versions in use.

    Your dev boxes should be the same version as your production boxes, just as your test boxes should be.

    I'd assume that MS probably did do it on purpose to reduce the risk of that happening, although i can't speak for MS.

    I would not expect them to change it.

    Friday, October 11, 2013 7:47 AM
  • Hi waqas105,
    Higher to Lower will always fail. As for Lower to Higher, I'm one hundred percent sure that we are able to move from lower to higher using Restore-spsite on SharePoint 2010. Its a common exercise we practice very often. We keep our SharePoint 2010 development/staging environment on SP1 (very low CU), that then gives us the ability to restore that site collection to any SP server equal to or higher then SP1 (production environments would generally carry more current CUs).

    I am not sure why you cannot reproduce this. Are you testing with a Team Site site collection? Your running management shell as administrator? If absolutely necessary I can create a video to prove this. It works I promise you. Thanks

    Jonathan Browne

    Friday, October 11, 2013 10:02 AM
  • Thanks Wendy
    Friday, October 11, 2013 10:03 AM
  • Hi Aries,

    Firstly we do not use Export Import as your first link suggests. Export Import is also not an option as we have found it can create duplicate web parts and other anomalies. We use Backup-spsite and Restore-spsite.

    When you say you usually get the same as waqas105, have you tested this? As I mentioned above in my reply to wasqas105, I don't know why this cannot be reproduced by wasqas105. I believe there maybe something else going on there like a partially upgraded farm or something. This is possible on SharePoint 2010 please take my word. I just wonder why its no longer possible on SharePoint 2013.

    Thanks

    Jonathan Browne

    Friday, October 11, 2013 10:17 AM
  • Hi Alex,
    Regarding this "Lazy" approach, I focus generally on what works and this process works on SharePoint 2010 regardless of opinion. We have never had an integrity check fail on any one of our restored site collections using this procedure.

    What I think is important to realise is that using the Restore-spsite feature keeps the process reasonably simple and away from direct interaction with the SQL server. I would suggest in some cases that this is the only viable way of distributing a site collection to a large organization. This is because it keeps the procedure within the hands of the SharePoint administration team and does not need to involve database administrators. Database servers usually carry with them so much procedural "red tape" and protection that that these simple DB restore requests become non runners.

    Saying all that I agree that a Development box should ideally be built to mirror a Production environment. This however does not take away from the fact this could be done on SharePoint 2010 and can no longer be done (on the limited number of CU's I have tested) on SharePoint 2013.

    Thanks

    Jonathan Browne

    Friday, October 11, 2013 10:44 AM
  • Hi Jonathan,

    some of the result from my research,

    restore and back up sp site, in some way it have relationship with the database table version.

    for example there is a cumulative update from early to higher cumulative update in sharepoint 2010, as i tried, if i backup and restore from lower to higher, it worked, but not from higher to lower as you mentioned, as i check this lies because there are database table update process. latest database may able to contain the early data, but not the early database to contain the latest data.

    at sharepoint 2013, most of the cumulative update includes database updates, so perhaps this is the reason why when you tried at sharepoint 2013, it was failed, and at 2010 it worked.

    we encourage, that for sharepoint 2013, this backup and restore needs to be the same version number to do restore and backup, unless you able to do move feature, that creates a site and you load the site with your move-site sites.

    at the time being i already put your request to our suggestion box, so that some from the product group may take notice and consider it, but i can't make any guarantee regarding the time process that they may need to take for this.


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by Qiao Wei Wednesday, October 23, 2013 6:10 AM
    Tuesday, October 15, 2013 10:14 AM