Adding log shipping to synchronous always on cluster for disaster recovery,why need to have have primary as backup default when add log shipping when always on opposite. Is that really true? Any lessons learned in Production environment for this?

  • Adding log shipping to synchronous always on cluster for disaster recovery, because other options won't work for us right now. Why do you need to make primary the preferred backup location for the log shipping setup when usually in the always on cluster it's the opposite. Can you still do it with secondary backups? 

    Have any lessons learned in a production always on/log shipping setup? We are setting up a proof of concept right now and then moving ahead quickly in production 2016 and 2014 enterprise environments with this shortly. Trying to get out the kinks in proof of concept/test phase and not rush ahead too quickly even though we are ready to put it into production.

  • I  haven't tried it, but I assume it's because backups taken on secondary replicas have to be copy-only.

    Why do you need to make primary the preferred backup location for the log shipping setup when usually in the always on cluster it's the opposite

    I'd dispute that. Many people back up their primary databases because even in synchronous commit mode you may lose data by backing up the secondaries.

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

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