Бэкап базы – Резервное копирование данных в MySQL / Habr

Разбираемся с утилитами для бэкапа баз данных

Содержание статьи

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

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

Для начала разберемся с тем, какие вообще бывают бэкапы. Сервер баз данных не является обычным десктопным приложением, и, чтобы обеспечить выполнение всех свойств 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

Сайт: pgbarman.org, sf.net/projects/pgbarman

Лицензия: 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

Сайт: sypex.net/ru/products/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

Сайт: sqlbackupandftp.com

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

Поддерживаемые СУБД: 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

Сайт: iperiusbackup.com

Лицензия:коммерческая, есть версия 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

Сайт: handybackup.ru

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

Поддерживаемые СУБД: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. Сам процесс развертывания несложен для любого админа.

xakep.ru

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

Как вы знаете, все важные данные ваших сайтов, их настройки, статьи, комментарии и другая информация хранятся в базе данных. Потеря этой информации может иметь очень тяжелые последствия для проекта. Поэтому важно своевременно делать резервные копии базы данных 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

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

sudo crontab -e

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

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;

Дальше закройте оболочку, нажав сочетание клавиш Ctrl+Q и импортируйте данные из файла командой:

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

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

Выводы

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

losst.ru

Как сделать резервную копию базы/таблицы в MySQL

В данной статье мы рассмотрим примеры того, как можно сделать резервную копию (бэкап, backup) базы данных MySQL (или же определенной таблицы из этой базы).

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

Содержимое статьи:

Бэкап БАЗЫ (БАЗ) данных

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

Создаем резервную копию ОДНОЙ базы

mysqldump -u root -p database_name > database_name_backup.sql

-u root — аргумент, означающий, что мы будем подключаться к MySQL серверу под учетной записью root (может быть любая учетная запись, имеющая необходимые права на нужную таблицу).
-p — аргумент, означающий, что необходимо ввести пароль для авторизации (т.е. доступ для данного пользователя без пароля — не разрешен). В случае, когда пароль не требуется, данный аргумент можно упустить.
database_name — это имя базы данных, резервную копию которой мы делаем.
database_name_backup.sql — это название бекапа, который будет создан. Создается он в текущем каталоге из которого вы запускаете данную команду. Если вам необходимо сохранить резервную копию в какой-либо определенный каталог, то можно сразу указать путь до этого каталога, написав вместо database_name_backup.sql, /tmp/database_name_backup.sql. Таком образом, резервная копия будет создана в каталоге /tmp

Создаем резервную копию НЕСКОЛЬКИХ баз

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

mysqldump -u root -p --databases database_name_1 database_name_2 database_name_3 > databases_backup.sql

--databases — аргумент, указывающий, что далее будут перечислены базы данных, резервные копии которых мы хотим сделать.
database_name_1 database_name_2 database_name_3 — имена баз данных, резервные копии которых мы хотим сделать. Разделяются пробелом.

Создаем резервную копию ВСЕХ баз

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

mysqldump -u root -p --all-databases > databases_backup.sql

--all-databases, аргумент, указывающий, что необходимо сделать резервную копию всех доступных баз данных.

Бэкап ТАБЛИЦЫ (ТАБЛИЦ) из определенной базы данных

Создаем резервную копию ОДНОЙ таблицы из базы

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

mysqldump -u root -p database_name table_name > table_name_backup.sql

table_name — это имя таблицы, резервную копию которой мы хотим сделать и которая находится в базе данных database_name.

Создаем резервную копию НЕСКОЛЬКИХ таблиц из базы

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

mysqldump -u root -p database_name table_name_1 table_name_2 table_name_3 > tables_backup.sql

table_name_1 table_name_2 table_name_3 — это названия таблиц, резервные копии которых мы хотим сделать. В нашем примере данные таблицы находятся в базе данных database_name.

sysadmin.ru

12 типичных ошибок при бэкапе баз данных / Habr

Наша компания занимается инструментами восстановления, резервного копирования, оптимизации и поддержкой СУБД (в основном Firebird, но есть и MSSQL, PostgreSQL, InterBase и др.) и, как результат многочисленных аудитов и ремонтов, накопила коллекцию ошибок, связанных с резервным копированием. Все пункты ниже изложены по мотивам реальных случаев с повреждением баз, потерей и повреждением бэкапов, дисков, сбоями серверов, и прочих «радостей» администраторов БД.

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

Итак, приступим.

1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Чаще всего эту ошибку совершают новички, которые не понимают, что основная цель существования резервной копии БД – обеспечить минимальный простой информационной системы (важной частью которой является БД), а не просто создание копии БД.
В результате, с момента удаления последнего бэкапа до создания нового, система находится в незащищенном состоянии, потому что в этот период у базы данных нет ни одной резервной копии. Так как бэкап может создаваться достаточно долго, то это идеальное время для срабатывания закона Мерфи. Особенно хорошо этот подход работает в связке с пунктом 7 (см. ниже).
Рекомендация: не удаляйте предыдущий бэкап до того момента, как создан новый! (и не делайте новый бэкап в уже существующий файл)

2. Перезапись существующей базы данных при восстановлении из бэкапа
Эту ошибку совершают реже, но вот результаты могут быть гораздо печальнее. Если бэкап не проверялся и был поврежден (см. пункт 6), то в результате перезаписи у вас не будет ни предыдущей копии базы, ни валидного бэкапа.
Обычно это безобразие случается в пятницу вечером, в момент дерготни, неразберихи и противоречивых указаний со стороны начальства. Немного отрицательного везения и томные выходные в серверной обеспечены.
У Firebird есть некая защита от этой ошибки – создание рестора из бэкапа с помощью утилиты gbak с дефолтным ключом –create не сработает в случае, если указанное имя файла указывает на существующую БД. К сожалению, есть и обход этой защиты – переключатель –rep, который позволяет-таки переписать существующий файл.
Рекомендации: никогда не перезаписывайте файл боевой БД, не получив письменного указания руководства и, желательно, не получив предложения о новой работе.

3. Использование одношагового бэкапа-рестора, без создания промежуточного файла бэкапа
Стандартные потоки ввода-вывода позволяют провернуть с многими СУБД (с Firebird в том числе) интересный трюк: выполнять потоковый бэкап с немедленным восстановлением БД из него. В результате не создается промежуточный файл бэкапа. Это удобно для проведения регламентных работ и запуска проверочного восстановления (при наличии другой резервной копии), но ни в коем случае не надо использовать это для автоматического бэкапа!
Если в процессе такого бэкап-рестора произойдет серьёзный сбой диска, например, то может повредиться исходная база данных, а новая еще не будет создана. Конечно, если п.1 соблюдается, и есть копия БД от предыдущей попытки, то произойдет только потеря данных, которые были созданы или изменены в БД с момента создания ее копии.
Рекомендации: не используйте одношаговый бэкап-рестор в автоматическом режиме, а в ручном всегда проверяйте наличие достаточно свежей копии.

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

5. Отсутствие проверки успешного окончания бэкапа
Вот это довольно частая ошибка и администраторов, и руководителей ИТ подразделений. Если результат бэкапа не проверять, то можно бэкап не делать вообще — результат в общем тот же. Обязательно нужны нотификации по email об успешном бэкапе, а еще лучше и по СМС. Причем, отсутствие нотификации это признак проблемы!
А причем тут руководители, спросит внимательный читатель, дочитавший до этого места? А притом, что администратор обычно бэкап настроит, но вот нотификации ему проверять лень, тем более что лежат они у него в отдельной папочке, и поэтому руководителю ИТ-отдела надо периодически запрашивать дополнительный отчет о состоянии всех бэкапов. Это к вопросу, кого наказывать, если бэкапы вроде есть, но в нужный момент их не оказалось 🙂
! А при комбинировании с пунктом 2 получаем отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты автоматизации бэкапов, которые умеют отслеживать успешные и неуспешные бэкапы, сообщать пользователям о проблемах, и имеют обзорные средства контроля (особенно актуально, когда нужно контролировать десятки и сотни бэкапов на разных серверах).

6. Отсутствие валидации бэкапов
То, что бэкапы куда-то кладутся, не означает, что они оттуда могут быть прочитаны.
Поэтому обязательна периодическая верификация создаваемых бэкапов, чтобы быть уверенным, что создаваемые бэкапы не повреждены, не были скопированы в /dev/null
Рекомендации: никому не доверять, даже себе. Всех надо проверять.

7. Отсутствие health check базы данных при использовании неверифицированных бэкапов
Обычно СУБД имеют несколько видов бэкапа – дампы, просто бэкапы и т.д. Не вдаваясь в конкретику, можно выделить 2 категории – верифицированные и неверифицированные бэкапы. У Firebird это gbak и nbackup.
Gbak читает всю БД на уровне записей для создания файла бэкапа, и создает БД путем вставки записей в новую БД, и таким образом верифицирует и бэкап (есть варианты, как ошибки могут просочиться в отресторенную копию, но это уже другой вид факапа администратора БД, связанный с неверной миграцией), и саму базы данных (если она может быть прочитана от начала до конца, то с большой долей вероятности она не повреждена).
Nbackup (он же инкрементальный бэкап) – временно блокирует основной файл БД на запись (в консистентном состоянии), и позволяет быстро скопировать файл базы данных (полностью или частично/инкрементально).
Для больших БД Firebird (более 500Гб), предпочтительно делать nbackup, чтобы не тормозить работу пользователей, но при этом нужно проверять БД, ведь созданные неверифицированные бэкапы – это страничные копии БД, и если ошибка гнездится на уровне записей (такое случается из-за сбоя RAM) или на логическом уровне, то неверифицированный бэкап будет ее содержать так же, как и оригинальная БД.
Для этого нужно использовать онлайн-валидацию исходной базы данных (в Firebird начиная с версии 2.5.4 доступна онлайн-валидация при помощи gfix, а наш инструмент FBDataGuard поддерживает онлайн-проверку БД для версий 1.5-2.5).
Также, в дополнение к неверифицированному бэкапу желательно периодически (раз в неделю, например) делать верифицированный бэкап.
Для других СУБД необходимо использовать соответствующие средства и комбинации проверок.

8. Отсутствие контроля за свободным местом для бэкапа
В общем-то, это классическая ошибка — при недостатке места бэкап занимает все свободное место и аварийно завершается. При размещении бэкапа на одном диске вместе с БД может привести к остановке работы с БД, при размещении на системном диске – к поломке системы.
В комбинации с пунктом 4 в лучшем случае получим остановку работы системы, потому что базе данных тоже нужно свободное место, а оно кончилось из-за бэкапа.
А в комбинации с пунктами 5 и 2 опять получаем в результате отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты для бэкапа, которые делают прогноз размера бэкапа и предупреждают о возможной нехватке места.

9. Отсутствие контроля времени продолжительности бэкапа
Буквально полгода назад бэкап длился 40 минут, и вдруг стал 3 часа – почему? Возможно, вырос размер БД, а может быть, выпал диск из RAID-массива, отчего скорость записи резко деградировала, и все ваши бэкапы вот-вот покинут этот бренный мир. А может быть, добрый коллега одновременно включил еще одну систему резервного копирования (кстати, в Firebird можно запустить несколько бэкапов сразу, только не очень понятно, зачем это может быть нужно).
Если не контролировать время исполнения бэкапа, то можно проглядеть возникшую проблему и упустить шанс исправить ее до того, как она станет большой.
Также, в случае, если система резервного копирования не отслеживает состояния заданий, а запускает их просто по графику, легко можно попасть на «утренний троллейбус» — это когда новый бэкап может начаться в момент, пока предыдущий еще не закончился.
Рекомендации: использовать средства контроля продолжительности процесса бэкапа.

10. Исполнение бэкапа БД во время применения апдейтов ОС
Очень частая проблема, особенно в комбинации с п.9 и включенными автоматическими апдейтами Windows (которые по умолчанию происходят в 3 ночи). В лучшем случае приводит к замедлению процесса, а если ОС перегружается для применения апдейтов, то бэкап будет испорчен. Хорошо еще, что апдейты ОС не каждый день случаются.
Рекомендации: Если нельзя отключить, то назначьте апдейты ОС на такое время, когда они не смогут помешать бэкапам.

11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Многие администраторы забывают о том факте, что любая СУБД имеет активный и сложный кэш, в котором содержатся читаемые и записываемые данные, а сами файлы БД открываются в режиме случайного доступа.
Именно поэтому необходимо использовать специальные виды бэкапа, а не простой файловый бэкап (включая простое копирование файлов БД) или бэкап виртуальной машины. Файловые средства бэкапа читают БД последовательно и, особенно для больших БД, могут идти продолжительное время, поэтому нельзя гарантировать целостность созданной копии.
Для желающих осуществлять бэкап БД с помощью файловых средств или средств бэкапа виртуальных машин можно предложить 2 способа:

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

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

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

12. Подмена бэкапа репликацией
Бэкап и репликация данных служат повышению надежности и предотвращению потери данных, но все же существенно отличаются.
Все любят репликацию за способность синхронизировать данные на другом сервере с минимальном задержкой, однако и у бэкапа есть ряд неоспоримых преимуществ. Например, в случае случайного (или намеренного) удаления данных репликация быстро и невозмутимо оттранслирует изменения на реплику, а бэкап, особенно на read-only носителе, к таким операциям невосприимчив. Настроить правильную репликацию, как и правильный бэкап, стоит определенных усилий, и вероятность ошибок там также существует.
Рекомендации: Если у вас настроена репликация, не пренебрегайте бэкапами, используйте их совместно.

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

Ну, и конечно – не забывайте холить и лелеять свою админскую паранойю, например, возьмите и проверьте свои бэкапы… вот прямо сейчас!

UPDATE

Господа, просьба откликнуться в личку тех, кто использует CBT на VMWare для ВМ с БД.

habr.com

Средства создания горячих BackUp`ов MySQL / Habr

• Если не использовать блокировку таблиц, вполне можно получить нарушение логических связей между содержимым таблиц(если в процессе создания копии кто-то решит оставить запись в базе). Здесь косвенно может помочь накатывание части bin-log`a после восстановления из дампа. Так что если по каким-то причинам не блокируете таблицы — применяйте ключ —flush-log — при его использовании старый лог будет закрыт и начат новый. Если кто-то что-то запишет в процессе создания бэкапа — это отразится в начале журнала и вы без проблем перенесёте это изменение в базу. Я бы советовал после окончания бэкапа так же выполнить mysqladmin -flush-logs и положить в бэкап помимо dump-файла предпоследний бинарный журнал.
• При использовании ключа —lock-tables все таблицы получают блокировку записи, запросы встают в очередь. Это может привести к таймаутам на стороне клиента.
• Стоит так же иметь ввиду, что подъём(как и создание дампа) большой базы, сохраненной таким образом может изрядно затянуться — в первом случае вы сгребаете из базы все записи, а при обратном варианте — скармливаете их ей. Тем не менее, это один из немногих способов сбэкапить базу из консоли, не имея root-доступа.

2. С помощью утилиты mysqlhotcopy. Еще одно средство из штатного набора MySQL. Идея такова: база ставится на блокировку, после чего средствами cp или scp её файлы копируются в другое место.

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

3. С помощью LVM.
LVM — дополнительный слой между файловой системой и самим жестким диском. Одной из примечательных особенностей LVM является возможность снять на лету образ с тома. Схема действий будет следующей: заблокировать все таблицы базы, снять snapshot с тома, разблокировать таблицы.

• Данный метод подразумевает предварительный FLUSH с блокировкой всех таблиц(лучше скриптик написать для этих целей).
• Для применения этого метода необходимо, чтобы данные MySQL(для Linux они скорее всего будут храниться в директории /var/lib/mysql) находились на LVM-томе(желательно отдельном, дабы не бэкапить лишнее).
• Учитывая, что мы говорим о горячем бэкапе — если вы собираетесь применять данный метод — решение о размещении лучше принять на этапе конфигурации сервера.

4. С помощью репликации. Несмотря на то, что этот вариант многие считают геморроем, мне такой способ резервирования кажется самым правильным. Логика такого подхода заключается в постоянной синхронизации основного(master) сервера с вторичным(slave). Подробней о репликации можно почитать здесь.

• Требуется конфигурация отдельного MySQL-сервера. Причем желательно — на автономном железе.
• Остановка slave-сервера не сыграет никакой роли на master`е — можно делать «холодный» бэкап.
• В случае падения master`a можно в кратчайшие сроки(было бы разумно автоматизировать этот процесс) перевести всю нагрузку на slave, а после восстановления отсинхронизировать с ним master и вернуть всё на прежние места.
• Slave может стать по совместительству площадкой для хранения бэкапов.
• Важно! Существование реплики не освобождает вас от создания бэкапов. Выполнение какого-нибудь DROP’а коснётся обоих серверов!

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

На этом этом я заканчиваю своё повествование, надеюсь оно будет вам полезно. Спасибо за внимание и до новых встреч в эфире. 🙂

habr.com

Бэкап всех баз mysql в отдельные файлы

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .

Самый простой способ сделать бэкап всех базы с помощью mysqldump следующий:

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases | /usr/bin/gzip -c > /backup/mysql/`date "+%Y-%m-%d"`.gz

На выходе будет один сжатый файл с именем вида 2018-09-27.gz, в котором будет дамп всех mysql баз сервера, в том числе служебных таблиц. Работать с таким файлом потом очень неудобно. Это подходит только для случая, когда вы на таком же сервере будете восстанавливать все базы данных.

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

# mysql -u root -p --one-database destdbname < alldatabases.sql

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

Заодно заменил скрипт бэкапа на следующий:

for i in `mysql -uroot -p'password' -e'show databases;' | grep -v information_schema | grep -v Database`; 
    do 
	/usr/bin/mysqldump -uroot -p'password' $i | /usr/bin/gzip -c > /backup/mysql/`date +%Y-%m-%d`-$i.sql.gz;
    done

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

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

Онлайн курс «DevOps практики и инструменты»

#!/bin/sh

# ---- Константы --------------------------------------
# Папка, куда складываем бекапы
BACKUP_DIR="/var/www/wscms/data/www/site.ru/backup/"
# Имя файла бекапа
BACKUP_FILE="sql.tar"
# Пользователь, владелец файла с бекапами
USER="wscms"
# Папка для временных дампов MySQL
MDIR="mysql/"
# Сервер БД MySQL
MHOST="localhost"
# MYSQL root пользователь
MUSER="root"
# MYSQL root пароль
MPASS="***************"
# Поставьте "-zcf" если хотите сжимать данные или "-cf" в противном случае
PARAMS="-cf"

#--- Служебные переменные --------------------------
# Путь к mysql.
MYSQL="$(which mysql)"
# Путь к mysqldump
MYSQLDUMP="$(which mysqldump)"
# Путь к tar
TAR="$(which tar)"
# Путь к chown
CHOWN="$(which chown)"
# Путь к RM
RM="$(which rm)"
# Путь к MKDIR
MKDIR="$(which mkdir)"

# ---- Получаем список баз данных
DBS="$($MYSQL -u $MUSER -h $MHOST -p$MPASS -Bse 'show databases')"

# ---- Чистим папку с дампами на случай, если она уже существовала
$RM -rf $BACKUP_DIR$MDIR
# ---- Создаем папку для дампов
$MKDIR -p $BACKUP_DIR$MDIR

# ---- Делаем дампы найденых баз. Старые дампы замещаются
for db in $DBS
do
    FILE=$BACKUP_DIR$MDIR$db.sql
    $MYSQLDUMP -u $MUSER -h $MHOST -p$MPASS $db > $FILE
done

# ---- Архивируем файлы
$TAR $PARAMS $BACKUP_DIR$BACKUP_FILE $BACKUP_DIR$MDIR

# ---- Удаляем уже не нужную нам папку с MySQL дампами
$RM -rf $BACKUP_DIR$MDIR

$CHOWN $USER $BACKUP_DIR
$CHOWN $USER $BACKUP_DIR$BACKUP_FILE
exit 0

#!/bin/sh

# ---- Константы --------------------------------------
# Папка, куда складываем бекапы
BACKUP_DIR="/var/www/wscms/data/www/site.ru/backup/"
# Расширение файла бекапа
EXT=".tar"
# Директория, в которой лежат аккаунты
MAIN_DIR="/var/www/"
# Директория, в которой лежат сайты аккаунтов
DATA_DIR="/data/www/"
# Пользователь, владелец файла с бекапами
USER="wscms"
# Поставьте "-zcf" если хотите сжимать данные или "-cf" в противном случае
# используйте u для добавления только новых файлов
PARAMS="-cf"

#--- Служебные переменные --------------------------
# Путь к tar
TAR="$(which tar)"
# Путь к chown
CHOWN="$(which chown)"
RM="$(which rm)"
MKDIR="$(which mkdir)"

# ---- Создаем папку для дампов
$MKDIR -p $BACKUP_DIR
$CHOWN -R $USER $BACKUP_DIR

# ---- Для всех пользователей панели
for DIR in $(/usr/local/ispmgr/sbin/mgrctl -m ispmgr user | cut -d' ' -f1 | sed s/name=//)
do
    # ---- Архивируем файлы
    $TAR $PARAMS $BACKUP_DIR$DIR$EXT $MAIN_DIR$DIR$DATA_DIR
    $CHOWN $USER $BACKUP_DIR$DIR$EXT
done

$CHOWN -R $USER $BACKUP_DIR
exit 0