Чем бэкапить RedНat Enterprise Linux Server 6 ?

Andrew Kant написал(а) к Victor Sudakov в Jan 18 19:47:26 по местному времени:

Нello Victor!

Thursday January 04 2018 13:39, Victor Sudakov wrote to Andrew Kant:
VS> [dd]
VS>>> В эхотаге стандартным средством бэкапа системы считается tar? Я
VS>>> не ради флейма спрашиваю.

AK>> Я не знаю, что считается стандартным, в линуксе нет хэндбука с
AK>> подобными стандартами,

VS> Как это нет хэндбука? То есть я понимаю, что общего хэндбука по линуксу
VS> быть не может, но у уважающих себя дистрибутивов хэндбук быть обязан,
VS> иначе какая же это OS (вспоминая многотомный бумажный мануал по
VS> нетвари).
Ну тогда иди читай красношляпный мануал :)

AK>> но сам пользуюсь либо tar'ом (если нужно
AK>> получить бэкап и сохранить его), либо rsync'ом (когда надо сразу
AK>> получить клон).

VS> tar и rsync нормально переносят симлинки, хардлинки, sparse файлы и
VS> прочие особенности?
линкивроде переносят без проблем, разряженных файлов у меня нет - не знаю.
Возьми попробуй.

VS>>> А как у тара с бэкапом живых файловых систем, или на ext4 можно
VS>>> сделать
VS>>> снапшот и его уже тарить?
AK>> Обычно ext4 лежит поверх lvm, а вот lvm уже умеет снэпшоты.

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

AK>> На счёт бэкапов живых файловых систем - как обычно, если нет
AK>> средств у приложений как-то подготовиться, то можешь получить
AK>> неконсистентное состояние. Но здесь тебя ничего не спасёт - разве
AK>> bsd-шный dump сможет тебе красиво сдампить файлы mysql если в них в
AK>> этот момент что-то меняется?

VS> Ответ, насколько я понимаю, скорее положительный: сможет. Потому что
VS> dump использует ufs snapshots, а они создаются с учетом операций записи
VS> в файлы, т.е. snapshot is FS-aware. Или он даже приостанавливает запись
VS> на диск на момент создания снэпшота, я не помню. Побочным следствием
VS> этого является тот факт, что при активной записи на диск можно очень
VS> долго дожидаться окончания создания снэпшота, у меня такое бывало.
И откуда FS знает, что приложение записало всё что нужно на диск, а не оставило где-то в буферах? Такой "скорее положительный" ответ и для других методов, то есть как повезёт.

VS> Ну и главное тут то, что процесс создания снапшота средствами fs очень
VS> кратковременный, вероятность неконсистентного состояния каких-то файлов
VS> явно меньше, чем если ты будешь полтора часа тарить систему как есть - у
VS> тебя за это время может полсистемы измениться, например обновления
VS> прилететь.
Процесс создания снэпшота средствами lvm также очень кратковременный, а дальше ты снэпшот можешь тарить хоть год.

AK>> Маленький пример (не для rhel, да простит меня Виссарионов, но идея
AK>> общая для любых дистрибутивов):

VS> Спасибо, сохранил, принцип понятен. Жаль, что не lvm и не gpt, ну да
VS> ладно, это детали. И сделанный rsync-ом клон потом работает без проблем?
Работает. Правда, там кроме функций рутинга почти ничего нет, поэтому не боюсь делать не останавливая оригинал. В твоей задаче ты не указал подобное условие - а с холодного бэкапа сделанного любыми средствами проблемы восстановиться быть не должно.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Eugene Grosbein написал(а) к Andrew Kant в Jan 18 02:59:31 по местному времени:

04 янв. 2018, четверг, в 20:47 NOVT, Andrew Kant написал(а):

AK>>> На счёт бэкапов живых файловых систем - как обычно, если нет
AK>>> средств у приложений как-то подготовиться, то можешь получить
AK>>> неконсистентное состояние. Но здесь тебя ничего не спасёт - разве
AK>>> bsd-шный dump сможет тебе красиво сдампить файлы mysql если в них в
AK>>> этот момент что-то меняется?
VS>> Ответ, насколько я понимаю, скорее положительный: сможет. Потому что
VS>> dump использует ufs snapshots, а они создаются с учетом операций записи
VS>> в файлы, т.е. snapshot is FS-aware. Или он даже приостанавливает запись
VS>> на диск на момент создания снэпшота, я не помню. Побочным следствием
VS>> этого является тот факт, что при активной записи на диск можно очень
VS>> долго дожидаться окончания создания снэпшота, у меня такое бывало.
AK> И откуда FS знает, что приложение записало всё что нужно на диск, а не оставило
AK> где-то в буферах?

Это называется "crash-consistent backup", то есть бекап, восстанавливающий
файлов файлы к тому же состоянию, в каком они были бы при аварийном
ребуте системы в момент (начала) создания снапшота/бекапа.

Обязанностью приложений (типа mysqld) является модификация своих файлов
таким образом, чтобы минимизировать потери данных при авариях системы
и если приложение это делает (а СУБД обычно делают), то и такой бекап
тоже получится юзабельным.

Eugene
--- slrn/1.0.2 (FreeBSD)

Andrew Kant написал(а) к Eugene Grosbein в Jan 18 07:31:58 по местному времени:

Нello Eugene!

Friday January 05 2018 02:59, Eugene Grosbein wrote to Andrew Kant:

AK>>>> На счёт бэкапов живых файловых систем - как обычно, если нет
AK>>>> средств у приложений как-то подготовиться, то можешь получить
AK>>>> неконсистентное состояние. Но здесь тебя ничего не спасёт - разве
AK>>>> bsd-шный dump сможет тебе красиво сдампить файлы mysql если в них
AK>>>> в этот момент что-то меняется?
VS>>> Ответ, насколько я понимаю, скорее положительный: сможет. Потому
VS>>> что dump использует ufs snapshots, а они создаются с учетом
VS>>> операций записи в файлы, т.е. snapshot is FS-aware. Или он даже
VS>>> приостанавливает запись на диск на момент создания снэпшота, я не
VS>>> помню. Побочным следствием этого является тот факт, что при
VS>>> активной записи на диск можно очень долго дожидаться окончания
VS>>> создания снэпшота, у меня такое бывало.
AK>> И откуда FS знает, что приложение записало всё что нужно на диск, а
AK>> не оставило где-то в буферах?

EG> Это называется "crash-consistent backup", то есть бекап,
EG> восстанавливающий файлов файлы к тому же состоянию, в каком они были бы
EG> при аварийном ребуте системы в момент (начала) создания снапшота/бекапа.

Спасибо, кэп :)

EG> Обязанностью приложений (типа mysqld) является модификация своих
EG> файлов
EG> таким образом, чтобы минимизировать потери данных при авариях системы
EG> и если приложение это делает (а СУБД обычно делают), то и такой бекап
EG> тоже получится юзабельным.

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

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Eugene Grosbein написал(а) к Andrew Kant в Jan 18 19:52:05 по местному времени:

05 янв. 2018, пятница, в 08:31 NOVT, Andrew Kant написал(а):

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

В теории да. На практике не всё так однозначно. На очень больших базах
"средства субд" могут оказаться практически бесполезными, потому как
вообще не в состоянии создать бекап за приемлемое время, в то время
создание crash-consistent backup путём zfs snapshot/zfs send получается
за вполне себе нормальное время.

Eugene
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Andrew Kant в Jan 18 00:20:32 по местному времени:

Dear Andrew,

04 Jan 18 19:47, you wrote to me:
VS>> [dd]
VS>>>> В эхотаге стандартным средством бэкапа системы считается tar? Я
VS>>>> не ради флейма спрашиваю.

AK>>> Я не знаю, что считается стандартным, в линуксе нет хэндбука с
AK>>> подобными стандартами,

VS>> Как это нет хэндбука? То есть я понимаю, что общего хэндбука по
VS>> линуксу быть не может, но у уважающих себя дистрибутивов хэндбук
VS>> быть обязан, иначе какая же это OS (вспоминая многотомный
VS>> бумажный мануал по нетвари).
AK> Ну тогда иди читай красношляпный мануал :)

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

AK>>> но сам пользуюсь либо tar'ом (если нужно
AK>>> получить бэкап и сохранить его), либо rsync'ом (когда надо сразу
AK>>> получить клон).

VS>> tar и rsync нормально переносят симлинки, хардлинки, sparse файлы
VS>> и прочие особенности?
AK> линкивроде переносят без проблем, разряженных файлов у меня нет - не
AK> знаю. Возьми попробуй.

А у меня разряженных файлов бывает много - как минимум диски thin provisioned виртуалок. Плохо, если они раздуются до своих "виртуальных" размеров при восстановлении/переносе.

Попробовал: вроде хорошо:
[sudakov@vas ~/tmp] truncate -s5g test1g.bin
[sudakov@vas ~/tmp] du -hs !$
du -hs test1g.bin
512B test1g.bin
[sudakov@vas ~/tmp] mkdir QQQ1
[sudakov@vas ~/tmp] rsync -av test1g.bin QQQ1/
sending incremental file list
test1g.bin

sent 5,370,019,944 bytes received 35 bytes 202,642,263.36 bytes/sec
total size is 5,368,709,120 speedup is 1.00
[sudakov@vas ~/tmp] du -hs QQQ1/test1g.bin
512B QQQ1/test1g.bin
[sudakov@vas ~/tmp]


VS>>>> А как у тара с бэкапом живых файловых систем, или на ext4 можно
VS>>>> сделать
VS>>>> снапшот и его уже тарить?
AK>>> Обычно ext4 лежит поверх lvm, а вот lvm уже умеет снэпшоты.

А как lvm-ом сделать снапшот и смонтировать его, не покажешь?

VS>> Снэпшоты, которым пофиг на вышележащую файловую систему - это
VS>> плохие снэпшоты.
AK> ну-ну, и снэпшоты уровня стораджа типа нетапа итп - тоже плохие?

Конечно. Ты же читал мотивацию создания ZFS? Там прямо написано, что ставилась задача создать logical volume manager, который интегрирован с FS:

"ZFS is unusual, because unlike most other storage systems, it unifies both of these roles and acts as both the volume manager and the file system. Therefore, it has complete knowledge of both the physical disks and volumes (including their condition, status, their logical arrangement into volumes, and also of all the files stored on them). "
https://en.wikipedia.org/wiki/ZFS#ZF...ile</b>systems

AK> С другой стороны, лучше плохо ехать, чем хорошо идти, так что и с
AK> плохими снэпшотами лучше, чем вообще без них, если знаешь где соломку
AK> стелить.

С этим не поспоришь.

AK>>> На счёт бэкапов живых файловых систем - как обычно, если нет
AK>>> средств у приложений как-то подготовиться, то можешь получить
AK>>> неконсистентное состояние. Но здесь тебя ничего не спасёт -
AK>>> разве bsd-шный dump сможет тебе красиво сдампить файлы mysql
AK>>> если в них в этот момент что-то меняется?

VS>> Ответ, насколько я понимаю, скорее положительный: сможет. Потому
VS>> что dump использует ufs snapshots, а они создаются с учетом
VS>> операций записи в файлы, т.е. snapshot is FS-aware. Или он даже
VS>> приостанавливает запись на диск на момент создания снэпшота, я не
VS>> помню. Побочным следствием этого является тот факт, что при
VS>> активной записи на диск можно очень долго дожидаться окончания
VS>> создания снэпшота, у меня такое бывало.
AK> И откуда FS знает, что приложение записало всё что нужно на диск, а не
AK> оставило где-то в буферах?

Э, задача бэкапить что-то в буферах приложения и не ставилась. Мы же бэкапим диск, а не system state. Второе уже на порядки сложнее, если речь не о виртуалке.

AK> Такой "скорее положительный" ответ и для
AK> других методов, то есть как повезёт.

Если LVM не знает о FS, то больше шансов, что он создаст снапшот по-живому.

VS>> Ну и главное тут то, что процесс создания снапшота средствами fs
VS>> очень кратковременный, вероятность неконсистентного состояния
VS>> каких-то файлов явно меньше, чем если ты будешь полтора часа
VS>> тарить систему как есть - у тебя за это время может полсистемы
VS>> измениться, например обновления прилететь.
AK> Процесс создания снэпшота средствами lvm также очень кратковременный,
AK> а дальше ты снэпшот можешь тарить хоть год.

Надо будет попробовать этот lvm snapshot.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Andrew Kant написал(а) к Eugene Grosbein в Jan 18 21:09:32 по местному времени:

Нello Eugene!

Friday January 05 2018 19:52, Eugene Grosbein wrote to Andrew Kant:

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

EG> В теории да. На практике не всё так однозначно. На очень больших базах
EG> "средства субд" могут оказаться практически бесполезными, потому как
EG> вообще не в состоянии создать бекап за приемлемое время, в то время
EG> создание crash-consistent backup путём zfs snapshot/zfs send получается
EG> за вполне себе нормальное время.

Я-бы усомнился в правильности проектирования подобного решения. В таком случае (imho) надо всё-таки использовать средства самой БД для репликации, а вот реплику можно и посадить на время создания того-же снэпшота, и получаем 100% гарантию консистентности бэкапа. В твоем случае ты можешь думать, что у тебя за нормальное время получен якобы crash-consistent backup, но при восстановлении вдруг понять, что пора искать другое место работы. Причем, один раз может и прокатит, а на второй - стрельнет. Зачем эти игры в русскую рулетку?

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Andrew Kant написал(а) к Victor Sudakov в Jan 18 21:21:17 по местному времени:

Нello Victor!

Saturday January 06 2018 00:20, Victor Sudakov wrote to Andrew Kant:
AK>> Ну тогда иди читай красношляпный мануал :)

VS> А это мысль. Закончатся новогодние праздники - пойду читать, может и
VS> насчет бэкапа что найдется, там с десяток книжек.
Как плохо, что подобная мысль приходит не первой из ... :)

VS>>>>> сделать
VS>>>>> снапшот и его уже тарить?
AK>>>> Обычно ext4 лежит поверх lvm, а вот lvm уже умеет снэпшоты.

VS> А как lvm-ом сделать снапшот и смонтировать его, не покажешь?
ну лучше всё-таки man lvm, man lvcreate на предмет -s, монтировать как обычно - mount /dev/vggroupname/snapshotname /mntpoint

Микропример как создать первый lvm-овский том, чтоб знать какие ключевые слова искать (заодно с примером как использовать софтовый raid):

- создаем зеркало типа RAID1 (-l 1) из двух дисков (-n 2), будет называться /dev/md2
mdadm --create /dev/md2 -n 2 -l 1 /dev/sda3 /dev/sdb3

- ждем, пока процесс закончится (либо не ждем, процесс идет часа 4 на терабайтных винтах, он не мешает работать с созданным зеркалом)
cat /proc/mdstat (много раз, чтоб посмотреть статус зеркала)

(предполагаем, что создали raid-массив через mdadm, он доступен как /dev/md2,
будем использовать его как место для создания lvm-овских томов. Можешь заменить на любое другое неформатированное устройство или даже файл.)

pvcreate /dev/md2 # создаем пространство для lvm
vgcreate vg2 /dev/md2 # делаем группу и даем ей место

- смотрим что получилось
pvs
vgs
lvs

- создаем тома (нарезаем на кусочки требуемого размера из свободного
места)
lvcreate vg2 -n swaplv -L 4G
lvcreate vg2 -n systemlv -L 10G
lvcreate vg2 -n userslv -L 150G

- смотрим что получилось
pvs
vgs
lvs

- форматируем полученные тома (для них автоматом создаётся иерархия в /dev)

mkfs -t ext4 /dev/vg2/userslv
mkfs -t ext4 /dev/vg2/systemlv
mkswap /dev/vg2/swaplv

Дальше можно их монтировать. Ну и делать с них снэпшоты. Кстати, снэпшоты не обязательно read-only, можно делать снэпшоты со снэпшотов итп.

lvcreate vg2 -n userbackuplv -s userslv -L 30G

# ls /dev/vg2/userbackuplv

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

VS> Надо будет попробовать этот lvm snapshot.
Пробуй.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Nickita A Startcev написал(а) к Andrew Kant в Jan 18 03:42:40 по местному времени:

Привет, Andrew !


01 Jan 18 , 23:34 Andrew Kant писал к Nickita A Startcev:

VS>>> Собственно сабж? Чтобы в случае отказа быстро и без проблем
VS>>> восстановить на новом железе (с нуля). Стоит всё по умолчанию,
VS>>> как инсталлятор предлагал (аппаратный RAID, на нем lvm, на нем
VS>>> ext4 несколько fs).

VS>>> Речь именно про бэкап на случай disaster recovery, а не про
VS>>> архив конфигураций и т.п.

VS>>> Заранее спасибо.

NS>> cat /dev/чтонадо | gzip -c1 > outfile.tgz?

AK> Думаешь, на новом железе обязательно будет тот-же (или хотя-бы не
AK> меньший) размер диска?

AK> В самом оригинальном вопросе уже звучал подтекст "не рекомендуйте мне
AK> стандартные средства типа тара, я хочу чего-то другого, чтоб само всё
AK> переразбило, закатало и запустило на любом железе".

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

. С уважением, Никита.
icq:240059686, lj-user:nicka_startcev
... Мужчина, разбрасывающий носки метит свою территорию?
--- GoldED+/LNX 1.1.5-b20161221

Alexey Vissarionov написал(а) к Andrew Kant в Jan 18 13:30:00 по местному времени:

Доброго времени суток, Andrew!
05 Jan 2018 21:09:32, ты -> Eugene Grosbein:

EG>> В теории да. На практике не всё так однозначно. На очень больших
EG>> базах "средства субд" могут оказаться практически бесполезными,
EG>> потому как вообще не в состоянии создать бекап за приемлемое время
AK> В таком случае (imho) надо всё-таки использовать средства самой БД
AK> для репликации, а вот реплику можно и посадить на время создания
AK> того-же снэпшота, и получаем 100% гарантию консистентности бэкапа.

Ну наконец-то :-)

Собственно, именно так резервное копирование БД и происходит. Более того, репликацию иногда настраивают еще хитрее: либо с боевого сервера на горячий резерв, а уже оттуда на что-то медленное, но надежное, либо между боевыми серверами двусторонняя, и с любого из них на медленное надежное хранилище. А потом да, обычный дамп с этого медленного надежного сервера.

AK> В твоем случае ты можешь думать, что у тебя за нормальное время
AK> получен якобы crash-consistent backup, но при восстановлении вдруг
AK> понять, что пора искать другое место работы. Причем, один раз может
AK> и прокатит, а на второй - стрельнет.

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

AK> Зачем эти игры в русскую рулетку?

... с ПМом.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Гладко было на бумаге, а потом полезли баги
--- /bin/vi

Vova Uralsky написал(а) к Andrew Kant в Jan 18 11:34:52 по местному времени:

Нello Andrew!

05 Jan 18 21:09, Andrew Kant wrote to Eugene Grosbein:

AK> Я-бы усомнился в правильности проектирования подобного решения. В
AK> таком случае (imho) надо всё-таки использовать средства самой БД для
AK> репликации, а вот реплику можно и посадить на время создания того-же
AK> снэпшота, и получаем 100% гарантию консистентности бэкапа. В твоем

Если соблюсти раяд условий, то такое решение вполне себе может использоваться. Вопрос только, для каких целей? У некоторых СУБД есть понятие external backup, которое сочитается с решением, предложенным EG. Естественно в зависимости от конкретного случая.

Вообще 100% гарантии практически не бывает, у тебя ещё никогда привод ленту на головы не наматывал?

Regards,
Vova

--- Msged/BSD 6.2.0