Я пытаюсь убедить клиента, что его стратегия резервного копирования SQL Server недостаточна. Короче говоря, их текущая «стратегия» резервного копирования - это еженедельное полное резервное копирование с последующим ежедневным резервным копированием журнала транзакций. Я уже советовал клиенту из-за размера базы данных переключиться на стратегию ежедневного полного резервного копирования, сопровождаемую несколькими ежедневными резервными копиями журнала транзакций, или, по крайней мере, добавить ежедневную дифференциальную резервную копию к тому, что у них уже есть. Однако они возятся с этим, потому что для этого потребуется гораздо больше места на диске, чем у них уже есть. Итак, мой вопрос: какие потенциальные проблемы или риски могут быть представлены для стратегии резервного копирования, которая представляет собой только еженедельное полное резервное копирование и ежедневное резервное копирование журнала транзакций? В основном ли дело в том, что восстановление базы данных может занять часы или дни, потому что восстановление t-log должно повторно запускать каждую транзакцию после восстановления полной резервной копии?
Вот спецификации базы данных для определения размеров и контекста активности:
Их стратегия резервного копирования не должна определяться вашим мнением, она должна определяться их целевой точкой восстановления и целевым временем восстановления. Обсудите это с клиентом, а затем реализуйте стратегию резервного копирования, которая отвечает этим целям.
При этом я был бы очень удивлен, если бы восстановление базы данных и журналов транзакций указанного количества и размера заняло бы больше, чем некоторое количество минут. Конечно, это не займет часы или дни.
Больше всего меня беспокоят резервные копии журналов транзакций. Если бы они потеряли базу данных за пять минут до запланированного резервного копирования t-log, они могли бы потерять почти 24 часа данных.
Более частое резервное копирование журнала не должно занимать много места - транзакций больше не будет. Это должно просто позволить лучшую точку восстановления.
(Нет, на восстановление базы данных размером 12,5 ГБ потребуется несколько дней.)
Основное преимущество дифференциации в этой ситуации состоит в том, что вы можете начать находить количество файлов резервных копий журнала слишком громоздким. Если они выполняют еженедельное полное и ежечасное резервное копирование журнала транзакций, это 24 файла в день. Если они потеряют свою базу данных за пять минут до полной и пятьдесят пять минут после последней резервной копии журнала, они могут потерять пятьдесят пять минут и потребуются 167 резервных копий журнала (я предполагаю, что это разные файлы). С ночным дифференциалом им нужно всего 23.
(Если они решат, что 55 минут - это слишком много, чтобы их терять, чаще делайте резервную копию журнала транзакций и соответственно умножайте количество файлов.)