В настоящее время мы внедряем решение для резервного копирования для клиента, и его решение ERP использует SQL Server.
Решение ERP было создано другой компанией. И Oни говорят мне, что очень важно создать резервную копию и усечь журнал транзакций.
Я немного прочитал этот журнал транзакций и не понимаю, почему это так важно. когда я все равно создаю резервную копию всей машины (Мы используем ArcServe UDP, который знает о SQL Server и использует VSS). Насколько я понимаю, задачи очистки на виртуальной машине SQL Server уже заботятся об усечении журнала, однако UDP также позволяет усечение журнала SQL Server.
Насколько я понимаю, журнал транзакций можно использовать для восстановления поврежденных баз данных, потому что это журнал всех транзакций. Но у меня уже есть ежечасная резервная копия всей базы данных, так зачем мне это?
Вам нужно сделать это только в том случае, если ваш режим восстановления БД установлен на «полный». Если он установлен на «простой», вам не нужно делать резервную копию журнала транзакций. Но обратите внимание на разницу между этими двумя вариантами!
Прежде всего: если вы хотите иметь возможность восстановить БД в конкретный момент времени вы должны использовать «полный» режим. (Я думаю, вы можете настроить время настолько точно, что вы даже можете указать миллисекунды для точки восстановления) В «простом» режиме вы можете вернуться только к последней полной резервной копии..
Если вы не сделаете резервную копию / не усечете журнал транзакций, он будет постоянно расти (в полном режиме). Я видел базы данных, в которых файл .trn был более чем в два раза больше, чем сама база данных. Это зависит от того, как часто вносились изменения в БД.
Другой момент заключается в том, что резервное копирование журнала обычно выполняется быстрее, чем полное резервное копирование.
Поэтому я думаю, что ваш план резервного копирования, предусматривающий создание полной резервной копии каждый час, не является оптимальным. Но это зависит от вашей ситуации:
Если вы скажете: хорошо, если я смогу восстановить БД до последнего полного часа, все в порядке. -> Вы также можете подумать о настройке режима восстановления на «простой», если хотите сохранять полную резервную копию каждый час.
На мой взгляд, лучше было бы сделать полную резервную копию рано утром, а затем делать резервную копию журнала транзакций каждый час. Это должно быть намного быстрее, и вы сможете восстановить данные в любой момент времени. А также ваш .trn файл не будет слишком сильно расти ...
Надеюсь это поможет.
Хорошо. Вы заботитесь, потому что, если ваша модель восстановления установлена на полную, и вы не создаете резервную копию журнала транзакций с помощью резервной копии SQL (а не резервной копии сервера), журнал транзакций продолжает расти, пока он не займет все доступное дисковое пространство. (Однажды я видел, как более мелкий коллега установил SQL Server на системный диск и никогда не создавал резервную копию журнала транзакций. ел Windows.)
Да, он также будет восстановлен до определенного момента времени. До минуты. Как говорит Твинклз, да, люди бросают столы и тому подобное.
Я не знаю, что вы используете для ежечасного резервного копирования всей базы данных, и если это тот же продукт, что и для всей машины. В этом случае решение для резервного копирования без поддержки SQL не поддерживается для восстановления. Например, количество времени, которое требуется VSS для копирования файлов MDF и LDF, может вызвать несоответствие внутренних меток времени.
Мы также управляем несколькими системами ERP. И проблема часто заключается в том, что ночью часто выполняются длительные пакетные задания, которые синхронизируют данные с другими системами. Иногда они занимают час или больше. Итак, что вы хотите сделать в случае сбоя, это перейти к точке, где у вас есть согласованные данные. (Что означает прямо между двумя пакетными заданиями.) Если вы посмотрите только на время, вы не всегда можете точно знать, каков был статус базы данных в это время.
Но, конечно, это зависит от ситуации. Если у вас нет автоматических заданий и т. Д., Вы можете полностью справиться с ежечасным резервным копированием.
Есть несколько причин, по которым вы хотите это сделать:
Когда ваша база данных выходит за рамки того, что вы можете создать за час, вам понадобится другая модель.
Полная резервная копия вашей базы данных усечет ваши журналы, но она должна быть «осведомлена о SQL», потому что в этом сценарии именно программа резервного копирования сообщает SQL-серверу, что было скопировано, а что обрезать.
Как отмечают другие, если у вас есть база данных в модели восстановления «Полное», ее журнал транзакций будет бесконечно увеличиваться, пока вы не сделаете полную резервную копию с учетом SQL.
Восстановление действительно проблема здесь, а не в резервном копировании. И это не техническое решение, это бизнес-решение!
Если владельцы вашего бизнеса согласны с потерей часа или более транзакций своей базы данных (что может быть ОЧЕНЬ сложно или невозможно повторить!), Тогда ваша модель работает. Если они согласны с тем, что система не работает в течение нескольких часов, пока вы восстанавливаете всю базу данных из резервной копии, то ваша модель работает.
Однако, если ваш бизнес считает свою ERP-систему критически важным активом для своей работы (не так ли?), То установление максимально допустимого времени восстановления (также известного как RTO, целевое время восстановления) для ваших критически важных услуг будет бизнес-решением.
Кроме того, владельцы бизнеса или заинтересованные стороны системы должны определить, сколько данных они готовы рисковать потерять в случае инцидента, также известного как RPO (цель точки восстановления).
Ответ, если вы их спросите, может быть таким: «Данные не могут быть потеряны! Система ERP должна быть доступна 24/7/365!» ... который, как мы все знаем, вряд ли будет рентабельным. Если вы представите им стоимость, связанную с построением такой полностью резервированной, непрерывной системы, они предложат более разумную цифру ..;)
Дело в том, что если вы можете избежать потери каких-либо транзакций, вы сэкономите своему бизнесу потенциально сотни или тысячи потерянных рабочих часов. Это дает ОГРОМНУЮ экономию в любой компании и растет вместе с размером вашей компании ...
У всех были отличные ответы на это, но я хотел бы добавить еще одно важное замечание ... или два.
Знание особенностей моделей восстановления SQL Server и требований вашего бизнеса в отношении потери данных очень важно; Однако в этом случае вам обязательно нужно понимать, как ваш продукт резервного копирования работает с SQL Server. (Судя по комментариям выше, похоже, что вы выполняете резервное копирование томов дисков с помощью копии VSS, что означает, что резервное копирование SQL Server может потребоваться, а может и не потребоваться.)
После недавней оценки аналогичного продукта вам, возможно, придется задать несколько важных вопросов:
Надеюсь, это будет полезно.
Опыт, полученный моей командой в ходе недавней оценки, дал несколько очень интересных ответов на поставленные выше вопросы. Одно можно сказать наверняка: резервное копирование для нас сложнее с продуктом резервного копирования VSS.
Как уже говорили многие другие, если вы используете сторонний инструмент для резервного копирования / создания моментального снимка виртуальной машины или хранилища, вы все равно рискуете не иметь действительной резервной копии. Все сторонние инструменты, которые управляют резервным копированием SQL Server, будут реализовывать и подключаться к SQL Server с помощью VSS. Это делается для того, чтобы SQL Server приостановил все операции ввода-вывода для файлов данных, чтобы можно было сделать согласованный моментальный снимок. В противном случае у вас может быть много транзакций в различных состояниях, и при восстановлении не будет известно, можно ли выполнить откат этих транзакций вперед или назад.
Я не работал со всеми сторонними инструментами для создания моментальных снимков виртуальных машин / хранилищ, но те, с которыми я работал, никогда не могли создавать моментальные снимки хранилища, в котором были расположены системные базы данных - SQL Server не может стабилизировать эти базы данных. Они ВСЕ создавали резервные копии этих баз данных в потоковом режиме - то есть ... выполняя команды BACKUP DATABASE, а затем создавая сам файл резервной копии.
Вдобавок ко всему, как многие также сказали, если вы используете модель ПОЛНОГО восстановления и не выполняете регулярно операторы BACKUP LOG, журнал транзакций будет продолжать расти, пока на диске не останется места.
Настоящий вопрос, который вам нужно задать, и я, возможно, пропустил его выше ... успешно ли вы восстанавливались из этих резервных копий несколько раз и довольны ли вы согласованностью данных в этих восстановлениях. Лично для меня даже этого было бы недостаточно, это все равно похоже на бросок кубика, а хороший администратор баз данных никогда этого не делает, когда дело касается резервного копирования и восстановления.
Помните, что журналы транзакций - это не просто механизм восстановления. Правильное ведение журнала также может играть важную роль в общей производительности базы данных (т. Е. Пропускной способности транзакций).
При частом резервном копировании файлов журнала выполняется несколько вещей:
Если вы можете делать полное резервное копирование ежечасно, то я не уверен, насколько вы выиграете от более частого резервного копирования журналов. В конце концов, как я понимаю, полная резервная копия также будет резервировать столько журнала, сколько необходимо для обеспечения полного восстановления.
С другой стороны, если ваше приложение генерирует множество транзакций между вашими почасовыми полными резервными копиями, это может объяснить, почему исходные разработчики предлагали более детальное обслуживание журналов. Количество транзакций может увеличить количество VLF в ваших журналах, что может привести к снижению производительности до тех пор, пока журнал не будет усечен. Я видел это как "истекло время ожидания запроса" ошибка в приложении (незадолго до зависания).
Рекомендации по ведению журнала транзакций очень хорошо описаны в этой статье. 8 шагов к увеличению пропускной способности журнала транзакций. Кроме того, эта статья Основные советы по эффективному обслуживанию базы данных упоминает несколько произвольный подсчет VLF для достижения (<200), который мне очень помог.
Другие люди уже привели большинство причин для резервного копирования транслогов и т. Д. Кажется, есть некоторые сомнения относительно того, почему это хорошая стратегия, когда вы уже резервное копирование сервера.
Для меня появилось несколько веских причин, которые не указаны выше. Что делать, если стороннему приложению не удается создать резервную копию, которую можно восстановить? Вы пробовали восстановить резервную копию? А как насчет нового сервера, который вы только что построили из своих шаблонов (подумайте о DR)? А как насчет другого сервера в вашем домене с другим параметром сортировки? или экземпляр SQL?
Я беру избыточные резервные копии без всякой причины, кроме случаев, когда ваше стороннее приложение - не самый быстрый способ восстановления. Иногда хранилище, в которое сохраняет ваше стороннее приложение, тоже влияет или повреждено по своим причинам.