Какова ваша лучшая практика Модель восстановления для баз данных SharePoint


9

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

Это моя практика (я не администратор БД :)))) использовать модель простого восстановления. Если резервные копии баз данных SharePoint выполняются на регулярной основе, а у вас также есть резервная копия стороннего инструмента на уровне элементов, вам действительно не нужно хранить все журналы.

Я что-то здесь упускаю? Это правильный подход? Вы когда-нибудь использовали журнал базы данных SharePoint для восстановления ваших данных?

Ответы:


8

Это полностью зависит от того, сколько данных вы готовы потерять в зависимости от объема административных усилий. Если вы используете простую модель восстановления и делаете резервные копии раз в неделю по воскресеньям ... если у вас сбой в 11:59 в субботу, значит, вы потеряли неделю работы. Увеличение частоты резервного копирования (или получение различий) уменьшит количество потери данных.

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

Говоря о Поле Рэндале ... он только что написал отличную статью именно на эту тему для журнала TechNet в этом месяце :) http://technet.microsoft.com/en-us/magazine/dd822915.aspx


Лора добавляет очень хороший момент ... Я ответил на вопрос как заданный вопрос, но лучшим вопросом может быть «Каков наилучший способ резервного копирования SharePoint?» Если вы просто делаете резервные копии SQL Server, вам придется заново создать базу данных конфигурации и заново присоединить ваши базы данных контента. Если вы используете приложение резервного копирования с поддержкой SharePoint, такое как Data Protection Manager ( microsoft.com/dpm ), оно позаботится о резервном копировании базы данных (включая конфигурационную базу данных) и все равно позволит вам выполнять восстановление SharePoint на определенный момент времени. , Намного проще, чем делать все вручную.
Шон Эрп

Резервное копирование - еще один вопрос, о котором мы могли бы спорить. DPM - это хорошо, но это не решение для малого и среднего бизнеса. Что бы вы порекомендовали для фермы с одним сервером (небольшой бизнес)? бекап стсадм, симантек или еще что?
Тони Франкола

1
К сожалению, история резервного копирования SharePoint имеет больше «это зависит», чем любой другой продукт, с которым я работал. Мы говорим о резервном копировании на уровне фермы? Аварийное восстановление? Резервное копирование семейства сайтов? Резервное копирование сайта? Ресурсный центр резервного копирования SharePoint на TechNet имеет несколько отличных ресурсов, которые помогут вам решить, какой инструмент использовать для резервного копирования, какой аспект SharePoint. Пока вы не возражаете против переконфигурирования всего в базе данных конфигурации (у вас есть это задокументировано, верно?), Резервное копирование SQL баз данных контента будет работать нормально для защиты фермы в целом.
Шон Эрп


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

5

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

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

http://technet.microsoft.com/en-us/library/cc288330.aspx Имеет некоторую информацию.

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

Отредактировано для релевантности. Прочитав это снова, я поняла, что отвлеклась и пропустила точку ответа моего ответа. Если вы выполняете полное резервное копирование с ведением журнала транзакций, вы можете вернуться к гораздо более точным моментам времени. Это требует больше навыков в качестве администратора, но это не так сложно. Если у вас нет тонны обновлений и потеря целого дня работы не конец света, то вы, вероятно, в порядке. Другие варианты включают запуск простого резервного копирования чаще. Скажем, полночь, 10:00, 14:00, 18:00 или все, что работает для рабочего цикла организации. Это израсходует больше диска, но уменьшит риски потери данных. Как и во всех резервных копиях, это баланс между тем, что будут терпеть пользователи, и тем, что могут предоставить администраторы.


Я полностью согласен с тобой. Что вы используете для резервного копирования?
Тони Франкола

Мы используем Symantec NetBackup. Мы находимся в процессе приобретения агента SharePoint. В настоящее время мы делаем двухэтапное резервное копирование.
Лора Томас

2

Sharepoint нужно рассматривать как базу данных SQL, потому что это база данных SQL, поэтому при настройке магазина примите все ваши обычные меры предосторожности при настройке SQL. Что касается резервных копий, вы должны не только регулярно создавать резервные копии своих баз данных, но и делать резервные копии своего 12-го улья, который содержит всю информацию о SP.

Проверьте эту тему для получения дополнительной информации: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea


Не уверен, почему это было отклонено ... SQLChicken является правильным, за исключением SSP. Это требует особой осторожности и кормления из-за поисковых индексов, которых нет в SQL Server.
Джефф

2
Мне бы очень хотелось, чтобы ServerFault заставлял людей оставлять комментарии, если они понизили голос ...
SQLChicken

0

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

В этом случае простой режим будет работать просто отлично.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.