Резервное копирование и восстановление приложения службы поиска в sharepoint с помощью vss

Перед началом работы

Восстановление конфигурации уровня фермы выполняется только после сбоя, затрагивающего базу данных конфигурации, но не другие данные фермы, такие как база данных содержимого или веб-приложение. Если восстановление конфигурации фермы не решило проблемы, следует восстановить ферму полностью. Дополнительные сведения о восстановлении всей фермы см. в статье Restore farms in SharePoint Server. Можно восстановить конфигурацию из резервной копии фермы, для которой использовался параметр Копировать содержимое и параметры конфигурации или Копировать только параметры конфигурации.

Примечание.

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

Основы Windows PowerShell

В отличие от большинства других средств командной строки, которые принимают и возвращают текстовые данные, Windows PowerShell основано на платформе Microsoft .NET Framework и поэтому принимает и возвращает объекты .NET Framework. Это фундаментальное отличие позволяет создавать новые методы и средства для улучшения управления, эффективности и производительности разработчиков и администраторов.

Windows PowerShell — это простое средство командной строки, в котором вводится понятие командлета. Командлет — это сочетание глагола и существительного, представляющих команду и объект, к которому она применяется. Имена командлетов Windows PowerShell состоят из глаголов и существительных, разделенных дефисом (-), которые определяют функциональные свойства командлета. Например, имя командлета Get-SPSite содержит глагол (команду) «Get» и существительное (объект) «SPSite» для обозначения командлета, который получает указанный объект SPSite. Командлеты можно использовать отдельно или объединять их в связанные последовательности для выполнения сложных задач.

Существительные командлетов принимают параметры в виде пар имени и значения, которые определяют существительное командлета. При вызове командлетов они возвращают выходные объекты. Эти объекты также содержат свойства, которые отображаются в виде пар имени и значения. Так как командлеты возвращают объекты, их можно передавать (или «ставить в конвейер») другим командлетам в последовательности. Таким образом командлеты можно объединять, что дает невероятную гибкость при их использовании.

К слову, это только одно из отличий командлетов Windows PowerShell и команд stsadm.exe. Например, следует запомнить, что командлет — это не исполняемый файл, а, скорее, экземпляр класса .NET Framework. Поэтому, с некоторыми исключениями, командлеты возвращают объекты, а не текстовые потоки, и они обрабатывают входные объекты из конвейера.

Как видно, Windows PowerShell — это не просто новое средство командной строки

Также, что более важно, это новый язык скриптов. Windows PowerShell устанавливает более 100 базовых командлетов Windows

Библиотека командлетов SharePoint Foundation, которая на данный момент содержит более 500 командлетов, устанавливается в дополнение к основным командлетам Windows. Доступ к командлетам SharePoint предоставляется с помощью специальной оболочки командной консоли SharePoint.

Наблюдение

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

  • С помощью мониторинга DPM по умолчанию можно настроить уведомления для упреждающего мониторинга с помощью публикации оповещений и настройки уведомлений. Вы можете отправлять по электронной почте уведомления для критических, предупреждающих и информационных оповещений, а также о состоянии работающих процессов восстановления.

  • При использовании Operations Manager вы можете публиковать оповещения централизованно.

Настройка уведомлений мониторинга

  1. В консоли администрирования DPM выберитеПараметрыдействий>мониторинга>.

  2. Выберите SMTP-сервер, введите имя сервера, порт и электронный адрес, с которого будут отправляться уведомления. Адрес должен быть допустимым.

  3. В поле Smtp-сервер с проверкой подлинности введите имя пользователя и пароль. Имя пользователя и пароль должны быть именем учетной записи домена пользователя, адрес которого «From» описан на предыдущем шаге. в противном случае доставка уведомлений завершается ошибкой.

  4. Чтобы проверить параметры SMTP-сервера, выберите Отправить тестовую электронную почту, введите адрес электронной почты, по которому DPM будет отправлять тестовое сообщение, и нажмите кнопку ОК. Выберите Параметры>Уведомления и укажите типы оповещений, о которых необходимо уведомлять получателей. В поле Получатели введите адрес электронной почты каждого получателя, которому DPM будет отправлять копии уведомлений.

Публикация оповещений Operations Manager

  1. В консоли администрирования DPM выберитеПараметры>действия>мониторинга>Публикация>оповещений Публикация активных оповещений

  2. После включения публикации оповещений все существующие оповещения DPM, которые могут потребовать действий пользователя, публикуются в журнале событий оповещений DPM . Затем агент Operations Manager, установленной на сервере DPM, публикует эти оповещения в Operations Manager и продолжает обновлять консоль при создании новых оповещений.

Изменение интерфейсного веб-сервера

В следующей процедуре используется пример фермы серверов с двумя интерфейсными веб-серверами: Server1 и Server2. DPM использует Server1 для защиты фермы. Вам нужно изменить интерфейсный веб-сервер, используемый DPM, на Server2, чтобы удалить из фермы сервер Server1.

Примечание

Если интерфейсный веб-сервер, используемый DPM для защиты фермы, недоступен, для его изменения используйте следующую процедуру, начиная с шага 4.

Изменение интерфейсного веб-сервера, используемого DPM для защиты фермы

  1. Остановите службу записи VSS SharePoint на сервере Server1, выполнив следующую команду в командной строке:

    stsadm -o unregisterwsswriter

  2. На Server1 откройте редактор реестра и перейдите к следующему разделу:

    HKLM\System\CCS\Services\VSS\VssAccessControl

  3. Проверьте все значения, перечисленные в подразделе VssAccessControl. Если какая-либо из записей имеет значение 0 и другой модуль записи VSS работает со связанными учетными данными, измените значение этой записи на 1.

  4. Установите агент защиты на Server2.

    Предупреждение

    Переключиться с одного интерфейсного веб-сервера на другой можно, только если оба находятся в одном домене.

  5. На сервере Server2 в командной строке измените каталог на расположение установки DPM\bin\ и запустите ConfigureSharepoint. Дополнительные сведения о ConfigureSharePoint: .

  6. Существует известная проблема, когда ферма серверов является единственным членом группы защиты, а группа защиты настроена для использования защиты на ленте. Если ваша ферма является единственным членом группы защиты на базе ленты, то чтобы изменить интерфейсный веб-сервер, используемый DPM для защиты фермы, необходимо временно добавить в группу защиты еще одного члена, выполнив следующие действия:

    • В консоли администрирования DPM выберите Защита на панели навигации.

    • Выберите группу защиты, к которой принадлежит ферма серверов, а затем выберите Изменить группу защиты.

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

    • Если в группе настроена краткосрочная защита на дисках и долгосрочная защита на ленте, выберите функцию создания реплики вручную. Это предотвращает создание реплики для тома, который вы временно добавляете в группу защиты.

    • Завершите работу мастера.

  7. Удалите Server1 из группы защиты и выберите сохранение реплик на дисках и ленте.

  8. Выберите группу защиты, к которой принадлежит ферма серверов, а затем выберите Изменить группу защиты.

  9. В мастере изменения групп на странице Выбор участников группы разверните узел Server2 и выберите ферму серверов, а затем завершите работу мастера.

    Будет запущена проверка согласованности.

  10. Если вы выполнили шаг 6, то теперь можете удалить том из группы защиты.

Резервное копирование рабочих процессов в SharePoint Server

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

  • Декларативные рабочие процессы, например процессы, созданные в SharePoint Designer, хранятся в базе данных контента для семейства веб-сайтов, в котором они развернуты. Для защиты таких рабочих процессов необходимо выполнить резервное копирование базы данных контента.

  • Компоненты пользовательских действий декларативных рабочих процессов хранятся в указанных ниже расположениях.

    • Сборки Visual Studio 2013 для действий хранятся в глобальном кэше сборок.

    • XML-файлы определения (. Файлы ACTIONS) хранятся в каталоге 16\TEMPLATE<LCID>\Workflow.

    • Запись XML, используемая, чтобы пометить действие в качестве авторизованного типа, хранится в файле Web.config для веб-приложений, в которых она используется.

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

  • Рабочие процессы, основанные на пользовательском коде, например процессы, созданные в Visual Studio, хранятся в двух расположениях. Сборки Visual Studio для рабочих процессов хранятся в глобальном кэше сборок, а XML-файлы определений — в каталоге Features. Этот же каталог используется и для других компонентов SharePoint, таких как веб-части и приемники событий. Для защиты рабочих процессов, установленных в составе пакета решения, необходимо выполнять резервное копирование фермы, веб-приложения, базы данных контента или семейства веб-сайтов.

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

  • Резервное копирование еще не развернутых рабочих процессов следует выполнять отдельно. Если разрабатывается новый рабочий процесс, но его развертывание в ферме SharePoint Server еще не выполнено, воспользуйтесь для резервного копирования папки с файлами проекта рабочего процесса приложением для резервного копирования файловой системы.

Удаление базы данных из фермы SharePoint

При удалении базы данных из фермы SharePoint DPM пропускает резервное копирование этой базы данных, продолжает резервное копирование других баз данных в ферме SharePoint и оповещает администратора резервного копирования.

Оповещение DPM — изменение конфигурации фермы

Это предупреждение, которое выдает Data Protection Manager (DPM) при сбое автоматической защиты базы данных SharePoint. Дополнительные сведения о причине этого оповещения см. в области Сведений об оповещении.

Чтобы устранить это предупреждение, сделайте следующее:

  1. Проверьте у администратора SharePoint, удалена ли база данных из фермы. Если база данных была удалена из фермы, ее необходимо удалить из функции активной защиты в DPM.
  2. Чтобы удалить базу данных из функции активной защиты, сделайте следующее.
    1. В консоли администрирования MABS выберите Защита на панели навигации.
    2. В области Отображение выберите и удерживайте группу защиты для фермы SharePoint, а затем выберите Остановить защиту члена.
    3. В диалоговом окне Остановить защиту выберите Сохранить защищенные данные.
    4. Выберите Остановить защиту.

Командлеты оболочки управления SharePoint

Windows PowerShell предоставляют общую реализацию и реализацию для SharePoint. В общем отличие заключается в том, что командлеты Windows PowerShell образованы от базового класса PSCmdlet, а командлеты SharePoint Foundation образованы от специализированного базового класса SharePoint с именем SPCmdlet.

Важно!

Различие командлетов Windows PowerShell, производных от класса PSCmdlet, и командлетов SharePoint, производных от класса SPCmdlet, очень существенно. Все командлеты SharePoint, которые поставляются с SharePoint Foundation и доступны в командной консоли SharePoint, производные от класса SPCmdlet

Кроме того все пользовательские командлеты для поддержки развертываний SharePoint также должны быть командлетами SharePoint.

Далее представлена сигнатура базового класса SPCmdlet. Учтите, что SPCmdlet — класс, производный от класса PSCmdlet.

public abstract class SPCmdlet : PSCmdlet

Обратите внимание, что при использовании командлетов с переменными операторами, такими как Get, Set, New и Remove, следует применять определенные реализации класса SPCmdlet, а не производные от класса PSCmdlet. Это верно для модели скриптов для использования командлетов Windows PowerShell в SharePoint Foundation

Для командлетов, обрабатывающих постоянные объекты:

  • Командлеты Get: SPGetCmdletBase<TCmdletObject>

  • Командлеты Set: SPSetCmdletBase<TCmdletObject>

  • Командлеты New: SPNewCmdletBase<TCmdletObject>

  • Командлеты Remove: SPRemoveCmdletBase<TCmdletObject>

Для командлетов, обрабатывающих непостоянные объекты:

  • Командлеты Get: SPCmdlet

  • Командлеты Set: SPCmdlet

Для командлетов действий:

SPCmdlet

Начало работы с объектной моделью 2010

В Microsoft SharePoint Foundation 2010 и Microsoft SharePoint Server 2010 содержатся обновления объектной модели, разработанные так, чтобы быть совместимыми с существующими решениями, разработанными для Windows SharePoint Services 3.0 и Microsoft Office SharePoint Server 2007. Некоторые пространства имен, классы и методы теперь устарели, но они остаются доступны и будут продолжать работать прежним образом в пользовательском коде. Хотя пользовательский интерфейс был существенно изменен, визуальный режим обратной совместимости предоставляет возможность сохранить визуальные настройки до тех пор, пока не произойдет адаптация к новым возможностям пользовательского интерфейса. Можно синхронизировать настройки и приложения с обновленными версиями Microsoft SharePoint Foundation 2010 и Microsoft SharePoint Server 2010 после их повторного развертывания. В данной статье предоставлены рекомендации, которые могут помочь избежать и преодолеть проблемы, которые могут возникнуть при повторном развертывании, тестировании и отладке кода Windows SharePoint Services 3.0 и Office SharePoint Server 2007 в SharePoint Foundation 2010 и Microsoft SharePoint Server 2010 соответственно.

Если были созданы проекты Windows SharePoint Services 3.0 или Office SharePoint Server 2007 с помощью расширений Microsoft Visual Studio 2005 для Windows SharePoint Services 3.0 версии 1.1, расширений Microsoft Visual Studio 2005 для Windows SharePoint Services 3.0 версии 1.2 и расширений Microsoft Visual Studio 2005 для Windows SharePoint Services 3.0 версии 1.3, можно обновить их с помощью средства обновления VSeWSS (Возможно, на английском языке), которое устанавливает шаблоны, преобразующие существующие пакеты решений для расширений Visual Studio для Windows SharePoint Services (написанные на Microsoft Visual Basic или Microsoft Visual C#) в решения Microsoft Visual Studio 2010 (рис. 1).

Рис. 1. Импортирование проекта для расширений Visual Studio для Windows SharePoint Services в Visual Studio 2010

После преобразования решений для расширений Visual Studio для Windows SharePoint Services в решения Visual Studio 2010 необходимо развернуть новые пакеты решений в обновленной платформе.

Настройка разрешений для запуска операций резервного копирования и восстановления в SharePoint с помощью PowerShell

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

Для добавления учетной записи пользователя к этой роли можно воспользоваться командлетом Add-SPShellAdmin. Этот командлет необходимо выполнить для каждой учетной записи пользователя. Кроме того, его необходимо выполнить для всех баз данных, к которым нужно предоставить доступ.

Примечание.

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

Важно!

Командлет Add-SPShellAdmin предоставляет роль SPDataAccess, но этого недостаточно для завершения операции восстановления. Это связано с тем, что командлет restore-spsite использует инструкции прямой вставки для добавления содержимого, а не хранимых процедур, которые вмеют другие взаимодействия. Командлет Add-SPShellAdmin работал нормально в SharePoint 2010, так как в составе схемы SPDataAccess он добавил разрешения dbo. Для SharePoint Server 2019, 2016 и 2013 db_owner предопределенных разрешений роли базы данных требуются для выполнения операций восстановления из командной консоли SharePoint.

Добавление пользователя в роль SharePoint_Shell_Access и удаление из нее с помощью PowerShell

  1. Убедитесь, что вы являетесь участником следующих групп:

    • Предопределенная роль сервера securityadmin для экземпляра SQL Server.

    • Предопределенная роль базы данных db_owner во всех базах данных, которые должны обновляться.

    • Группа администраторов для сервера, на котором выполняются командлеты PowerShell.

    С помощью командлета Add-SPShellAdmin администратор может предоставлять разрешения на использование командлетов SharePoint Server.

    Примечание.

    При отсутствии разрешений обратитесь к своему администратору программы установки или администратору SQL Server за разрешениями. Дополнительные сведения о разрешениях PowerShell см. в статье Add-SPShellAdmin.

  2. Запустите командную консоль SharePoint.

  3. В командной строке PowerShell введите следующую команду:

    Где:

    это идентификатор GUID базы данных.

    Чтобы добавить учетную запись пользователя ко всем базам данных в ферме, выполните следующую команду:

    Где:

    это пользователь, учетную запись которого требуется добавить.

    Чтобы удалить учетную запись пользователя из всех баз данных в ферме, выполните следующую команду:

    Где:

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

    Чтобы просмотреть учетные записи пользователей, добавленные к базам данных в ферме, выполните следующую команду:

Дополнительные сведения см. в статье Add-SPShellAdmin.

Примечание.

Для выполнения административных задач из командной строки мы рекомендуем использовать Windows PowerShell. Программа командной строки Stsadm является устаревшей, однако она добавлена для совместимости с предыдущими версиями продукта.

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

Компонент фермы Участник группы администраторов на локальном компьютере Участник группы администраторов фермы SharePoint Полный доступ к папке резервного копирования
Ферма Да Нет ДА
Приложение-служба ДА Нет ДА
База данных контента ДА Нет ДА
Семейство веб-сайтов НЕТ Да ДА
Сайт, список, библиотека документов ДА Нет Да

Перед началом работы

Рекомендуется регулярно выполнять резервное копирование всей фермы, включая конфигурацию и контент. Однако резервное копирование только конфигурации лучше выполнять в тестовых средах или средах разработки. Аналогичным образом, если вы используете SQL Server для резервного копирования баз данных для фермы, необходимо создать резервную копию конфигурации. Регулярное копирование фермы сокращает вероятность потери данных вследствие сбоев оборудования, отключения питания или других проблем. Это гарантирует наличие всех данных и конфигурации фермы на случай восстановления. Дополнительные сведения о том, какие элементы следует включать в процесс резервного копирования, см. в статье Plan for backup and recovery in SharePoint Server.

Рекомендации по выбору средства резервного копирования см. в статье Общие сведения о резервном копировании и восстановлении в SharePoint Server.

Перед выполнением этой операции ознакомьтесь со следующими сведениями.

  • Необходимо создать локальную или сетевую папку, в которой затем будет сохранен файл резервной копии. Для повышения производительности рекомендуется выполнять резервное копирование в локальную папку, а затем перемещать полученный файл в сетевую. Дополнительные сведения о создании папки резервной копии см. в статье Prepare to back up and restore farms in SharePoint Server.

  • При резервном копировании конфигурации фермы не сохраняются данные, необходимые для восстановления приложений-служб. Для обеспечения возможности восстановления приложений-служб следует выполнять резервное копирование конфигурации и контента фермы. Дополнительные сведения о резервном копировании и восстановлении баз данных см. в статье Back up service applications in SharePoint Server.

  • Для резервного копирования конфигурации фермы нельзя использовать средства SQL Server или Data Protection Manager.

Рейтинг
( Пока оценок нет )
Editor
Editor/ автор статьи

Давно интересуюсь темой. Мне нравится писать о том, в чём разбираюсь.

Понравилась статья? Поделиться с друзьями:
Работатека
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: