Решение с использованием сценария, вторичная конфигурация и правила восстановления
Технологии Microsoft SharePoint позволяют совместно использовать информацию в группах пользователей как внутри предприятия, так и между несколькими компаниями. В настоящей статье в качестве Portal Server рассматривается Microsoft SharePoint Portal Server 2003 и Windows SharePoint Services 2.0 в качестве SharePoint Services. Для обозначения обоих продуктов будет использоваться термин SharePoint. SharePoint обеспечивает функции управления документами, используя два типа хранилищ: библиотеки и списки документов. При этом собственно файлы хранятся в контентной базе данных SharePoint, а не в файловой системе Windows.
В SharePoint отсутствует одна очень важная с точки зрения управления документами функция: нет простого способа восстановить случайно удаленные файлы. Кроме того, хотя контроль версий присутствует, Portal Server и SharePoint Services уничтожают всю историю о версиях после удаления документа. Помимо этих проблем, модуль SharePoint, отвечающий за резервирование информации, реализован относительно слабо и не предоставляет возможности восстановления изолированного файла из резервной копии.
Несмотря на эти упущения, на базе SharePoint уже существуют вполне работоспособные решения. В данной статье будут рассмотрены методы автоматизации процесса резервирования в SharePoint при помощи сценариев, а затем мы обсудим некоторые способы восстановления файлов.
Восстановление из резервной копии
Вместо того чтобы бороться с недостатками SharePoint в области восстановления данных, можно организовать восстановление изолированных файлов и функцию Undelete, используя резервные версии копии портала Portal Server (на базе отдельного сервера или серверной фермы), копии SharePoint Services или сайтов SharePoint. Однако для обслуживания процедур Backup/Restore нужны специальные сотрудники для наблюдения за рабочими процессами, требуется механизм запросов восстановления файлов и, возможно, дополнительное оборудование для вторичной среды работы. Один из способов минимизировать затраты на вторичную среду работы заключается в виртуализации копии портала с помощью таких продуктов, как VMware Workstation или Microsoft Virtual PC.
Будет ли реализована вторичная среда SharePoint физически или виртуально, в любом случае для хранения резервных копий может потребоваться значительный место на носителе. Для хранения может использоваться технология SAN, уже доступная во многих крупных организациях, или терабайтные носители информации. Многие поставщики NAS предоставляют терабайтные устройства, которые могут использоваться для недорогого хранения резервных копий SharePoint. Такие копии целесообразно хранить в вынесенном хранилище, а отказоустойчивость обеспечить с помощью решений на базе RAID-массивов.
Доступные утилиты
Если обслуживание вторичной среды SharePoint, содержащей предыдущую версию бизнес-среды, для компании обязательно, можно регулярно выполнять процедуры полного резервирования Full Backup и восстановления. В случае с Portal Server можно воспользоваться утилитой SharePoint Portal Server Data Backup and Restore (spsbackup.exe). Для «чистой» реализации SharePoint Services, в которой не содержится Portal Server, можно использовать утилиту администрирования SharePoint (stsadm.exe) или инструментарий Microsoft SQL Server, например OSQL (osql.exe), для выполнения операций Backup/Restore. Подробнее о резервировании и восстановлении SharePoint Services рассказано в статье Microsoft «How to back up and restore installations of Windows SharePoint Services that use Microsoft SQL Server 2000 Desktop Engine (Windows)» (http://support.microsoft.com/?kbid=833797.)
Хотя программа Stsadm может быть использована для резервирования и восстановления Portal Server, здесь есть некоторые ограничения. Об этом речь идет в другой статье Microsoft, «Supported scenarios for using the Stsadm.exe command-line tool to back up and to restore Windows SharePoint Services Web sites and personal sites in SharePoint Portal Server 2003» (http://support.microsoft.com/?kbid=889236).
Процедуры Portal Server Backup
Запуск Spsbackup осуществляется из программной группы SharePoint Portal Server или из командной строки (предварительно следует перейти в каталог SharePointBin):
spsbackup.exe
Путь к каталогу Bin можно добавить в переменную PATH сервера, на котором планируется запускать процедуру Backup.
Если процедура запускается регулярно, то поиск данных для восстановления будет несложным (по дате резервирования). Для автоматизации запуска процедуры резервирования можно создать специальное задание, которое будет вызывать утилиту Spsbackup, либо можно написать свой сценарий. После чего с помощью команды планировщика AT (winat.exe) или Task Scheduler создается расписание регулярного резервирования.
Код, приведенный в листинге, демонстрирует простой сценарий на VBScript. С его помощью создается каталог для резервируемых данных с привязкой к текущей дате (используются возможности FileSystemObject и функции Date). Затем используется объект WshShell и метод Exec для вызова процедуры Spsbackup. Чтобы воспользоваться данным сценарием, нужно изменить значение переменной strDestinationFolder применительно к конкретным условиям и указать путь в нотации Universal Naming Convention (UNC) либо локальный путь. При реализации односерверного Portal Server утилита Spsbackup требует указания пути на локальном диске в качестве целевого каталога резервирования; при реализации Portal Server на серверной ферме для указания целевого каталога резервирования используется UNC. Причем, если для резервных копий будут использоваться внешние хранилища, соответствующий путь к ним непосредственно повлияет на то, как будут подключаться внешние устройства. Простое использование буквы диска в UNC-пути для односерверной реализации Portal Server работать не будет. В этом случае можно расширить приведенный сценарий с помощью метода FileSystemObject MoveFolder, и после того, как процедура резервирования будет выполнена локально, переместить данные в целевой каталог с использованием пути UNC.
К сожалению, разработчики Microsoft не потрудились создать SharePoint API для сценариев, так что нам остается или воспользоваться утилитами командной строки, что показано в приведенном примере сценария, или написать собственный COM-объект для расширения объектной модели SharePoint при помощи Microsoft .NET Framework. Можно зарегистрировать свои COM-компоненты и проиллюстрировать их примерами вызова в сценариях. Можно также воспользоваться новой средой Windows PowerShell для вызова Spsbackup, но, насколько мне известно, в настоящее время для текущей версии Portal Server соответствующие библиотеки (cmdlets) Microsoft .NET отсутствуют. Упомянутые библиотеки инкапсулируют задачи при помощи вызовов .NET-методов, доступных в различных объектных моделях. Разработчики (и Microsoft, и независимых компаний) могут написать собственные cmdlets для автоматизации функций администрирования SharePoint, расширив объектные модели .NET для Portal Server или SharePoint Services. Подробнее об использовании cmdlets в Windows Power-Shell рассказано в статье «Введение в Windows PowerShell», опубликованной в №8 нашего журнала за 2006 г.
После того как сценарий настроен, его можно запускать по расписанию на сервере SharePoint с помощью утилиты AT или Scheduled Task Wizard (программная группа System Tools). Если резервная копия создана, можно провести полное восстановление Portal Server при помощи утилиты Spsbackup, воспользовавшись графическим интерфейсом этой утилиты или ее реализацией в виде командной строки. Окно управления Spsbackup можно найти в программной группе Portal Server или запустив Spsbackup с командной строки без параметров.
Стратегии восстановления
Теперь, когда у нас есть процедура резервирования, рассмотрим три варианта стратегии восстановления: создание снимка (snapshot), специализированный (ad hoc) и гибридный (hybrid). В методе snapshot создается среда восстановления, которая представляет собой образ бизнес-портала на некоторый более ранний момент времени. Для этого нужно периодически запускать операции резервирования/восстановления для получения снимков портала, естественно, с некоторым отставанием от текущего состояния портала. Очевидный недостаток метода — невозможно восстановить файлы на дату, предшествующую дате восстановления портала. Этого недостатка лишен метод ad hoc, используя который можно регулярно создавать и архивировать Backup-наборы и при необходимости выполнять восстановление данных. Если потребуется файл трехмесячной давности, то все, что нужно, — это достать соответствующий Backup-набор, подготовить процедуру восстановления и извлечь необходимый файл. Однако, в зависимости от частоты запросов на восстановление, метод ad hoc может и не подойти, поскольку восстановление может занять очень много времени.
В гибридном методе комбинируются первые два метода, т. е. поддерживаются как снимки Portal Server, так и возможность специфического восстановления среды по запросу. Можно перезаписывать снимки с учетом специфических запросов или поддерживать третий сервер на случай восстановления по запросу. Размер организации, возможности группы администрирования, инфраструктура Portal Server, частота запросов на восстановление — все это влияет на выбор того или иного метода.
Другие методы
Другие методы, которые можно применять во второй портальной среде, не требуют использования процедур полного восстановления баз данных портала для обнаружения удаленных данных. Можно ограничить область местонахождения библиотек или списков документов несколькими коллекциями сайта, отдельными сайтами, подсайтами, можно резервировать и восстанавливать более мелкие секции портала с большей частотой и делать это с необходимой периодичностью. Используя такой подход к проблеме восстановления отдельного файла, мы как бы изолируем зоны резервирования/восстановления на отдельных уровнях SharePoint Services при помощи утилиты миграции smigrate.exe или stsadm.exe для создания зеркала отдельных структур сайта. Утилита stsadm.exe с ключом -о в режиме Backup и Restore позволяет резервировать коллекции сайта в одной среде и восстанавливать их в другой; smigrate.exe обеспечивает аналогичную функциональность для индивидуальных сайтов. Подробное описание этих программ можно найти в руководствах Microsoft Office SharePoint Portal Server 2003 Administrator?s Guide (http://www.microsoft.com/technet/prodtechnol/ office/sps2003/downloads/admdwnld.mspx) и Windows SharePoint Services Administrator?s Guide (http://www.microsoft.com/technet/prodtechnol/ sppt/wss/wssagabs.mspx).
Стратегия резервирования/восстановления более мелкими секциями позволяет выполнять более частое и быстрое восстановление данных, чем при использовании операций Full Backup/Full Restore. Однако для этого требуется правильно идентифицировать список коллекций сайта или индивидуальных сайтов и корректно управлять ими, прежде чем запускать процедуры резервного копирования.
Еще один метод решения проблемы восстановления отдельных файлов состоит в использовании контентных баз данных SharePoint внутри SQL Server. Описание этого решения приводится во врезке «Восстановление файлов с помощью контентных баз данных SharePoint».
Независимые разработчики, такие как AvePoint и Nintex, также предлагают решения для восстановления файлов и реализации функции Undelete.
Не имеет значения, каким именно образом предполагается справиться с проблемой резервирования/восстановления SharePoint, однако следует учесть потребности в хранении данных, которые напрямую зависят от избранного метода, рассмотреть вопросы безопасности и дублирования данных, чтобы большинство пользователей не могли получить к ним доступ.
Продукт продолжает совершенствоваться
Разработчики Microsoft усовершенствовали функции восстановления в Microsoft Office SharePoint Server 2007. В текущей бета-версии вы уже найдете двухстадийный процесс Undelete. После удаления файлы остаются в корзине recycle bin в течение некоторого времени (настраиваемый параметр), в пределах которого пользователь может восстановить удаленные данные. Администратор имеет возможность восстановить файлы пользователя и настроить политики хранения файла) на основе настраиваемых квот хранения. Кроме того, в бета-версии присутствуют утилиты, позволяющие выполнить дифференциальный, инкрементальный и полный Backup.
Любой профессионал в области ИT согласится с тем, что совершенного программного продукта не существует. Но есть надежда, что предлагаемые в данной статье решения помогут преодолеть недостатки SharePoint, связанные с резервированием и восстановлением файлов.
Этан Вилански (ewilansky@windowsitpro.com) — редактор Windows IT Pro и главный технолог подразделения Technology Strategy and Architecture компании EDS. Автор и соавтор более десятка книг, выпущенных компанией Microsoft.
Джефф Сандлер (jsandl01@gmail.com) — ведущий технолог подразделения Technology Strategy and Architecture компании EDS. Проработал в компании EDS более 15 лет в качестве архитектора и разработчика.
Краткое описание решения
Проблема
В SharePoint нет простого способа восстановления удаленных файлов.
Решение
Восстанавливаем файлы с помощью автоматизированной процедуры резервирования с привлечением одной из стратегий восстановления файлов.
Что нужно
SharePoint Portal Server и Windows SharePoint Services; вторичная конфигурация SharePoint (физическая или виртуальная); сценарий резервного копирования.
Сложность
3 из 5
Что делаем
- Создаем вторичную портальную конфигурацию (физическую или виртуальную).
- Создаем сценарий для автоматизации процедуры Backup.
- Выбираем подходящую стратегию восстановления.
- Восстанавливаем файлы.
Восстановление файлов с помощью контентных баз данных SharePoint
На сайте MSD2D (http://www.msd2d.com) опубликовано несколько документов из серии SharePoint Technology Tips с описанием решений для восстановления файлов с помощью контентных баз данных Microsoft SQL Server SharePoint. Одно такое решение Деннис Моксли предлагает в статье «Item Level Restore in a Document Library» (http://msd2d.com/content/tip_viewitem_ 03noauth.aspx?id=18b3b9d7-bcd4-465f-9bd7-8ece0bd1e9bc§ion=sharepoint), где описывается восстановление документа при помощи SQL Server Backup. Используя функции SQL Server Backup, можно реализовать более эффективный способ резервирования и восстановления портального контента, что означает большую гибкость в управлении контентом непосредственно из самих баз данных. Чтобы получить доступ к опубликованным статьям, необходимо зарегистрироваться на MSD2D.
В своей статье Моксли объясняет, как установить местоположение файлов в таблице Doc с помощью SQL-запроса, составленного для резервной копии базы данных сайта SharePoint. Затем он показывает, как построить новый запрос, который заносит соответствующий контент обратно в «боевую» базу данных. Можно добавить результаты запроса в таблицу Doc с помощью функции SQL Server Enterprise Manager Import Data. Как подчеркивает Моксли, необходимо создать дополнительные конфигурации для получения списка библиотек документов SharePoint в целях восстановления файлов.
Похожая методика приведена на том же сайте в статье Карлоса Монтиллы и Джима Бима «File Level Restore» (http://msd2d.com/content/tip_viewitem_03.aspx?section=sharepoint&category =administration&id=6fbc9145-cc08-4a5b-a7d7-14b37e014672). Здесь описан автоматизированный подход к проблеме восстановления контента, который выдает точную информацию для процессов резервирования и восстановления. Для восстановления файлов в методе Монтиллы и Бима используется специально созданная таблица с триггерами и хранимыми процедурами. Однако следует отметить, что авторы непосредственно используют схему базы данных сайта SharePoint, которую Microsoft в последующих обновлениях SharePoint Portal Server может изменить.