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