Always On restore question

  • We are performing a SharePoint upgrade in our environment which consists of 60 databases in an AO availably group. Generally when we perform software upgrades we snapshot the software servers and backup all databases and if the upgrade fails we have restore the snapshots then restore the database. The database restore alone can take hours.

    Can this be done another way? My always on avail replicas are Svr1 and Svr2 with Svr1 as the primary. If I shutdown Svr2 when I snapshot my SharePoint servers and the upgrade fails would I be able to simply revert the SharePoint snapshots, shutdown Svr1 and bring up Svr2 as the primary to get the SharePoint site back up? Then proceed with removing the db's from the avail group on Svr2, bring up Svr1, drop the dbs on Svr1 then re-add them to the avail group on Svr2.

    I'm using SharePoint in this hypothetical, but what I'm really asking is can a secondary server replace a restore if necessary, in other words, is this a feasible restore plan? And of course I would backup my databases prior to the upgrade regardless.

  • Hi,

    I think that depends if the patch also affect database engine binaries and/or AG database data or metadata. If only affects middleware (SharePoint binaries for example) or database engine binaries, you can use the passive first - failover after quorum majority - new passive machines approach, like an OS or SQL Server binaries patch. In that case you can suspend affected secondary replica and take cold snapshots. If affects database metadata, you can suspend AG replication from primary, take cold snapshot and then patch.

    I hope that this helps.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply