Резервное копирование баз данных Microsoft SQL Server. Резервное копирование бд

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

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

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

Так будет значительно надежнее и спокойнее. Если все-таки ваш интернет проект рухнул, а восстанавливать его не из чего, то попробуйте попытать счастье в Webarchive (здесь про более подробно написано), ибо он постоянно делает слепки подавляющего большинства сайтов в интернете.

Как сделать бэкап файлов сайта с помощью FileZilla

Как вы уже, наверное, знаете, сайты , созданные на основе какого-либо движка, будь то Joomla, WordPress или SMF, состоят из двух важных частей :

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

В базе данных (БД) могут храниться также настройки некоторых параметров движка и его расширений. Я уже писал об этом в статье про . Такая организация имеет массу преимуществ.

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

Начнем, пожалуй, с нашего первого помощника под названием FileZilla , хотя вместо нее вы можете использовать любой другой FTP-менеджер, вплоть до , но я предпочитаю именно это детище свободного ПО. мною уже были довольно подробно описаны в приведенной статье, посему останавливаться на этом подробно не будем (хотите — сами почитайте, особливо про хранение в этой программе паролей и проблемы с этим связанные).

Давайте рассмотрим, как сделать бэкап файлов с ее помощью. Получив доступ к серверу своего хостинга, вы должны зайти в корневую папку (она обычно называется public_html или htdocs). Удаленный сервер в Файлзиле отображается справа, а слева отображается содержимое вашего компьютера.

Если бэкап планируете делать регулярно, то советую создать на жестком диске компьютера папку с «говорящим» названием, а внутри нее каталоги с названиями ваших проектов. Внутри этих каталогов можно создавать папки с текущей датой, в которые и будут копироваться файлы вашего веб-проекта. Благодаря этому потом будет проще ориентироваться в резервных копиях и удалять сильно устаревшие для освобождения места.

Теперь открываем в левой части FileZilla папку, куда будет осуществляться резервное копирование, а в правой части — корневую папку вебсайта. Советую включить в настройках этой программы возможность показывать скрытые файлы: в верхнем меню выберете пункт «Сервер» — «Принудительно отображать скрытые файлы» .

Это нужно для того, чтобы в ваш бэкап попали и скрытые файлики, такие, например, как.htaccess. Далее вы выделяете все объекты вашего сайта в корневой директории, удерживая кнопку SHift на клавиатуре. Щелкаете по выделенным объектам правой кнопкой мыши и выбираете из контекстного меню пункт «Скачать» .

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

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

Правда, если вы запаковали файлы в архив ZIP, то его можно будет загрузить на сервер, а уже там распаковать (тут описано, как ). Но при этом могут возникнуть некоторые неприятности с последующим , которые можно решить PHP средствами (читайте по ссылке про права доступа и изменение Cmod программным способом).

Как сделать бэкап базы данных с помощью phpMyAdmin

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

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

Скачав на свой компьютер архив, вы должны его распаковать и залить получившуюся папку (можно для простоты ее предварительно переименовать просто в phpmyadmin) в корневую директорию. В общем-то и все. Теперь останется только ввести в адресной строке вашего браузера следующий Урл: http://vash_sait.ru/phpmyadmin

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

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

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

Внизу открывшейся страницы поставьте галочку «gzip» . И нажмите кнопку «ok».

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

В результате, через некоторое время (которое зависит от скорости работы сервера, его загруженности и размера вашей БД) откроется стандартный диалог копирования, в котором вы должны выбрать место сохранения бэкапа этой БД.

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

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

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

У вас откроется окно со списком всех удаляемых таблиц. Вы нажимаете на кнопку «Да».

Теперь можно восстановить базу данных из сделанной ранее резервной копии. Для этого выбираем закладку «Импорт» :

В открывшемся окне нажимаете на кнопку «Выберете файл» и находите сделанный ранее бэкап этой БД у себя на жестком диске. Жмете на кнопку «Вперед» (или «OK» в старых версиях скрипта) внизу страницы и ждете, когда загрузка закончится (время опять же зависит от скорости сервера и размера базы данных). Все.

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

Перенос сайта на новый хостинг

Итак, как же нам осуществить перенос сайта на новое место жительства? После покупки хостинга вам предоставят данные для доступа к серверу хостинга по FTP, которые вы и введете в программу Файлзила для получения доступа к серверу.

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

Но для этого нужно предварительно на новом хостинге (куда потом будут копироваться сохраненные вами таблицы). Как это сделать вы узнаете из статьи про phpMyAdmin, ссылку на которую я приводил чуть выше. Обратите внимание, что у вас, скорей всего, не получится выбрать имя для БД и ее пользователя такими же как и на предыдущем месте жительства. Дело в том, что на хостинге обычно добавляют к выбранному вами имени БД еще и ваш логин.

Поэтому, после окончания копирования файлов и БД, прежде, чем обращаться к сайту из браузера, следует внести соответствующие изменения в настройки движка вашего сайта . Для этого нужно будет опять же получить доступ к файлам сайта по FTP и внести изменения в конфигурационные файлы того или иного движка (Joomla, WordPress, SMF и др.). Рассмотрим настройки для каждого движка в отдельности.

Что нужно изменить в настройках WordPress при его переносе

Перенос блога на Вордпрессе потребует изменения следующих настроек. Нужно будет открыть на редактирование с помощью FileZilla файл WP-CONFIG.PHP , который находится в корневой директории на сервере. В нем нужно отредактировать строки, отвечающие за название БД и пользователя.

// ** Настройки MySQL - Вы можете получить их у вашего хостера ** // /** Имя БД для WordPress */ define("WP_CACHE", true); //Added by WP-Cache Manager define("DB_NAME", "введите сюда новое имя вашей базы данных"); /** MySQL имя пользователя */ define("DB_USER", "введите сюда новое имя пользователя"); /** MySQL пароль БД */ define("DB_PASSWORD", "anipiimaaxai"); /** MySQL сервер - иногда требуется изменять это значение, например, на Мастерхосте */ define("DB_HOST", "localhost"); /** Кодировка БД, используемая при создании таблиц. */ define("DB_CHARSET", "utf8"); /** Сопоставление БД. НЕ ИЗМЕНЯЙТЕ ЭТО ЗНАЧЕНИЕ. */ define("DB_COLLATE", "");

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

Далее, с помощью встроенного «поиска с заменой», найдите все упоминания старого Урла вашего блога и замените его новый адрес (например, vasy.ru на vova.ru). После этого сохраните файл с резервной копией БД и осуществите его «Импорт» в программе phpMyAdmin.

После того, как вы зайдете в админку Вордпресса, нужно будет еще прописать правильный абсолютный путь к объектам вашего блога (он изменился, т.к. вы перенесли WordPress на другой хостинг). Задается абсолютный путь через параметр UPLOAD_PATH в глобальных настройках WP. Попасть в эти настройки можно, добавив к Урлу главной страницы следующий путь:

/wp-admin/options.php

Для адреса моего блога получится так:

Https://сайт/wp-admin/options.php

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

Что нужно изменить в настройках Joomla при смене хостинга

Перенос на другой хостинг сайта на Joomla потребует изменения следующих настроек. Вам нужно будет открыть на редактирование CONFIGURATION.PHP в корневой папке сервера. Найдите в нем строки, отвечающие за получение доступа к БД:

Var $user = "введите сюда новое имя пользователя"; var $db = "введите сюда новое имя вашей базы данных";

Кроме этого вам нужно будет еще изменить там абсолютный путь к папкам для хранения логов и временных файлов в Joomla. Изменить его нужно в этих строках:

Var $log_path = "/home/xxxxx/public_html/logs"; var $tmp_path = "/home/xxxx/public_html/tmp";

Перенос форума SMF на новый хостинг

Перенос форума на SMF потребует изменения некоторых настроек. Нужно будет открыть на редактирование SETTINGS.PHP из корневой папки форума. Так же, как и в случае с Joomla, здесь тоже нужно будет не только изменить имя БД и пользователя SMF, но и абсолютные пути до папки форума и папки SOURCES форума.

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

Как начать работать с сайтом сразу после его переноса на новый хостинг

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

Адреса DNS серверов вы можете посмотреть в письме, которое вам пришлет ваш новый хостер. Где именно в панели регистратора нужно вводить эти DNS , однозначно сказать трудно, но это должно быть не глубоко закопано и лежать на виду. В крайнем случае обратитесь к службе техподдержки.

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

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

Но владелец хоста в письме всегда указывает IP адрес вашего нового сервера. Используя его, можно получить доступ к своему ресурсу не ожидая прописывания ДНС . Но доступ, в этом случае, получите только вы и только на том компьютере, где вы произведете описанные ниже настройки. Итак, нужно проделать следующее:

1. с помощью любого файлового менеджера открыть для редактирования (по этой ссылке вы найдет подробную статью по тому, где находится этот файл, как его найти в Windows 7 и что в нем должно быть прописано), расположенный по следующему пути: c:\Windows\System32\drivers\etc\hosts
2. в конце содержимого HOSTS нужно дописать строчку: 109.77.43.4 сайт где в начале идет IP адрес нового сервера, а после него, через пробел, домен
3. сохраните этот файл и можете смело набирать в браузере адрес того ресурса, перенос которого вы только что осуществили (может понадобиться сброс ДНС-кэша на компьютере — читайте об этом в приведенной чуть выше статье про файл Хостс)

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

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

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

Приятного просмотра!

Удачи вам! До скорых встреч на страницах блога сайт

посмотреть еще ролики можно перейдя на

Вам может быть интересно

Майкл Вандайн (Michael Vandine), главный технический консультант

Введение

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

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

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

Ниже описаны основные возможности, которые должны быть реализованы для обеспечения точного восстановления:

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

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

Резервное копирование баз данных

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

Резервная копия состоит из базы данных (файл с расширением BKP) и всех log-файлов, требуемых для приведения BKP-файла к согласованному состоянию во время резервирования. Необходимо помнить, что вне зависимости от типа выполняемого резервного копирования резервируемые данные должны быть неповрежденными. Поэтому рекомендуется проверять базу данных ("check database") перед резервным копированием и проводить эту процедуру только тогда, когда база данных находится в устойчивом состоянии.

Резервирование может быть осуществлено либо в режиме онлайн, используя ПО резервного копирования SQLBase (сервер SQLBase запущен, а пользователи подключены к базе данных), либо в режиме оффлайн с помощью стандартных команд операционной системы, т.е. используя COPY (отключен сервер SQLBase либо демонтирована база данных), а затем команду "set nextlog". Наиболее часто используемый вариант - резервирование в режиме онлайн, поскольку для большинства операций очень сложно найти подходящее время, когда все пользователи отключены от всех баз данных, с тем чтобы можно было корректно завершить работу сервера SQLBase или демонтировать все базы данных. Это необходимо, потому что сервер SQLBase удерживает базу данных в виде открытого файла, начиная с момента подключения первого процесса и заканчивая демонтажем базы данных или выключением сервера SQLBase.

SQLBase использует log-файлы транзакций, чтобы фиксировать исходный и преобразованный вид записей изменений базы данных, а также в качестве регулярных контрольных точек управления транзакциями. Они используются для восстановления после сбоев (что выполняется автоматически после прерывания энергоснабжения, отказа сервера и т. д.), отката (если в базу данных были внесены ненужные изменения или сбой стал причиной отмены транзакции) и для восстановления данных (восстановления баз данных).

Следует обратить внимание, что база данных состоит из файла с расширением DBS и log-файлов. В случае удаления log-файлов база данных становится недоступной для использования! По умолчанию SQLBase автоматически удаляет log-файлы после их резервирования, или когда они не нужны для восстановления после сбоев или отката. Это поведение можно изменить, установив для базы данных параметр LOGBACKUP в положение ON с помощью интерфейса SQLTalk. При таком положении параметра log-файлы сохраняются до тех пор, пока не создается их резервная копия с помощью специальной команды "backup logs". Это единственный способ удаления log-файлов. Этот параметр должен находится в положении ON, если необходимо применить команды "backup database" или "backup logs". И наоборот, не нужно устанавливать этот параметр в данное положение, если нет намерений использовать команду "backup logs" или внедрять возможность "rollforward" (восстановление с повтором всех завершенных транзакций) в стратегию восстановления, т. е. если предполагается делать только "моментальные снимки".

Максимальный размер log-файлов, создаваемых для каждой базы данных, можно указать, задав параметр LOGFILESIZE с помощью SQLTalk (по умолчанию этот размер - 1 МБ). Сначала log-файлы имеют минимальный размер, а затем они растут в объеме до указанного предела. Если с помощью SQLTalk установить параметр LOGFILEPREALLOC в положение ON, то есть возможность создавать для каждой базы данных шаблоны log-файлов максимального размера. Если необходимо много log-файлов, можно установить их максимальный объем большим (скажем 5 МБ) и заранее назначить размер файлов. Это приведет к уменьшению числа операций ввода/вывода, необходимых для создания новых файлов или дописывания существующих.

Log-файлы могут быть удалены только после применения команды "release log" или "backup logs", и если они не являются "блокированными". Log-файл оказывается блокированным в следующих случаях:

1. Текущая транзакция осуществляет запись в этот log-файл. Блокировка может быть снята с этого файла только после завершения или отката транзакции.
2. Предпоследняя контрольная точка была создана при использовании данного или предыдущего log-файла. Например, если контрольная точка была создана в 6.log, то этот log-файл и все последующие будут блокированы. В этом случае блокировку можно снять с помощью команды "release log".
3. Параметр LOGBACKUP находится в положении ON, а у данного log-файла еще нет резервной копии. Блокировка с него может быть снята только с помощью команды "backup logs". Исполнение команды "backup snapshot" никак не отразится на блокировке этого log-файла.

Log-файлы, для которых была сделана резервная копия, должны регулярно удаляться вручную. Сохраняются только log-файлы, имеющие прямое отношение к BKP-файлу в области резервного копирования. Например, если в какой-то день создается резервная копия в виде моментального снимка, то все предыдущие резервные копии log-файлов могут быть удалены. Будьте внимательны: эти файлы могут занимать значительный объем дискового пространства.

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

Существует два основных варианта резервирования в режиме онлайн. Первый соответствует использованию команды "backup snapshot" (закончен сам по себе), и второй - последовательному применению команд "backup database", "release log" и "backup logs" (они все необходимы для согласованного резервирования).

Независимо от выбранного варианта, резервное копирование состоит из следующей последовательности шагов:

Создание BKP-файла в избранной области резервного копирования (backup database);
- обновление самых последних log-файлов, поскольку в них содержится вся информация о текущем резервировании (release log);
- копирование всех надлежащих разблокированных log-файлов, предшествующих текущему log-файлу, в избранную область резервного копирования (backup logs).
В случае использования метода моментальных снимков (backup snapshot) все эти шаги выполняются автоматически.

При выполнении резервирования пунктом назначения данных может служить клиентский компьютер или сама сеть. Это указывается в ключе "directory-name" команды резервного копирования. Также необходимо хорошо представлять себе разницу между ключами "on server" и "on client" этой команды. При использовании ключа "on client" все данные и log-файлы будут помещены в указанный каталог определенного компьютера (даже если это сетевой сервер). Использование ключа "on server" приведет к резервированию прямо на сервере без предварительного сохранения данных на клиентском компьютере. Это может привести к значительному выигрышу в скорости резервного копирования и сокращению сетевого трафика!

Если используется ключ "on client", т.е. данные сохраняются на клиентском компьютере, каталог должен быть задан полным локальным путем либо в виде сетевого диска, например, C:\SQLBASE\BACKUPS\DB1 (локальный путь) или F:\BACKUPS\DB1 (сетевой диск). Однако, при применении ключа "on server" указываемый диск должен быть локальным для сервера, а не сетевым. Если используется сервер Novell, то путь к нужному каталогу должен быть указан в формате сервера Novell. Например, если резервное копирование базы данных производится в каталоге:

SERVER1\SYS:SQLBASE\BACKUPS\DB1

моментальный снимок базы данных DB1 может быть сделан следующим образом:

BACKUP SNAPSHOT FROM DB1 TO \SQLBASE\BACKUPS\DB1 ON SERVER;

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

Создание моментальных снимков (команда backup snapshot) - самый простой метод резервного копирования баз данных. В этом случае копируются база данных и log-файлы, необходимые для восстановления базы данных до согласованного состояния. Перед резервированием log-файлов проводится их обновление, что позволяет включить в резервную копию текущий активный log-файл. В этом варианте резервного копирования требуется одна команда для резервирования данных и одна для их восстановления. Обычно этот метод применяется один раз вечером, перед резервным копированием сервера на магнитную ленту, и, может быть, один раз в течение дня. Недостаток этого метода заключается в том, что создание моментальных снимков очень большой базы данных может потребовать значительных затрат времени, и, кроме того, варианты восстановления ограничены возвращением базы данных в состояние на момент формирования последнего моментального снимка. Любые изменения, сделанные после данного снимка, будут потеряны.

Этот метод резервного копирования данных несколько более сложен, но гибкость восстановления стоит дополнительных усилий. Он требует резервного копирования файла базы данных, разблокирования log-файла (поскольку тот содержит информацию о текущей резервной копии), а затем резервирования log-файлов. Внимание! Никогда не делайте резервной копии только одной базы данных без log-файлов. Этот метод резервного копирования позволяет изредка резервировать базу данных вместе с ее log-файлами, после чего регулярно создавать резервные копии только одних log-файлов, например, несколько раз в день. Это позволяет провести восстановление базы данных, а затем использовать возможность "rollforward" log-файлов для восстановления работы, выполненной в течение дня. То, насколько часто создаются резервные копии log-файлов, зависит от объема доступного пространства на диске и от того, какое количество данных пользователь может себе позволить потерять. Заметим: накопление log-файлов может привести к очень быстрому заполнению диска. Такой подход особенно удобен для больших баз данных, поскольку резервное копирование файла базы данных, отнимающее много времени, выполняется редко, а периодическое создание резервных копий log-файлов можно выполнить достаточно быстро. Недостатком метода является скапливание log-файлов до их резервирования.

В прошлом любую базу данных SQLBase размера больше 2 ГБ было необходимо разбивать на части. Начиная с SQLBase версии 7.5.0, это ограничение было поднято для баз данных на всех операционных системах, за исключением семейства Novell. Теперь их размер может расти до 256 ГБ без необходимости разбиения. Впрочем, это ограничение действует только для DBS-файла, а не временных файлов или с расширением.bkp. Чтобы справиться с таким ограничением, был введен новый метод сегментированного резервного копирования.

Сконфигурируйте контрольный файл и положите в тот же каталог, где сохраняются резервные копии. Не нужно вносить какие-либо изменения в операторы резервного копирования или запущенные программы. Сервер SQLBase находит контрольный файл в целевом каталоге и сегментирует резервную копию соответствующим образом. Контрольный файл имеет расширение.bcf, а его имя совпадает с названием резервируемой базы данных. Для создания этого файла можно использовать любой редактор текстовых файлов (например, notepad.exe).

Контрольный файл имеет следующий формат:

FILEPREFIX префикс
DIR каталог, куда помещается резервная копия сегмента
SIZE размер в МБ

Можно указать несколько операторов DIR, чтобы разбить базу данных на сегменты, каждый из которых меньше 2 Гбайт. Заметим, что суммарный объем, задаваемый всеми операторами SIZE, должен быть достаточно большим, чтобы позволить сделать резервную копию всей базы данных. Например:

FILEPREFIX MIKE
DIR C:\BACKUPS\MIKE SIZE 1000
DIR C:\BACKUPS\MIKE SIZE 1000
DIR C:\BACKUPS\MIKE SIZE 500

позволяет создать три файла в каталоге C:\BACKUPS\MIKE:

MIKE.1 1 ГБ
MIKE.2 1 ГБ
MIKE.3 0,5 ГБ

Обратите внимание на то, что эти файлы создаются, только если база данных требует столько места. В приведенном выше примере, если бы размер базы данных составлял лишь 1,8 ГБ, то были бы созданы лишь два сегмента: MIKE.1 и MIKE.2 размером 1 ГБ и 0,8 ГБ, соответственно.

Можно использовать: предоставляемый компанией Gupta интерфейс SQLTalk для выполнения команд, показанных выше; продукт SQLConsole (использует вызовы C/API), чтобы планировать создание резервных копий; собственное программное обеспечение, которое при резервировании учитывает все возможные особенности конкретной системы, например, проводит проверку базы данных перед резервным копированием.

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

Выше были рассмотрены основные моменты и рекомендации по проведению резервного копирования в режиме онлайн. Сделаем их краткий обзор:

1. Выполняйте проверку базы данных ("check database") перед ее резервированием. Если проверка обнаружила ошибки в базе данных, не записывайте ее резервную копию поверх неповрежденной копии.
2. Если не предполагается создать моментальный снимок, проверьте последовательность резервного копирования, т.е. порядок следования команд ""backup database", "release log" и "backup logs".
3. Чтобы сэкономить время, по возможности используйте ключ "on server"!
4. При использовании ключа "on server" на сервере Novell, путь к целевому каталогу должен быть указан в формате сервера Novell, а не в виде сетевого диска.
5. Не удаляйте НИКАКИЕ log-файлы из текущего каталога их хранения, задаваемого утверждением logdir= в конфигурационном файле сервера под названием sql.ini (или утверждение dbdir=, если logdir= не определено).
6. Периодически удаляйте из области резервного копирования старые log-файлы, чтобы освободить пространство на диске. Не стирайте файлы, относящиеся к текущему BKP-файлу. Безопасным является удаление из области резервного копирования любых log-файлов, которые были созданы раньше текущего BKP-файла.
7. Если параметр LOGBACKUP находится в положении ON и используется команда "backup snapshot", log-файлы не будут разблокированы. Чтобы добиться этого, выполните команду "backup logs".
8. Не помещайте резервные копии в подкаталог самой базы данных.
9. Если во время создания резервной копии в виде моментального снимка была произведена перезагрузка клиентского компьютера, то при попытке повторного резервирования базы данных может появиться сообщение о том, что резервное копирование уже находится в процессе выполнения. Это может произойти при подключении к серверу до завершения предыдущего сеанса. Возникшее затруднение можно преодолеть, завершив прерванный сеанс с помощью SQLConsole или перезапуска сервера SQLBase.

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

Для создания резервных копий DBS-файла базы данных и всех log-файлов из ее каталога, используйте команды или утилиты операционной системы (например, команду "copy" или средства ARCServe). Если параметр LOGBACKUP находится в положении OFF, log-файлы копироваться не будут. Однако, если он находится в положении ON, необходимо сообщить серверу SQLBase, были ли log-файлы резервированы или они останутся "блокированным". Это можно сделать с помощью команды "nextlog" из арсенала интерфейса SQLTalk от Gupta. Для этого требуется быть подсоединенным к базе данных. Используется следующий формат:

SET NEXTLOG [целое число]

Заданное число указывает следующий резервируемый log-файл. Например, если последними в архив были отправлены резервные копии 4.LOG и 5.LOG, нужно выполнить команду "set nextlog 6".

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

Восстановление базы данных

Здесь описываются различные варианты восстановления базы данных до согласованного состояния на основе выбранных настроек резервного копирования.

Комплект восстановления состоит из резервных копий BKP-файла и связанных с ним log-файлов. BKP-файл бесполезен без ассоциированных log-файлов. Процесс восстановления, по существу, проходит в три этапа:

1. Скопируйте BKP-файл в каталог базы данных.
2. Скопируйте log-файлы в каталог базы данных.
3. Запустите двухходовой (redo и undo) процесс rollforward (восстановление с повтором всех завершенных транзакций) в отношении нового DBS-файла.

Команда восстановления имеет следующий формат:

В случае использования команды "restore snapshot", дальнейшие действия не требуются, поскольку все этапы восстановления будут выполнены автоматически. При выборе варианта "restore database" после восстановления базы данных нужно выполнить команду "rollforward". Следует отметить, что, как и в фазе резервного копирования, при использовании ключа "on server" (при котором время восстановления значительно сокращается) на сервере Novell, путь к целевому каталогу должен быть указан в формате сервера Novell, а не в виде сетевого диска. Процесс rollforward заключается в восстановлении всех изменений, сделанных после резервирования базы данных, чтобы привести ее в согласованное состояние. Log-файлы содержат информацию обо всех транзакциях, как успешных, так и тех, для которых был произведен откат. В процессе rollforward обращение к log-файлам происходит дважды. Во время прохода "redo" SQLBase локализует начальную точку всех транзакций и применяет все успешные транзакции к данной резервной копии. В проходе "undo" происходит обращение всех транзакций, для которых производился откат. В конце процесса отката база данных находится в полностью согласованном состоянии без незавершенных транзакций. Команда "rollforward" имеет следующий формат:

При использовании команды "rollforward to backup" будет восстановлена вся работа, совершенная вплоть до момента создания резервной копии базы данных. Это эквивалентно исполнению команды "restore snapshot". При этом не восстанавливаются никакие дополнительные log-файлы, которые могли быть резервированы после создания исходной резервной копии.

Команда "rollforward to time" позволяет восстанавливать данные до определенного момента времени. Это очень хорошо подходит для отката значительного объема ошибочно сделанных изменений. Например, если какой-нибудь новый неосторожный программист удалил половину базы данных и зафиксировал это изменение, то ее можно восстановить до состояния на момент удаления с помощью резервной копии и процесса rollforward.

В результате команды "rollforward to end" обрабатываются все log-файлы с последовательными номерами, начиная с первого файла от момента создания резервной копии. В этом случае восстанавливается максимально возможный объем работы. После обработки последнего log-файла появится сообщение о том, что следующий log-файл не может быть найден. Это нормально! Просто выполните команду "rollforward end", чтобы завершить восстановление и процесс rollforward.

Обратите внимание, что необходимо иметь и последовательно использовать ВСЕ log-файлы, чтобы откат был успешным. Если какие-либо log-файлы потеряны, операция rollforward будет остановлена в ожидании пропущенных файлов. Если это возможно, можно применить команду "restore logs", чтобы сделать нужные log-файлы доступными, а затем использовать команду "rollforward continue", чтобы продолжить процесс. Если какой-то из необходимых log-файлов недоступен, примените команду "rollforward end" для завершения процесса. База данных будет восстановлена только с учетом последнего обработанного log-файла.

Пара советов, на что нужно обратить особое внимание при проведении восстановления базы данных:

1. После завершения исполнения команды "restore snapshot" может появиться сообщение "cannot connect to the database" (не удается подключиться к базе данных). По существу, это проблема синхронизации. После завершения восстановления старая база данных удаляется, BKP-файл копируется из каталога резервного копирования в каталог базы данных и устанавливается. После этого процесс восстановления пытается подсоединиться к базе данных для обработки log-файлов. Если система загружена или сервер SQLBase слишком медленно работает, чтобы вовремя обработать сообщение об обновлении установки базы данных, процесс восстановления не может к ней подключиться. Решением этого затруднения является увеличение значения параметра CONNECTTIMEOUT в секции маршрутизатора (router) конфигурационного файла sql.ini. Этот параметр указывает время ожидания (в секундах) после неудачного подключения к серверу перед следующей попыткой соединения. Например, если для успешного подключения к базе данных нужно задать параметру CONNECTTIMEOUT значение 20, создайте в секции маршрутизатора строку со значением: connecttimeout=20.
2. Наличие одного только BKP-файла без log-файлов означает большую проблему. Тем не менее, и в этом случае можно попытаться что-то сделать. Иногда это работает, но ничего нельзя гарантировать. Предположим, что база данных называется MIKE.BKP. Используя SQLTalk, выполните команду задания имени сервера (set server), а затем сделайте следующее:

RESTORE DATABASE FROM [путь к каталогу резервных копий] ON SERVER TO MIKE;

Появится сообщение <> (База данных восстановлена. Используйте команду rollforward для завершения восстановления).

ROLLFORWARD MIKE TO BACKUP; (Заметим, что "to backup" - похоже, единственная опция, которая может сработать)
Возникнет сообщение <> (Вначале необходимо восстановить базу данных).

ROLLFORWARD MIKE TO BACKUP; (Да, исполните эту команду еще раз!) Будет выдано сообщение <> (Процесс rollforward завершен).

CONNECT MIKE 1 username/password;
Появится сообщение <> (Установлено соединение с базой данных MIKE).
Проведите проверку базы данных (команда "check database"), чтобы узнать о ее состоянии.

Сценарии

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

Ниже приведены несколько сравнений различных методов резервного копирования, чтобы дать представление о требованиях к дисковому пространству и возможностях восстановления. Предполагается следующее: стандартный размер log-файла - 1 МБ, их отсчет начинается с 1.LOG, для всех log-файлов созданы шаблоны максимального размера и все транзакции завершены до создания резервных копий.

Если в этот момент произошел отказ системы, возможности восстановления будут доступны только для предыдущей резервной копии. Восстановление последних трех log-файлов транзакций невозможно, так как нарушена непрерывность последовательности log-файлов (файлы 1-7 в области базы данных были разблокированы, поскольку транзакции были завершены и не нуждались в восстановлении после сбоя или в откате).

После моментального снимка:

Область базы данных Область резервного копирования

Заметим, что файл 4.LOG из области резервного копирования предназначен для удаления, поскольку соответствующие ему транзакции включены в файл DB1.BKP, а создан он был раньше этого файла.

Заметим, что все log-файлы находятся в области базы данных до их резервирования командой "backup logs", даже если все транзакции были завершены.

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

Если в этот момент произошел отказ системы, возможности восстановления доступны для самой последней транзакции путем восстановления BKP-файла, обработки сначала log-файлов 1-4 из области резервного копирования, а затем файлов 5-8 из области базы данных.

_____________________________________________
После завершения методов "release log" и "backup logs"

Заметим, что ни один log-файл из области резервного копирования не предназначен для удаления, поскольку они ВСЕ должны быть использованы вместе с DB1.BKP из той же области, чтобы сделать его согласованным с файлом DB1.DBS из области базы данных.

Заметим, что раз были созданы резервные копии базы данных и log-файлов, log-файлы 1-10 из области резервного копирования могут быть разблокированы, поскольку новый BKP-файл должен содержать все соответствующие транзакции, а дата и время их создания будут более ранними, чем у файла DB1.BKP.

Заключение

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

Копирование баз данных

Используемые базы данных делятся на две категории: 3 системные БД (oktell, oktell_cc_temp и oktell_settings) и БД для модулей веб-клиента Okapp. Для запуска Oktell после восстановления нужны только системные базы. Остальные БД нужны только, если вы хотите сохранить ваши настройки веб-модуля.

Например, база WO_Module_journal используется модулем Журнал хранит в себе теги записей разговоров. База WO_Module_dashboards нужна для работы модуля Дашборды Okboard и содержит настройки используемых индикаторов.

Шаг 1. Копии системных таблиц создаются автоматически каждый день, по умолчанию в 02:00 по серверному времени, если не отключен параметр DBAutoDailyBackup . Создание копий происходит особым образом, оставляя копии

• последние две недели - каждый день
• далее три месяца - раз в неделю
• далее два года - каждый месяц
• далее раз в год

Все копии находятся в папке \oktell\server\Backup, если не переопределено в параметре DBBackupDir .

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

После окончания резервного копирования созданные бэкапы будут доступны в корне папки oktell\server\backup .

Шаг 2. Для созданий копий остальных баз данных откройте SQL Server Management Studio. Кликните правой кнопкой на нужной БД и в контекстном меню выберите Задачи, затем Создать резервную копию . В открывшемся окне вы можете поменять путь для создания бэкапа, для начала копирования нажмите ОК. Копии по умолчанию создается в папке C:\Program Files\Microsoft SQL Server\MSSQL11.OKTELL\MSSQL\Backup\ .

Восстановление баз данных

Восстановить базы данных можно только на такую же версию SQL-сервера или выше. Если базы были созданы на версии SQL Server 2008 R2, их нельзя восстановить на SQL Server 2008.

Шаг 1. Остановите службу oktellserver. Запустите командную строку с правами администратора и введите туда следующую строчку:

Net stop oktellserver

Шаг 2. Запустите SQL Server Management Studio с учетной записью sa:

• Login: sa
• Password: 123Oktell321

Шаг 3. Если у вас есть ранее установленные базы данных Oktell, то их нужно удалить. Это касается системных БД и БД, используемых веб-модулями.

Шаг 4. Приступаем к процедуре восстановления. Нажмите правой кнопкой на System Database (Системные базы данных) и нажмите Restore Database (Восстановить резервную копию).

Выберите файл с копией баз данных. Для этого выберите пункт Device (Устройство), в открывшемся окне Add (Добавить) и выберите ваш файл с резервной копией, например db_ok_130628.bak (в данном случае, это БД oktell).

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

Повторите тоже самое с остальными базами данных.

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

Шаг 6. Если вы перенесли базу данных на сторонний сервер, то проверьте настройки в серверном конфигурационном файле \oktell\server\oktell.ServerService.exe.config . Убедитесь что в строке с ключом DBConnectionString ссылка на базу данных, логин и пароль указаны верно. По умолчанию, строка подключения выглядит следующим образом:

Server=(local)\OKTELL;database=oktell;uid=AutelService;pwd=;pooling=true

Новое название сервера нужно указать вместо значения (local)\OKTELL . Например, SQL-сервер перенесен на сервер WORK с IP-адресом 192.168.0.3. Следовательно, в параметре вам нужно указать WORK\OKTELL . Если сервер не запускается с этой настройкой, попробуйте указать только название сервера без инстанса - WORK . Вместо названия сервера можно указать IP-адрес - 192.168.0.3/OKTELL или только 192.168.0.3 .

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

Узнать название вашего сервера (инстанс) вы всегда можете с помощью команды

Sqlcmd.exe -L

в командной строке Windows.

Шаг 7. Запустите службу oktellserver . Для этого в командной строке выполните