Экземпляр "Минус день" в дополнение к DEV, TEST и PROD

[Владимир Максимов]

Не знаю даже как назвать. Замечания, что ли...

Замечание 1

FULL Backup базы данных необходимо делать регулярно вне зависимости от его дальнейшего использования. Минимум, раз в неделю. Описанная технология не может заменить создание FULL Backup. При этом Backup логов начинает "отсчет" от момента создания последнего FULL Backup. Это значит, что после выполнения FULL Backup все ранее созданные Backup логов можно смело выбрасывать. Они больше не нужны. А созданный FULL Backup необходимо будет скопировать на машину с базой "минус день".

В момент создания FULL Backup описанная технология не имеет никаких преимуществ

Замечание 2

Использование Backup логов предполагает, что они создаются друг за другом без разрывов. Это значит, что если в какой-то момент создание Backup-лога "сбойнуло" и был "пропущен" кусок за очередные 15 минут, то процесс восстановления из Backup станет невозможен. Точнее, восстановление остановится на "пропущенном" участке. А запустить повторное создание "пропущенного" куска - невозможно. Необходимо будет сделать полный или дифференциальный Backup базы данных.

В случае сбоя создания очередного "фрагмента" Backup-лога описанная технология перестает работать.

[Kasper]

Владимир, спасибо за замечания. Вот мои ответы

Цитата:

Сообщение от Владимир Максимов

FULL Backup базы данных необходимо делать регулярно вне зависимости от его дальнейшего использования. Минимум, раз в неделю. Описанная технология не может заменить создание FULL Backup.

Технология "Минус день с подхватом логов" не предназначена для замены FULL BACKUP и не влияет на принятую корпоративную политику резервного копирования.
Эта технология имеет иные цели: для сотрудников -- снизить количество сторно, для консультантов -- дать бОльшую оперативность решения проблем

Цитата:

Сообщение от Владимир Максимов

При этом Backup логов начинает "отсчет" от момента создания последнего FULL Backup. Это значит, что после выполнения FULL Backup все ранее созданные Backup логов можно смело выбрасывать. Они больше не нужны. А созданный FULL Backup необходимо будет скопировать на машину с базой "минус день".

Нет, это не так.
Transaction Log'и содержат записи об изменениях. Каждое изменение имеет LSN -- Log Sequence Number. Они должны быть без промежутков. При выполнении FULL BACKUP "дырок" в LSN не образуется.
Я проверил это ещё раз -- сделал в середине цикла FULL BACKUP -- база "Минус день" проигнорировала факт создания большого бэкапа и продолжила накатывать логи по цепочке.
В том, что "дырок" в LSN не образуется, Вы можете убедиться выполнив запрос

select a.BACKUP_SET_ID, a.NAME, a.USER_NAME
     , FIRST_LSN, LAST_LSN, CHECKPOINT_LSN
     , DATABASE_BACKUP_LSN, TYPE, b.PHYSICAL_DEVICE_NAME
from msdb..BACKUPSET a, msdb..BACKUPMEDIAFAMILY b
where a.MEDIA_SET_ID = b.MEDIA_SET_ID

Результат выполнения на моей БД я выложил здесь
Вы можете увидеть, что между зелёными клетками нет промежутка в LSN, хотя между ними был FULL BACKUP

Цитата:

Сообщение от Владимир Максимов

Использование Backup логов предполагает, что они создаются друг за другом без разрывов. Это значит, что если в какой-то момент создание Backup-лога "сбойнуло" и был "пропущен" кусок за очередные 15 минут, то процесс восстановления из Backup станет невозможен. Точнее, восстановление остановится на "пропущенном" участке. А запустить повторное создание "пропущенного" куска - невозможно. Необходимо будет сделать полный или дифференциальный Backup базы данных.

Transaction Log является важной частью базы данных и утеря его недопустима, как для "Минус дня", так и для штатного backup. Если всё-же такое произойдёт -- да, нужно сделать полный backup. Это в равной степени относится и к штатному backup.

Механизм TLS очень похож на ARCHIVELOG в Oracle. Там та-же ситуация и такое-же решение.
Обычно этого не происходит

[Владимир Максимов]

Цитата:

Сообщение от Kasper

Я проверил это ещё раз -- сделал в середине цикла FULL BACKUP -- база "Минус день" проигнорировала факт создания большого бэкапа и продолжила накатывать логи по цепочке.

Вот именно этот момент меня и смущал. Если создание Full Backup не приводит к необходимости "начинать сначала", то возражение снимается. Я просто не проверял этот момент.

Кстати, не подскажите, насколько описанная Вами технология требовательна к дисковому пространству? Если за единицу отсчета брать размер рабочей базы данных, то сколько дискового пространства требуется для виртуальных дисков? Ну, например, если рабочая база 2ТБ, то сколько потребуется на виртуальную машину?

[Kasper]

Цитата:

Сообщение от Владимир Максимов

Кстати, не подскажите, насколько описанная Вами технология требовательна к дисковому пространству? Если за единицу отсчета брать размер рабочей базы данных, то сколько дискового пространства требуется для виртуальных дисков? Ну, например, если рабочая база 2ТБ, то сколько потребуется на виртуальную машину?

Требования к ресурсам таковы:

RAM: + 1 ГБ для внутреннего гипервизора

Диски -- объём складывается из трёх компонентов:
1) Сама база
2) Transaction Logs (хранятся за 72 часа или как настроите) -- мне оценить сложно, поскольку это зависит от того, сколько операций у Вас выполняется
3) Дифференциальный диск -- я бы принял объём диффдиска в 20...25% от базового диска

Таким образом, для базы в 2ТБ Вам будет комфортно, если выделить 4...5 ТБ, при этом такую большую БД ставить надо по сети, не копируя на внутреннюю машину