Пол Рэндал задал несколько действительно хороших вопросов о передовых методах работы с базами данных SharePoint SQL. Сегодня, помогая клиенту поддерживать установку SharePoint, он задал мне вопрос о лучшей модели восстановления SQL для базы данных SharePoint.
Это моя практика (я не админ БД :)))) использовать простую модель восстановления. Если для баз данных SharePoint выполняется регулярное резервное копирование, и у вас также есть стороннее средство резервного копирования на уровне элементов, вам действительно не нужно хранить все журналы.
Я что-то упустил? Это правильный подход? Вы когда-нибудь использовали журнал базы данных SharePoint для восстановления данных?
Это полностью зависит от того, сколько данных вы готовы потерять по сравнению с объемом необходимых административных усилий. Если вы используете простую модель восстановления и делаете резервные копии раз в неделю по воскресеньям ... если у вас сбой в 11:59 в субботу, вы потеряли неделю работы. Увеличение частоты резервного копирования (или дифференциала) уменьшит объем потери данных.
Делая регулярные полные / дифференциальные резервные копии, но используя модель полного восстановления с журналами транзакций, вы можете восстановить последнюю резервную копию, а затем воспроизвести журналы транзакций на момент времени, непосредственно предшествующий сбою, и практически не потерять данные.
Кстати о Поле Рэндале ... он только что написал отличную статью именно на эту тему для журнала TechNet в этом месяце :) http://technet.microsoft.com/en-us/magazine/dd822915.aspx
Резервное копирование только базы данных НЕ приведет к получению всей информации о вашей точке доступа. Конечно, он получит все, что есть в базе данных, но все настройки и внешний вид будут потеряны. Это может не иметь значения для вас как администратора, но я уверяю вас, что ваши пользователи будут недовольны.
Варианты включают получение агента резервного копирования, который может читать базу данных sharepoint для вашего программного обеспечения резервного копирования, или выполнение нескольких сценариев резервного копирования, которые захватывают информацию о конфигурации и помещают ее, а также резервную копию базы данных SQL в безопасное место.
http://technet.microsoft.com/en-us/library/cc288330.aspx Есть информация.
ПРОВЕРЬТЕ свои резервные копии. Восстановите их. Посмотрите, что меняется, что работает, что нет. Наша первая реставрация была не так хороша, как могла бы быть. К счастью для нас, это была лишь часть процесса создания тестового сервера, который был копией нашего производственного сервера, а не попытка восстановить потерянные или уничтоженные данные.
Отредактировано для актуальности Прочитав это снова, я понял, что отвлекся и пропустил ответ в своем ответе. Если вы делаете полные резервные копии с ведением журнала транзакций, вы можете откатиться к более точным моментам времени. Это требует больше навыков администратора баз данных, но это не так уж и сложно. Если у вас нет тонны обновлений и потеря целого дня работы - это не конец света, то, вероятно, у вас все в порядке. Другие варианты включают более частое выполнение простого резервного копирования. Скажем, полночь, 10:00, 14:00, 18:00 или что-то еще, что подходит для рабочего цикла организации. Это займет больше места на диске, но снизит риски потери данных. Как и все резервные копии, это баланс между тем, что терпят пользователи, и тем, что могут предоставить администраторы.
С Sharepoint следует обращаться как с базой данных SQL, потому что это база данных SQL, поэтому при настройке магазина примите все обычные меры предосторожности при настройке SQL. Что касается резервных копий, вы должны не только регулярно выполнять резервное копирование своих баз данных, вам необходимо создавать резервные копии вашего 12-улья, в котором хранится вся ваша информация SP.
Ознакомьтесь с этой веткой для получения дополнительной информации: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea
Есть некоторые базы данных, которые изначально настроены на простой режим. Например, база данных поиска. Данные поиска хранятся в двух местах: в базе данных и индексном файле в файловой системе сервера. Вам нужны оба, чтобы обслуживать поисковые запросы, и их резервные копии выполняются одновременно, чтобы любая восстановленная версия работала. Поскольку шансы на это очень и очень низкие, большинство людей предпочли бы просто повторно сканировать свой контент и восстанавливать поисковый индекс.
В этом случае простой режим будет работать нормально.