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

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

Виды бэкапов баз данных

Для начала разберемся с тем, какие вообще бывают бэкапы. Сервер баз данных не является обычным десктопным приложением, и, чтобы обеспечить выполнение всех свойств ACID (Atomic, Consistency, Isolated, Durable), используется ряд технологий, а поэтому создание и восстановление БД из архива имеет свои особенности. Существуют три различных подхода к резервному копированию данных, каждый из которых имеет свои плюсы и минусы.

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

Физический бэкап (уровня файловой системы) - копирование файлов, которые СУБД использует для хранения данных в базе данных. Но при простом копировании игнорируются блокировки и транзакции, которые, скорее всего, будут неправильно сохранены и нарушены. При попытке присоединить этот файл он будет в несогласованном состоянии и приведет к ошибкам. Чтобы получить актуальный бэкап, базу данных нужно остановить (можно уменьшить время простоя, использовав два раза rsync - вначале на работающей, потом на остановленной). Недостаток этого метода очевиден - нельзя восстановить определенные данные, только всю базу данных. При старте БД, восстановленной из архива файловой системы, нужно будет провести проверку на целостность. Здесь используются разные вспомогательные технологии. Например, в PostgreSQL логи упреждающей журнализации WAL (Write Ahead Logs) и специальная функция (Point in Time Recovery - PITR), позволяющая вернуться к определенному состоянию базы. С их помощью легко реализуется третий сценарий, когда бэкап уровня файловой системы объединяется с резервной копией WAL-файлов. Вначале восстанавливаем файлы резервной копии файловой системы, а затем при помощи WAL база приводится к актуальному состоянию. Это чуть более сложный подход для администрирования, но зато нет проблем с целостностью БД и восстановлением баз до определенного времени.

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

Barman

Лицензия: GNU GPL

Поддерживаемые СУБД: PostgreSQL

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

Barman (backup and recovery manager) - внутренняя разработка компании 2ndQuadrant, предоставляющей услуги на базе PostgreSQL. Предназначен для физического бэкапа PostgreSQL (логический не поддерживает), архивирования WAL и быстрого восстановления после сбоев. Поддерживаются удаленный бэкап и восстановление нескольких серверов, функции point-in-time-recovery (PITR), управление WAL. Для копирования и подачи команд на удаленный узел используется SSH, синхронизация и бэкап при помощи rsync позволяет сократить трафик. Также Barman интегрируется со стандартными утилитами bzip2, gzip, tar и подобными. В принципе, можно использовать любую программу сжатия и архивирования, интеграция не займет много времени. Реализованы различные сервисные и диагностические функции, позволяющие контролировать состояние сервисов и регулировать полосу пропускания. Поддерживаются Pre/Post-скрипты.

Barman написан на Python, управление политиками резервного копирования производится при помощи понятного INI-файла barman.conf, который может находиться в /etc или домашнем каталоге пользователя. В поставке идет готовый шаблон с подробными комментариями внутри. Работает только на *nix-системах. Для установки в RHEL, CentOS и Scientific Linux следует подключить EPEL - репозиторий, в котором содержатся дополнительные пакеты. В распоряжении пользователей Debian/Ubuntu официальный репозиторий:

$ sudo apt-get install barman

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

Sypex Dumper

Лицензия: BSD

Поддерживаемые СУБД: MySQL

Вместе с MySQL поставляются утилиты mysqldump, mysqlhotcopy, позволяющие легко создать дамп базы данных, они хорошо документированы, и в интернете можно найти большое количество готовых примеров и фронтендов. Последние позволяют новичку быстро приступить к работе. Sypex Dumper представляет собой PHP-скрипт, позволяющий легко создать и восстановить копию базы данных MySQL. Создавался для работы с большими базами данных, работает очень быстро, понятен и удобен в использовании. Умеет работать с объектами MySQL - представлениями, процедурами, функциями, триггерами и событиями.

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

• CREATE + INSERT - стандартный режим восстановления;
• TRUNCATE + INSERT - меньше времени на создание таблиц;
• REPLACE - восстанавливаем в рабочей базе старые данные, не затирая новые;
• INSERT IGNORE - добавляем в базу удаленные или новые данные, не трогая существующие.

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

Управление производится при помощи веб-браузера, интерфейс с использование AJAX локализован из коробки и создает впечатление работы с настольным приложением. Также возможно запускать задания из консоли и по расписанию (через cron).

Для работы Dumper понадобится классический L|WAMP-сервер, установка обычная для всех приложений, написанных на PHP (копируем файлы и устанавливаем права), и не будет сложной даже для новичка. Проект предоставляет подробную документацию и видеоуроки, демонстрирующие работу с Sypex Dumper.

Есть две редакции: Sypex Dumper (бесплатно) и Pro (10 долларов). Вторая имеет больше возможностей, все отличия приведены на сайте.

SQL Backup And FTP

Лицензия:

Поддерживаемые СУБД: MS SQL Server

MS SQL Server - одно из популярных решений, а потому встречается достаточно часто. Задание резервного копирования создается при помощи среды SQL Server Management Studio, собственно Transact-SQL и командлетов модуля SQL PowerShell (Backup-SqlDatabase). На сайте MS можно найти просто огромное количество документации, которая позволяет разобраться с процессом. Документация хотя и полная, но очень специфическая, а информация в интернете часто противоречит друг другу. Новичку действительно вначале потребуется потренироваться, «набив руку», поэтому, даже несмотря на все сказанное, сторонним разработчикам есть где развернуться. К тому же бесплатная версия SQL Server Express не может похвастаться встроенными инструментами для резервного копирования. Для более ранних версий MS SQL (до 2008) можно найти бесплатные утилиты, например SQL Server backup , но в большинстве подобные проекты уже коммерциализировались, хотя и предлагают всю функциональность часто за символическую сумму.

Например, разработка SQL Backup And FTP и One-Click SQL Restore соответствует принципу «настроил и забыл». Обладая очень простым и понятным интерфейсом, они позволяют создавать копии баз данных MS SQL Server (включая Express) и Azure, сохранять зашифрованные и сжатые файлы на FTP и облачных сервисах (Dropbox, Box, Google Drive, MS SkyDrive или Amazon S3), результат можно тут же просмотреть. Возможен запуск процесса как вручную, так и по расписанию, отправка сообщения о результате задания по email, запуск пользовательских скриптов.

Поддерживаются все варианты бэкапа: полный, дифференциальный, журнал транзакций, копирование папки с файлами и многое другое. Старые резервные копии удаляются автоматически. Для подключения к виртуальному узлу используется SQL Management Studio, хотя здесь могут быть нюансы и это будет работать не во всех таких конфигурациях. Для загрузки предлагается пять версий - от бесплатной Free до навороченной Prof Lifetime (на момент написания этих строк стоила всего 149 долларов). Функционала Free вполне достаточно для небольших сетей, в которых установлено один-два SQL-сервера, все основные функции активны. Ограничено количество резервных БД, возможность отправки файлов на Google Drive и SkyDrive и шифрование файлов. Интерфейс хотя и не локализован, но очень прост и понятен даже новичку. Нужно лишь подключиться к SQL-серверу, после чего будет выведен список баз данных, следует отметить нужные, настроить доступ к удаленным ресурсам и указать время выполнения задания. И все это в одном окне.

Но есть одно «но». Сама программа не предназначена для восстановления архивов. Для этого предлагается отдельная бесплатная утилита One-Click SQL Restore, понимающая и формат, созданный командой BACKUP DATABASE. Админу необходимо лишь указать архив и сервер, на который восстановить данные, и нажать одну кнопку. Но в более сложных сценариях придется использовать RESTORE.

Особенности бэкапа MS SQL Server

Создание резервной копии и восстановление СУБД имеет свои отличия, которые нужно учитывать, особенно их много при переносе архива на другой сервер. Для примера разберем некоторые нюансы MS SQL Server. Для архивирования при помощи Transact-SQL следует использовать команду BACKUP DATABASE (есть и разностная DIFFERENTIAL) и журнал транзакций BACKUP LOG.

Если резервная копия разворачивается на другом сервере, нужно убедиться, что присутствуют те же самые логические диски. Как вариант - можно вручную прописать правильные пути для файлов базы данных, используя опцию WITH MOVE команды RESTORE DATABASE.

Простая ситуация - бэкап и перенос баз на другие версии SQL Server. Эта операция поддерживается, но в случае SQL Server будет работать, если версия сервера, на которой разворачивается копия, такая же или новее, чем та, на которой она создавалась. Причем есть ограничение: новее не более чем на две версии. После восстановления БД будет находиться в режиме совместимости с той версией, с которой осуществлялся переход, то есть новые функции будут недоступны. Это легко поправить, изменив COMPATIBILITY_LEVEL. Можно это сделать при помощи GUI или SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Определить, на какой версии была создана копия, можно, просмотрев заголовок файла архива. Чтобы не экспериментировать, при переходе на новую версию SQL Server следует запустить бесплатную утилиту Microsoft Upgrade Advisor.

Iperius

Лицензия: коммерческая, есть версия Free

Поддерживаемые СУБД: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL и MS SQL Server

Когда приходится управлять несколькими типами СУБД, без комбайнов не обойтись. Выбор большой. Например, Iperius - легкая, очень простая в использовании и одновременная мощная программа для резервного копирования файлов, имеющая функцию горячего резервирования баз данных без прерывания в работе или блокирования. Обеспечивает полный или инкрементальный бэкап. Может создавать полные образы дисков для автоматической переустановки всей системы. Поддерживает резервное копирование на NAS, USB-устройства, стример, FTP/FTPS, Google Drive, Dropbox и SkyDrive. Поддерживает сжатие zip без ограничения в размере файлов и AES256-шифрование, запуск внешних скриптов и программ. Включает весьма функциональный планировщик заданий, возможно параллельное или последовательное выполнение нескольких заданий, результат отправляется на email. Поддерживаются многочисленные фильтры, переменные для персонализации путей и настроек.

Возможность закачки по FTP позволяет легко обновлять информацию на нескольких веб-сайтах. Открытые файлы резервируются при помощи технологии VSS (теневого копирования томов), что позволяет производить горячий бэкап не только файлов СУБД, но и других приложений. Для Oracle также задействуется средство организации резервного копирования и восстановления данных RMAN (Recovery Manager). Чтобы не перегружать канал, есть возможность настройки полосы пропускания. Управление резервированием и восстановлением производится при помощи локальной и веб-консоли. Все функции на виду, поэтому для настройки задания потребуется лишь понимание процесса, в документацию заглядывать даже не придется. Просто следуем подсказкам мастера. Также можно отметить менеджер учетных записей, что очень удобно при большом количестве систем.

Базовые функции предлагаются бесплатно, но возможность резервирования БД заложена только в версиях Advanced DB и Full. Поддерживается установка от XP до Windows Server 2012.

Handy Backup

Лицензия: коммерческая

Поддерживаемые СУБД: Oracle, MySQL, IBM DB2 (7–9.5) и MS SQL Server

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

Db2 backup db sample

Или снапшот, использующий функцию Advanced Copy Services (ACS):

Db2 backup db sample use snapshot

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

Например, Handy Backup позволяет выполнять бэкап нескольких типов серверов баз данных и сохранять файлы практически на любой носитель (жесткий диск, CD/DVD, облачное и сетевое хранилище, FTP/S, WebDAV и другие). Возможен бэкап баз данных через ODBC (только таблицы). Это одно из немногих решений, поддерживающих DB2, и к тому же имеет логотип «Ready for IBM DB2 Data Server Software». Вся процедура выполняется при помощи обычного мастера, в котором необходимо лишь выбрать нужный пункт и сформировать задачу. Сам процесс настройки настолько прост, что разобраться сможет и новичок. Можно создать несколько заданий, которые будут запускаться по расписанию. Результат фиксируется в журнале и отправляется по email. Во время работы задания остановка сервиса не требуется. Архив автоматически сжимается и шифруется, что гарантирует его безопасность.

Работу с DB2 поддерживают две версии Handy Backup - Office Expert (локальный) и Server Network (сетевой). Работает на компьютерах под управлением Win8/7/Vista/XP или 2012/2008/2003. Сам процесс развертывания несложен для любого админа.

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

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

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

Для экспорта информации из базы данных в формате SQL можно использовать утилиту mysqldump. Вот ее синтаксис:

$ mysqldump опции имя_базы [имя_таблицы] > файл.sql

По умолчанию утилита будет выводить все в стандартный вывод, поэтому нам нужно перенаправить эти данные в файл, что мы и делаем с помощью оператора ">". Опции указывают параметры аутентификации и работы, а имя базы и таблицы - данные которые нужно экспортировать. Теперь рассмотрим кратко опции, которые будем использовать:

• -A - копировать все таблицы из всех баз данных;
• -i - записывать дополнительную информацию в комментариях;
• -c - использовать имена колонок для инструкции INSERT;
• -a - включать все возможные опции в инструкцию CREATE TABLE;
• -k - отключает первичные ключи на время копирования;
• -e - использовать многострочный вариант инструкции INSERT;
• -f - продолжить даже после ошибки;
• -h - имя хоста, на котором расположен сервер баз данных, по умолчанию localhost;
• -n - не писать инструкции для создания базы данных;
• -t - не писать инструкции для создания таблиц;
• -d - не записывать данные таблиц, а только их структуру;
• -p - пароль базы данных;
• -P - порт сервера баз данных;
• -Q - брать все имена таблиц, баз данных, полей в кавычки;
• -X - использовать синтаксис XML вместо SQL;
• -u - пользователь, от имени которого нужно подключаться к базе данных.

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

mysqldump -u имя_пользователя -p имя_базы > data-dump.sql

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

head -n 5 data-dump.sql

Но если во время создания копии возникнут какие-либо ошибки, они будут выведены на экран и вы сразу о них узнаете. Более сложный вариант, это выполнить резервное копирование mysql с другого хоста, если у вас есть к нему доступ:

mysqldump -h хост -P порт -u имя_пользователя -p имя_базы > data-dump.sql

Копирование таблицы mysql может быть выполнено простым добавлением имени таблицы в конец строки:

mysqldump -u имя_пользователя -p имя_базы имя_таблицы > data-dump.sql

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

mysqldump -u имя_пользователя -pпароль имя_базы > data-dump.sql

Мы можем делать бэкап вручную время от времени, но это не совсем удобно, поскольку есть другие важные дела. Поэтому используем планировщик cron, чтобы автоматизировать процесс. Тут есть два способа более простой, и более сложный, но точный. Допустим, нам нужно создавать резервную копию каждый день, тогда просто создайте скрипт в папке /etc/cron.daily/ со следующим содержимым:

sudo vi /etc/cron.daily/mysql-backup

!/bin/bash
/usr/bin/mysqldump -u имя_пользователя -pпароль имя_базы > /backups/mysql-dump.sql

Папку /backups/mysql-dump.sql нужно заменить на свою папку для резервных копий. Осталось дать скрипту права на выполнение:

chmod ugo+x /etc/cron.daily/mysql-backup

Добавьте в открывшейся файл такую строку и сохраните изменения:

30 2 * * * /usr/bin/mysqldump -u имя_пользователя -pпароль имя_базы > /backups/mysql-dump.sql

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

Восстановление из резервной копии

Восстановить резервную копию mysql или mariadb из существующего SQL файла тоже очень просто. Поскольку использовался синтаксис sql мы просто можем выполнить все команды с помощью стандартного клиента mysql.

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

mysql -u root -p

Затем создайте новую базу данных, например, с именем new_database, если база данных уже существует, то этого делать не нужно:

mysql> CREATE DATABASE new_database;

mysql -u пользователь -p база_данных < data-dump.sql

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

Выводы

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

Майкл Вандайн (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.

Заключение

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

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

Неисправности аппаратного обеспечения

• Некорректное использование инструкций UPDATE и DELETE

  Ошибки программного обеспечения

  Аварийные ситуации, например, пожар или затопление

Чтобы избежать потери данных, можно реализовать для базы данных стратегию восстановления. Стратегию восстановления необходимо спланировать, реализовать и протестировать с учетом возможных неисправностей, с которыми можно встретиться в процессе работы системы, и необходимого уровня защиты данных. В витринах данных, то есть в случаях, когда данные можно восстановить из других систем, вероятно, нет необходимости создавать резервные копии каждой отдельной транзакции. Возможно, будет достаточно выполнять полное резервное копирование данных с регулярными временными интервалами. И наоборот, для базы данных, в которой хранятся транзакции интернет-магазина, возможно, будет необходимо сохранять резервные копии каждой отдельной транзакции. СУБД SQL Server предоставляет полный комплекс функций для реализации именно того вида резервного копирования, который вам необходим. В данной лекции рассматриваются наиболее широко используемые в Microsoft SQL Server стратегии для защиты данных.

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

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

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

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

Скорость резервного копирования определяется скоростью используемых устройств ввода/вывода (тех устройств ввода вывода, которые используются для сбора и хранения информации). Чтобы добиться наилучшей производительности, SQL Server считывает файлы последовательно. Если ваши устройства ввода/вывода способны одновременно обрабатывать данные ввода/вывода резервного копирования и данные ввода/вывода, поступающие в результате обычного использования системы, то создание резервной копии окажет на производительность системы незначительное воздействие. Тем не менее, лучше выполнять полное резервное копирование базы данных при отсутствии пиковых нагрузок.

В следующем разделе мы рассмотрим варианты реализации этой стратегии резервного копирования.

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

Следует заранее уведомить SQL Server о том, какой тип резервного копирования вы намерены использовать, поэтому надо сконфигурировать базу данных так, чтобы настройки соответствовали выбранному вами типу резервного копирования. Такая настройка выполняется посредством выбора значения параметра "модель восстановления базы данных". Модель восстановления базы данных, которая используется по умолчанию, является производным от модели восстановления модели базы данных, определенной при ее создании. Чтобы реализовать стратегию резервного копирования, которая будет включать только полные резервные копии, следует выбрать простую модель восстановления (SIMPLE).

Выбираем модель восстановления SIMPLE

В меню Start (Пуск) выберите All Programs,. Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

В диалоговом окне Connect To Server (Соединение с сервером) нажмите кнопку Connect (Соединить).

В панели инструментов Standard (Стандартная) нажмите кнопку New Query (Новый запрос), чтобы открыть окно New Query (Новый запрос).

Чтобы задать модель восстановления, можно использовать инструкцию ALTER DATABASE. Введите текст следующей инструкции и нажмите кнопку Execute (Выполнить).

ALTER DATABASE AdventureWorks

SET RECOVERY SIMPLE;

Дополнительная информация .В этой лекции рассматривается, главным образом, создание резервных копий и восстановление с помощью инструкций SQL. В лекциях 6-7 будет рассмотрено выполнение многих из этих же процедур не через инструкции T-SQL, а с помощью интерфейса пользователя SQL Server Management Studio.

Проверяем настройки модели аварийного восстановления

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

SELECT DATABASEPROPERTYEX("AdventureWorks","Recovery")

Убедитесь, что в результатах запроса указана модель восстановления SIMPLE.

Закройте окно среды SQL Server Management Studio.

Устройства резервного копирования

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

Ленточные устройства .Могут использоваться для хранения резервных копий на лентах. Ленточные устройства должны быть установлены локально. Резервная копия может занимать несколько лент, а на одной ленте могут находиться одновременно резервные копии SQL Server и Windows.

Дисковые устройства .Файлы на локальном или удаленном диске или дисковом накопителе. К этим файлам обращаются, указывая путь к файлу, в котором хранится резервная копия. Для обращения к удаленным хранилищам следует использовать путь в формате UNC.

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

Устройства резервного копирования идентифицируются по имени устройства. В качестве имени устройства может использоваться имя логического или физического устройства. Имя физического дискового устройства представляет собой путь к файлу резервной копии, например, "\\BACKUPSERVER\Backups\adv\AdventureWorks.bak". Этот путь можно включить непосредственно в инструкцию резервного копирования. Имя логического устройства представляет собой имя, указывающее на имя физического устройства резервного копирования и хранящееся в SQL Server. Когда в инструкции резервного копирования используется имя логического устройства, SQL Server осуществляет поиск соответствующего физического устройства в системном каталоге и выполняет резервное копирование, сохраняя резервную копию в указанной папке.

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

EXEC sp addumpdevice "disk", "AdvFullDbDev", "T:\BACKUPS\AdvFullDbDev.bak";

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

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

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

Совет . Сокращение RAID происходит от выражения "redundant array of independent disks" (избыточный массив независимых дисков). Такие массивы представляют собой системы дисков с несколькими приводами, которые используются для повышения доступности и емкости хранилища.

Выполнение полного резервного копирования базы данных

После того, как вы установили модель резервного копирования на SIMPLE и решили, на каком устройстве резервного копирования сохранять резервные копии, можно приступить к выполнению резервного копирования. Полное резервное копирование базы данных выполняется с помощью довольно простой инструкции BACKUP DATABASE. В простейшей форме нужно только указать системе, резервную копию какой базы данных создать и на каком устройстве ее сохранить. Чтобы создать резервную копию базы данных AdventureWorks на предварительно выбранном логическом устройстве, используется следующая инструкция T-SQL:

TO Adv_FullDb_Dev;

Если надо выполнить полное резервное копирование базы данных на физическое устройство, необходимо указать тип устройства и место размещения резервной копии в инструкцииBACKUP DATABASE. Чтобы создать резервную копию базы данных в папке t:\adv.bak, используйте следующую инструкцию:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv.bak";

Как уже говорилось, на любом устройстве резервного копирования может храниться больше одной резервной копии. В аргументе инструкции BACKUP DATABASE можно указать, следует ли SQL Server перезаписать существующую резервную копию на этом устройстве или дописать ее к существующим резервным копиям. Для этого используются ключевые слова INIT илиNOINIT. Если указать INIT, то перед запуском резервного копирования устройство резервного копирования форматируется, при этом удаляются все резервные копии, которые имеются на этом устройстве. NOINIT, которое используется по умолчанию, если не указано иное, разрешает SQL Server дописать резервную копию на существующее устройство резервного копирования с сохранением всех существующих на нем резервных копий. Эти опции устанавливаются при помощи блока WITH в конце инструкции BACKUP DATABASE.

Если нужно создать такую же резервную копию, как в предыдущем примере, но при этом указать SQL Server сначала очистить устройство, используйте следующую инструкцию:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv.bak"

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

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

Главное преимущество полного резервного копирования базы данных заключается в том, что в полной резервной копии содержатся все данные, которые необходимы для восстановления базы данных полностью. Но это преимущество может одновременно быть и недостатком. Представьте себе базу данных, для которой каждую ночь создается резервная копия. Если придется восстанавливать базу данных, в любом случае придется использовать резервную копию, созданную прошлой ночью, и в результате будут потеряны результаты работы за целый день. Один из способов уменьшить потенциальный промежуток времени, который может быть не учтен резервным копированием является более частое выполнение полного резервного копирования базы данных. Но это само по себе является проблематичным. Поскольку все данные и фрагменты журнала транзакций записываются на устройство резервного копирования, выполнение резервного копирования может отнимать слишком много времени. Кроме того, для хранения всех этих резервных копий необходимо много дискового пространства h° , а полное резервное копирование может снизить производительность базы данных в результате потребности в большом объеме операций ввода/вывода. Не лучше ли будет один раз выполнить резервное копирование ночью, а затем выполнять резервное копирование только тех данных, которые были изменены в течение дня? Такие функциональные возможности предоставляет разностный тип резервного копирования.

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

Рис. 4.1. Стратегия резервного копирования с использованием разностных резервных копий

Выполнение разностного резервного копирования

Выполнение разностного резервного копирования мало чем отличается от выполнения полного резервного копирования. Единственное отличие заключается в том, что в блоке WITHобъявляются инструкции по создании разностной резервной копии. Синтаксис инструкции BACKUP DATABASE для выполнения резервного копирования базы данных Adventure Works на физическое устройство с перезаписью других существующих резервных копий на этом устройстве будет таким:

BACKUP DATABASE AdventureWorks

TO DISK="t:\adv_diff.bak"

WITH INIT,DIFFERENTIAL;

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

EXEC sp_addumpdevice "disk", "Adv_Diff_Dev",

"T:\BACKUPS\AdvDiffDev.bak";

BACKUP DATABASE AdventureWorks

TO Adv_Diff_Dev

WITH INIT,DIFFERENTIAL;

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

Резервное копирование журнала транзакций

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

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

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

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

Рис. 4.2. Стратегия резервного копирования с использованием резервных копий журнала транзакций

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

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

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

Рис. 4.3. Комбинированная стратегия резервного копирования

Например, чтобы восстановить данные до резервной копии журнала транзакций Т3, следует восстановить данные полной резервной копии F1, разностной резервной копии D1 и резервной копии журнала транзакций Т3.

Интервал времени между созданием резервных копий журнала транзакций зависит от:

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

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

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

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

Базу данных MySQL можно скопировать, если временно выключить MySQL-сервер и просто скопировать файлы из папки /var/lib/mysql/db/ . Если сервер не выключить, по очевидным причинам вероятна потеря и порча данных. Для больших нагруженных баз эта вероятность близка к 100%. Кроме того, при первом запуске с «грязной» копией базы данных MySQL-сервер начнет процесс проверки всей базы, который может затянуться на часы.

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

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

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

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

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

Для того, чтобы считать в бэкап данные из production-базы, необязательно дергать файлы. Можно выбрать данные запросом и сохранить их в текстовый файл. Для этого используется SQL-команда SELECT INTO OUTFILE и парная ей LOAD DATA INFILE . Выгрузка производится построчно (можно отобрать для сохранения только нужные строки, как в обычном SELECT). Структура таблиц нигде не указывается - об этом должен заботиться программист. Он также должен позаботиться о включении команд SELECT INTO OUTFILE в транзакцию, если это необходимо для обеспечения целостности данных. На практике SELECT INTO OUTFILE используется для частичного бэкапа очень больших таблиц, которые нельзя скопировать никаким другим образом.

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

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

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

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

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

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

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

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

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

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