Просто интересно, какие у вас есть процессы резервного копирования.
В настоящее время я выполняю еженедельное полное резервное копирование базы данных с ежедневным дифференциальным резервным копированием.
Насколько я понимаю, при такой настройке разница между режимом полного восстановления и простым режимом восстановления заключается в том, что в режиме полного восстановления я смогу использовать журналы транзакций для отката моей БД к определенному моменту времени, применив последнюю версию дифференциальное резервное копирование.
Предполагая, что в моем сценарии последняя дифференциальная резервная копия служит моей последней и конечной «точкой сохранения», я не вижу необходимости откатывать мою БД еще дальше, используя журналы. Это подводит меня к моему вопросу: есть ли какие-либо дополнительные преимущества от использования режима полного восстановления для моего текущего процесса резервного копирования?
Как правило, при определении стратегии резервного копирования необходимо учитывать два фактора. Целевое значение точки восстановления (RPO) и целевое время восстановления (RTO).
Цель восстановления времени
Я вообще не буду описывать RTO, поскольку это касается зеркального отображения / кластеризации базы данных, где вы храните свои резервные копии и т. Д. Однако имейте в виду, сколько времени вам потребуется, чтобы вернуть сервер в рабочее состояние после сбоя, например. возвращение лент на место, получение нового сервера, восстановление сервера и т. д. RPO и RTO - это две цифры, о которых вы должны сообщить бизнесу, и вам следует регулярно их тестировать.
Цель восстановления
Целевая точка восстановления - это момент времени, на который нужно восстановить базу данных.
Полный против простого
Если вам нужно выполнить восстановление до определенного момента времени, вам необходимо перейти в режим полного восстановления и резервное копирование журнала транзакций. В противном случае вы сможете восстановить только до точки последней полной или дифференциальной резервной копии.
Даже при том, что большинство компаний говорят, что потеря данных еженедельно или 4 часа приемлема. Когда вы попадаете в такую ситуацию, чаще всего это не так. Поэтому я всегда выполняю полное восстановление с резервными копиями журнала транзакций.
Полное восстановление
Как правило, я делаю еженощное полное резервное копирование большинства своих баз данных. Я также делаю дифференциалы каждые 4 часа и журналы транзакций каждые 15 минут. Если размер дифференциальной резервной копии начинает превышать размер полной резервной копии. Пора чаще делать полные резервные копии.
Если размер вашей разностной резервной копии начинает превышать размер полной резервной копии. Пора сделать полное резервное копирование, поскольку вы теряете все преимущества дифференциального резервного копирования с точки зрения скорости восстановления.
Самая большая проблема с полным восстановлением заключается в том, что у вас всегда должна быть последняя полная резервная копия в наборе, из которой можно будет выполнить восстановление. Если кто-то выполняет резервное копирование базы данных вручную и не сохраняет резервную копию, он сломает ваш набор, и вы не сможете восстановить без него. (используйте резервную копию только с копией)
Кроме того, если вы выполняете полное восстановление, вы делаете резервные копии журнала транзакций, иначе ваши файлы журнала станут неуправляемыми.
Восстановление
Для восстановления в режиме полного восстановления вам необходимо. Последняя полная резервная копия, ближайшая к вашей точке восстановления, затем ближайшая резервная копия различий, затем вам нужно выполнить повтор транзакций для каждого журнала транзакций, чтобы добраться до нужного момента времени.
Процесс восстановления намного сложнее, но оно того стоит. Поскольку вы можете восстановить точный момент времени, когда разработчик отправил удалить все в базу данных.
Итак, чтобы ответить на вопрос, «Полное восстановление» определенно стоит дополнительных усилий, потому что вы будете благодарны за возможность восстановления на определенный момент времени для различных ситуаций. Особенно, если у вас произошел серьезный сбой непосредственно перед финансовым процессом окончания месяца.
Что ж, если вы не сохраняете журналы, лучшее, что вы можете сделать, это откатиться к последней разнице.
Обычно я делаю резервную копию журнала транзакций с гораздо более короткими интервалами (может быть, каждые 15 минут или около того). Это не дает мне потерять много данных в худшем случае (машина сгорит дотла). Это очень легкая операция, поэтому ее можно выполнять в режиме онлайн с минимальным воздействием.
Как правило, вам следует использовать только режим полного резервного копирования, и вам следует часто создавать резервные копии журнала транзакций, если только вы не можете позволить себе потерять данные за целый день, а это то, чему вы сейчас подвержены.
В размер базы данных играет большую роль в дифференциальном резервном копировании журналов транзакций. В очень большой базе данных время, необходимое для выполнения дифференциального или полного резервного копирования, будет превышать требования к частоте резервного копирования базы данных. Например, во многих местах я видел сочетание ночного разностного, почасового журнала транзакций и еженедельного полного резервного копирования.
Возможность восстановления на определенный момент времени или контрольную точку - еще одна причина того, что резервные копии журналов транзакций полезны. Если я правильно помню, эта функция недоступна для дифференциальных резервных копий.
В небольшой базе данных время разницы по сравнению с базой данных журнала транзакций может быть менее значительным, что может быть причиной того, что вы не видите это дополнительное значение. У вас также могут быть более простые требования к обслуживанию.
Для получения экспертной информации по этому поводу ознакомьтесь со всем на Блог Пола Рэндала о резервном копировании и журналах транзакций. Каждая ситуация индивидуальна, и только вы можете решить, что вам нужно. Изучите себя, а затем выберите, что будет работать для восстановления данных, которое вам нужно, и насколько допустима потеря данных.
В случае, например, данных конфигурации (т.е. нет данных пользователя, только параметры конфигурации) вы можете использовать простую резервную копию, чтобы избавиться от необходимости вести журналы транзакций.