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

Victor Sudakov написал(а) к All в Jan 18 23:02:56 по местному времени:

Dear All,

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

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

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

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

Nickita A Startcev написал(а) к Victor Sudakov в Jan 18 20:14:26 по местному времени:

Привет, Victor !


01 Jan 18 , 23:02 Victor Sudakov писал к All:

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

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

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

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

. С уважением, Никита.
icq:240059686, lj-user:nicka_startcev
... но не курица уж над ним - кадильниц благовонный дым. Не слышно пенья в поздний час.
--- GoldED+/LNX 1.1.5-b20161221

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

Нello Nickita!

Monday January 01 2018 20:14, Nickita A Startcev wrote to Victor Sudakov:

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

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

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

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

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

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


Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Victor Sudakov написал(а) к Nickita A Startcev в Jan 18 21:03:46 по местному времени:

Dear Nickita,

01 Jan 18 20:14, you wrote to me:

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

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

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

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

Если в Linux это действительно рекомендуемый вариант, то это очень плохо, потому что:

1) такое можно делать только на размонтированной или смонтированной в ro файловой системе;

2) зачем бэкапить и хранить пустое место?

3) а вдруг на новом железе диск другого размера?

Но на самом деле я не верю, что для энтерпрайза это реально предлагают.

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

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

Dear Andrew,

01 Jan 18 23:34, you wrote to 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> стандартные средства типа тара,

В эхотаге стандартным средством бэкапа системы считается tar? Я не ради флейма спрашиваю.

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

Инкрементальные бэкапы в GNU tar в рудиментарном виде существуют, судя по man. Но по сравнению с FreeBSD-шным dump выглядят они убого.

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

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

https://victor-sudakov.dreamwidth.org/124492.html
https://victor-sudakov.dreamwidth.org/125653.html
https://victor-sudakov.dreamwidth.org/357521.html

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

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

Нello Victor!

Wednesday January 03 2018 21:09, Victor Sudakov wrote to Andrew Kant:

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

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

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

AK>> В самом оригинальном вопросе уже звучал подтекст "не рекомендуйте
AK>> мне стандартные средства типа тара,

VS> В эхотаге стандартным средством бэкапа системы считается tar? Я не ради
VS> флейма спрашиваю.

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

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

VS> Инкрементальные бэкапы в GNU tar в рудиментарном виде существуют,
VS> судя
VS> по man. Но по сравнению с FreeBSD-шным dump выглядят они убого.

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

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

VS> https://victor-sudakov.dreamwidth.org/124492.html
VS> https://victor-sudakov.dreamwidth.org/125653.html
VS> https://victor-sudakov.dreamwidth.org/357521.html

Ну подобного рода инструкций много (у каждого свои). Загрузка с флэшки либо PXE, fdisk либо его клоны, потом lvm (если хочешь), потом mkfs, потом раскрываем архив, потом тюнинг конфига и воссоздание загрузчика.

В варианте когда хранишь полный образ устройства естественно последние пункты могут быть лишними.

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

dd if=/dev/zero of=/dev/sda bs=512 count=1

sfdisk /dev/sda --DOS -uM << EOF
,8000,L,*
,,E
;
;
,500,S
,,L
EOF

mke2fs -j /dev/sda1

mke2fs -j /dev/sda6

mkswap /dev/sda5

mkdir /m

mount /dev/sda1 /m

rsync -avxz --numeric-ids 10.1.1.1:/ /m/

rsync -R -avzx --numeric-ids /dev /m/

mount /dev/sda6 /m/home

rsync -R --delete -avxz --numeric-ids 10.1.1.1:/home /m/
(--delete потому, что эту команду можно потом запустить ещё раз, чтоб освежить копию)

rm /m/etc/mtab

echo "/dev/sda1 / ext3 rw,errors=remount-ro 0 0" > /m/etc/mtab

chroot /m dpkg-reconfigure grub-pc

umount /m/home

umount /m

reboot

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

Хотя в последнее время я предпочитаю бэкапить rhel средствами гипервизора, на котором он запущен :) Но это немного не стыкуется с твоей постановкой задачи про bare metal. Так что может быть есть смысл подумать об упразднении этого условия.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Vova Uralsky написал(а) к Victor Sudakov в Jan 18 18:57:44 по местному времени:

Нello Victor!

01 Jan 18 23:02, Victor Sudakov wrote to All:

VS> Собственно сабж? Чтобы в случае отказа быстро и без проблем
VS> восстановить на новом железе (с нуля).

BMR как был проблемой, так и останется навсегда. Если не на коленке мастерить, см:

https://www.ibm.com/support/knowledg...</b>using.html

например...

Regards,
Vova

--- Msged/BSD 6.2.0

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

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

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

Что же касается zfs снапшотов, то ответа на твой вопрос я не знаю. Но поскольку они тоже FS-aware, предполагаю что этот вопрос как-то решён. Могу ошибаться.

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

[dd]

AK> Ну подобного рода инструкций много (у каждого свои). Загрузка с флэшки
AK> либо PXE, fdisk либо его клоны, потом lvm (если хочешь), потом mkfs,
AK> потом раскрываем архив, потом тюнинг конфига и воссоздание загрузчика.

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

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

Спасибо, сохранил, принцип понятен. Жаль, что не lvm и не gpt, ну да ладно, это детали.
И сделанный rsync-ом клон потом работает без проблем?

[dd]

AK> Хотя в последнее время я предпочитаю бэкапить rhel средствами
AK> гипервизора, на котором он запущен :)
AK> Но это немного не стыкуется с
AK> твоей постановкой задачи про bare metal. Так что может быть есть смысл
AK> подумать об упразднении этого условия.

К сожалению, не получится подумать: набор сертифицированного софта утверждён, всё это будет периодически проверяться, добавлять нельзя. Я думаю и сабж такой древний прислали именно из-за наличия сертификатов.

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

Victor Sudakov написал(а) к Vova Uralsky в Jan 18 14:04:22 по местному времени:

Dear Vova,

03 Jan 18 18:57, you wrote to me:

VS>> Собственно сабж? Чтобы в случае отказа быстро и без проблем
VS>> восстановить на новом железе (с нуля).

VU> BMR как был проблемой, так и останется навсегда.

Под виндой-то он проблемой почему-то не является, есть Акронис и множество его аналогов.
Под FreeBSD тоже не является, я столько раз перетаскивал и клонировал машины между разными железками и виртуалками с помощью dump/restore/gpart/newfs.

Вот с RootOnZFS машинками пока руку не набил до полной уверенности, хотя пару раз переносил и их, но с опаской. Мало их у меня, одна дома и парочка виртуалок на работе.

VU> Если не на коленке
VU> мастерить, см:

VU> https://www.ibm.com/support/knowledg...1.11/com.ibm.t
VU> sm.fb.bmr.doc/BMRUse/c_fast_bmrusing.html

VU> например...

Так и по этой ссылке винда упомянута.


"Using the FastBack for Bare Machine Recovery CD for bare machine recovery on your Windows system

If you want to boot your operating system from the FastBack for Bare Machine Recovery CD, follow the steps in this section. Follow these steps if you see a blue screen when you boot."

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

Vova Uralsky написал(а) к Victor Sudakov в Jan 18 17:19:20 по местному времени:

Нello Victor!

04 Jan 18 14:04, Victor Sudakov wrote to Vova Uralsky:

VS>>> Собственно сабж? Чтобы в случае отказа быстро и без проблем
VS>>> восстановить на новом железе (с нуля).
VU>> BMR как был проблемой, так и останется навсегда.
VS> Под виндой-то он проблемой почему-то не является, есть Акронис и
VS> множество его аналогов.
VS> Под FreeBSD тоже не является, я столько раз перетаскивал и клонировал
VS> машины между разными железками и виртуалками с помощью
VS> dump/restore/gpart/newfs.

Угумс

VU>> sm.fb.bmr.doc/BMRUse/c_fast_bmrusing.html
VU>> например...
VS> Так и по этой ссылке винда упомянута.

VS> "Using the FastBack for Bare Machine Recovery CD for bare machine
VS> recovery on your Windows system
VS> If you want to boot your operating system from the FastBack for
VS> Bare Machine Recovery CD, follow the steps in this section. Follow
VS> these steps if you see a blue screen when you boot."

Ты это не читай, вот "Using Tivoli Storage Manager FastBack for Bare Machine Recovery on your Linux system
Restore a Linux machine that is protected by the IBM Tivoli Storage Manager for FastBack client. A customized Linux image is used to boot the client machine to be recovered." читай.

Regards,
Vova

--- Msged/BSD 6.2.0