Комментарии 4
В СУБД MySQL имеются два вида бэкапов: логические и физические.
Примитивно и вообще-то неверно, ну или как минимум некорректно. Я делаю бэкап структуры с помощью mysqldump, а бэкап данных с помощью SELECT .. INTO OUTFILE - он какой? такой метод ни под одну из двух описанных категорий не подпадает.
Если делить на два типа, то это будут:
#1 - бэкап, создаваемый при работающем сервере БД, путём получения копии данных (включая метаданные) путём выполнения запросов к серверу БД.
#2 - бэкап, создаваемый при остановленном сервере БД, путём копирования файлов баз данных сторонними средствами (средствами операционной системы или программами третьей стороны).
Описанный в статье логический бэкап есть всего лишь подмножество типа #1.
Формально ещё есть и третий тип, когда используются программные средства третьей стороны, самостоятельно интерпретирующие и резервирующие состояние БД либо прямым доступом к файлам БД, либо встраиваясь в процессы сервера. То есть выполняющие резервирование при работающем сервере БД, но "помимо" него. При этом такие программные средства должны самостоятельно отслеживать выполняемые сервером операции с данными и принимать меры к тому, чтобы не получить несогласованный бэкап. Обычно такие программы устанавливают в систему свой агент (реже - используют в качестве такого агента внешнюю UDF), который и занимается таким отслеживанием и предоставляет программе необходимые сведения. В общем, нечто типа получения снапшота работающей системы, но пригодного к использованию при восстановлении.
я думаю, тут описано другое разделение типов. "логические" бэкапы - это когда восстановление происходит через выполнение sql-команд из текстовых дампов. а "физические" - это бэкапы на уровне бинарных файлов.
ваш способ (mysqldump+select into outfile) относится к "логическому".
при этом авторский вариант инкрементальных бэкапов - это некий гибрид. главный бэкап через mysqldump, а дельта-инкременты - через файлы бинарного журнала (хотя в конце концов их придется преобразовать в sql-команды перед восстановлением).
Надеюсь, автор не сочтет за придирки, но есть пара замечаний, которые новичкам следует иметь в виду:
Приведенные скрипты не будут работать из-под планировшика как ожидалось: поскольку пароль не указан, то во время исполнения скрипт остановит работу и будет ждать, когда же пользователь его – пароль – введет. Может и три дня прождать. Пустяковый трабл, конечно.
В таком виде скрипты, обращающиеся к mysqldunp, не сохраняют в дампе хранимые процедуры и функции. В глаза это не бросаетя, но рано или поздно станет проблемой, когда потребуется восстановить БД полностью, а не только таблицы. Нужно включать опцию --routines (или -R).
@Andrey_Biryukov FYI
Резервное копирование и восстановление СУБД MySQL