Применение сохо. Современные локальные вычислительные сети SOHO. Выбор оборудования для сетей SOHO

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

Модели восстановления

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

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

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

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

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

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

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

Виды резервных копий

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

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

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

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

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

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

Журнал транзакций

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

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

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

Та часть журнала, которая содержит активные транзакции и используется для восстановления данных называется активной частью журнала. Она начинается с номера, который называется минимальным номером восстановления (MinLSN).

В простейшем случае MinLSN - это номер записи первой незавершенной транзакции. Если посмотреть на рисунок выше, то открыв синюю транзакцию мы получим MinLSN равную 321, после ее фиксации в записи 324, номер MinLSN изменится на 323, что будет соответствовать номеру зеленой, еще не зафиксированной, транзакции.

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

• При явном выполнении инструкции CHECKPOINT. Контрольная точка срабатывает в текущей базе данных соединения.
• При выполнении в базе данных операции с минимальной регистрацией, например, при выполнении операции массового копирования для базы данных, на которую распространяется модель восстановления с неполным протоколированием.
• При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.
• При остановке экземпляра SQL Server с помощью инструкции SHUTDOWN или при остановке службы SQL Server (MSSQLSERVER). И в том, и в другом случае будет создана контрольная точка каждой базы данных в экземпляре SQL Server.
• Если экземпляр SQL Server периодически создает в каждой базе данных автоматические контрольные точки для сокращения времени восстановления базы данных.
• При создании резервной копии базы данных.
• При выполнении действия, требующего отключения базы данных. Примерами могут служить присвоение параметру AUTO_CLOSE значения ON и закрытие последнего соединения пользователя с базой данных или изменение параметра базы данных, требующее перезапуска базы данных.

В зависимости от того, какое событие произошло раньше, MinLSN будет присвоено значение либо номера записи контрольной точки, либо начала самой старой незавершенной транзакции.

Усечение журнала транзакций

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

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

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

Если количество транзакций велико и к моменту достижения 70% размера физического файла не окажется неактивных логических журналов, то размер физического файла будет увеличен.

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

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

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

В этом случае самое время вспомнить то, о чем мы говорили в начале статьи, если затраты на полную модель превышают затраты на восстановление следует отдать предпочтение простой модели.

Простая модель восстановления

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

Резервное копирование выполнялось раз в сутки и последняя копия была создана ночью с 21-го на 22-е. Сбой происходит вечером 22-го до создания очередной копии. В этом случае нам потребуется последовательно восстановить полную и последнюю разностные копии, при этом данные за последний рабочий день будут утеряны. Если по каким-либо причинам копия от 21-го также окажется повреждена, то мы можем восстановить предыдущую копию, потеряв еще день работы, в тоже время повреждение копии за 20-е число никак не помешает успешно восстановить данные на вечер 21-го, при наличии соответствующей копии.

Полная модель восстановления

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

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

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

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

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

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

С другой стороны, если одна из копий лога транзакций будет повреждена, скажем, предпоследняя, то восстановить данные мы сможем только на момент последней резервной копии + период в неповрежденной цепочке копий журналов. Например, если журналы делались в 12, 14 и 16 часов и поврежден журнал, созданный в 14 часов, то располагая суточной копией мы сможем восстановить базу до момента окончания непрерывной цепочки, т.е. до 12 часов.

• Теги:

Можно выделить 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 сек.

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

Резервное копирование данных в 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. Репликация

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

При желании иметь актуальную резервную копию БД, возникает желание использовать конфигурацию дисков RAID, которая обеспечивает создание зеркала с целью защиты данных, но это не панацея. Массивы RAID являются только первой ступенью в деле обеспечения защиты данных от потери. В зависимости от конфигурации массива RAID, один или даже несколько жестких дисков должны выйти из строя, прежде чем произойдет безвозвратная потеря данных. Кроме того, использование дисков «горячей» замены и горячего резерва может быть использовано для того, чтобы сервер продолжал работать без отключения даже в случае выхода из строя жесткого диска. Ключевая вещь, которую вы должен понимать АБД, это то, что массивы RAID могут защитить данные в случае выхода из строя жестких дисков. А что произойдет, если будет ЧП (пожар, потоп, ограбление и т.д.)? Файлы базы данных окажутся, повреждены в результате ошибки программного обеспечения или аппаратного сбоя? Ну и наконец, что будет, если пользователь (или сам АБД) удалит по ошибки данные, которые вдруг потребуются в дальнейшем? Конфигурация RAID не сможет помочь в этих случаях.

Самое главное - администратор может всегда заменить сервер, но данные этого сервера восстановить чрезвычайно трудно, иногда просто невозможно.

Рассмотрим некоторые типы резервного копирования баз данных.

Сервер SQL поддерживает три вида резервного копирования: полное (Full), разностное или дифференциальное (Differential) и копирование журнала (Log). В дополнение к трем основным видам резервного копирования, которые работают со всей базой данных в целом, есть также несколько дополнительных типов резервного копирования, которые используются для копирования одного файла или группы файлов.

Полное резервное копирование (Full) - создает полную резервную копию всех экстентов базы данных. Если АБД будет восстанавливать базу данных, используя для этого полную резервную копию, потребуется только самый последний созданный им экземпляр. Однако, полное резервное копирование - самый медленный тип резервного копирования.

Дифференциальное резервное копирование (Differential) - создает резервную копию только тех экстентов, которые были изменены с момента последнего полного копирования. Если АБД будет восстанавливать базу данных, используя дифференциальную резервную копию, ему потребуется последняя полная резервная копия и последняя созданная им дифференциальная резервная копия. Дифференциальное резервное копирование осуществляется гораздо быстрее, но требует больше времени на восстановление, так как требует применение, как полной резервной копии, так и дифференциальной резервной копии.

Резервная копия журнала - создает резервную копию журнала транзакций с момента последней полной резервной копии или предыдущей копии журнала транзакций. АБД потребуется (или не потребуется) создавать резервные копии журнала транзакций в зависимости от используемой им модели восстановления. Если он будет восстанавливать базу данных, используя полное резервное копирование и копирование журнала транзакций, для восстановления ему потребуется последняя полная резервная копия и все (по порядку) резервные копии журнала транзакций.

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

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

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

Каждая база данных, запущенная на сервере SQL может придерживаться одной из трех моделей восстановления: Полной (Full), Регистрации пакетных операций (Bulk_Logged) и Простой (Simple).

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

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

Модель регистрации пакетных операций (bulk_logged) достаточно похожа на модель полного восстановления с некоторые добавлениями и преимуществами. Как и в полной модели восстановления, в модели регистрации пакетных операций также фиксируются все операторы UPDATE, DELETE и INSERT. Однако, для определенных команд, в данной модели фиксируется лишь то, что операция имела место. Это верно для таких команд как BULK INSERT, bcp, CREATE INDEX, SELECT INTO, WRITETEXT и UPDATETEXT. Модель регистрации пакетных операций похожа на модель полного восстановления тем, что не использует повторно (не перезаписывает) пространство журнала до тех пор, пока не будет произведено резервное копирование всех транзакций.

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

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

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

база данные администрирование документоведение

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

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