Постоянное резервное копирование SQL Server 2012, полное и только копирование

8

Мне нужно быстрое разъяснение по резервному копированию только для копирования по сравнению с полным резервным копированием, поскольку оно относится к нумерации журналов транзакций и восстановлению при необходимости.

У меня есть SQL Server 2012 с постоянно включенным для нескольких баз данных. Группы доступности настроены с предпочтительным резервным копированием на реплике.

только копии только и резервные копии журнала транзакций возможны на реплике. Означает ли это, что мне потребуется сделать полное резервное копирование на первичном сервере, если требуется восстановление журнала транзакций?

Спасибо

— Дебби
источник

2

на реплике возможно только копирование и копирование журнала транзакций

Правда.

Означает ли это, что мне потребуется сделать полное резервное копирование на первичном сервере, если требуется восстановление журнала транзакций?

Краткий ответ ДА .

От BOL :

Согласованная цепочка журналов обеспечивается для всех резервных копий журналов, выполняемых на любой из реплик (первичной или вторичной), независимо от режима их доступности (синхронная фиксация или асинхронная фиксация).

Поэтому, чтобы ответить на ваш вопрос, резервная копия COPY_ONLY не может быть частью восстановления, которое включает в себя резервные копии T-log (восстановление на момент времени). Весь смысл в том, чтобы иметь набор резервных копий вне обычной цепочки резервных копий, НЕ влияющий на последовательность восстановления.

Полное резервное копирование должно быть выполнено в первичной базе данных (не может быть резервной копией только для копирования).

Только резервное копирование T-журнала (как упомянуто выше) может быть выполнено на первичном или вторичном с CAVEAT, что он не испортит LSN на PRIMARY, то есть он будет поддерживать согласованность LSN - независимо от того, где вы делаете резервные копии журналов в группе доступности. ,

Лучше всего проверить, sys.fn_hadr_backup_is_preferred_replicaчтобы при резервном копировании журнала использовались параметры резервного копирования группы «Доступность» для резервного копирования журнала.

См. Выполнение резервного копирования журнала транзакций с использованием вторичных реплик группы «AlwaysOn», доступных только для чтения. Часть 1

— Кин Шах
источник

2

Вы, конечно, можете использовать полную резервную копию COPY_ONLY и применять журналы транзакций поверх нее. Полная резервная копия COPY_ONLY структурно такая же, как и любая другая полная резервная копия. Разница лишь в том, что он не сбрасывает дифференциальную битовую карту. После восстановления полного COPY_ONLY вы можете начать восстановление с журнала транзакций, который содержит последний номер LSN резервной копии COPY_ONLY, а затем продолжить работу с цепочкой журналов в обычном режиме.

— AMTwo

6

Означает ли это, что мне потребуется сделать полное резервное копирование на первичном сервере, если требуется восстановление журнала транзакций?

НЕТ - Вы можете добавить резервные копии t-log для восстановления резервной копии COPY_ONLY.

— user42163
источник

2

Вы можете восстановить журналы транзакций поверх полной копии только для копирования - это означает, что вы можете использовать резервную копию только для копирования из вторичной реплики вместе с журналами транзакций и выполнять восстановление на определенный момент времени.

Однако, если вы выполняете только резервные копии только для вторичной реплики, у вас не будет «реальной» резервной копии для сброса дифференциальной битовой карты на первичной реплике. Если разностное резервное копирование является частью вашей стратегии восстановления, то вам необходимо сделать полное резервное копирование на первичном. Если вы все хотите использовать разностное резервное копирование, вам нужно будет сделать полное резервное копирование на первичной реплике, чтобы использовать его в качестве разностного основания.

— AMtwo
источник

2

Я успешно протестировал использование резервной копии только для копирования и резервных копий журнала, которые охватывают только копирование до желаемого момента времени. Вы должны иметь все резервные копии журнала. Поэтому, если у вас есть несколько реплик, которые вы используете для создания резервных копий (например, аварийное переключение произошло), вы должны убедиться в этом и отслеживать их. В моем тестировании я просто настроил все так, чтобы все резервные копии отправлялись в центральное место. SQL поддерживает цепочку журналов для резервного копирования журналов на всех узлах AG. Хорошая статья здесь ... http://info.tricoresolutions.com/blog/understanding-backups-with-sql-server-alwayson-high-availability-mirrors

— JohnH
источник

1

У меня было много путаницы вокруг темы - в кластере AG восстановление журнала резервное копирование с последующим копированием - только полное резервное копирование.

Сейчас работает нормально. Мы можем использовать только резервную копию из вторичной реплики:

USE [master]
RESTORE DATABASE [xxxxx_testDB] FROM  
DISK = N'D:\Backups\FULL_COPY_ONLY\xxxxx_testDB_FULL_COPY_ONLY.bak' 
WITH  FILE = 1, 
MOVE N'xxxxx_testDB' TO N'D:\testdb\xxxxx_testDB.mdf',  
MOVE N'xxxxx_testDB_log' TO N'D:\testdb\xxxxx_testDB.ldf',  
NORECOVERY

GO


RESTORE LOG xxxxx_testDB
FROM DISK = 'D:\Backups\FULL_COPY_ONLY\xxxxx_testDB_LOG_1.trn'
WITH NORECOVERY; 
GO

RESTORE LOG xxxxx_testDB
FROM DISK = 'D:\Backups\FULL_COPY_ONLY\xxxxx_testDB_LOG_2.trn'
WITH NORECOVERY; 
GO


RESTORE DATABASE xxxxx_testDB WITH RECOVERY

— JAYAKUMAR SINNAPILLAI
источник