Почему TO DISK = N’NUL’?
Я не понимаю, почему вы используете TO DISK = N’NUL’:
BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’
Если вы это сделаете, резервная копия будет сохранена в NUL(то есть = в никуда / ничего) и не может быть использована, потому что ее файл не существует.
Хотя NULего также можно использовать в качестве места назначения для резервного копирования журналов, его также не следует использовать, особенно на серверах Prod, поскольку журналы будут потеряны и цепь резервного копирования будет разорвана. (~ похож на SHRINKFILE)
LOG Backup
Перед добавлением БД в группу, вы должны подготовить ее. Если вы хотите подготовить вторичную БД, необходимо сделать и восстановить как минимум 1 резервную копию журнала транзакций. Зеркало использует его, чтобы выяснить, какие транзакции уже синхронизированы на вторичной БД, а какие транзакции еще не синхронизированы с первичной БД.
Поэтому вы должны сделать резервную копию журналов транзакций на первичной БД:
BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak'
WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
COPY_ONLYОпция должна использоваться. Это гарантирует, что журналы не усекаются в конце резервной копии журнала.
Основная цепочка резервных копий БД
Однако вы не можете восстановить резервную копию журнала в одиночку, то есть без цепочки резервных копий (см. Также ответ Kin). Это означает, что резервное копирование журнала транзакций должно выполняться после полного резервного копирования базы данных (+ необязательный дифференциал, если необходимо).
Поскольку COPY_ONLYопция не разрывает цепочку резервного копирования, она также не создает цепочку резервного копирования. Этот COPY_ONLYпараметр нельзя использовать для резервного копирования базы данных.
Резервные копии по порядку:
- Полное резервное копирование базы данных без
COPY_ONLYопции
- Дополнительное дифференциальное резервное копирование
- Резервное копирование 1 журнала с
COPY_ONLYопцией
- другое (или более) резервное копирование журнала при необходимости ...
Восстановите вторичную БД
Затем резервная копия базы данных должна быть восстановлена (+ разностная) на вторичном.
Он должен быть восстановлен с помощью этой NORECOVERYопции, потому что вы также хотите восстановить резервную копию журналов после восстановления полной резервной копии.
Наконец, вы восстановите резервную копию журнала. Вам все еще нужно использовать эту NORECOVERYопцию, потому что зеркало будет продолжать восстанавливать транзакции, как только они появятся.
- Восстановите ПОЛНУЮ резервную копию с
NORECOVERYопцией
- Восстановите резервную копию DIFF с помощью
NORECOVERYопции
- Восстановите все резервные копии LOG в порядке с
NORECOVERYопцией
Давайте сложим все вместе (адаптируем к вашей среде)
На основном сервере запустите:
USE master
Go
BACKUP DATABASE [test0916aj8CJ] TO DISK = N'....bak'
WITH FORMAT, INIT, NAME = N'test0916aj8CJ-Full Database Backup', STATS = 10
GO
BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak'
WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
GO
На Вторичном сервере запустите:
USE master
Go
RESTORE DATABASE [test0916aj8CJ] FROM DISK = N'....bak'
WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE LOG [test0916aj8CJ] FROM DISK = N'....bak'
WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
Затем вы можете продолжить добавление новой вторичной БД в группу доступности ...
Дополнительные действия
- Лучше установить параметр DISK для общей папки, доступной как с основного, так и с дополнительного серверов.
- Также лучше хранить файлы БД на одинаковом диске и в одном месте на основном и дополнительном серверах.
