Действительно ли достаточно резервировать весь сервер - включенный MySQL?
Функцией, которую Вы ищете в решении для резервного копирования, является способность к долям резервной сети. Ленточные накопители (и ленты) являются действительно очень дорогими. Диски LTO4, которые я просто купил, стоят очень дорогой пенс. Если Вы не покупаете ленточную систему, которая может содержать Ваше все резервное копирование в единственной ленте, необходимо будет запланировать или ручные изменения ленты во время резервных копий или получить автопогрузчик некоторого вида.
Я боюсь, что достойные ленточные системы (где 'достойный' означает стандартный, а не починенный от частей), вероятно, значительно превысят цену Вашего NAS. Вы в размере, где, покупая другой, более крупный NAS и делая резервные копии прямо к диску являются, вероятно, Вашим лучше ставка.
Я не могу согласиться с Нильсом. Я признаю, что не могу говорить с MySQL, но по опыту могу сказать, что это не верно для Oracle.
Создание моментального снимка файлов базы данных на диске довольно бессмысленно, даже если оно происходит мгновенно . База данных содержит множество транзакций, некоторые из которых почти полностью сбрасываются на диск, некоторые из них частично сбрасываются, а некоторые остаются почти полностью в ОЗУ. То, что находится на диске, можно восстановить с помощью инструментов БД, но вряд ли это будет работоспособная база данных.
Еще хуже: для любой базы данных большого размера резервное копирование займет некоторое время, а это означает, что резервное копирование только на диск совершенно бесполезно. Думайте об этом как о очень размытом снимке; вы фотографируете что-то движущееся довольно быстро (вашу БД) и держите шторку открытой в течение времени, необходимого для создания резервной копии (20 минут? 2 часа? 28 часов? (для некоторых из моих производственных БД)). Фотография будет очень размытой; вы поймаете некоторые столы раньше, и на диск будет записано несколько транзакций; другие вы можете поймать много часов спустя, и к тому времени на диске будет еще несколько сотен тысяч транзакций. Не могу сказать, что резервное копирование вашего диска сразу не заработает; Я даже не могу сказать, что вы не сможете восстановиться с помощью криминалистических инструментов БД; но я бы не стал доверять ему свою работу.
Если ваша FS поддерживает моментальные снимки, а ваша БД поддерживает горячее резервное копирование (или эквивалент), они могут работать. «Горячее» резервное копирование - это инструкция базе данных для стабилизации табличных пространств; он буферизует все ожидающие транзакции в каком-то файле журнала, и применяет их en bloc , когда вы выводите табличные пространства из состояния горячего резервного копирования. Это может сработать, пока вы приостанавливаете табличные пространства и сохраняете их на ленту, но сработает абсолютное удовольствие, если вы можете приостановить табличные пространства, сделать снимок базовой файловой системы, затем освободить таблицы от горячего резервного копирования и развернуть снимок на ленту.
Если вы не можете с этим справиться - а я часто не могу, - то я приказываю программе резервного копирования полностью игнорировать файлы данных, и пусть MySQL сначала запускает mysqldumps в онлайн-хранилище, а затем откатывает это на ленту. У меня никогда не было проблем с восстановлением после них.
Но, как я всегда добавляю в этих случаях, что бы вы ни делали, вы должны хорошо документировать это и часто тестировать . Последнее более важно, чем любой другой совет. Если вы знаете, что это работает, кого волнует, что ты делаешь? Вы можете выполнить резервное копирование с помощью zip в архивы WORM, написанные на крыльях цикад, если известно, что они работают надежно. Но , если вы его не тестируете, кого волнует, что говорят говорящие головы о сбоях сервера? Это не соответствует назначению.
В основном да - все в виде файла. Но: файлы на диске, содержащие данные, могут быть несовместимыми из-за того, что некоторые данные все еще находятся в RAM-кеше и еще не были записаны на диск.
Итак, я создаю резервную копию БД при большой нагрузке, просто используя файл- резервное копирование, вы можете потерять некоторые транзакции. Самый безопасный способ иметь полную резервную копию по файлам - выключить БД, синхронизировать диски и затем начать резервное копирование. Или используйте средства DB для резервного копирования содержимого базы данных на диск - эти резервные копии будут более или менее согласованными. В mySQL вы можете выбирать разные режимы резервного копирования ...
EDIT: Попробуйте mysql-Administrator (если он у вас есть). Здесь вы можете указать задания резервного копирования через графический интерфейс. Результатом будет соответствующая команда резервного копирования в виде задания cron с использованием вашей спецификации резервного копирования.