Почему так важно сделать резервную копию вашего журнала транзакций?

В настоящее время мы внедряем решение резервного копирования для клиента, а в их решении ERP используется SQL Server.

ERP-решение было создано другой компанией. И они говорят мне, что очень важно сделать резервную копию и обрезать журнал транзакций.

Я немного читал об этом журнале транзакций, и я не понимаю, почему это так важно, когда я все равно выполняю резервное копирование всей машины (мы используем ArcServe UDP, который знает о SQL Server и использует VSS). Насколько я понимаю, задачи очистки на виртуальной машине SQL Server уже занимаются усечением журнала, однако UDP также разрешает усечение журнала SQL Server.

Насколько я понимаю, журнал транзакций можно использовать для восстановления поврежденных баз данных, потому что это журнал всех транзакций. Но у меня уже есть почасовая резервная копия всей базы данных, так что меня это волнует?

Это необходимо сделать только в том случае, если режим восстановления БД установлен на «полный». Если установлено «простое», вам не нужно делать резервную копию журнала транзакций. Но обратите внимание на разницу между этими двумя вариантами!

Прежде всего: если вы хотите иметь возможность восстановить БД в определенный момент времени, вы должны использовать «полный» режим. (Я думаю, вы можете отрегулировать синхронизацию настолько точно, что вы даже сможете указать миллисекунды для точки восстановления). В «простом» режиме вы можете вернуться только к последней полной резервной копии .

Если вы не сделаете резервную копию / усечете свой журнал транзакций, он будет постоянно расти (в полном режиме). Я видел базы данных, где файл .trn был более чем в два раза больше, чем сама база данных. Это зависит от того, как часто были внесены изменения в БД.

Другой момент заключается в том, что резервное копирование журнала обычно выполняется быстрее, чем полное резервное копирование.

Поэтому я думаю, что ваш план резервного копирования для создания полного резервного копирования каждый час не является оптимальным. Но это зависит от вашей ситуации:

Если вы скажете: хорошо, если я смогу восстановить базу данных до последнего полного часа, все в порядке. -> Вы также можете подумать о том, чтобы установить режим восстановления на «простой», если вы хотите хранить полную резервную копию каждый час.

На мой взгляд, лучшей идеей было бы сделать полное резервное копирование рано утром, а затем делать резервное копирование журнала транзакций каждый час. Это должно быть намного быстрее, и вы сможете восстановить в любой момент времени, который вы хотите. А также ваш файл .trn не будет расти слишком сильно ...

Надеюсь это поможет.

Что ж. Вы заботитесь о том, что если у вас установлена ​​полная модель восстановления, и вы не выполняете резервное копирование журнала транзакций, используя резервную копию SQL (а не резервную копию сервера), журнал транзакций продолжает расти до тех пор, пока он не займет все доступное дисковое пространство. (Однажды я видел, как младший коллега установил SQL Server на системный диск и никогда не делал резервных копий журнала транзакций. Он съел Windows .)

Да, это также восстановит к определенному моменту времени также. Вплоть до минуты. Как говорит Twinkles, да, люди бросают столы и тому подобное.

Я не знаю, что вы используете для ежечасного резервного копирования всей базы данных, и если это тот же продукт, что вы используете для всей машины. В этом случае решение для резервного копирования без поддержки SQL не поддерживается для восстановления. Количество времени, которое требуется VSS для копирования файлов MDF и LDF, может привести, например, к внутреннему несоответствию временных меток.

Мы также управляем несколькими системами ERP. И проблема часто в том, что ночью часто выполняются пакетные задания, которые синхронизируют данные с другими системами. И они занимают иногда час или больше. Итак, что вы хотите сделать в случае сбоя, это перейти к точке, где у вас есть согласованные данные. (Это означает право между двумя пакетными заданиями.) Если вы посмотрите только на время, вы не всегда точно знаете, каково было состояние базы данных в это время.

Но, конечно, это зависит от ситуации. Если у вас нет автоматических заданий и т. Д., Вы можете полностью справиться с почасовым резервным копированием.

Есть несколько причин, почему вы хотите сделать это:

1. Система базы данных обычно занята, возможно, выполняет тысячи транзакций в секунду. Данные могут быть распределены по нескольким файлам в разных файловых системах. Нетрудно убедиться, что после восстановления база данных находится в согласованном (можно использовать) состоянии. Если ваше решение для резервного копирования соответствует поставленной задаче, отлично, но вам лучше быть в этом уверенным, прежде чем ставить свою работу на него.
2. Пример: кто-то по ошибке выбрасывает таблицу с важными данными. Если у вас есть резервная копия базы данных с возможностью восстановления на определенный момент времени, вы можете быстро восстановить данные без необходимости восстановления всей системы.
3. Если база данных находится в режиме полного восстановления, журнал транзакций SQL Server будет расти. Место хранения в журнале транзакций используется повторно только в том случае, если для журнала транзакций было выполнено резервное копирование. Если вы не будете регулярно выполнять резервное копирование журнала транзакций, ваша файловая система будет заполняться до тех пор, пока не останется свободного места. В этот момент все сразу остановится , поскольку новые транзакции не могут быть запущены.

Когда ваша база данных выходит за рамки того, что вы можете сделать за час, вам нужна другая модель.

Полная резервная копия вашей базы данных будет урезать ваши журналы, но она должна быть «осведомлена о SQL», потому что в этом случае именно программное обеспечение для резервного копирования сообщает SQL-серверу, что оно скопировало и что нужно усечь.

Как отмечают другие, если у вас есть база данных в модели «полного» восстановления, ее журнал транзакций будет расти бесконечно, пока вы не создадите резервную копию с поддержкой полного SQL.

Восстановление - действительно проблема здесь, не Резервное копирование. И это не техническое решение, это бизнес-решение!

Если владельцы вашего бизнеса согласны с потерей часа или более транзакций с базой данных (что может быть ОЧЕНЬ сложно или невозможно повторить!), Тогда ваша модель работает. Если они в порядке, когда система не работает в течение нескольких часов, пока вы восстанавливаете всю базу данных из резервной копии, тогда ваша модель работает.

Однако, если ваш бизнес рассматривает свою ERP-систему в качестве критически важного актива для своей работы (не все ли они?), То установление максимально приемлемого времени восстановления (т.н. RTO, время восстановления цели) для ваших критически важных услуг будет бизнес-решением.

Кроме того, владельцы бизнеса или заинтересованные стороны системы должны определить, сколько данных они готовы потерять в результате инцидента, или RPO (цель восстановления точки).

Если вы спросите их, ответ может быть следующим: «НЕТ данных может быть потеряно! Система ERP должна быть доступна 24/7/365!» ... что, как мы все знаем, вряд ли будет экономически эффективным. Если вы представите им стоимость, связанную с созданием такой полностью бесперебойной системы, они получат более разумную цифру ..;)

Дело в том, что если вы можете избежать потери каких-либо транзакций, вы сохраняете свой бизнес потенциально на сотни или тысячи потерянных рабочих часов. Это составляет ОГРОМНУЮ экономию в любой компании и растет с ростом вашей компании ...

У всех были отличные ответы на это, но я хотел бы добавить еще одну важную заметку ... или две.

Знание особенностей моделей восстановления SQL Server и ваших бизнес-требований к потере данных очень важно; однако в этом случае вам необходимо понять, как ваш продукт резервного копирования работает с SQL Server. (Судя по комментариям выше, создается впечатление, что вы выполняете резервное копирование томов дисков с помощью копии VSS, что означает, что резервные копии SQL Server могут или не могут потребоваться дополнительно.)

После того, как вы недавно оценили аналогичный продукт, вы можете задать следующие важные вопросы:

• Как выполняется восстановление к моменту времени для базы данных в полном восстановлении?
• Как обрабатывается первоначальное резервное копирование для новой базы данных при полном восстановлении?
• Требует ли продукт резервного копирования резервного копирования журналов SQL Server для восстановления на определенный момент времени? (В моем случае ответ был да.)
• Может ли ваша инфраструктура хранения обрабатывать объем данных для копий / различий VSS (с заданным интервалом) в дополнение к обычной загрузке SQL?

Надеюсь, это полезно.

Опыт, полученный моей командой с нашей недавней оценкой, дал несколько очень интересных ответов на вышеуказанные вопросы. Одно можно сказать наверняка, резервное копирование является более сложным для нас с продуктом резервного копирования VSS.

Как уже говорили многие другие, если вы используете стороннее средство для резервного копирования / создания моментального снимка либо виртуальной машины, либо хранилища, вы все равно рискуете не иметь правильной резервной копии. Все сторонние инструменты, которые управляют резервным копированием SQL Server, будут внедряться и подключаться к SQL Server с использованием VSS. Это делается для того, чтобы запросить SQL Server приостановить все операции ввода-вывода в файлах данных, чтобы можно было сделать согласованный снимок. Если нет, то вы можете иметь много транзакций в различных состояниях, и восстановление не будет знать, могут ли эти транзакции быть перенесены вперед или назад.

Я не работал со всеми сторонними инструментами моментальных снимков VM / Storage, но те, с которыми я работал, никогда не могли создавать моментальные снимки хранилища, в котором находились системные базы данных - SQL Server не может отключить эти базы данных. ВСЕ они выполняли резервное копирование этих баз данных в потоковом режиме - то есть ... с помощью команд BACKUP DATABASE и последующего захвата самого файла резервной копии.

Вдобавок ко всему, как уже говорили многие, если вы работаете в модели полного восстановления и не выполняете операторы BACKUP LOG регулярно, журнал транзакций будет продолжать расти до тех пор, пока на диске не останется свободного места.

Реальный вопрос, который вам нужно задать, и я, возможно, пропустил его выше ... успешно ли вы восстанавливались из этих резервных копий несколько раз и довольны ли вы последовательностью данных в этих восстановлениях. Лично, даже этого было бы недостаточно для меня, это все еще похоже на бросок костей, и это не то, что хороший администратор баз данных никогда не принимает, когда дело доходит до резервного копирования и восстановления.

Признайте, что журналы транзакций - это не просто механизм восстановления. Правильное ведение журнала также может играть важную роль в общей производительности базы данных (т. Е. Пропускной способности транзакций).

Частое резервное копирование файлов журналов делает несколько вещей:

1. Это уменьшает количество VLF в файлах физического журнала, что хорошо для производительности.
2. Вы лучше подготовлены к использованию резервных копий журналов в том случае, если вам нужно восстановить базу данных.
3. Это немного быстрее, чем полная резервная копия

Если вам удастся выполнить ежечасное полное резервное копирование, тогда вы не уверены, сколько вы выиграете от более частого резервного копирования журналов. В конце концов, насколько я понимаю, полное резервное копирование также создаст резервные копии журнала, необходимого для полного восстановления.

С другой стороны, если ваше приложение генерирует тонны транзакций между вашими ежечасными полными резервными копиями, это может объяснить, почему оригинальные разработчики предлагали более детальное обслуживание журналов. Много транзакций может увеличить количество VLF в ваших журналах, что может привести к снижению производительности, пока журнал не будет усечен. Я видел это как «запрос истек срок ожидания» в приложении (незадолго до зависания).

Рекомендации, связанные с ведением журнала транзакций, очень хорошо описаны в этой статье. 8 шагов к лучшей пропускной способности журнала транзакций . Кроме того, в этой статье « Советы по эффективному ведению базы данных» упоминается несколько произвольное число VLF, чтобы стремиться к (<200), что мне очень помогло.

Другие люди уже указали большинство причин для резервного копирования и т. Д. Похоже, есть некоторые сомнения относительно того, почему это хорошая стратегия, когда вы уже делаете резервную копию сервера.

У меня есть пара веских причин, которые не выше. Что делать, если стороннему приложению не удается создать резервную копию, которую можно восстановить? Вы пытались восстановить резервную копию? Как насчет нового сервера, который вы только что создали из ваших шаблонов (подумайте о DR)? Как насчет другого сервера в вашем домене, который имеет другое сопоставление? или экземпляр SQL?

Я беру избыточные резервные копии только по той причине, что иногда стороннее приложение не является самым быстрым способом восстановления. Иногда хранилище, в которое сохраняет стороннее приложение, также затрагивается или повреждено по собственным причинам.