Почему не стоит делать бекап или восстанавливаться «по-живому»

Почему не стоит делать бекап

Скорее всего потому, что можно занести в бэкап слишком много лишнего (рабочие данные, содержимое /sys и /dev, /tmp, /var/tmp) или повредить симлинки. Хотя насчет второго просто предположение.

или восстанавливаться «по-живому»

А это вот не совсем ясно, имелось в виду «из под Live CD» ?

В процессе работы самой системы изменяются разные данные на диске и в памяти (кэше файловых операций), они будут неполными или некорректными после операций копирования и восстановления.

Какие могут быть проблемы?

Потеряете важные данные.

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

Для этого придумали снапшоты.

В процессе работы самой системы изменяются разные данные на диске и в памяти (кэше файловых операций), они будут неполными или некорректными после операций копирования и восстановления.

Вообще-то можно бэкапить, исключив каталоги, содержащие динамически изменяемые данные

Пример

cat /etc/stage4.excl 
/dev/*
/home/*
/media/*
/mnt/*
/var/tmp/*
/tmp/*
/proc/*
/sys/*
/run/*
/usr/portage/packages
/usr/portage/distfiles
/etc/ssh/ssh_host_*key* 

Если есть большой файл, который постоянно перезаписывается (файлы БД, образ виртуалки), то файл получится битый, не полный и восстановиться вообще не получиться. В таких случаях сбрасывают данные на диск (FLUSH для СУБД), блокируют запись (write lock для СУБД), делают снэпшот средствами ФС или LVM и восстанавливаю запись. Снэпшот уже можно бэкапить.

В каких случаях и почему не стоит делать бекап или восстанавливаться «по-живому»?

В любых случаях где есть открытые на запись файлы

Какие могут быть проблемы?

Есть далеко не нулевые шансы потерять содержимое открытых на запись файлов.

Вообще-то можно бэкапить, исключив каталоги, содержащие динамически изменяемые данные

Любитель спорить сам с собой?

но при этом нужно учитывать некоторые дополнительные условия

В каких случаях и почему не стоит делать бекап или восстанавливаться «по-живому»? Какие могут быть проблемы?

нарушение причинно-следственной связи и как результат TIME PARADOX. Т.е. если причина в изменении А, а следствие изменение Б, то при бекапе по живому, в бекап попадает УЖЕ новое Б, но ЕЩЁ старое А. Ну а при восстановлении, изменение в Б получается НИОТКУДА, т.к. причина в А не зафиксирована.

GNU tar в таком случае выдаёт exit status 2, и пишет «файлы изменились», но это не авария, и можно игнорировать — бекап создан, и с виду он «хороший, годный». На деле бекап получается битый, но узнаём мы это уже тогда, когда всё похерено.

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

Есть далеко не нулевые шансы потерять содержимое открытых на запись файлов.

это вряд-ли, если файлы открываются обычным в GNU/Linux способом.

Т.е. если ты изменяешь файлы sed, vim, или, ВНЕЗАПНО libre office. Но не все программы так делают.

Как пример можно привести СУБД и DVCS. У них имеются встроенные средства для бекапа.

В случаях, когда на твоей системе бегает хотя-бы одно приложение, согласованность данных в котором критична и может быть нарушена в процессе бекапа/восстановления. И это не обязательно база данных. Любое приложение может оказаться таким.

Он правильный пример привёл.

Подскажите, с какой частью моего утверждения он спорил?

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

А вам лишь бы попаддакивать. С умным видом повторяя «а вот я совал пальцы в розетку и остался жив».

это вряд-ли, если файлы открываются обычным в GNU/Linux способом.

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

Т.е. если ты изменяешь файлы sed, vim, или, ВНЕЗАПНО libre office.

Угу - если ты сохранил конфиг после начала бекапа fs, но до его конца - то будет ли у тебя сохраненый конфиг в бекапе ? В общем случае неизвестно. Вне зависимости от того каким способом ты его открыл или записал.

Но не все программы так делают.

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

Как пример можно привести СУБД и DVCS

Именно поэтому нельзя делать бекап на живой системе, потому что способ live бекапа определяет программа. Для Веб-сервера достаточно tar, для СУБД нужен свой отдельный. Даже для iptables по хорошему нужен скрипт что перед бекапом сохранит текущее состояние фильтров.

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

естественно. Я об этом написал ниже.

Угу - если ты сохранил конфиг после начала бекапа fs, но до его конца - то будет ли у тебя сохраненый конфиг в бекапе ? В общем случае неизвестно. Вне зависимости от того каким способом ты его открыл или записал.

я делаю бекап так (ВАЖНО! Это десктоп/лаптоп, в продакшене так НЕ НУЖНО делать!) :

1. сохраняю время

2. ищу все файлы, новее посл. бекапа и добавляю в новый бекап

3. ищу все файлы новее п1, если есть, то goto п1

для обычных файлов это подходит. Для DVCS/СУБД/etc настроены исключения.

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

у меня — решает. Бекаплю так /home/ каждый час более года. ИЧСХ, /home/ в памяти, т.ч. при каждом старте он разворачивается из бекапа.

Именно поэтому нельзя делать бекап на живой системе, потому что способ live бекапа определяет программа.

нет, мой скрипт.

Для Веб-сервера достаточно tar

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

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

А почему это mysql не должен работать? Постоянно переношу систему таким образом, всегда всё работало. Наверное, я что-то неправильно делаю :З

Может это у вас бэкап повреждается? Тогда мне нечего сказать.

системы не запускается очередной mysql или ldap

Вы читать умеете?

kostik87

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

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

/bin/
/sbin/
/etc/
/lib/
/usr/
/opt/

/proc
/dev
/sys

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

/tmp/
/var/

Это единственно критичные части файловой системы, в которые производится запись, ещё /home.

Так вот в /var/ как раз и хранятся данные mysql и ldap, логи, /var/tmp, /var/run, вот это всё и надо исключать при создании архива.

Если вы что-то не делали и не представляете как это делается, то не надо говорить, что так сделать нельзя и это неправильно.

В общем после переноса системы попросту затем копируются данные mysql, ldap, создаются директории в /var/log.

Просто нужно включить голову.

Удачи.

Если вы что-то не делали и не представляете как это делается, то не надо говорить

Еще меня студенты не учили, как делать бекап. :)

Еще раз внимательно посмотри на мой пост и ответь, что в нём неверно - Почему не стоит делать бекап или восстанавливаться «по-живому» (комментарий)

Хе-хе, понятно, все доводы у вас иссякли, переходите на личности.

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

А так, почитайте ещё раз моё предыдущее сообщение, может хоть чему-то научитесь.

Удачи.

А так, почитайте ещё раз моё предыдущее сообщение, может хоть чему-то научитесь.

Теперь внимательно буду следить за вашими сообщениями и подробно конспектировать.

UPD:

Еще раз внимательно посмотри на мой пост и ответь, что в нём неверно

В процессе работы самой системы изменяются разные данные на диске и в памяти (кэше файловых операций), они будут неполными или некорректными после операций копирования и восстановления.

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

Потеряете важные данные.

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

Про прочие нюансы, которые я описал выше я повторять не буду.

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

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

Похвально.

Удачи.

А ты почитай, что написал я.

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

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

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

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

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

Какие пол системы? Иди почитай ещё раз то, что я написал. Но я думаю, что раз за два раза ты не понял, то и за третий не поймёшь.

естественно. Я об этом написал ниже.

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

я делаю бекап так ...

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

нет, мой скрипт.

Кому нафиг уперся тут твой скрипт ? У тебя с ЧСВ все в порядке ?

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

Вторым инструментом в обсуждаемом документе идет dd, как думаешь через dd вообще можно бекапить открытый на запись раздел ? Только не нужно опять расказывать ... а вот у меня скрипт.

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

ОК - остановить сервисы - то есть перевести часть системы из режима Live в режим Shutdown. То есть ровно то о чем и говорят.

он привел ссылку

а я Ъ

Кому нафиг уперся тут твой скрипт ?

мне.

У тебя с ЧСВ все в порядке ?

а при чём тут ЧСВ? Если твоя любимая говнопрограмма так не может, как мой скрипт, то твоя программа не нужна. Ничего личного, если ты конечно не автор программы.

как думаешь через dd вообще можно бекапить открытый на запись раздел ?

можно. Некоторые одмины даже так и делают. А при чём тут это?

PS: ТС цитирует:

при этом нужно учитывать некоторые дополнительные условия, которые в данной статье пока что не рассматриваются

а я взял, и рассмотрел. Тебе не интересно? Зачем ты мне докладываешь, что тебе не интересно, а нужно про dd рассказывать?

ОК - остановить сервисы

ну mysql может просто залочить таблицы, дабы они не изменялись. Тогда СУБД сможет обработать запросы на чтение, но будет тормозить запросы на запись (а их обычно мало). Т.ч. это не совсем shutdown, а часто — не критично(если БД маленькая и нагрузка в этот момент небольшая).

а я Ъ

Значит ЧСВ в чистом незамутненном виде. ЧТД.

можно. Некоторые одмины даже так и делают. А при чём тут это?

Батя ты задолбал упапрыватся, при том что обсуждается примечание к статье где dd фигурирует как один из способов бекапа.

ну mysql может просто залочить таблицы, дабы они не изменялись.

На другой СУБД что делать будешь ? Да на том же mysql кто тебе гарантирует что лок таблиц сбрасывает «кеш записи» на диск ? Кто тебе гарантирует что в момент лока все транзации завершены ? Вот нахрена городит велосипеды ?

Т.ч. это не совсем shutdown, а часто — не критично(если БД маленькая и нагрузка в этот момент небольшая).

Млин откуда вы такие умные лезете ? ... наберут по объявлениям

А это вот не совсем ясно, имелось в виду «из под Live CD» ?

Я так думаю, имелось ввиду то же самое - из-под самой себя.

к статье где dd фигурирует как один из способов бекапа.

На другой СУБД что делать будешь ? Да на том же mysql кто тебе гарантирует что лок таблиц сбрасывает «кеш записи» на диск ? Кто тебе гарантирует что в момент лока все транзации завершены ? Вот нахрена городит велосипеды ?

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

Значит ЧСВ в чистом незамутненном виде.

у твоего воображаемого друга, любителя dd? Бывает, да. А я тут при чём?

Млин откуда вы такие умные лезете ?

тебе виднее, почему у тебя голоса в голове.

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