Автоматическое резервирование mysql: Резервное копирование данных в MySQL / Хабр

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

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

Доброго времени суток. Недавно я задался вопросом о том, как делать горячие BackUp`ы MySQL-серверов — ниже компиляция из прочитанного. Заранее хочу сказать, что данный пост является скорее большой заметкой, чем полноценной статьёй. Я намеренно уклоняюсь от описания синтаксиса — на эту тему уже немало написано — я же ставил перед собой другую цель — составить краткий обзор основных методов с характерными особенностями:

1. C помощью утилиты mysqldump. Данная программка крайне популярна среди пользователей веб-хостингов. Читая содержимое таблиц, она создаёт файл с SQL-инструкциями для последующего заполнения. Но, как правило, при использовании люди забывают про три ключевых момента:

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

Восстановление: путём скармливания dump-файла утилите mysql через STDIN.

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

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

Восстановление: путём копирования сохраненных файлов в каталог данных MySQL.

3. С помощью LVM.

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

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

Восстановление: путём копирования сохраненных с образа файлов в каталог данных MySQL.

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

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

Восстановление: вывод slave-сервера на место master`a, либо восстановление одним из вышеуказанных методов(в зависимости от выбранного).

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

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

Полный и инкрементный бэкап Mysql

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

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

Введение

В качестве примера я рассмотрю серверы с установленными там продуктами bitrix, работающими в bitrixenv. Особенностью будет то, что bitrix до сих пор использует не самую свежую версию mysql от percona — Percona Server for MySQL 5.7. Тем не менее, проблем с этим нет никаких. Версия будет поддерживаться минимум до октября 2023 года.

Для полных и инкрементных бэкапов я рассмотрю утилиту Percona XtraBackup, которая позволяет делать архивы баз данных на лету без блокировок таблиц. В моей статье будет использоваться версия 2.4, так как именно она поддерживает mysql 5.7. Это максимально доступная версия в репозиториях, которые устанавливает окружение bitrixenv.

Примеры в этой статье будут актуальны практически для всех версий Mysql и XtraBackup, так как в подходах и командах отличий почти нет. Важно знать, что последняя версия XtraBackup на момент написания статьи была 8.0 и она поддерживает популярный форк mysql — MariaDB только до версии 10.2 включительно, да и то с оговорками. Для более поздних версий mariadb рекомендуется использовать mariabackup. Это форк XtraBackup, который в использовании практически ничем не отличается от оригинала.

Сегодня я рассмотрю инкрементные бэкапы mysql только с помощью XtraBackup, а так же полные бэкапы в том числе с помощью mysqldump. MariaDB и Mariabackup рассматривать не буду. Принципиальных отличий между ними нет. Там все то же самое.

Установка Percona XtraBackup

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

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Дальше ставим нужную нам версию программы. Самую последнюю 8.0:

# yum install percona-xtrabackup-80

или 2.4

# yum install percona-xtrabackup-24

Обращаю внимание, что если на сервере с установленным bitrixenv установить просто пакет xtrabackup, без указания версии, будет установлена версия 2.3, которая не работает с уставленным там же по дефолту сервером mysql 5.7.

Устанавливаем в Debian/Ubuntu:

# wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
# dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb

И сам пакет:

# apt update && apt install percona-xtrabackup-80

Полный бэкап Mysql сервера

Итак, база данных у нас работает, утилиту для бэкапа мы установили. Давайте теперь сделаем полный backup всех баз данных нашего сервера mysql.

# xtrabackup --backup --user=root --password='R(zDXcVUmI[zwx%aNBTN' --target-dir=/root/backupdb/full

В дальнейших примерах я не буду указывать пользователя и пароль, чтобы упростить команды. Эти данные я указал в файле ~/.my.cnf.

[client]
user=root
password='R(zDXcVUmI[zwx%aNBTN'

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

# xtrabackup --prepare --target-dir=/root/backupdb/full

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

# xtrabackup --backup --compress --target-dir=/root/backupdb/full

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

# xtrabackup --decompress --target-dir=/root/backupdb/full

Для того, чтобы команда decompress отработала без ошибки:

sh: qpress: command not found
cat: write error: Broken pipe
Error: decrypt and decompress thread 0 failed.

Необходимо установить пакет qpress.

# yum install qpress

Он есть в репозитории percona. После этого распаковка пройдет штатно.

Лично я не вижу большого смысла использовать ключи compress и decompress. Можно сделать полный бэкап, подготовить его, а потом сжать тем же gzip.

# tar -czvf /root/backupdb/full.tar.gz -C /root/backupdb full

На выходе получите тот же архив, только сжат лучше и нет необходимости ставить дополнительный софт. Gzip и tar обычно есть во всех дистрибутивах. К тому же архив в виде единого файла проще и быстрее передать на сервер бэкапов и там хранить.

В завершении раздела про полный backup, предлагаю простенький скрипт для автоматизации процесса через cron — mysql-full-backup.sh.

#!/bin/bash

DATA=`date +%Y-%m-%d`

mkdir -p /root/backupdb/$DATA
xtrabackup --backup --target-dir=/root/backupdb/$DATA/full
xtrabackup --prepare --target-dir=/root/backupdb/$DATA/full
tar -czvf /root/backupdb/$DATA/full.tar.gz -C /root/backupdb/$DATA full
rm -rf /root/backupdb/$DATA/full

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

Инкрементный бэкап Mysql

Основное удобство XtraBackup как раз в простых, быстрых и удобных инкрементных бэкапах для mysql. Допустим, по примеру выше, вы сделали полный бэкап. Он должен быть не сжатый. Теперь на основе этого полного бэкапа, можно сделать инкрементный, где будут только изменения со времени полного бэкапа.

# xtrabackup --backup --target-dir=/root/backupdb/inc1 --incremental-basedir=/root/backupdb/full

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

backup_type = full-backuped
from_lsn = 0
to_lsn = 17687056
last_lsn = 17687065
compact = 0
recover_binlog_info = 1
flushed_lsn = 17687065

LSN — log sequence number. Это регистрационные номера транзакций. В данном случае полный бэкап начинается с нулевой транзакции и заканчивается 17687056. Теперь смотрим этот же файл в директории inc1.

backup_type = incremental
from_lsn = 17687056
to_lsn = 17710039
last_lsn = 17710048
compact = 0
recover_binlog_info = 1
flushed_lsn = 17710048

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

# xtrabackup --backup --target-dir=/root/backupdb/inc2 --incremental-basedir=/root/backupdb/full

либо так:

# xtrabackup --backup --target-dir=/root/backupdb/inc2 --incremental-basedir=/root/backupdb/inc1

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

Предлагаю вот такой скрипт для инкрементных бэкапов — mysql-inc-backup.sh.

#!/bin/bash

DATA1=`date +%Y-%m-%d`
DATA2=`date +%H-%M-%S`

xtrabackup --backup --target-dir=/root/backupdb/$DATA1/inc-$DATA2 --incremental-basedir=/root/backupdb/$DATA1/full

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

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

Восстановление из бэкапа

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

# systemctl stop mysqld && rm -rf /var/lib/mysql/*
# xtrabackup --copy-back --target-dir=/root/backupdb/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Разбираем, что я сделал.

1. Остановил mysql сервер и удалил все из ее рабочей директории.
2. Восстановил данные из архивной копии xtrabackup. По факту он просто скопировал данные в рабочую директорию mysql сервера.
3. Назначил пользователя mysql владельцем рабочей директории и всего ее содержимого.
4. Запустил mysql сервер с восстановленными данными.

После запуска mysql сервера проверяйте лог /var/log/mysql/error.log на предмет ошибок. Если увидите там такие ошибки:

[ERROR] InnoDB: Page [page id: space=14, page number=4] log sequence number 17744745 is in the future! Current system log sequence number 9160744.

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

Если будете восстанавливать базу на другой сервер, то последовательность действий будет следующая. Подключаем репозиторий percona.

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Ставим mysql server и xtrabackup нужной версии.

# yum install Percona-Server-server-57 percona-xtrabackup-24

Копируем на новый сервер архив сервера баз данных.

# scp [email protected]:/root/backupdb/full.tar.gz ~

Распаковываем его:

# tar xzvf full.tar.gz

Восстанавливаем данные и запускаем mysql сервер.

# xtrabackup --copy-back --target-dir=~/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Заходим в консоль mysql и проверяем список баз и пользователей.

# mysql -u root -p
mysql> show databases;
mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;

Все на месте, как и на исходном сервере.

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

# xtrabackup --prepare --apply-log-only --target-dir=/root/backupdb/full

Теперь добавляем туда данные из инкрементного бэкапа.

# xtrabackup --prepare --apply-log-only --target-dir=/root/backupdb/full --incremental-dir=/root/backupdb/inc1

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

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

Бэкап отдельной таблицы или базы

Не всегда нужны архивные копии всего mysql сервера. Иногда достаточно отдельной базы данных или даже таблицы. Xtrabackup позволяет это сделать. Архивируем только одну базу данных sitemanager.

Для того, чтобы этот способ бэкапа отдельной базы mysql работал, необходим параметр innodb_file_per_table в настройка сервера баз данных.

# xtrabackup --backup --databases "sitemanager" --target-dir=/root/backupdb/sitemanager

Восстановление отдельной базы mysql будет выглядеть так.

# xtrabackup --prepare --databases "sitemanager" --target-dir=/root/backupdb/sitemanager
# systemctl stop mysqld
# mkdir -p /var/lib/mysql.old/sitemanager
# mv /var/lib/mysql/sitemanager /var/lib/mysql.old
# mv /root/backupdb/sitemanager/sitemanager /var/lib/mysql
# chown -R mysql. /var/lib/mysql
# systemctl start mysql

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

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

Готовим бэкап к восстановлению:

# xtrabackup --prepare --export --target-dir=/root/backupdb/full

Идем в консоль mysql и выбираем там таблицу для восстановления. В моем примере это будет таблица b_user_access из базы sitemanager. Смотрим, заполнена ли таблица данными.

mysql> SELECT COUNT(*) FROM sitemanager.b_user_access;
+----------+
| COUNT(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Делаем DISCARD этой таблицы.

mysql> ALTER TABLE sitemanager.b_user_access DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

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

# cp /root/backupdb/full/sitemanager/b_user_access.* /var/lib/mysql/sitemanager
# chown mysql. /var/lib/mysql/sitemanager/b_user_access.*

Возвращаемся в консоль mysql и импортируем данные.

mysql> ALTER TABLE sitemanager.b_user_access IMPORT TABLESPACE;
Query OK, 0 rows affected (0.03 sec)

Смотрим, что получилось.

> SELECT COUNT(*) FROM sitemanager.b_user_access;
+----------+
| COUNT(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Данные восстановлены. Вернулись те же 6 строк, что и были до этого.

Бэкап и восстановление mysql с помощью mysqldump

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

Бэкап всех баз mysql сервера с его помощью:

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases > /root/backupdb/all.sql

Можно сразу же сжимать его.

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

Бэкап конкретной базы данных.

/usr/bin/mysqldump sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz

Мне чаще всего мешают в дампе команды на создание базы данных — CREATE DATABASE, поэтому я их убираю ключом no-create-db.

/usr/bin/mysqldump --no-create-db sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz

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

# mysql -uroot -p
mysql> use sitemanager;
mysql> source /root/backupdb/sitemanager.sql;

Если дамп без команды на создание базы данных и ее нет у вас на сервере, то не забудьте ее перед этим создать. Так же восстановить базу данных из дампа можно следующим образом.

mysql> use sitemanager;
mysql> \. /root/backupdb/sitemanager.sql

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

#!/bin/bash

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 > /root/backupdb/`date +%Y-%m-%d`-$i.sql.gz;
    done

Так же могу порекомендовать вот этот скрипт для бэкапа — https://github.com/adegtyarev/mysqlbackup. Описывать его не буду, по комментариям в скрипте понятен его функционал.

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

# cat sitemanager.sql | /usr/bin/awk '/CREATE TABLE `b_catalog_discount`/,/UNLOCK TABLES/' > /tmp/b_catalog_discount.sql

Дальше через source можно восстановить данные из этого дампа отдельной таблицы.

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

#!/bin/bash

USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'

MYSQL="mysql --user=$USER --password=$PASS --skip-column-names";
DIR="/root/backupdb"

for s in mysql `$MYSQL -e "SHOW DATABASES"`;
    do
    mkdir $DIR/$s;
    for t in `$MYSQL -e "SHOW TABLES FROM $s"`;
	do
	    /usr/bin/mysqldump --user="$USER" --password="$PASS" --opt $s $t | /usr/bin/gzip -c > $DIR/$s/$t.sql.gz;
	done
    done

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

for s in mysql sitemanager;

Восстановить потом всю базу из такого потабличного бэкапа можно таким образом.

#!/bin/bash
#

DB=sitemanager;
USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'
DIR="/root/backupdb/sitemanager"

for s in `ls -1 $DIR`;
    do
    echo "--> $s restoring... ";
    zcat $DIR/$s | /usr/bin/mysql --user=$USER --password=$PASS $DB;
    done

При использовании пароля в открытом виде в mysql или mysqldump, в консоль постоянно сыпятся предупреждения.

mysql: [Warning] Using a password on the command line interface can be insecure.

Чтобы их не было, перенесите, как я показывал выше, пароль в отдельный файл ~/.my.cnf, а из скрипта уберите авторизацию вообще.

На этом, пожалуй, насчет бэкапа баз mysql сервера все. Поделился основными своими наработками.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

К примеру, если работает интернет магазин или crm, делать бэкап раз в сутки по ночам не вариант. Надо намного чаще. Хотя бы каждые час-два. Полные дампы снимать не рационально в этом случае. Это и долго, и объем большой. Нужны инкрементные бэкапы.

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

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Что даст вам этот курс:

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

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автоматизация настройки резервного копирования MS SQL с помощью .NET приложения

Я долго созревал, чтобы написать данную статью и выложить свое приложение. Надеюсь вам будет интересно.

О чем данная статья

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

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

Для описанных ниже задач можно использовать мастер планов обслуживания, но мне больше понравился такой подход. Основное преимущество описанного мною метода, что данный способ можно применять ко всем версиям MS SQL (кроме Express, там немного другой подход). План обслуживания можно переносить, но у вас должна быть соответствующая в версия MS SQL и все равно будет создан Job для запуска плана обслуживания.

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

Кому подойдет данная статья:

• Тем, у кого MS SQL Express и нет возможности запускать с помощью Job задачи
• Тем, кто в ближайшем будущем планирует перейти с MS SQL 2008 на более новую версию и не хочет настраивать зеркалирование БД, а сразу на новой версии настроить AlwaysOn
• Тем, у кого нет средств для поднятия еще резервных серверов и приходится обходиться тем, что есть.
• У кого нет сжатых сроков на время восстановления БД. Главное – это результат
• Кому лень что-то делать
• Просто любопытным людям.

Оглавление:

Теория о резервном копирование

1. Журнал транзакций
2. Разностная копия БД
3. Системные базы данных
4. План бекапирования
5. Общие рекомендации по резервному копированию

Используем приложение

1. Настройка уведомления администратора
2. Дополнительные уведомления для администратора
3. Решение проблем при настройке DatabaseMail
4. Настраиваем резервное копирование с помощью приложения для SQL Standart
5. Настраиваем резервное копирование с помощью приложения для SQL Express
6. Удаление задач из БД
7. Удаление копий БД

Как восстанавливать резервные копии

Список статей хабра, которые я использовал

1. Создание и хранение резервных копий баз данных в MS SQL. Практические советы
2. Построение цепочки восстановлений баз данных MS SQL
3. Настройка Database Mail в MS SQL Server 2005 и старше
4. SQL Server 2008: бэкапим с умом. Часть 1: Теория
5. Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server

Исходники на github для MS SQL Standart и для MS SQL Express
Если появится желающие добавить свои мысли в код, принимаю pull request. Готов выслушать конструктивную критику и доработать приложение, если это действительно кому-то нужно будет.

Теория о резервном копирование

Все что описано в теории, вы можете найти самостоятельно. Конфигурации, которые описаны в данном разделе, автоматически будут выполнены моим приложением при настройке резервного копирования.
MS SQL Server поддерживает 3 модели резервного копирования.

1. Простую
2. Модель полного восстановление
3. Модель полного восстановления с неполным протоколированием

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

ALTER DATABASE [Имя базы данных] SET RECOVERY FULL;

При переключении модели восстановления на полную у нас появится следующие возможности:

1. СУБД перестанет автоматически очищать журнал транзакций . Журнал будет расти до тех пор, пока не будет сделана его резервная копия. Это важный момент, администратору БД необходимо продумать вопрос о плане резервного копирования и очистки журнала. UPD: спасибо за помощь Yggaz
2. Создание разностной резервной копии
3. Создание полной резервной копии

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

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

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

Преимущества при восстановлении БД с помощью журнала транзакций:

1. восстановление отдельных транзакций;
2. восстановление всех незавершенных транзакций при запуске SQL Server;
3. накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя и т.д

Рекомендации

1. Вынести на быстрый жесткий диск, чтобы при большом потоке операций не было задержек при записи.
2. Необходимо делать резервные копии журнала транзакций не реже чем каждый час.
3. После создания полной (разностной) копии базы данных, все старые журналы можно удалять, т.к. они теряют свою актуальность.
4. Внимательно следите за размером диска на котором хранятся журналы транзакций, если оно закончится, то записать новые данные в БД будет невозможно, пока не произойдет уменьшение размеров журнала транзакций или не добавиться новый дополнительный файл транзакций.
5. Журнал транзакций необходимо регулярно усекать, чтобы избежать его переполнения. UPD: Как сказал kolu4iy данная операция по усечению слегка сомнительна в плане производительности, т.к. при бэкапирование журнал транзакции очищается внутри и СУБД начинает писать в нем по новой. Однако у вас может возникнуть ситуация, которую описал я в своем комментарии и тогда это вам может пригодиться.
6. Возможна ситуация, когда невозможно сразу сделать усечение журнала. Они описаны в данной статье
7. Для получения информации о состоянии базы данных можно с помощью следующего запроса:

   select name,log_reuse_wait, log_reuse_wait_desc  from sys.databases

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

   DBCC OPENTRAN (Имя базы данных) WITH TABLERESULTS
   

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

BACKUP LOG [Имя базы данных] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL\MSSQL\Backup\[Имя файла].bak' WITH NOFORMAT, NOINIT, 
NAME = N'Журнал транзакций  Резервное копирование', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
USE [Имя базы данных]
GO
DBCC SHRINKFILE (N'Имя файла лога БД' , 25)
GO

Эти же операции можно проделать с помощью SSMS

2.Разностная копия БД

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

1. Используйте разностные копии БД, если создание полной копии БД занимает большой промежуток времени
2. Периодически делайте полную копию БД, чтобы уменьшить объемы создаваемых разностных копий.
3. После создания полной копии БД, все предыдущие разностные копии теряют свою актуальность.

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

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

Пример SQL для создания резервной разностной копии БД с проверкой копии по завершению (отличается от полного копирования флагом DIFFERENTIAL вместо него нужно использовать NOFORMAT).

declare @pathBackup as varchar(55)
set @pathBackup =  N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak'
BACKUP DATABASE [Имя базы данных] TO  DISK = @pathBackup
WITH DIFFERENTIAL, NOFORMAT, INIT, NAME = N'Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM
GO
declare @backupSetId as int
declare @pathBackup as varchar(55)
set @pathBackup =  N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak'
select @backupSetId = position from msdb..backupset where database_name=N'[Имя базы данных]' 
and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'[Имя базы данных]')
if @backupSetId is null 
begin 
	raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "[Имя базы данных]" не найдены.', 16, 1) 
end
RESTORE VERIFYONLY FROM  DISK = @pathBackup
WITH FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

3.Системные базы данных

Помимо основной базы и связанных с ней файлов, я настоятельно рекомендую делать копии и системных баз данных. Начнем с того, что рассмотрим какие базы существуют в MS SQL. Их всего 5:

Более подробно можете прочитать о них тут и еще вот тут.

Я выбрал резервировать только 2 системные БД:

1. msdb – потому что, там хранятся настроенные задачи и другие
2. master – хранятся все произведенные настройки SQL Server.

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

4. План бекапирования

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

Мы будем делать следующие резервные копии:

• Полная копия основной БД, чаще чем раз в неделю нет необходимости
• Разностная копия основной БД, каждый день
• Копии журнала транзакций основной БД, каждый час
• Копия системной БД master, раз в неделю
• Копия системной БД msdb, раз в неделю

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

5. Общие рекомендации по резервному копированию

1. Используйте опцию

   BACKUP WITH CHECKSUM

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

2. Не выполняйте резервное копирование файлов на тот же физический диск, на котором хранится база данных или протокол транзакций.
3. Если вы используете MS SQL 2008 или выше, рекомендую вам использовать сжатие резервных копий средствами SQL. Следующий код включит сжатие по умолчанию:

   USE master; GO EXEC sp_configure ‘backup compression default’, '1'; RECONFIGURE WITH OVERRIDE;

4. держите резервные копии по нескольку дней на случай, если одна из них будет повреждена – старая резервная копия лучше, чем никакой.
5. Используйте DBCC CHECKDB для проверки каждой базы данных перед копированием, это своевременно предупредит вас о надвигающихся проблемах.

   DBCC CHECKDB ('Имя базы данных') WITH NO_INFOMSGS,   ALL_ERRORMSGS;

   Примечание: на практики мы использовали данную проверку, только перед выполнением полной резервной копии.

6. Выполняйте периодически обновление статистики и реорганизации индексов БД

Используем приложение

Несколько нюансов по приложению:

• Все тексты и запросы в коде вынесены в ресурсы, мне так было проще
• При вводе параметров соединения и других настроек, они сохраняются в файл. Для Express и Standart используются разные файлы (dbStandart, udExpress) в них хранится класс UserData
• Для выполнения некоторых операций могут потребоваться права администратора
• На данный момент не работает соединение с БД под доменной учетной записью
• Программа не обладает суперкрасивым интерфейсом

1. Настройка уведомления администратора

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

Для данной цели используется DatabaseMail MS SQL (для версии Standart и выше)

В своем приложение я сделал специальный раздел для автоматизации данной задачи

При нажатии появится форма для заполнения информации необходимой для создания профиля рассылки писем:

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

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

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

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

Выполняемые действия на данном этапе:

1. Меняются системные параметры MS SQL.
2. Создается DatabaseMail Profile
3. Активируется в SQL Agente профиль
4. Создается DatabaseMail Account
5. Добавляется DatabaseMail Account к Database Mail Profile
6. Создается DatabaseMail Operator

Более подробно описано в следующей статье и, частично, я брал отсюда. Естественно, данные действия можно выполнить с помощью SSMS.

2.Дополнительные уведомления для администратора

В программе предусмотрены 2 задачи, применяемые к БД:

1. проверка целостности БД. Для проверки базы данных использовалась стандартная процедура DBCC CHECKDB.
2. информирование о свободном месте в файловых группах.
3. Вторая задача была реализована с помощью запроса к системной таблице dbo.sysfiles
4. Вот пример данного запроса, который выполнялся к базе:

Select 
 NAME = left(a.NAME,15),
 a.FILEID,
 [FILE_SIZE_MB] = convert(decimal(12,2),round(a.size/128.000,2)),
 [SPACE_USED_MB] = convert(decimal(12,2),round(fileproperty(a.name,'SpaceUsed')/128.000,2)),
 [FREE_SPACE_MB] = convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) ,
 FILENAME = a.FILENAME
From dbo.sysfiles a

Ответ с сервера приходит на почту администратора в виде html разметки. Данный синтаксис возможен благодаря следующей стандартной функции MS SQL FOR XML.

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

Настроить эти операции можно с помощью соответствующего пункта в меню программы:

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

3.Решение проблем при настройке DatabaseMail

В MS SQL 2008 я столкнулся с проблемой при настройке SQL Server Agent. Симптомы следующие, после настройки невозможно запустить SQL Agent. В основном это решается с помощью установки update на SQL сервер.

Убедитесь, что установлен sp1, а потом можно уже ставить обновление.

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

Если есть проблемы с модулем DatabaseMail. После настройки данного модуля с помощью приложения, необходимо зайти в SQL Agent и просмотреть журнал событий. Если там будут ошибки «невозможно подключиться к почтовому ящику». Значит есть проблема, даже если через проверку отправляется письмо.

Исправляется это следующими манипуляциями:

1. Management Studio — SQL Server Agent — Properties.
2. Alert System
3. Уберите галочку с Enable mail profile
4. Нажмите OК
5. Зайдите снова и поставьте галочку
6. Перезагрузите SQL Server Agent.

Проверьте учетную запись для SQL Agent service. Если это доменная учетная запись измените ее на системную или наоборот. Все должно заработать.

4.Настраиваем резервное копирование с помощью приложения для SQL Standart:

Выбираем версию Standart. Настраиваем уведомления. (см. раздел, настройки уведомления):

Соединяемся с БД, заполняя данные для соединения и указываем БД, для которой будет применяться Job:

Выбираем настройку резервного копирования:

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

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

5.Настраиваем резервное копирование с помощью приложения для SQL Express:

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

Для этого запускаем приложение. Выбираем пункт MS SQL Express:

Появляется форма для заполнения параметров:

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

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

6.Удаление задач из БД.

Если необходимо удалить все задачи из БД (например, захотели изменить пути сохранения БД). Для этого используем соответствующий пункт в меню программы. Из SQL Agent будут удалены все задачи с определенным начальным префиксом (в моем случае King):

7.Удаление копий БД

В некоторых задачах, настроено удаление старых копий БД. Для этого я использую процедуру master.dbo.xp_delete_file. Пример использования: Удалит все файлы с расширением bak из указанной папки, дата создания которых превышает 14 дней.

EXECUTE master.dbo.xp_delete_file 0,"E:\backups",N'bak',dateadd(d,-14,getdate()),0;

И вот еще один более подробный пример и информация о том, какие параметры принимает данная функция.

Как восстанавливать резервные копии

Из-за нехватки времени модуль восстановления еще не реализован, возможно в будущем я его добавлю, а пока просто кратко опишу как можно будет восстановить базу.

С помощью SQL скрипта. Для восстановления базы данных используется команда RESTORE.

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

RESTORE DATABASE [Имя базы данных] FROM DISK = 'Z:\SQLServerBackups\back.bak' WITH REPLACE

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

RESTORE DATABASE TEST_DB –восстанавливаем полную копию
   FROM test_db_full
   WITH NORECOVERY;
GO
RESTORE DATABASE TEST_DB –восстанавливаем разностную копию
   FROM test_db_diff
   WITH FILE = 1,
   NORECOVERY;
GO
RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №1
   FROM test_db_tran_1
   WITH FILE = 1,
   WITH NORECOVERY;
GO
RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №2
   FROM test_db_tran_2
   WITH FILE = 1,
   WITH NORECOVERY;
GO
RESTORE DATABASE TEST_DB
   WITH RECOVERY;
GO

Для восстановления БД можно использовать так же и SSMS.

Резервное копирование MySQL. Бэкап MySQL. Сделать бэкап MySQL

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

В данном документе подробно рассматриваются принципы и процедуры, которые необходимо соблюдать для реализации стратегии резервного копирования MySQL на уровне предприятия при использовании агента Bacula Enterprise Edition для MySQL.

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

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

Резервное копирование MySQL доступно для платформ Linux 32 и 64 бита (платформы Debian, Ubuntu, CentOS и др.), и поддерживает MySQL 4.0.x, 4.1.x, 5.0.x, 5.5.x, 5.6.x.

Как сделать бэкап MySQL: дамп или бинарный лог?

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

[1] Чтобы восстановить единичный объект MySQL, необходимо отредактировать дамп файл.

[2] Чтобы восстановить базу MySQL до предыдущей версии, Вам, возможно, потребуется отредактировать SQL файл, если вы используете функции, недоступные в предыдущей версии. Как правило, восстановление MySQL до предыдущей версии не поддерживается и не гарантируется.

Рисунок 1: Связь между бэкапом и бинарными логами

Автоматический бэкап MySQL с внутренним агентом

Автоматический бэкап базы данных MySQL в режиме дампа

На протяжении всего срока существования БД MySQL создает логи, которые можно использовать для репликации и/или защиты БД с помощью технологии P.I.T.R (восстановление MySQL до заданной контрольной точки).
По умолчанию агент MySQL создает дамп каждой БД отдельно. Это значит, что, если вам нужно восстановить весь сервер, все БД будут согласованы по-отдельности, но их резервные копии не не будут создаваться в одно и тоже время. Значит базы данных MySQL не будут согласованы глобально. Чтобы решить данную проблему, агент для резервного копирования MySQL также будет сохранять лог файлы, создаваемые во время резервного копирования. Эти лог файлы можно будет считать впоследствии, чтобы гарантировать согласованность баз данных на определенный момент времени.

На рисунке 1, показан процесс создания бэкапов баз данных MySQL БД1, БД2 и БД3 (процесс занимает несколько часов). Во время данного процесса генерируются 3 лог файла. Эти файлы включаются в полный бэкап MySQL. Следующий инкрементальный или дифференциальный бэкап MySQL сохранит только бинарные логи, созданные после полного бэкапа. Чтобы гарантировать, что только одна копия каждого лог файла включена в бэкап, необходимо активировать функцию Accurate для выполнения задачи.

В примере выше, первый инкрементальный бэкап, созданный после полного бэкапа, будет включать логи 5 и 6, второй инкрементальный бэкап будет включать логи 7 и 8. Дифференциальный бэкап включал бы лог файлы 5, 6, 7 и 8.
При использовании функции all_databases будут создаваться дампы всех БД одновременно. При этом лог файлы , созданные по завершении полного бэкапа, не будут включаться в него, а логи, сгенерированные до завершения задачи, будут включены в полный бэкап. В примере на рисунке 2 показано, что полный бэкап сгенерирует единый дамп файл «all-databases.sql», который будет включать лог файлы 2 и 3. Первый последующий инкрементальный бэкап будет включать логи 4, 5 и 6.

Рисунок 2: Связь между функцией all_databases и бинарными логами

Как сделать бэкап базы данных MySQL в режиме бинарных логов

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

Утилита бэкапа MySQL может создавать резервные копии данных из хранилищ InnoDB, XtraDB, и MyISAM на немодифицированных серверах MySQL 5.0, 5.1 и 5.5, также как это делает утилита Percona Server с XtraDB.
Более подробную информацию об утилите Percona вы найдете на сайте:

http://www.percona.com/doc/percona-xtrabackup.

Оценка информации при бэкапе таблицы MySQL

Команда estimate позволяет отобразить всю информацию, найденную агентом MySQL. В случае режима дампа, наше ПО не может оценить размер дамп файла для БД. Вместо этого оно отобразит размер БД.

Информация о резервном копировании MySQL в режиме дампа

Агент MySQL сгенерирует следующие файлы в каталоге Bacula для сервера, имеющего единую БД “test”.

Таблица 2. Содержание бэкапа MySQL в режиме дампа

Восстановление MySQL

Bacula позволяет восстановить бэкап MySQL в нескольких режимах восстановления:

• Восстановление MySQL из дамп файла или бинарных логов
• Восстановление пользователей и ролей
• Восстановление единой БД MySQL
• Восстановление MySQL до контрольной точки

Чтобы восстановить бэкап MySQL в режиме бинарных логов, агент использует утилиту percona.

Рисунок 3: Содержимое сервера во время восстановления MySQL

Рисунок 4: Содержимое БД во время восстановления MySQL

Как сделать бэкап базы данных MySQL без использования плагина бесплатно

Создание дампа базы данных MySQL

Данный способ полностью бесплатен, поскольку позволяет делать бэкап MySQL с помощью open source версии Bacula Community и без дополнительных плагинов. Для резервного копирования небольших баз данных MySQL можно использовать простые bash-скрипты для резервного копирования баз данных. Для случая с резервным копированием баз MySQL можно сделать скрипт бэкапа MySQL, который будет запускаться на клиенте и делать dump базы данных MySQL.

#!/bin/bash  

mysqldump -uuser -ppassword —all-databases | gzip > /opt/mysql_backup/backup.`date +%F`.sql.gz 

find /home/bacula-backup/ -type f -mtime +3 -exec rm -f {} \;

Этот скрипт бэкапа MySQL сохранит дамп всех БД MySQL в директорию /opt/mysql_backup/ из которой мы и будем делать резервные копии дампов базы данных, при помощи директивы Client Run Before Job.

Пример задачи на бэкап базы MySQL:

Job {

   Name = «BackupSmallMysqlServer»

   Type = Backup

   Level = Incremental

   Client = mysqlserver1

   FileSet = «mysqlserver»  

   Schedule = «WeeklyCycle»  

   Storage = SD1  

   Messages = Standard

   Pool = Mysql

   ClientRunBeforeJob = «/opt/sbin/mysql.sh»

   SpoolAttributes = yes

   Priority = 10

   Write Bootstrap = «/var/lib/bacula/%c.bsr»

     }

   FileSet {  

     Name = «mysqlserver»  

     Include {    

        Options {      

          signature = MD5      

          compression = GZIP    

                }

     File = /opt/mysql_backup/  

              }

            }

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

Как сделать бэкап нагруженных баз данных MySQL?

Если база данных MySQL сильно нагружена, то не рекомендуется на ней делать дамп, так как таблицы на время дампа блокируются. Самое правильно решение в этом случае — сделать реплику базы данных Master-Slave Replication.

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

Для нагруженных систем резервное копирование MySQL необходимо делать именно для Slave базы данных.

Ежедневная архивация mysql-баз под windows / Хабр

Задача, которая стояла передо мной:
Есть сервер с mysql под управлением windows server 2008 R2, на котором, в числе прочего, крутится mysql с несколькими десятками баз данных, число и состав которых периодически меняется. Нужно организовать ежедневный бекап этих баз без остановки mysql сервера, причем таким образом, чтобы каждая база попадала в отдельных архив. Эта, на первый взгляд простейшая задача (возможно, так оно и есть) для меня оказалась достаточно сложной.

Что нам говорит гугл?

О том, что есть mysqlhotcopy и mysqldump. Первый работает прямо с файлами баз данных, второй — делает дампы с помощью запросов.

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

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

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

Реализовал я это так — батник смотрит какие папки лежат в директории данных mysql и в цикле подставляет имя каждой из них (которое и является именем базы данных) в строку параметров mysqldump.

SET SOURCEDIR=E:\xampp\mysql\data\

set hour=%TIME:~0,2%
set minute=%TIME:~3,2%
set second=%TIME:~6,2%
set HHMMSS=%hour%-%minute%

for /d %%i in (%SOURCEDIR%\*) do "E:\xampp\mysql\bin\mysqldump.exe" -uusername -hlocalhost -ppassword -c -n %%~ni | "c:\Program Files\7-Zip\7z.exe" a -tgzip -si"%%~ni_%DATE%_%HHMMSS%.sql" "D:\backups\data\%DATE%_%HHMMSS%\%%~ni.sql.gzip"

eachfile.exe -purge -r -w -e -d 13 -l 0 -dir D:\backups\data\

exit

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

В процессе гугления также наткнулся на программу MySQL Backup Tool тестировать которую, однако, не решился.

автоматическая копия базы данных по расписанию

С помощью инструмента Handy Backup MySQL резервная копия базы сохраняется в виде читаемых и модифицируемых dump-файлов, содержащих в себе последовательности команд MySQL для восстановления исходных таблиц. Это позволяет реализовать следующие принципы.

Модифицируемость

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

Масштабируемость

Резервное копирование базы данных MySQL указанным методом позволяет использовать файлы копий таблиц для различных целей, помимо аварийного восстановления, как-то: для размножения (клонирования, зеркалирования, репликации) таблиц, рассылки БД и т.п.

Сжатие

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

На MySQL основано множество коммерческих приложений и задач уровня предприятия. Рассмотрим основные сферы, где резервные копии данных MySQL будут критически важны при создании системы безопасности для коммерческих или приватных данных.

Динамические данные веб-сайтов под управлением MySQL

Обычно управление сайтом осуществляется по FTP или через систему управления веб-контентом (CMS). Ниже представлен сценарий управления динамическим контентом сайта с подключенной БД MySQL по FTP:

• Для бэкапа статического контента сайта воспользуйтесь плагином FTP. Этот плагин предназначен для резервного копирования на FTP сервер и предоставляет доступ к файлам на удалённом сервере через протокол FTP.
• Далее воспользуйтесь плагином MySQL Backup для резервного копирования требуемых динамических данных веб-сайта, хранящихся под управлением MySQL (например, содержимого форумов или CMS).

Эта схема работает для большинства систем управления контентом (CMS): WordPress, Drupal, Joomla, ModX и другие. Узнать подробнее о резервном копировании сайтов.

Приложения, основанные на MySQL

Для бизнес-приложений, не имеющих встроенного механизма резервного копирования, любой сбой может обернуться потерей данных и серьёзными убытками. Handy Backup позволит вам избежать подобных проблем, создавая резервные копии таблиц MySQL.

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

Совет: создавая продукт или услугу, использующую БД MySQL (например, сервис хостинга файлов), включите в её состав резервное копирование с Handy Backup, чтобы повысить стабильность и надёжность хранения данных.
(См. наш раздел о партнёрской программе).

MySQL Auto Backup | Блог SQLBackupAndFTP

Если вам нужен инструмент автоматического резервного копирования MySQL, вы можете использовать SQLBackupAndFTP. Очень важно регулярно делать резервные копии MySQL. Вам действительно нужно делать автоматическое резервное копирование и восстановление MySQL? Конечно. Если вы не заботитесь о своих данных или вам не нужно полностью воссоздавать базу данных в случае аварии, вам нужен какой-то способ восстановить базу данных до работоспособного состояния. Есть несколько способов выполнить резервное копирование и восстановление MySQL Server, но самый быстрый — использовать приложение SQLBackupAndFTP.

MySQL Auto Backup

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

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

Составить стратегию резервного копирования на самом деле проще и легче, чем может показаться, даже несмотря на то, что команды автоматического резервного копирования и восстановления MySQL имеют множество решений.

Реализация плана резервного копирования — относительно простая часть. Составление рабочего плана — чрезвычайно важная вещь, о которой часто забывают.

План автоматического резервного копирования и восстановления MySQL

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

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

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

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

Еще одна важная опция, которая поможет вам предотвратить сбой базы данных, — это запуск самых последних обновлений для MySQL Server. Или же это приведет к неправильной работе вашей смены.

Следующая проблема, которая потенциально может повредить вашу базу данных, — это необходимость сэкономить свободное место на локальном диске. Согласно моему личному опыту, были некоторые пользователи, которые хранили все файлы базы данных MySQL Server в zip или 7zip файлах, чтобы сэкономить немного места на своих жестких дисках. В конце концов, эти шаги приводят к сбою базы данных.Если вам отчаянно требуется свободное место, не стесняйтесь использовать сторонний инструмент, такой как SQLBackupAndFTP, для создания резервных копий базы данных со сжатием и хранения их в Интернете.

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

MySQL Auto Backup

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

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

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

SQLBackupAndFTP — MySQL Auto Backup Tool

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

Рабочие команды:

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

С помощью mysqldump:

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

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

.

AutoMySQLBackup скачать | SourceForge.net

Полное имя

Телефонный номер

Должность

Промышленность

Компания

Размер компании

Размер компании: 1 — 2526 — 99100 — 499500 — 9991,000 — 4,9995,000 — 9,99910,000 — 19,99920,000 или более

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

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

Да, также присылайте мне специальные предложения о продуктах и ​​услугах, касающихся:

Программное обеспечение для бизнеса

Программное обеспечение с открытым исходным кодом

Информационные технологии

Программирование

Оборудование

Вы можете связаться со мной через:

Электронная почта (обязательно)

Телефон

смс

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

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

Для этой формы требуется JavaScript.

Подписывайся

Кажется, у вас отключен CSS.Пожалуйста, не заполняйте это поле.

Кажется, у вас отключен CSS.
Пожалуйста, не заполняйте это поле.

.

Бесплатный инструмент резервного копирования MySQL

Резервное копирование MySQL за 2 мин.

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

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

Особенности и цены

от $ 0

• бесплатно — резервное копирование 2 баз данных в сеть или FTP по расписанию

• $ 39 + резервное копирование 5 баз данных, Google Drive или Dropbox

• $ 89 + неограниченное резервное копирование базы данных, OneDrive Personal и Box

• 129 долларов США + Amazon S3, Windows Azure, OneDrive для бизнеса и шифрование AES

• 399 $ + пожизненные обновления

Купить сейчас

Что умеет SQLBackupAndFTP?

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

• Запустить запланированное резервное копирование баз данных MySQL, а также локальных файлов и папок
• Сжатие и шифрование резервных копий
• Хранить резервные копии в сетевой папке, на FTP-сервере или в облаке (Amazon S3, Google Drive, Dropbox, Box, OneDrive)
• Удалить старые резервные копии
• Отправить уведомление по электронной почте, чтобы подтвердить успешное или неудачное резервное копирование
• Восстановить любую резервную копию прямо из программы
• Сделать историю резервного копирования доступной для просмотра в Интернете
• Уведомить вас, если ваш сервер MySQL не работает

Что уникального в этом инструменте резервного копирования MySQL?

• Не все хостинговые платформы позволяют администраторам баз данных подключаться к размещенной базе данных через TCP / IP.Если вы не можете подключиться к серверу MySQL через TCP / IP, вы все равно можете сделать резервную копию MySQL через экспорт phpMyAdmin. Все, что вам нужно, это URL-адрес для входа в phpMyAdmin

.

• Вы можете просмотреть результаты резервного копирования MySQL для нескольких серверов. Результаты доступны в веб-журнале
• У этого инструмента есть полнофункциональная бесплатная версия. Это идеальное решение, если все, что вам нужно, — это специальные резервные копии MySQL или резервное копирование по расписанию для 1 или 2 баз данных

Как сделать резервную копию баз данных MySql?

SQLBackupAndFTP работает на машинах Windows и может создавать резервные копии как удаленных, так и локальных баз данных MySQL.Доступны два метода подключения к базе данных: через соединение TCP / IP (SSH) или с помощью экспорта phpMyAdmin. В обоих случаях он создает сценарии MySQL, которые можно запустить позже для восстановления баз данных MySQL. Когда используется соединение TCP / IP, резервное копирование выполняется с помощью утилиты mysqldump.

Как этот инструмент связан с MySQLBackupFTP?

Ранее SQLBackupAndFTP и MySQLBackupFTP были двумя разными продуктами. MySQLBackupFTP с тех пор устарел.Теперь SQLBackupAndFTP включает в себя все функции MySQLBackupFTP и многое другое. SQLBackupAndFTP может восстанавливать резервные копии MySQL. Кроме того, он также может уведомить вас, если что-то пойдет не так с вашими серверами MySQL.

.

Скачать AutoMySQLBackup с SourceForge.net

Полное имя

Телефонный номер

Должность

Промышленность

Компания

Размер компании

Размер компании: 1 — 2526 — 99100 — 499500 — 9991,000 — 4,9995,000 — 9,99910,000 — 19,99920,000 или более

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

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

Да, также присылайте мне специальные предложения о продуктах и ​​услугах, касающихся:

Программное обеспечение для бизнеса

Программное обеспечение с открытым исходным кодом

Информационные технологии

Программирование

Оборудование

Вы можете связаться со мной через:

Электронная почта (обязательно)

Телефон

смс

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

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

Для этой формы требуется JavaScript.

Подписывайся

Кажется, у вас отключен CSS.Пожалуйста, не заполняйте это поле.

Кажется, у вас отключен CSS.
Пожалуйста, не заполняйте это поле.

.