= Сообщение: 4593 из 8625 ========================================= RU.LINUX = От : Victor Sudakov 2:5005/49 04 Jan 18 13:39:26 Кому : Andrew Kant 04 Jan 18 13:39:26 Тема : Чем бэкапить RedHat Enterprise Linux Server 6 ? FGHI : area://RU.LINUX?msgid=2:5005/49+5a4dd1ee На : area://RU.LINUX?msgid=2:469/83.1+5a4d02d1 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.LINUX?msgid=2:469/83.1+5a4e6b6a ============================================================================== Dear Andrew,
03 Jan 18 17:50, you wrote to me:
[dd] VS>> В эхотаге стандартным средством бэкапа системы считается tar? Я VS>> не ради флейма спрашиваю.
AK> Я не знаю, что считается стандартным, в линуксе нет хэндбука с AK> подобными стандартами,
Как это нет хэндбука? То есть я понимаю, что общего хэндбука по линуксу быть не может, но у уважающих себя дистрибутивов хэндбук быть обязан, иначе какая же это OS (вспоминая многотомный бумажный мануал по нетвари).
AK> но сам пользуюсь либо tar'ом (если нужно AK> получить бэкап и сохранить его), либо rsync'ом (когда надо сразу AK> получить клон).
tar и rsync нормально переносят симлинки, хардлинки, sparse файлы и прочие особенности?
VS>> А как у тара с бэкапом живых файловых систем, или на ext4 можно VS>> сделать VS>> снапшот и его уже тарить? AK> Обычно ext4 лежит поверх lvm, а вот lvm уже умеет снэпшоты.
Снэпшоты, которым пофиг на вышележащую файловую систему - это плохие снэпшоты.
AK> Hа счёт бэкапов живых файловых систем - как обычно, если нет средств у AK> приложений как-то подготовиться, то можешь получить неконсистентное AK> состояние. Hо здесь тебя ничего не спасёт - разве bsd-шный dump сможет AK> тебе красиво сдампить файлы mysql если в них в этот момент что-то AK> меняется?
Ответ, насколько я понимаю, скорее положительный: сможет. Потому что dump использует ufs snapshots, а они создаются с учетом операций записи в файлы, т.е. snapshot is FS-aware. Или он даже приостанавливает запись на диск на момент создания снэпшота, я не помню. Побочным следствием этого является тот факт, что при активной записи на диск можно очень долго дожидаться окончания создания снэпшота, у меня такое бывало.
Что же касается zfs снапшотов, то ответа на твой вопрос я не знаю. Но поскольку они тоже FS-aware, предполагаю что этот вопрос как-то решён. Могу ошибаться.
Ну и главное тут то, что процесс создания снапшота средствами fs очень кратковременный, вероятность неконсистентного состояния каких-то файлов явно меньше, чем если ты будешь полтора часа тарить систему как есть - у тебя за это время может полсистемы измениться, например обновления прилететь.
[dd]
AK> Hу подобного рода инструкций много (у каждого свои). Загрузка с флэшки AK> либо PXE, fdisk либо его клоны, потом lvm (если хочешь), потом mkfs, AK> потом раскрываем архив, потом тюнинг конфига и воссоздание загрузчика.
AK> В варианте когда хранишь полный образ устройства естественно последние AK> пункты могут быть лишними.
AK> Маленький пример (не для rhel, да простит меня Виссарионов, но идея AK> общая для любых дистрибутивов):
Спасибо, сохранил, принцип понятен. Жаль, что не lvm и не gpt, ну да ладно, это детали. И сделанный rsync-ом клон потом работает без проблем?
[dd]
AK> Хотя в последнее время я предпочитаю бэкапить rhel средствами AK> гипервизора, на котором он запущен :) AK> Hо это немного не стыкуется с AK> твоей постановкой задачи про bare metal. Так что может быть есть смысл AK> подумать об упразднении этого условия.
К сожалению, не получится подумать: набор сертифицированного софта утверждён, всё это будет периодически проверяться, добавлять нельзя. Я думаю и сабж такой древний прислали именно из-за наличия сертификатов.
