Полный бэкап серверов (включая партишн тейбл)

[sptica]

Коллеги, здравствуйте!

Кто как решает вопрос с полным бэкапом серверов, работающих 24/7? Очень хочется в ситуациях, когда погорел винт, воткнуть другой, накатить на него бэкап и чтобы заработало. При этом чтобы бэкапы по крону делались раз в неделю.

Варианты с tar/dump не плохи, но решают только часть задачи. Для восстановления сервера придётся ставить свежую систему и уже туда копировать конфиги, что долго, а хочется быстро. Варианты с ручным копированием партишн тейбла что то не заработали у меня на kvm (пробовал просто для примера). В общем пока в растерянности. Гугл тоже быстрого ответа не дал.

Поделитесь пожалуйста опытом, кто как решает задачу и решает ли вообще .

[Bizdelnick]

Очень хочется в ситуациях, когда погорел винт, воткнуть другой, накатить на него бэкап и чтобы заработало.

Зачем? RAID же для этого есть. Бекапы для внештатных ситуаций, а полетевший винт - совершенно рядовая.

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

[drBatty]

Кто как решает вопрос с полным бэкапом серверов, работающих 24/7? Очень хочется в ситуациях, когда погорел винт, воткнуть другой, накатить на него бэкап и чтобы заработало. При этом чтобы бэкапы по крону делались раз в неделю.

Это вам к волшебнику нужно обращаться.

Варианты с tar/dump не плохи, но решают только часть задачи. Для восстановления сервера придётся ставить свежую систему и уже туда копировать конфиги

что мешает вам решить вторую часть задачи -- ещё раз запустить tar, и затарить всю систему без /var и прочего изменяемого барахла(которое вы уже забекапили)? Затем нужно запустить dd, и забекапить таблицу разделов. Причём запускать второй tar и эту dd нужно будет лишь после обновления системы.

Тогда для восстановления на такой же диск достаточно будет
1. командой dd скинуть таблицу разделов на новый диск.
2. распаковать в корень систему.
3. распаковать данные.
Если геометрия нового диска другая, то придётся его ручками перепиливать, например если новый диск втрое больше. Но шаги 2 и 3 не меняются, только нужно будет скорректировать UUID новых разделов(которые поменяются).

ИМХО полный бекап - вообще бестолковая затея. Важны только уникальные данные и конфиги, а тратить сотни гигабайт на хранение того, что всегда есть в репозиториях, бессмысленно.

++

всё равно на практике нужно качать данные. Какая разница откуда? Зачем поддерживать свой репозиторий? А если надо свой, то пусть это будет репозиторий, как у людей. А не HEX.

[Bizdelnick]

Затем нужно запустить dd, и забекапить таблицу разделов.

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

[lazhu]

zfs send/receive

[drBatty]

dd не подходит для бекапа таблицы разделов, если среди них есть расширенные. dd MBR + sfdisk тогда уж.

угу. Ессно.

Но тарить файлы с работающей системы - не лучший вариант.

если данные у ТСа хорошо затарились, то и система подавно затарится. Главное -- не обновлять систему в момент затарки системы.

А вот с данными -- да, беда. На сервере так никто не делает, а дома -- можно.

[Sleeping Daemon]

Коллеги, здравствуйте!

Кто как решает вопрос с полным бэкапом серверов, работающих 24/7? Очень хочется в ситуациях, когда погорел винт, воткнуть другой, накатить на него бэкап и чтобы заработало. При этом чтобы бэкапы по крону делались раз в неделю.

Варианты с tar/dump не плохи, но решают только часть задачи. Для восстановления сервера придётся ставить свежую систему и уже туда копировать конфиги, что долго, а хочется быстро. Варианты с ручным копированием партишн тейбла что то не заработали у меня на kvm (пробовал просто для примера). В общем пока в растерянности. Гугл тоже быстрого ответа не дал.

Поделитесь пожалуйста опытом, кто как решает задачу и решает ли вообще .

Если всё так критично, то делайте высоконадёжный кластер + внешнии аппаратные раиды 5.6.уровней.

[BigBrother]

Коллеги, здравствуйте!
Кто как решает вопрос с полным бэкапом серверов, работающих 24/7? Очень хочется в ситуациях, когда погорел винт, воткнуть другой, накатить на него бэкап и чтобы заработало.

Если серверов много, смотри в сторону облаков. Например публичные клауды (aws, rackspace ...) или городить свой велосипед, приватный клауд, типа openstack`а - что есть очень трудно для одного человека, необходима команда спецов.
А насчет полного бекапа (влоть до системных файлов) - задача напряжная. Может проще делать бекап критических данных (архивы по датам), и держать под рукой образ с системой. А когда сервер выйдет из строя, быстро накатать на новый сервак образ, и залить данные.
Или рассмотреть варианты с использование RAID`ов.

[drBatty]

быстро накатать на новый сервак образ, и залить данные.
Или рассмотреть варианты с использование RAID`ов.

скорее "И". RAID защитит отдельный сервер от выхода из строя одного из HDD и позволит его быстро поменять. Бекап тут не при чём.

Вообще говоря, скажу неожиданную вещь: бекап часто не нужен. Не нужно путать бекап с

1. RAID массивом
2. схемой быстрого развёртывания системы на новый сервер
3. системой репликации данных

если у вас есть п1, п2, и п3, то не совсем понятно, что вы собственно хотите бекапить?

[neol]

Вообще говоря, скажу неожиданную вещь: бекап часто не нужен. Не нужно путать бекап с

1. RAID массивом
2. схемой быстрого развёртывания системы на новый сервер
3. системой репликации данных

если у вас есть п1, п2, и п3, то не совсем понятно, что вы собственно хотите бекапить?

Если вспомнить недавний факап с репозиторием KDE, становится понятно что и зачем бекапить.

PS Может я не правильно понял вашу мысль?

[drBatty]

Если вспомнить недавний факап с репозиторием KDE, становится понятно что и зачем бекапить.

PS Может я не правильно понял вашу мысль?

вы про https://mail.kde.org/pipermail/owncloud/201...ust/010118.html что-ли? При чём тут вообще бекапы? Обычный рабочий момент при работе в любой DVCS, который успешно исправляется средствами самой DVCS.

Ну используйте mercurial, там из истории вообще хрен что выдернуть можно, и это не баг, а фича. А вот в git'е -- да, историю можно править. Git'опроблемы, на самом деле.

[sptica]

Спасибо всем за участие!

Действительно правильное решение проблемы это софтворный рейд и на системных жестких дисках. Пользовательские то данные все зеркалированны, а вот системы с конфигами нет.

Плюс отдельно бэкапы конфигов.

[neol]

вы про https://mail.kde.org/pipermail/owncloud/201...ust/010118.html что-ли? При чём тут вообще бекапы?

http://www.opennet.ru/opennews/art.shtml?num=36491

[drBatty]

neol
ну разве сложно научится читать до конца?

Оказалось, что механизм самоверификации, работающий при выполнении команд git, не работает для режима "--mirror". При выполнении "git --mirror", зеркалирование выполняется без проверки целостности и без лишних предупреждений даже в случае наличия в репозитории повреждённых объектов коммитов

если зеркало уже разбито, зачем размножать осколки? Очевидно, нужно найти целое зеркало, раз это разбилось.

типичная дефективность схемы "звезда", с "главным сервером", который умирая рушит за собой ВСЮ систему.

Конец немного предсказуем. В данном случае просто повезло, что нашлось хоть одно зеркало, которое было создано грамотно.

Нельзя никому доверять.

Особенно "центральному серверу", на который и будет направлена атака. Мало того, надёжная распределённая система должна включать в себя меры для того, что-бы этот "центральный сервер" уничтожался автоматически. В любой система с функцией качества образуется положительная обратная связь, которая засасывает один из узлов в яму низкой энергии -- чем больше систем считают ЦС "хорошим", тем более "хорошим" становится ЦС. Это типичный рак. И он тоже ведёт к неизбежной смерти. Обычный сценарий -- ЦС не справляется с нагрузкой, и рушится. Его можно подпереть костылями, но это временная мера.

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