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