Чому TO DISK = N’NUL’?
Я не розумію, чому ви використовуєте TO DISK = N’NUL’:
BACKUP
DATABASE [test0916aj8CJ] TO DISK = N’NUL’
Якщо ви це зробите, резервна копія зберігається в NUL(тобто = в нікуди / нічого) і не може бути використана, оскільки її файл не існує.
Хоча він NULтакож може бути використаний як місце призначення резервних копій LOG, він також не повинен використовуватися, особливо на Prod серверах, оскільки LOG будуть втрачені і ланцюг резервного копіювання буде розірвано. (~ схожий на a SHRINKFILE)
Резервне копіювання LOG
Перш ніж додати БД до групи, ви повинні її підготувати. Коли ви хочете підготувати вторинну БД, потрібно взяти та відновити принаймні 1 резервну копію журналу транзакцій. Дзеркало використовує його для визначення того, які транзакції вже синхронізовані у вторинній БД, а які транзакції ще не синхронізовані з первинною БД.
Тому ви повинні створити резервну копію журналів транзакцій у первинному БД:
BACKUP LOG [test0916aj8CJ] TO DISK = N'....bak'
WITH COPY_ONLY, FORMAT, INIT, NAME = N'test0916aj8CJ-Transaction Log Backup', STATS = 10
COPY_ONLYОпція повинна використовуватися. Це гарантує, що журнали не будуть усічені в кінці резервної копії LOG.
Первинний ланцюг резервного копіювання БД
Однак ви не можете відновити резервну копію журналу самостійно, тобто без ланцюга резервного копіювання (див. Відповідь Кіна також). Це означає, що резервна копія журналу транзакцій повинна бути зроблена після того, як було зроблено ПОВНЕ резервне копіювання бази даних (+ необов'язковий диференціал, якщо потрібно).
Оскільки COPY_ONLYопція не розриває ланцюг резервного копіювання, вона також не створює ланцюг резервного копіювання. Цей COPY_ONLYпараметр не можна використовувати для резервного копіювання бази даних.
Резервні копії в порядку:
- ПОВНА резервна копія бази даних без
COPY_ONLYможливості
- Необов’язковий диференціальний резервний запас
- 1 Резервне копіювання LOG з
COPY_ONLYопцією
- інша (або більше) резервна копія LOG, якщо потрібно ...
Відновити вторинну БД
Потім резервне копіювання бази даних має бути відновлено (+ диференціальне) на вторинному рівні.
Її потрібно відновити за допомогою NORECOVERYпараметра, оскільки ви також хочете відновити резервну копію LOG після відновлення ПОВНОЇ резервної копії.
Нарешті, ви відновите резервну копію LOG. Вам все одно потрібно скористатися 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 на загальну папку, яка доступна як на первинному, так і на вторинному серверах.
- Також краще зберігати файли БД на схожих дисках та місцях як на первинному, так і на вторинному серверах.
