[Sysadmins] быстрое восстановление с помощью LVM & OpenVZ?

[Sysadmins] быстрое восстановление с помощью LVM & OpenVZ?

[Mike Lykov]

Здравствуйте.

Хочется спросить о практике использования разных средств для быстрого восстановления системы, кто как это реализует?

Задача такая: есть, например, хостинг (или сервер другого назначения, но с публичным доступом, и стоит он в датацентре).
На нем настраивается что-то администраторами и работает. от железных сбоев они защитились двойным питанием, RAID и т.п. 
Но тут приходит "злобный взломщик", который через некую необьявленую дыру получает root и делает rm -rf /
(или это был пьяный администратор, может, перепутав с домашней машиной).

Соответственно, RAID никак не спасает, и нужно быстро восстановить систему каким-либо средством (но учитывая, что сервер удаленный - в датацентре. т.е. возиться "как у себя" долго не дадут, пришел - запустил  - сделал).

Пока есть два варианта - LVM snapshots и/или OpenVZ.
в первом случае - как, куда, чем кто пользуется, чтобы сделать бекап? сколько на это нужно места? (если система занимает все доступное пространство - куда тогда кладется бекап?)
Какая практика восстановления потом?

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

Есть и еще (более экзотические варианты, наверно)  - DRBD для создания аналога RAID, разнесенного по сети, Xen вместо OpenVZ - стоит ли их использовать, если есть преимущества? 

--
Mike

Re: [Sysadmins] быстрое восстановление с помощью LVM & OpenVZ?

[Eugene Prokopiev]

> Задача такая: есть, например, хостинг (или сервер другого назначения, но с публичным доступом, и стоит он в датацентре).
> На нем настраивается что-то администраторами и работает. от железных сбоев они защитились двойным питанием, RAID и т.п.
> Но тут приходит "злобный взломщик", который через некую необьявленую дыру получает root и делает rm -rf /
> (или это был пьяный администратор, может, перепутав с домашней машиной).
>
> Соответственно, RAID никак не спасает, и нужно быстро восстановить систему каким-либо средством (но учитывая, что сервер удаленный - в датацентре. т.е. возиться "как у себя" долго не дадут, пришел - запустил  - сделал).
>
> Пока есть два варианта - LVM snapshots и/или OpenVZ.
> в первом случае - как, куда, чем кто пользуется, чтобы сделать бекап? сколько на это нужно места? (если система занимает все доступное пространство - куда тогда кладется бекап?)

Места нужно столько же, сколько и под рабочую систему (для снапшотов)
+ место, куда будет помещен образ файловых систем или cpio/tar-архив,
снятый с примонтированных снапшотов. Снапшоты в данном случае полезны
только для того, чтоб не получить неконсистентный бэкап, но на
практике это опасно разве что для разных БД, которые в любом случае
лучше бэкапить родными средствами вплоть до выгрузки дампов.

> Какая практика восстановления потом?

Загрузка с livecd, разметка дисков, выливание на диски готовых
файловых систем либо создание пустых, монтирование и выливание на них
архивов, прописывание загрузчика :)

В отсутствие физического доступа к серверу или всяких iLO вариант
неприменимый ...

> Второй вариант - видимо, в этом случае речь идет только об одном контейнере. Но все равно, и его нужно восстанавливать. Кто какими средствами практически пользуется в OpenVZ? опять же - какое место  нужно для бекапа и куда его класть? как производится быстрое восстановление?

Я просто архивирую VE в tar.bz2 - занимается этим крон в HN. Для
postgresql делаю дампы и тоже сжимаю.

> Есть и еще (более экзотические варианты, наверно)  - DRBD для создания аналога RAID, разнесенного по сети, Xen вместо OpenVZ - стоит ли их использовать, если есть преимущества?

DRBD спасет от физической смерти машины, но не от пьяного админа и rm
-rf / - подробнее
http://www.freesource.info/wiki/Software/HighAvailability и
http://www.freesource.info/wiki/TZ/RazrabotkaNuzhnyxProgramm/ClusterManager
- работа начата, но пока заморожена, т.к. есть более приоритетные
задачи :(

Xen вместо OpenVZ полезен, когда в разных VE нужны разные ядра - и
это, естественно, дороже.

PS: кажется, вы и сами знаете ответы на свои вопросы :)

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] быстрое восстановление с помощью LVM & OpenVZ?

[Michael Shigorin]

On Fri, Dec 21, 2007 at 09:38:25AM +0300, Mike Lykov wrote:
> Пока есть два варианта - LVM snapshots и/или OpenVZ.

Как, ты ещё не пользуешь для публичных сервисов ovz?

> Есть и еще (более экзотические варианты, наверно)

Когда-то AMI делали тормозные рейды -- у знакомых был прецедент,
что после приложенного заботливыми китайцами или там бразильцами 
патча Бармина сконфигурированное на отложенную синхронизацию
зеркало пересинкалось со второго диска, когда система с первого
упала.  Не уверен, что лет десять спустя ещё актуально...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] быстрое восстановление с помощью LVM & OpenVZ?

[Mike Lykov]

22.12.07, 15:01, Eugene Prokopiev (enp@altlinux.org):


> PS: кажется, вы и сами знаете ответы на свои вопросы :)

спасибо ;)
просто перед тем, как написать сюда, почитал/подумал - не люблю задавать неподготовленные вопросы ;)
но практический опыт всегда полезен.

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

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

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

ЗЫ это все только планируется ;)

--
Mike