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

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

• MySQL

Резервное копирование базы данных - это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы - это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья - для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.

1. Копирование файлов базы

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

Некоторые файловые системы, например, ZFS, поддерживают снятие снэпшотов нативно. Если вы не пользуетесь ZFS, но на вашем сервере стоит менеджер томов LVM, вы также сможете скопировать базу MySQL через снэпшот . Наконец, под *nix можно воспользоваться драйвером снэпшотов R1Soft Hot Copy , но этот способ не заработает в контейнере openvz ().

Для баз MyISAM существует официальная бесплатная утилита mysqlhotcopy , которая «правильно» копирует файлы баз MyISAM без остановки сервера. Существует аналогичная утилита для InnoDB , но она платная, хотя и возможностей в ней больше.

Копирование файлов - самый быстрый способ перебросить базу данных целиком с одного сервера на другой.

2. Копирование через текстовые файлы

В большинстве случаев намного более удобна созданная Игорем Романенко утилита mysqldump . Утилита mysqldump формирует файл, содержащий все SQL-команды, необходимые для полного восстановления БД на другом сервере. Отдельными опциями можно добиться совместимости этого файла с практически любой СУБД (не только MySQL), кроме того, существует возможность выгрузки данных в форматах CSV и XML. Для восстановления данных из таких форматов существует утилита mysqlimport .

Утилита mysqldump консольная. Существуют её надстройки и аналоги, позволяющие управлять бэкапом через веб-интерфейс, например, украинская тулза Sypex Dumper (их представитель есть на хабре).

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

3. Инкрементные бэкапы

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

Здесь практически вне конкуренции система Percona XtraBackup , которая содержит модифицированный движок InnoDB, анализирует двоичные логи MySQL и вытаскивает из них необходимую информацию. Почти такими же возможностями обладает платная InnoDB Hot Backup, упомянутая выше.

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

4. Репликация

Для целостности ИТ инфраструктуры крайне важно обеспечить правильное резервное копирование базы данных. Как правило, при этом важно соблюдать требования политики безопасности. Реализованные на базе плагинов для СУБД передовые решения Bacula Systems позволят любой компании-пользователю Bacula Enterprise быстро и надежно производить резервное копирование баз данных.

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

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

Упрощает процедуры резервного копирования и восстановления баз данных Oracle. Администраторы БД Oracle могут воспользоваться командами RMAN с целью более простого и удобного резервного копирования базы данных. Помимо скорости и простоты, плагин для Oracle существенно оптимизирует прочие важные функции, в том числе восстановление БД на любой момент времени, а также фильтр объектов во время резервного копирования и восстановления. Все эти возможности доступны при использовании любого из двух методов резервного копирования, а именно “Dump” метода и метода восстановление до заданной контрольной точки (PITR) с помощью тесной интеграции плагина с диспетчером восстановления Oracle RMAN.

Плагин также задействует RMAN API sbt, что позволяет исключать запись файлов в первую очередь на локальные диски. И в режиме “Dump”, и в режиме RMAN плагин создает резервную копию значимой информации, что является бест-практикой администрирования Oracle DB. Как правило, методы “Dump” и RMAN PITR используются совместно для резервного копирования одного и того же кластера.

Повышение эффективности инкрементального и дифференциального резервного копирования Oracle
​

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

​
Восстановление данных Oracle
​

Как показано на рисунке ниже, плагин для Oracle позволяет восстанавливать БД с помощью утилит RMAN или используя метод Dump.

​Поддерживаемые версии платформы Oracle для бэкапа​​

Плагин доступен для 32 и 64-битной версии Linux и совместим с БД Oracle версий 10.x, 11.x.

Резервное копирование и восстановление PostgreSQL​​​

Был разработан с целью упростить процедуры резервного копирования и восстановления кластеров БД PostgreSQL. Администратору не нужно знать внутренние методы резервного копирования PostgreSQL или процедуры написания сложных скриптов. Плагин автоматически создает резервную копию значимой информации, например, конфигурации БД, определений пользователей, табличных пространств. Плагин для PostgreSQL поддерживает два метода создания резервных копий “Dump” и PITR.

Используя уникальную технологию включения последних данных Late Data Inclusion (LDI) от компании Bacula Systems, данный плагин эффективно захватывает данные вплоть до момента завершения создания бэкапа, тем самым, сводя к минимуму риск их потери. Это является преимуществом плагина по сравнению с решениями других вендоров.

​Горячее резервное копирование базы данных PostgreSQL​​​​

Плагин Bacula Systems для PostgreSQL также позволяет администратору БД создавать бэкапы серверов PostgreSQL в режиме «горячего резервного копирования» с резервным копированием WAL файлов.

​Восстановление PostgreSQL​​​

Содержимое кластера

Содержимое базы данных

Поддерживаемые версии платформы PostgreSQL для бэкапа

​​Резервное копирование базы данных PostgreSQL доступно используется под 32 и 64-битные версии Linux и поддерживает PostgreSQL версий: 8.4, 9.0, 9.1 и 9.2. Работает на базе ПО Bacula Enterprise версии 6.0.6 и выше.

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

Был разработан с целью упростить процедуры резервного копирования и восстановления серверов MySQL. Администратору не нужно знать внутренние методы резервного копирования MySQL или процедуры написания сложных скриптов. Плагин конфигурируем и автоматически создает бэкапы значимой информации, например, конфигурации БД и определений пользователей. Плагин для MySQL поддерживает два метода создания резервных копий “Dump” и “Binary”.

Возможность выбора методики резервного копирования базы данных MySQL​

Позволяет администратору выбирать метод Dump или Binary для более быстрого резервного копирования и создания больших по объему бэкапов. Плагин для MySQL обрабатывает лог-файлы MySQL при использовании функции создания PITR бэкапов.

Восстановление данных БД MySQL​

Восстановление единичной БД MySQL

Поддерживаемые версии платформы MySQL для бэкапа​

​Резервное копирование и восстановление базы данных MySQL доступно под 32 и 64-битные версии Linux и поддерживает MySQL версий 4.0.x, 4.1.x, 5.0.x, 5.5.x, 5.6.x.
​

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

​VSS плагин – один из двух способов резервного копирования базы SQL Server с помощью ПО Bacula Systems. Резервное копирование базы данных SQL Server через VSS плагин разработано для бэкапа нескольких специфических компонентов Windows, в частности базы SQL Server. Плагин Bacula Enterprise VSS существенно упрощает создание резервных копий БД SQL Server.
​

Быстрый и простой способ восстановления базы данных SQL​ Server

​VSS плагин способен восстанавливать либо master, либо прочие инстансы БД. Все БД, за исключением master, могут быть восстановлены во время работы MS SQL. VSS плагин также может быть использован совместно с процессом перемещения БД MS SQL.

Дерево SQL сервера во время восстановления

Перемещенная БД

Поддерживаемые версии резервного копирования базы данных SQL

Резервное копирование базы данных SQL осуществляется под Windows 2003 SP1 и выше, Windows 2008 R1 и Windows 2008 R2.

Резервное копирование базы данных SQL — расширенные возможности

– это современное решение для создания резервных копий множества БД MS SQL, позволяющий:

• Осуществлять полное резервное копирование, при котором сохраняются файлы БД и лог-файлы транзакций, что позволяет избегать отказа системы хранения данных.
• При дифференциальном резервном копировании сохраняется только те данные, которые были изменены с момента создания последнего полного бэкапа. Плагин Bacula Enterprise для SQL Server включает интегрированные опции по повышению класса резервного копирования с дифференциального до полного если это необходимо.
• Создание инкрементальных бэкапов посредством резервного копирования логов транзакций. В случае конфигурации по соответствующей модели, данный метод позволяет использовать режим PITR.
• Резервное копирование master-БД для создания резервной копии информации о конфигурации MS SQL.

Мощный инструмент восстановления баз данных SQL​

Плагин Bacula Enterprise для SQL способен восстанавливать данные несколькими способами, в том числе с использованием восстановления до контрольной точки PITR. В таком случае процесс восстановления предполагает следующие сценарии:

• Восстановление файлов на диск
• Восстановление исходной БД
• Восстановление БД с новым именем
• Восстановление БД с новым именем и перемещением файлов

Модель создания бэкапа БД “с полным и неполным протоколированием”

Поддерживаемые версии платформы MS SQL для бэкапа

​Резервное копирование базы данных MS SQL возможно под Windows 2003 R2, Windows 2008 R2, Windows 2012 и для MS SQL Server 2005, 2008 и 2014.

Интересует резервное копирование базы данных с Bacula Enterprise и квалифицированная поддержка? Смотрите видео.​

Можно выделить 5 основных причин потери данных:

1. Программные ошибки — Возникновение условий, приводящих к аварийному завершению системы. Поскольку такие ошибки основываются на дефектах программной логики, система баз данных не может выполнить восстановление в подобных ситуациях. Поэтому восстановление должен проводить сам программист, выполнив обработку таких исключений.
2. Ошибки администратора (человеческий фактор) — Случаи, в которых пользователь с большими полномочиями может неумышленно (или умышленно) разрушить данные. Необходимо постараться создать такой режим работы, который сделает подобную ситуацию маловероятной, однако совсем исключать такую возможность нельзя.
3. Выход из строя компьютера (сбой системы) — Возникает в результате ошибок в оборудовании и программном обеспечении. В этом случае содержимое оперативной памяти компьютера может быть потерянно. В качестве защиты, можно рекомендовать использование резервного сервера, зеркальное отображение баз данных и пр.
4. Отказ дискового накопителя — Физическое разрушение жесткого диска. Рекомендуется использование технологий RAID для хранения файлов баз данных, кроме того необходимо, чтобы файлы резервных копий хранились на дисковом носителе, отличным от устройства, на котором располагаются файлы баз данных.
5. Катастрофы (пожар, наводнение, землетрясение) или кража — Обойти эту ситуацию станет возможным, если устройство, содержащее необходимую для восстановления данных информацию, будет храниться отдельно от основного оборудования и не будет потеряно в результате катастроф или краж.

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

2. Типы резервного копирования

Существует 2 режима создания резервных копий:

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

MS SQL Server поддерживает оба режима создания резервных копий.

3. Модели восстановления баз данных

Выбор модели восстановления базы данных определяет объем данных, который может быть потерян во время разрушения базы данных, а также скорость использования, размер резервной копии протокола транзакций и период времени, необходимый для резервного копирования протокола. MS SQL Server поддерживает три модели восстановления:

1. Полная модель восстановления — модель, при которой все операции записываются в протокол транзакций. Поэтому эта модель предоставляет полную защиту против сбоев внешних устройств.
   • Преимущества:
     1. Есть возможность восстановить базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола.
     2. Возможно восстановить данные на любой момент времени.
     3. Возможно восстановить данные на отметку в протоколе. Отметки в протоколе соответствуют заданной транзакции и добавляются только если эта транзакция подтверждается.
     4. Протоколируются все операции, связанные с изменением индекса. В этом случае пересоздание индекса выполняется быстрее, потому что не надо создавать их заново.
   • Недостатки:
     1. Соответствующий протокол транзакций может быть очень большим по объему, и файлы на диске, содержащие этот протокол, могут увеличиваться в размере очень быстро. В связи с этим возможно заполнение протокола транзакций.
     2. Протокол транзакций должен быть защищен от сбоев внешних устройств. По этой причине использование технологии RAID для защиты протокола транзакций строго рекомендуется.
     3. Требуется значительно больше времени на резервное копирование.
   • Заключение:
     Данная модель восстановления рекомендована для производственных баз данных, если позволяет аппаратная часть сервера баз данных.
2. Модель восстановления с неполным протоколированием — То же, что и полная модель восстановления, за тем исключением, что не ведется протоколирование массовых или bulk-операций . А резервные копии протокола транзакций содержат в этом случае результат такой операции.
   • Преимущества:
     1. Как и с полной моделью восстановления, есть возможность восстановить базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола.
     2. Возможно восстановить данные на любой момент времени, если не выполнялось объемных операций.
     3. Возможно восстановить данные на отметку в протоколе, если не было объемных операций.
     4. Объемные операции выполняются намного быстрее, чем под полной моделью восстановления, так как они не протоколируются.
     5. Для резервной копии протокола требуется гораздо меньше памяти, чем в случае полного восстановления.
   • Недостатки:
     1. Те же, что и при полной модели восстановления.
     2. Не протоколируется операции с изменением индекса. При восстановлении, индексы потребуется создать заново.
     3. Восстановление с резервной копии протокола дольше, нежели при полной модели восстановления.
     4. Нет возможности восстановить данные на момент времени или на отметку в протоколе в случае объемных операций.
   • Заключение:
     Модель восстановления с неполным протоколированием используется для производственных баз данных в тех случаях, когда периодически происходят крупномасштабные или объемные bulk-операции.
3. Простая модель восстановления — В простой модели восстановления протокол транзакций усекается, если появляется точка восстановления. Но это не означает, что вообще не существует протоколирования, содержимое протокола используется во время создания контрольной точки, где все транзакции протокола подтверждены или для них выполнен откат.
   • Преимущества:
     1. Производительность всех объемных операций очень высокая.
     2. Низкие требования к объему памяти протокола.
   • Недостатки:
     1. Данные возможно восстановить только на момент последнего резервного копирования, а значит недопустимы восстановления на конкретный момент времени или на отметку в протоколе. Все изменения с последнего резервного копирования должны быть восстановлены вручную.
   • Заключение:
     Рекомендуется использовать простую модель восстановления для производственных баз, только в тех случаях, когда сервер баз данных не обладает достаточным объемом памяти или когда аппаратная часть сервера баз данных ниже рекомендуемой.

4. Методы резервного копирования

MS SQL Server предоставляет 4 различных метода резервного копирования:

1. Полное копирование базы данных (Full) —При полном резервном копировании создается резервная копия всей базы данных целиком, она включает в себя схему всех таблиц, соответствующие файловые структуры, а также содержит все данные из этой базы на момент завершения резервного копирования. Это осуществляется благодаря тому, что полное копирование захватывает состояние базы данных на момент начала копирования. А затем, если копирование выполняется динамически, система записывает любые действия, которые имеют место в процессе создания копии.
   • Преимущества:
     Быстрая скорость восстановление базы данных.
   • Недостатки:
     Полное резервное копирование требует больше времени и требует больше пространства для хранения, чем другие методы копирования.
   • Заключение:
     Для небольших баз данных, которые можно скопировать быстро, лучше всего применять полное резервное копирование. Но для больших баз требуется кроме полных резервных копий, создавать также и дифференцированные (разностные) копии баз данных.
     
2. Дифференцированное (разностное) резервное копирование (Differential) — В этом случае создается копия только частей баз данных, которые менялись с момента последнего полного копирования баз данных. Эта полная резервная копия называется основой для разностной копии. Как и в случае полного резервного копирования, любые действия, имеющие место во время создания копии, также копируются.
   • Преимущества:
     Этот тип резервного копирования минимизирует время, требуемое для копирования, т. к. количество копируемых данных значительно меньше, чем при полном копировании.
   • Недостатки:
     Для восстановления необходимо загрузить сначала полную копию баз данных, а затем разностную, что занимает больше времени. И, соответственно, нет смысла применять разностное копирование без полного.
   • Заключение:
     Используется на больших базах данных в связке с полным резервным копированием.
3. Резервное копирование протокола транзакций (Transaction log) — Данный вид копирования применяется при полной модели восстановления (или при неполном протоколировании) баз данных, и учитывает только изменения, записанные в протокол транзакций. Поэтому такая форма резервного копирования не основывается на физических страницах баз данных, а только на логических операциях.
   • Преимущества:
     1. Самая быстрая скорость создания копии.
     2. В отличии от дифференцированных резервных копий, где возможно восстановить базу данных только на момент последнего копирования, позволяет восстановить базу данных на конкретный момент времени.
     3. Правильное «закрытие» протокола транзакций перед началом новой порции действий с этим протоколом. Одна из наиболее общих ошибок системы возникает, когда переполняется протокол транзакций. Если память, используемая для протокола транзакций, заполняется на 100%, то система должна остановить все выполняющие транзакции, пока память не будет освобождена. Эта проблема может быть устранена только при частом выполнении резервного копирования протокола транзакций: каждый раз происходит «закрытие» порции существующего протокола и сохранение на другом внешнем устройстве. Эта порция протокола становится повторно используемой, следовательно, система восстанавливает дисковое пространство.
   • Недостатки:
     Более долгий процесс восстановления, чем при дифференцированном резервном копировании, где требуется полная копия базы данных и последняя разностная копия, в данном случае потребуется полная копия и все существующие копии протоколов транзакций.
   • Заключение:
     Рекомендуется применять на производственных базах данных в связке с полным резервным копированием.
     
4. Резервное копирование файлов или файловых групп — Данный метод позволяет копировать указанные файлы баз данных вместо копирования всей базы данных. Отдельные файлы могут быть восстановлены из копии, позволяя выполнить восстановление после сбоя, который повлиял лишь на небольшое подмножество файлов баз данных.
   • Заключение :
     Копирование файлов базы данных рекомендуется выполнять только когда база данных является очень большой, и нет достаточно времени для полного копирования базы данных.

5. Какие базы данных и как часто копировать?

1. База данных master является наиболее важной базой данных системы, потому что она содержит информацию обо всех базах данных в этой системе. Поэтому резервное копирование базы данных master должно происходить на регулярной основе. Кроме того, рекомендуется создавать копию каждый раз, когда выполняются действия, приводящие к модификации базы данных master . Вот некоторые из них:
   • Выполнение операторов и хранимых процедур;
   • Создание, изменение и удаление базы данных;
   • Изменения протокола транзакций.
2. Следует выполнять резервное копирование всех производственных баз данных на регулярной основе. Дополнительно, необходимо делать резервную копию после того как с базами данных были выполнены следующие изменения:
   • После создания базы данных;
   • После создания индексов;
   Microsoft SQL Server 2008 R2

Базы данных:

• Общий объем баз данных: ~ 95 Гб
• Объем базы данных master : ~ 5 Мб
• Объем базы данных DB 1 : ~ 23 Гб
• Модель восстановления базы данных DB 1 : Полная
• Прирост базы данных DB 1 в день: ~ 200 Мб

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

• Время создания полной резервной копии: ~ 5 мин.
• Время создания копии протокола транзакций: ~ 4 сек.
• Размер полной резервной копии (с сжатием): ~ 1,6 Гб
• Размер копии протокола транзакций: ~ 20 Мб

Необходимое дисковое пространство для плана резервного копирования DB 1 :

• Хранение полных резервных копий (1 месяц): ~ 50 Гб
• Хранение копий протокола транзакций (1 месяц): ~ 10 Гб
• Хранение полных копий от 1-ого числа каждого месяца (1 год): ~ 20 Гб
• Итого размер дискового пространства: ~ 80 Гб
• Итого размер дискового пространства в % от размера базы: ~ 350 %

Время восстановления базы данных DB1 :

• Время восстановления полной резервной копии: ~ 5 мин.
• Время восстановления копии протокола транзакций: ~ 5 сек.

Помогла ли Вам данная статья?

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

Используемые базы данных делятся на две категории: 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 . Для этого в командной строке выполните

Резервное копирование базы данных - это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы - это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья - для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.

1. Копирование файлов базы

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

Некоторые файловые системы, например, ZFS, поддерживают снятие снэпшотов нативно. Если вы не пользуетесь ZFS, но на вашем сервере стоит менеджер томов LVM, вы также сможете скопировать базу MySQL через снэпшот . Наконец, под *nix можно воспользоваться драйвером снэпшотов R1Soft Hot Copy , но этот способ не заработает в контейнере openvz ().

Для баз MyISAM существует официальная бесплатная утилита mysqlhotcopy , которая «правильно» копирует файлы баз MyISAM без остановки сервера. Существует аналогичная утилита для InnoDB , но она платная, хотя и возможностей в ней больше.

Копирование файлов - самый быстрый способ перебросить базу данных целиком с одного сервера на другой.

2. Копирование через текстовые файлы

В большинстве случаев намного более удобна созданная Игорем Романенко утилита mysqldump . Утилита mysqldump формирует файл, содержащий все SQL-команды, необходимые для полного восстановления БД на другом сервере. Отдельными опциями можно добиться совместимости этого файла с практически любой СУБД (не только MySQL), кроме того, существует возможность выгрузки данных в форматах CSV и XML. Для восстановления данных из таких форматов существует утилита mysqlimport .

Утилита mysqldump консольная. Существуют её надстройки и аналоги, позволяющие управлять бэкапом через веб-интерфейс, например, украинская тулза Sypex Dumper (их представитель zapimir есть на хабре).

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

3. Инкрементные бэкапы

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

Здесь практически вне конкуренции система Percona XtraBackup , которая содержит модифицированный движок InnoDB, анализирует двоичные логи MySQL и вытаскивает из них необходимую информацию. Почти такими же возможностями обладает платная InnoDB Hot Backup, упомянутая выше.

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

4. Репликация