Это мой первый пост DBA.SE, поэтому, пожалуйста, сообщите мне о любых ошибках, спасибо!
Я новый администратор (не ИТ-специалист, просто никто другой в компании не занимается этим), поэтому чем более простое объяснение, тем лучше. Я читал о стратегиях резервного копирования базы данных (или, как я научился их называть, «стратегии восстановления»). Я понимаю, что делают полные, разностные и журналы транзакций, но я хочу знать, почему разностное резервное копирование может быть основано только на самом последнем полном резервном копировании.
Если разностная резервная копия - это все, что изменилось со времени последней полной резервной копии, то почему разностная резервная копия не может быть основана на любой резервной копии по моему выбору? Чтобы быть более понятным, я спрашиваю об указании базы при резервном копировании , а не при восстановлении. Я предполагаю, что при восстановлении вы выбрали бы правильную базу и соответствующий дифференциал для выполнения восстановления (не используя дифференциал, изготовленный из базы B, для восстановления из базы A).
Какова причина, которая препятствует тому, чтобы эта функциональность была возможна? Я полагаю, что должна быть причина, я просто не знаю, что это.
Примечание: я понимаю, что база не может быть указана, но мой вопрос, почему нет ? (Я также не заинтересован в обсуждении "почему бы вам?")
аналогия
Вот аналогия с тем, как я понимаю дифференциальную резервную копию:
У меня есть файл Excel с некоторыми данными в ячейках.
В первый день я делаю копию этого файла и сохраняю его где-то еще («полная резервная копия»).
Во второй день я смотрю на файл и сравниваю его с резервной копией, которую я сделал в первый день, и отмечаю все изменившиеся ячейки и их новые значения («дифференциальная резервная копия»). Я не отмечаю каждое изменение, внесенное в ячейку, только то, каково его окончательное значение. Если бы ячейка А1 начиналась как «Альфред», изменилась на «Бетти», «Чарли», затем «Дейв», я бы только отметил, что «А1 теперь Дейв».
На третий день я снова сравниваю текущий файл с файлом резервной копии и отмечаю изменения (еще одна «дифференциальная резервная копия» с той же базой, что и на второй день). Опять же, отмечая только конечные значения для каждой ячейки за наблюдаемое время, а не все значения, которые были для ячейки в течение дня.
На четвертый день я снова сравниваю и снова замечаю изменения. Продолжая с ячейки A1, теперь она говорит «Сара», даже если в течение дня было 10 других имен, и все, что я отмечаю, это «Теперь А1 - Сара».
На 5-й день мой файл испортился; Итак, я смотрю на резервную копию, которую я сделал в 1-й день, затем окончательные состояния, отмеченные на 4-й день, и применяю изменения, отмеченные к резервной копии, и теперь у меня есть файл, "восстановленный", как это было в 4-й день. Итак, я смотрю на резервную копию, сделанную в 1-й день, вижу, что на 4-й день ячейка A1 завершилась как «Сара», и изменяю резервную ячейку А1 на «Сара».
Почему это имеет значение, если я сделал другую резервную копию («полную») файла на второй день? Почему все еще невозможно сравнить (читай, «сделать разностное резервное копирование») файл в день 3 или 4 с копией, сделанной в день 1? Насколько я понимаю, SQL Server потребовал бы, чтобы я сравнил (при создании другой дифференциальной резервной копии) с полной резервной копией, сделанной на второй день (если она была сделана), - другого варианта нет.
источник
COPY_ONLYЕсли операционная система должна была выполнять регулярное полное резервное копирование в 1-й день иCOPY_ONLYполное резервное копирование в 2-й день, то какие проблемы могут быть вызваны применением более позднего дифференциала из той же базы? на второй день бекап?Функция, которую вы хотите, может существовать в принципе. Это не будет эффективно с текущими структурами базы данных (см. Ответ Макса Вернона). SQL Server должен будет поддерживать набор разностных карт или сравнивать текущее содержимое БД с полной резервной копией, которую вы указали в качестве базы.
Есть приложения, которые дедуплицируют большие файлы. Вы можете сделать две полные резервные копии, и только измененные данные будут фактически сохранены. Это как diff с пользовательской базой.
exdupeнапример, может сделать это.Приятно то, что он работает с любым набором файлов резервных копий. На самом деле, начиная с 3-го полного файла резервной копии, вы будете платить только дополнительное (не дифференциальное) использование пространства. Использование места - это разница с предыдущим файлом резервной копии (не с первым). Дедуплицирующее хранилище имеет похожее поведение.
Почему описанная вами функция не существует? Каждая функция расходует бюджет, в результате чего другие функции отсутствуют. Этот, очевидно, не сделал это достаточно далеко в списке приоритетов. Я не уверен, для чего это будет хорошо. Похоже, довольно эзотерическое требование использовать пользовательские базы.
источник
Не путайте резервные копии журнала транзакций с дифференциальными, они имеют разные цели! То, что вы называете «дифференциальной резервной копией», когда вы « записываете все изменения в ячейки», на самом деле является журналом транзакций .
Целью дифференциальной резервной копии является сохранение небольшого размера полученного файла резервной копии путем записи только информации, которая изменилась со времени последней полной резервной копии, и сохранение времени восстановления в пределах целевого значения времени восстановления (RTO).
А цель журнала резервной копирования транзакций является , чтобы позволить вам повторить транзакции до произвольной точки во время - часто, но , безусловно , не обязательно «самого недавнего ничего , чтобы это произошло».
То, о чем вы говорите, на самом деле возможно, но вам нужно восстановить полную резервную копию, а затем восстановить журналы транзакций.
Если у вас есть полная резервная копия на 1-й день и все резервные копии журнала транзакций между 1-м и 5-м днем, ничто не помешает вам восстановить резервную копию 1-го дня и воспроизводить журнал транзакций до тех пор, пока у вас не будут данные, как это было на 4-й день. также можно начать со резервного копирования на второй день, который будет восстановлен немного быстрее, поскольку вы будете воспроизводить меньше транзакций. Вы также можете восстановить полное резервное копирование на 1-й день, дифференциальное резервное копирование на 3-й день, а затем восстановить журналы транзакций до 4-го дня.
Изменить: ОК, ваша отредактированная аналогия имеет немного больше смысла. Ответ таков: «потому что вы уже можете достичь того, чего хотите, с помощью резервного копирования журнала транзакций». Дифференциальное резервное копирование - это всего лишь дешевый и удобный способ записи целого ряда операций журнала транзакций. Он не предлагает никакой детализации восстановления данных, которую не предлагает резервная копия журнала транзакций. Есть только так много функций, которые предлагают «простое удобство», которые превращают его в продукт.
источник
Давать аналогию с Excel сравнивает яблоки и апельсины. Почему ? Excel не является базой данных, так как ему не хватает целостности данных. Excel является довольно хорошим приложением для работы с электронными таблицами и может дополнять базу данных.
SQL Server - это система реляционных баз данных, которая позволяет вам хранить все ваши данные и предоставляет механизм для их запроса. Важной частью является «Реляционный», так как взаимосвязь данных важна наряду с целостностью данных (свойства ACID).
Основы:
Данные в базе данных организованы в логические компоненты (таблицы, представления, процедуры, триггеры и т. Д.), Которые видны пользователю. Как минимум, база данных также физически реализована в виде двух (файл данных и файла журнала) или более (вторичный файл данных) файлов на диске.
Основываясь на вашей аналогии с Excel, вы применяете то, что изменилось на первое. Это применяет все зафиксированные транзакции из журнала транзакций
with STOP AT(примечание: на 5-й день файл испортился, а вы останавливаетесь на 4-й день)В каждом разделе 4 ГБ (называемом интервалом GAM) каждого файла данных имеется специальная страница базы данных, которая называется дифференциальной битовой картой, которая отслеживает, какие части (называемые экстентами) этого раздела 4 ГБ изменились с момента последнего полного резервного копирования, указывая на данные, которые изменились или были добавлены в базу данных.
Дифференциальное резервное копирование просматривает эти растровые изображения и создает только резервные копии экстентов файлов данных, которые помечены как измененные. Растровые изображения сбрасываются при следующей полной резервной копии (следовательно, дифференциальная резервная копия может основываться только на самой последней полной резервной копии) , поэтому вы можете видеть, что чем больше и больше изменяется база данных, тем больше ее будет отмечаться в дифференциальных битовых картах и последовательные дифференциальные резервные копии будут все больше и больше.
Вы даже можете использовать этот скрипт, чтобы узнать, сколько базы данных изменилось с момента последнего полного резервного копирования? ,
Разностная базовая информация хранится в
masterбазе данных -sys.database_fileили (sys.master_filesполезна, когда база данных доступна только для чтения или автономна).Есть 3 важных столбца, которые хранят информацию, связанную с дифференциальной базой .
differential_base_lsnбаза для дифференциальных резервных копий. Экстенты данных, которые будут изменены после,differential_base_lsnбудут включены в дифференциальную резервную копию.differential_base_guidуникальный идентификатор базовой резервной копии, на которой основана дифференциальная резервная копия.differential_base_timeЭто время, соответствующееdifferential_base_lsnДифференциальное резервное копирование полезно для ускорения RTO (время восстановления = время, необходимое для восстановления вашей базы данных), в отличие от более частых полных резервных копий, которые будут проблемой для больших баз данных или восстановления объема резервных копий журнала транзакций, поскольку они могут стать большими. с течением времени.
Примечание. Полная резервная копия COPY_ONLY не сбрасывает дифференциальную базу, поэтому резервная копия COPY_ONLY не может служить дифференциальной базой.
Ссылки :
источник