Мне нужна полная резервная копия моего сервера. Это CentOS 5.
Мои мысли: я могу буквально взять каждый файл на сервере и создать его резервную копию, и у меня будет резервная копия всего. Конфигурация сервера, мои файлы PHP, БД MySQL, ВСЕ ... это точное предположение?
Я собирался сделать резервную копию MySQL дополнительно, но, возможно, в этом нет необходимости, поскольку файлы БД включены в резервные копии моего сервера?
Дальше... Я пробую RackSpace Server Backup. Это в основном берет каждый файл на моем диске, создает его резервную копию через SSL и шифрует данные на резервном диске. Я могу запускать его каждый день, и в место назначения резервной копии отправляются только «обновленные файлы».
Спасибо за помощь здесь ...
Я не могу согласиться с Нильсом. Я признаю, что не могу говорить с MySQL, но по опыту могу сказать, что это не верно Oracle.
Создание моментального снимка файлов базы данных на диске бессмысленно, даже если оно происходит мгновенно. БД содержит множество транзакций, некоторые из которых почти полностью сбрасываются на диск, некоторые из них частично сбрасываются, а некоторые остаются почти полностью в ОЗУ. То, что находится на диске, можно восстановить с помощью инструментов БД, но вряд ли это будет работоспособная база данных.
Что еще хуже: для любой базы данных большого размера резервное копирование займет некоторое время, а это означает, что резервное копирование только на диск совершенно бесполезно. Думайте об этом как о очень размытом снимке; вы фотографируете что-то движущееся довольно быстро (вашу БД) и держите шторку открытой в течение времени, необходимого для создания резервной копии (20 минут? 2 часа? 28 часов? (для некоторых из моих производственных БД)). Фотография будет очень размытой; вы поймаете некоторые столы раньше, и на диск будет записано несколько транзакций; другие вы можете поймать много часов спустя, и к тому времени на диске будет еще несколько сотен тысяч транзакций. Не могу сказать, что резервное копирование вашего диска сразу не заработает; Я даже не могу сказать, что вы не сможете восстановиться с помощью криминалистических инструментов БД; но я бы не доверил этому свою работу.
Если ваша FS поддерживает моментальные снимки, а ваша БД поддерживает горячее резервное копирование (или эквивалент), они могут работать. «Горячее» резервное копирование - это инструкция базе данных для стабилизации табличных пространств; он буферизует все ожидающие транзакции в каком-либо файле журнала и применяет их в блоке когда вы выводите табличные пространства из состояния горячего резервного копирования. Это может сработать, пока вы стабилизируете табличные пространства и сохраняете их на ленту, но сработает абсолютное удовольствие, если вы можете стабилизировать табличные пространства, сделать снимок базовой файловой системы, затем освободить таблицы от горячего резервного копирования и свернуть снимок на ленту.
Если вы не можете с этим справиться - а я часто не могу, - то я приказываю программе резервного копирования полностью игнорировать файлы данных и сначала запустить mysqldumps в онлайн-хранилище, а затем перенести это на ленту. У меня никогда не было проблем с восстановлением после этого.
Но, как я всегда добавляю в этих случаях, без разницы вы делаете, вы должны хорошо задокументировать и протестировать часто. Последний совет более важен, чем любой другой. Если вы знаете, что это работает, кого волнует, что вы делаете? Вы можете выполнить резервное копирование с помощью zip в архивы WORM, написанные на крыльях цикад, если известно, что они работают надежно. Но если вы не тестируете его, кого волнует, что говорят говорящие головы serverfault? Это не по назначению.
В основном да - все в виде файла. Но: файлы на диске, содержащие данные, могут быть несовместимыми из-за того, что некоторые данные все еще находятся в RAM-кеше и еще не были записаны на диск.
Итак, если вы создаете резервную копию БД под большой нагрузкой, просто используя резервное копирование файлов, вы можете потерять некоторые транзакции. Самый безопасный способ сделать полную резервную копию по файлам - выключить БД, синхронизировать диски и затем запустить резервное копирование. Или используйте средства DB для резервного копирования содержимого базы данных на диск - эти резервные копии будут более или менее согласованными. В mySQL вы можете выбирать разные режимы резервного копирования ...
РЕДАКТИРОВАТЬ: попробуйте mysql-Administrator (если он у вас есть). Здесь вы можете указать задания резервного копирования через графический интерфейс. Результатом будет соответствующая команда резервного копирования в виде задания cron с использованием вашей спецификации резервного копирования.