Резервное копирование и восстановление ESXi

Самому пока ума не хватило, поэтому вот:

http://vforv.me/2010/12/25/backuprestore-esxi-серверов/

Процитирую, на случай, если ссылка устареет:

Одним из важных элементов администрирования ESXi серверов иметь план резервного копирования (Backup Plan) и восстановления (Recovery Plan). Сегодня хочу показать вам как делать бэкапы ESXi серверов используя vCLI (vSphere Command-Line Interface).

Конфигурация ESXi сервера хранится в архиве state.tgz что позволяет ей сохранятся после рестартов или в случае выключения сервера.

Бэкап ESXi сервера делается командой vicfg-cfgbackup из vCLI или же из vMA сервера.

vicfg-cfgbackup.pl –server имя_сервера –save путь_к_файлу

Вводим root и его пароль и бэкап начинается.

Бэкап успешно завершён.

Перейдём к восстановлению системы. Первое что надо это установить систему заново или же починить ее. Важно пропатчить систему чтоб она стала идентичной той которая она была когда мы брали бэкап или же во время восстановления использовать параметр –-force. Чтоб восстановить конфигурацию набираем:

vicfg-cfgbackup.pl – -server IP_Адрес –load Конфигурационный_Файл

Вот и все.

Есть один такой нюанс что если у вас бесплатная версия ESXi сервера вы сможете сделать бэкап системы но восстановить ее на бесплатную версию ESXi сервера к сожалению уже не получится. Это ограничение присутствует из-за того что в бесплатной версии ESXi сервера vSphere API работает в режиме read only, но всегда можно переустановить и в триальном режиме сервера восстановить конфигурацию. Так что так.


Читать далее

Перемещение виртуальной машины с одного ESXi на другой

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

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

Имеем VMWare ESXi 4.1 update 1

Поковыряв гугл минут 20 получил очень классный и вообще офигенно простой вариант:



1. Гасим виртуалку на старом ESXi.
2. Копируем папку с виртуальной машиной на новый ESXi (например при помощи Veeam Backup and FastSPC).
3. На новом ESXI открываем через vSphere Client хранилище (datastore), и находим в папке с виртуальной машиной файл с расширением vmx, кликаем правой кнопкой на нем, и выбираем "Add to Inventory".

Ха!!! Дальше сами догадайтесь, чего еще можно сделать чтоб у вас не получилось :)


Читать далее

Восстановление Software RAID 1 на SLES9

Давно использую софтрэйд и вот первый раз у меня реальная проблема. Выгладит она так:

deimos:/proc # lsraid -a /dev/md0
[dev 9, 0] /dev/md0 D98A9487.3EE69195.E35737F7.76A313AC online
[dev ?, ?] (unknown) 00000000.00000000.00000000.00000000 missing
[dev 8, 33] /dev/sdc1 D98A9487.3EE69195.E35737F7.76A313AC good



deimos:/proc # mdadm -D /dev/md0
/dev/md0:
Version : 00.90.00
Creation Time : Thu Aug 17 16:16:53 2006
Raid Level : raid1
Array Size : 35543680 (33.90 GiB 36.40 GB)
Device Size : 35543680 (33.90 GiB 36.40 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Wed Jun 8 17:26:02 2011
State : clean, no-errors
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0


Number Major Minor RaidDevice State
0 0 0 -1 removed
1 8 33 1 active sync /dev/sdc1
2 8 17 -1 faulty /dev/sdb1
UUID : d98a9487:3ee69195:e35737f7:76a313ac
Events : 0.269823066

deimos:/proc # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdc1[1] sdb1[2](F)
35543680 blocks [2/1] [_U]

unused devices:


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

Кроме меня.

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

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

mdadm /dev/md0 -r /dev/sdb1

Перегружаемся и видим что яст его увидел (до перезагрузки не видел), что не может не радовать.
Пробуем добавить:

mdadm /dev/md0 -a /dev/sdb1

mdadm после этого покажет нам его как spare. Сначала меня это напугало, но глянув в /proc/mdstat увидел, что идет синхронизация массива:

deimos:~ # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdc1[1] sdb1[2]
35543680 blocks [2/1] [_U]
[>....................] recovery = 0.1% (70528/35543680) finish=566.6min speed=1041K/sec
unused devices:

Так что все гуд.

Нужно не забыть на всех массивах mdadm настроить на отправку сообщений по почте...



Читать далее

scp, ну как тут не применить :)

Почти 50 линуховых хостов по всей области, это вам не хухры-мухры. И часто нужно какую-то файловую мелкоту, типа логов и т.д. скопировать с линуха на линух. Не везде есть ftp, samba или nfs, зато везде есть ssh. И вот как просто можно обмениваться файлами имея только ssh и scp(не встречал еще ни одного дистра opensuse или debian где ее небыло бы). Итак...

Передаем файлик с хоста, где мы залогинены куда-нибудь далеко на другой хост:

scp 1.tar.gz alexsf@10.77.11.200:/zzz/alexsf/work/2011.06.06-res_performance/2011.06.07

И всех делов :)

С удаленного хоста себе файл забрать не залогиниваясь на него так:

scp alexsf@10.77.11.200:/zzz/alexsf/work/2011.06.06-res_performance/2011.06.07/1.tar.gz /u02/work

Простота линуха радует :)
Читать далее