使用僅複製 + 次要副本的日誌的 HA SQL AlwaysOn 備份
我希望從您的 DBA 集體經驗中獲得一些指導。
這是我們的問題：
我們的大型數據庫（大約 3TB）的完整備份消耗了太多資源，以至於我們遭受了長時間的超時。它似乎主要受 I/O 限制。
每週進行一次完整備份，其間定期進行 15 分鐘的事務日誌備份。我們必須在某個時候進行完整備份。
我們正在考慮的選項：
- 從 SQL 2016 標準版升級到 2016 年企業版並配置資源調控器以限制由備份引起的 I/O。基本上阻塞備份一點，以便更好地為應用程序請求提供服務。
- 走 HA *（高可用性）*路線並使用 SQL AlwaysOn 部署輔助節點，從輔助副本執行備份。這將減輕備份職責的主要副本並保持可用於應用程序請求，從而可能解決我們的超時問題。
優點缺點：
企業版的成本並非微不足道，雖然它提供了許多其他好處，但此時它是一顆難以下嚥的藥丸。
以相似甚至更低的成本，我們可以部署第二個 SQL 2016 標準版伺服器，並從基於 HADR 的數據庫部署中受益。這個選項對我們非常有吸引力，因為我們目前只有一個冷備用來恢復。
如果我們可以解決備份期間的超時問題，我們可能會更喜歡 HADR 的優勢而不是 Enterprise。
一些實驗室發現：
對於企業版，一些實驗室測試表明我們可以很好地控製備份資源，但感覺並不理想。我們需要調整硬體的數字以找到“最佳位置”，以實現所需的備份限制級別，而不會對其造成太大的不利影響。
對於 AlwaysOn，我們進行了一些實驗室測試，發現我們無法在輔助副本上執行典型的“完整”備份，但我們可以進行 COPY_ONLY“完整”備份。這是有道理的，因為它保留了主副本的日誌鏈。
我們能夠在輔助副本上進行事務日誌備份，這也很好，因為該日誌鏈實際上是主副本的“從屬”，並且在輔助副本上進行時不會造成任何傷害。
已確認我們能夠從 CopyOnlyBackup+TransactionLogs 進行恢復，因此這可能是一種可行的數據恢復策略。
調查結果和問題：
- 有沒有人遇到過類似的問題並使用任一選項解決了它，確認該選項對我們來說是可行的？
- 在“CopyOnlyBackup+TransactionLogs from secondary replica”的場景中，主副本上的任何完整備份都會破壞日誌鏈，並使後續事務日誌備份的從屬副本的 CopyOnlyBackup 無效。補救措施是在輔助副本上創建另一個 CopyOnlyBackup，或者不在主副本上進行完整備份。
- 不在主伺服器上進行正常的完整備份而只進行 COPY_ONLY 完整備份的含義是什麼。從長遠來看，這可以嗎？
任何指導將不勝感激。希望我們不要叫錯樹。
我實際上使用了具有 1TB 數據庫的類似設置。
- 有沒有人遇到過類似的問題並使用任一選項解決了它，確認該選項對我們來說是可行的？
我只在輔助上使用備份。即使在幾次中斷中，我也嘗試使用僅複製完整備份和日誌備份來恢復它們。
使用僅複製備份沒有問題。
上述陳述將為您的第二個和第三個問題提供清晰的說明。