Восстановление бд из резервной копии. Восстановление удаленных файлов базы данных MySQL

26.03.2019

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

Поэтому к существует великое множество дополнений — плагинов.

Большинство из них можно использовать по желанию, но есть и такие, которые просто-таки необходимы для корректной работы наших сайтов.

В любом случае, нам надо уметь их устанавливать. Без этого никак.

Есть несколько способов установки плагинов на WordPress. Давайте рассмотрим их все.

1. Поиск и установка плагина встроенными средствами WordPress .

В админ-панели WordPress переходим на вкладку «Плагины».

Вверху нажимаем на кнопку «Добавить новый».

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

Появляется список плагинов, которые удовлетворяют Вашему запросу. Возле названия каждого плагина есть две ссылки: «подробности» и «установить».

2. Установка плагина WordPress с домашнего компьютера.

Если у Вас нужный плагин уже закачан на компьютер в виде архива, то Вы можете установить его оттуда.

Для этого также переходим на вкладку «Плагины», «Добавить новый». Но теперь обращаем внимание на самую верхнюю строчку. И выбираем там ссылку «Загрузить».

Появляется страничка загрузки плагина с Вашего компьютера.

Нажимаем кнопку «Обзор» и выбираем нужный плагин со своего компьютера. Плагин должен быть обязательно в формате zip-архива. Если Вы качали его с официального сайта, то он в таком виде и есть.

Затем нажимаем кнопку «Установить».

Все. Установка пошла. Остается опять только активировать плагин.

3. Установка плагина WordPress вручную.

Также мы можем устанавливать плагины для WordPress вручную. Для этого мы должны воспользоваться какой-нибудь программой для FTP-соединения с сервером, на котором расположен наш сайт. Например FileZilla.

При помощи этой программы мы сможем загрузить файлы плагина на сервер нашего сайта. Устанавливать нужно в папку: вашсайт/ wp-content/plugins

Если плагин у Вас был в архиве, то перед копированием его надо разархивировать.

После того, как файлы плагина загружены на сервер, нам остается только активировать плагин.

4. Итак, активация плагина.

Это самый простой шаг при установке плагина. Переходим на вкладку «Плагины». Находим наш свежеустановленный плагин и нажимаем возле его названия ссылку «Активировать» .

Вот и все.

Это очень просто. Проблем не должно возникнуть ни у кого.

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

Зачем нужны плагины

Несомненно, движок WordPress хорош сам по себе, но истинный вебмастер всегда ищет что-то новое, пытается добавить в структуру своего сайта что-то интересное и необычное.

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

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

Что такое плагин и их разнообразие

Плагин (plug-in) — программный модуль, который преобразует функциональный потенциал основной программы. Подключение расширения выполняется с помощью динамической компиляции системных элементов программного блока WordPress.

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

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

Каждый plug-in относится к определенной категории, далее представлены наиболее стабильные модули для конкретных задач:

Резервное копирование

UpdraftPlus Backup — бесплатный программный блок, который успешно справляется с задачей резервного копирования системы вордпресс. Сохранение может быть выполнено как вручную, так и в автоматическом режиме. Для размещения контента и баз данных используются следующие локации: Dropbox, Amazon S3, Google Drive и др. Возможен удаленный режим работы по расписанию.

Безопасность

В данном сегменте представлен один из лучших модулей, который легко обеспечивает высокую степень защиты WordPress — Better WP Security. Plug-in содержит все современные наработки в сфере безопасности и надежности популярной CMS.

Изображения, медиа контент

NextGen Gallery — отличный плагин для оптимизации контента в системе wordpress. Расширяет возможности предустановленной галереи WordPresss, позволяет добавить файлы вручную, также доступна автоматическая загрузка контента с поддержкой flash слайдшоу.

Виджеты, меню

WordPresss Popular Posts — виджет с функцией отображения актуальных записей в сайдбаре. Можно добавить количество выводимых записей, способ ротации записей и др.

Социальные сети

WP Socializer — полезный и мощный plug in для комфортного шаринга в социальные сети (доступно более 100 соцсетей). Включает много дополнительных настроек и функций.

Поддержка языков

qTranslate — современный способ для достижения мультиязычности на сайте Вордпресс. Интегрирована поддержка множества языков, предусмотрено быстрое переключение языковых модулей на сайте.

SEO-интструменты

All-In-One SEO — качественный блок инструментов для реализации поисковой оптимизации сайта. Плагин в автоматическом режиме создает корректные заголовки и теги для контента, расположенного на сайте.

Методы установки плагинов WordPress

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

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

Установка с официальной директории плагинов системы https://wordpress.org/plugins/ ;
Загрузка прямо из админки (административной панели).

Использование официальной директории

Данный метод позволяет всего за пару кликов установить требуемый программный блок:

переходим в Плагины, выбираем Добавить новый,
в поисковом поле прописываем название нужного плагина,
выбираем опцию Поиск плагинов и жмем клавишу Enter на ПК,
определяем нужный вариант из предложенного списка и выполняем его Установку и Активацию.

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

Установка по FTP

Выполнение установки плагинов по FTP включает несколько моментов:

войдите в каталог файлов вашего ресурса, используя сервис FTP;
откройте папку plugin, которая расположена в wp-content\plugins;
далее следует добавить разархивированную папку с плагином на сервер в директорию plugin;
последний этап — простая активация загруженного плагина.

Установка zip-архива прямо из административной панели

Предположим, что у вас на жестком диске ПК уже есть скачанный архив с нужным плагином.

От вас требуется перейти в админку вашего сайта, которая расположена по адресу http://адрес-вашего-сайта/wp-admin/ и пройти авторизацию.

После того, как система загрузит файл, его необходимо активировать.

Как видно из описанных методик, вся процедура загрузки и установки новых плагинов, в системе WordPress реализована достаточно просто и удобно.

SQL Server поддерживает три различных вида резервных копий – полную (full backup), дифференциальную (differential backup) и резервную копию журнала транзакций (transaction log backup). Первые два вида резервных копий доступны для баз данных в любой модели восстановления, резервная копия журнала транзакций – для баз данных в модели восстановления FULL и BULK-LOGGED (про модели восстановления вкратце вы можете прочитать , а лучше в BOL).

Если вы используете модель восстановления SIMPLE – вы сможете восстановить свою базу только из полного бэкапа (ну и накатить, дополнительно, дифференциальную копию). Вы никогда не восстановитесь на момент времени предшествующий сбою, только если вы не создали резервную копию непосредственно перед сбоем. Если ваша база данных находится в модели восстановления FULL и вы никогда не делаете бэкап журнала транзакций, но время от времени «обрезаете лог», прочитайте дальше – узнайте чего вы лишаетесь:).

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

Что такое «цепочка восстановления»? Это непрерывная последовательность резервных копий, состоящая из полного бэкапа и непрерывной последовательности резервных копий журнала транзакций. Например, в 12.30 вы создали полный бэкап (назовем его full1), а в 12.45, 13.00 и 13.15 создавали резервные копии журнала транзакций (trlog1, trlog2, trlog3, соответственно). До тех пор пока у вас есть все эти резервные копии, вы сможете восстановить свою базу данных на любой момент времени между 12.30 и 13.15, на 12.48, например.

Если вы удалите копию trlog2, созданную в 13.00, то резервная копия trlog3 (и все копии сделанные в дальнейшем) станет абсолютно бесполезной – восстановиться вы сможете на любой момент времени между 12.30 и 12.45. То же самое произойдет в случае, если кто-то создаст копию в 12.31 и удалит ее – все последующие копии станут бесполезны. Чтобы начать новую цепочку восстановления вам нужно будет сделать полную резервную копию и, затем, резервную копию журнала транзакций.

Во всем этом есть один не очень очевидный (по крайней мере, так было для меня) момент. Полная резервная копия всегда начинает, но никогда не прерывает цепочку восстановления (это справедливо для SQL Server 2005 и старше). Разберем это на примере. Вдобавок к уже имеющимся копиям (full1, trlog1, trlog2, trlog3 – непрерывная цепочка восстановления) сделаем в 13.30 полную резервную копию full2 и резервные копии журнала транзакций trlog3, trlog4, trlog5 в 13.45, 14.00 и 14.15, соответственно.

Теперь, если нам нужно восстановить базу данных на 14.15, проще всего использовать «новую» цепочку восстановления, т.е. восстановить full2 и «накатить» на нее последовательно trlog3, trlog4, trlog5. Но, если окажется, что из копии full2 мы не можем восстановиться (например, посыпался диск, содержащий эту копию), то мы можем воспользоваться нашей «первой» цепочкой восстановления – восстановить резервную копию full1 и последовательно накатить на нее копии журнала транзакций trlog1, trlog2, trlog3, trlog4, trlog5, trlog6. Точно также, мы можем использовать первую цепочку восстановления, для восстановления базы данных на 13.29 – восстанавливаем full1 и накатываем trlog1, trlog2, trlog3 и trlog4.

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

Дальше я расскажу несколько способов использования резервных копий SQL Server.
Первый вариант (он работает для всех моделей восстановления) – необходимо восстановить базу данных из полной резервной копии . Здесь все просто – необходимо выполнить T-SQL скрипт:

RESOTRE DATABASE [имя_базы_данных]
FROM DISK = "путь к полной резервной копии"
WITH REPLACE, RECOVERY, STATS = 10

Параметр REPLACE указывает на то, что если база данных с именем [имя_базы_данных] существует, то мы заменяем ее содержимое содержимым резервной копии. Если вы восстанавливаете базу данных с помощью GUI – нужно указать «Overwrite the existing database» на вкладке «Options».

RECOVERY говорит о том, что базу данных необходимо перевести в согласованное состояние и разрешить соединения пользователей. В GUI это соответствует опции «Leave the database ready to use by rolling back uncommitted transactions. Additional transaction logs cannot be restored.». Т.е., SQL Server откатывает все незафиксированные транзакции и позволяет пользователям работать с данными. После того как вы восстановили резервную копию с параметром RECOVERY, к ней нельзя применять дополнительно копии журналов транзакций и дифференциальные копии. Будьте внимательны, этот параметр устанавливается по умолчанию и если вы захотите «накатить» еще одну копию – процесс восстановления придется начать заново.

STATS = 10 отвечает за вывод информации о процессе восстановления. В данном случае, при восстановлении каждых 10 % резервной копии, на вкладке Messages в SSMS будет появляться сообщение. При восстановлении с помощью GUI вы не можете управлять этим параметром – за изменениями можно следить на «графике» в нижнем левом углу.

По умолчанию копия восстанавливается в то же самое место откуда она была сделана. Т.е. если изначально все файлы базы данных лежали в каталоге C:\Database, а вы хотите восстановить копию в другое место, то необходимо использовать параметр MOVE. Для использования MOVE вам необходимо знать логические имена файлов – их можно посмотреть с помощью представления sys.database_files. На рисунке показан пример использования этого представления.

Таким образом, чтобы восстановить базу данных AdventureWorks из резервной копии и одновременно перенести ее в другое место, можно воспользоваться следующим скриптом:

WITH REPLACE, RECOVERY, STATS = 10,

Если восстановление производится с помощью GUI, необходимо задать новые имена файлов на вкладке «Options» (таблица «Restore the database files as:», колонка «Restore As»).

Второй вариант – восстановление из полной резервной копии и всех резервных копий журнала транзакций (или дифференциальных копий).

Восстановление всегда начинается с восстановления полной резервной копии, но если вы хотите после этого восстанавливать какие-либо дополнительные копии, вам нужно оставить базу в состоянии RESTORING. Для этого воспользуемся следующим скриптом:

RESTORE DATABASE
FROM DISK = "D:\backup\awfull.bak"
WITH REPLACE, NORECOVERY, STATS = 10,
MOVE "AdventureWorks_Data" TO "D:\database\AW_data.mdf",
MOVE "AdventureWorks_Log" TO "D:\database\AW_log.ldf"

Если после выполнения восстановления вы попробуете обратиться к базе – получите ошибку:
Database "AdventureWorks" cannot be opened. It is in the middle of a restore.
После восстановления полной резервной копии восстанавливаем последнюю дифференциальную копию (если есть):

RESTORE DATABASE
FROM DISK = "D:\backup\awDIFF.bak"
WITH NORECOVERY, STATS = 10

На этом, если у вас модель SIMPLE, вы можете остановиться – больше вы ничего не сделаете. Если у вас модель FULL, вы можете дополнительно накатить резервные копии журнала транзакций :

RESTORE LOG
FROM DISK = "D:\backup\awlog1.trn"
WITH NORECOVERY
….
RESTORE LOG
FROM DISK = "D:\backup\awlog12.trn"
WITH RECOVERY

Обратите внимание, последняя копия должна быть восстановлена с параметром RECOVERY. Если база данных осталась в состоянии RESTORING, ее можно привести в работоспособное состояние и без резервных копий:

RESTORE DATABASE
WITH RECOVERY

После этого база данных «вернется к жизни».
Третий вариант – восстановление на момент времени . У меня есть база данных AdventureWorks, ее полная резервная копия и резервная копия журнала транзакций, сделанная ранее. Результат выполнения запроса

SELECT *
FROM Person.AddressType

представлен на рисунке:

В 13.46 эта таблица была удалена. Тот же самый запрос теперь возвращает:
Invalid object name "Person.AddressType"
Чтобы вернуть все на свои места, в первую очередь делаем резервную копию журнала транзакций:

BACKUP LOG
TO DISK = "D:\backup\awlog2.trn"

После того как копия создана, восстанавливаем полную резервную копию и первую резервную копию журнала транзакций (обе с параметром NORECOVERY).
Теперь восстановим последнюю резервную копию, созданную ПОСЛЕ удаления таблицы:

RESTORE LOG
WITH RECOVERY, STOPAT = "09/10/2010 13:45"
(дата здесь задается в формате "ММ/ДД/ГГГГ ЧЧ:ММ")
После этого исходный запрос возвращает нормальный результат, таблица восстановилась.

Еще один вариант восстановления данных. История из жизни :).
Несколько месяцев назад попали в не очень приятную ситуацию – записи в одном из регистров сведений (периодическом, не подчиненном регистратору) были «испорчены». То есть они как бы остались, но свой смысл потеряли. Регистр был большим и нужным. Ошибка произошла несколько часов назад, так что полностью восстанавливать базу данных было нельзя. Собирались переносить данные с помощью обработки ВыгрузкаЗагрузкаДанныхXML, но программисты попросили попробовать перенести данные средствами SQL, в надежде, что это будет быстрее.

Мы восстановили из бэкапов копию базы на момент времени предшествующий порче данных. С помощью функции «ПолучитьСтруктуруХраненияБазыДанных» узнали имя регистра сведений в базе данных - _InfoReg4452 (например, точно я уже не помню). Очистили в основной базе этот «испорченный» регистр с помощью TRUNCATE TABLE _InfoReg4452.
На копии базы выбрали TASKS -> ExportData, в качестве источника указали копию с нормальным регистром, в качестве приемника рабочий сервер и рабочую базу (с очищенным регистром). На странице выбора объектов выбрали только одну – нужную нам таблицу:

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

P.S. Не верьте мне на слово - попробуйте все это сделать на своих копиях!

Сегодня в уроке: MySQL. (MySQL - система свободного управления базами данных). Восстановить базу данных достаточно просто, но для этого нужно иметь резервную копию базы. Когда у меня появились проблемы с базой, то я не мог зайти на сайт, и все мои статьи пропали. Пришлось срочно решать, как восстановить базу данных Wordprerss.

Такая ситуация у меня произошла пару дней назад, когда я писал 59 урок. Мне буквально через несколько минут пришло СМС от Яндекс-Метрики, что мой сайт не доступен. Если Вы с такой проблемой раньше сталкивались, то знаете как все вернуть в рабочее состояние, а если нет - читайте далее.

Как восстановить базу данных WordPress (способ 1)

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

Если на Вашем блоге еще не установлен плагин , или ему подобный, то Вы рискуете остаться без блога. Представьте, Вы ведете блог долгое время, а потом раз, и все! Амба! Этот плагин не позволит случится такому. Он сохраняет базу данных Вашего блога постоянно в автоматическом режиме и без Вашего участия.

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

Чтобы вернуть блог в прежнее состояние, у Вас должна быть свежая резервная копия базы данных. Распакуйте файл базы и откройте распакованный файл в блокноте Windows. Скопируйте содержимое фала в . Перейдите в панели управления на Вашем хостинге в PhpMyAdmin.

Щелкните по названию базы данных, которую хотите восснановить.

Потом нужно щелкнуть по "SQL " и вставьте в окошко то, что скопировали с файла базы данных, нажав "CTRL " + "V ". Нажмите потом "ОК ".

Подождав пока закончится восстановление базы данных. Должна появится надпись об успешном выполнении.

Теперь Ваш блог полностью восстановлен.

Как быстро восстановить базу данных WordPress (способ 2)

Итак, без лишних вступлений. Переходите на Вашем хостинге в контрольную панель (cPanel). Найдите ссылку «MySQL » или «PhpMyAdmin ».

Теперь нужно осуществить вход в панель управление базами данных, т. е. в PhpMyAdmin. Нажимаем «Войти »

Вы попадете в PhpMyAdmin. Слева щелкните по базе, которую собираетесь восстановить. В моем случае это база dvpress.

После того, как выберите базу, появятся все таблицы этой базы данных. Чтобы во время восстановления, не возникало никаких ошибок, надо эту базу полностью удалить. Опускаемся в самый низ и находим «Отметить все / Снять выделение ». Нажимаете на «Отметить все », чтобы все таблицах базы стояли галочки в чекбоксе. Выбираем в окошке правее «Удалить », а потом подтвердите "Да ". База данных должна полностью очиститься от всех таблиц.

Теперь Ваша задача восстановить эту базу из резервной копии. Жмите вверху «Импорт », потом щелкайте по кнопке «Выберите файл ». Найдите на своем компьютере резервную копию базы и нажмите «Открыть ». Теперь в PhpMyAdmin внизу нажмите «Ок ». Операция должна пройти успешно, о чем должна оповестить надпись «SQL запрос успешно выполнен ».

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

Запомните, если Вы восстанавливаете базу, используя Simple Recovery Model, Вам нужно будет восстановить только последнюю полную копию. Если же Вы используете Full или Bulk Recovery Model , Вы должны восстановить полную копию, затем последнюю дифференциальную копию и все копии журналов транзакций. Изучим подробнее процессы восстановления.

Восстановление базы данных из полной копии.

Независимо от модели восстановления, первым шагом всегда является восстановление последней полной резервной копии. Для восстановления БД в Enterprise Manager, следует выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, после этого откроется диалоговое окно, показанное на Рисунке A.

Рисунок А.

Диалоговое окно Restore Database позволяет просматривать все последние резервные копии в хронологическом порядке. Там же Вы можете выбрать базу данных, которую нужно восстановить. На вкладке Options показанной на Рисунке B, Вы можете выбрать сделующие опции:

Eject tapes after restoring each backup (выгружать ленту после каждого восстановления)
Prompt befor restoring each backup (выдавать дополнительное предупреждение перед началом восстановления каждой копии)
Force restore over existing database (осуществлять восстановление поверх существующей базы данных), эта опция эквивалентна Move в T-SQL.

Рисунок B.

В нижней части окна находятся три переключателя, которые позволяют определить состояние базы после восстановления копии:

Leave Database Operational. No Additional Transaction Logs Can Be Restored.
- Если Вы выбрали это значение, то после загрузки резервной копии будет инициирован процесс восстановления, что приведет к откату всех незавершенных транзакций. Станет невозможной загрузка дополнительных копий журнала транзакций. Пользователи получат возможность нормально работать с базой данных.
Leave Database Nonoperational But Able To Restore Additional Transaction Logs.
- По окончании загрузки копии база данных будет оставаться временно недоступной. Будет необходимо загрузить дополнительные копии, после чего инициировать процесс восстановления.
Leave Database Read-Only And Able To Restore Additional Transaction Logs.
- База данных становится доступной только для чтения. Вы можете загрузить дополнительные резервные копии журнала транзакций. Эта опция используется для создания резервного сервера (Standby Server)

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

Восстановление базы данных с помощью T-SQL.

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

RESTORE DATABASE { database_name | @ database_name_var }
[ FROM < backup_device > [ , ...n ] ]
[ WITH
[ RESTRICTED_USER ]
[ [ , ] FILE = { file_number | @ file_number } ]
[ [ , ] PASSWORD= { password | @ password_variable } ]
[ [ , ] MEDIANAME= { media_name | @ media_name_variable } ]
[ [ , ] MEDIAPASSWORD= { mediapassword | @ mediapassword_variable } ]
[ [ , ] MOVE " logical_file_name " TO " operating_system_file_name " ]
[ , ...n ]
[ [ , ] KEEP_REPLICATION ]
[ [ , ] { NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] REPLACE ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]

Для детального изучения каждой опции следует прочитать описание в SQL Server 2000 Books Online .

На Рисунке C показано восстановление базы данных Pubs из полной копии с устройства резервного копирования.

Рисунок С.

Восстановление базы данных из дифференциальной копии.

Если Вы используете Full или Bulk Recovery Model, Вы должны выполнить сначала восстановление полной резервной копии, затем последней дифференциальной копии и всех журналов транзакций. Для выполнения восстановления базы данных, используя дифференциальную копию, в Enterprise Manager необходимо выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, выбрать восстановления полной и дифференциальной копии базы данных, а затем нажать OK. (исунок D)

Рисунок D.

Синтаксис команды Restore для выполнения восстановления с использованием дифференциальных копий, показан на Рисунке Е.

Рисунок Е.

Восстановление журнала транзакций.

Перед началом восстановления журнала транзакций, Вы должны восстановить полную и последнюю дифференциальную копию базы. Затем Вы можете восстанавливать журналы транзакций в соответсвующем порядке. Если Вы используете Enterprise Manager, нужно выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, выбрать все нужные копии и, если есть необходимость, опцию Point in Time Restore (восстановление на определенный момент времени) (Рисунок F).

Рисунок F.

Синтаксис команды Restore для восстановления журнала транзакций, показан на РисункеG.

Рисунок G.

Подведем итоги. Резервное копирование и восстановление базы данных – это одна из основных, наиболее важных задач администратора баз данных. В любой момент времени Вы должны быть уверены в своей способности восстановить базу данных SQL Server 2000 согласно Вашему плану аварийного восстановления. Если же у Вас нет плана аварийного восстановления, я рекомендую начать работать над ним. В случае, если что-то произойдет и данные будут потеряны, следующей потерей для Вас может стать потеря места работы.