Аллергия на необратимые десйствия или Пособие по воскрешению Amazon EC2 Instance после chown root

Итак, вы счастливый владелец/пользователь Amazon EC2 Instance’а.

Вы администрировали свой *nix сервер.

И вы сделали необратимое, не имея при этом бекапов. Например sudo mv /etc /bin  …или sudo chown -R /, как в моем случае.

Не опускайте руки и не спешите стреляться. Если вы сделали НЕ sudo rm -rf, то есть выход.

Итак как я уже сказал в моем случае я получил сервер с проблемой sudo chown -R /. SSH доступ к серверу при этом тут же отпал и отказался подключаться в дальнейшем.

Для таких как я, для тех кто не знает, что же такое на самом деле Amazon EC2, я должен сказать, что это не просто выделенный сервер в облаке, это целая серверная стойка в облаке. Со некоторой присущей спецификой, из которой для меня полезным оказалась возможность «вынять» диск из одного сервера и «вставить» его в другой и конечно же вообще сама возможность «включить» отдельный сервер.

Но обо все этом я знал не сразу. И более того, что из этого всего «жесткий диск» я понимал слабо.

У нас на сервере был поднят только один Instance и к нему привязан Elastic IP. Бекапы сайтов с нашего сервера были… и остались они все на том же сервере. Но слава богу, речь идет о Amazon EC2 и я впервые почувствовал разницу с другими облачными хостингами.

Достаем диск

Чтобы «достать диск», сперва понадобилось создать AMI (Amazon Machine Image, слепок/снимок всего сервера). Для этого я зашел в Instances и в контекстном меню нашего Instance’а выбрал «Create Image». Это заняло не больше 5 минут времени. Вместе с AMI создался и Shapshot собственного самого жесткого диска. Из Shapshot’а я создал уже сам жесткий диск, тоже через контекстное меню Snapshot’а — «Create Volume from Snapshot».

Создаем еще один сервер

Для запуска второго сервера идем в Instances и кликаем «Launch Instance». Проходим мастер создания Instance’а. Не включаем его пока что.

Да, кстати, большого счета за второй сервер вы не получите, т.к. в Amazon EC2 вы платите только за запущенные Instance’ы. А одновременно они будут запущены всего несколько часов, в нашем случае получилось что-то около двух с половиной часов, после чего старый Instance был остановлен, а на новый был настроен Elastic IP старого и все закрутилось.

Вставляем старый диск в новый сервер

Для этого идем в Volumes, нажимаем правой кнопкой на пока еще не задействованный недавно созданный диск, в контекстном меню выбираем «Attach», в диалоговом окне выбираем только что созданный Instance, жмём «Yes, attach».

Запускаем новый сервер

Идем в Instances, находим новый сервер, в контекстном меню выбираем «Start». Подключаемся по ssh к новому серверу, создаем директорию, допустим mkdir ~/disk_for_recovery.

После этого монтируем подсоединенный диск командой mount /dev/sdf ~/disk_for_recovery. Здесь имейте в виду, что название вашего диска может отличаться. Вообще Амазон указывает, каким устройством будет подключен диск на странице Volumes в колонке «Attachment Information». Но при этом они же предупреждают, что разные ОС могут по разному подключать его. Мой был к примеру подключен как /dev/xdvj. При монтировании тип файловой системы я не указывал.

После монтирования, я перенес на новый сервер все конфиги и папки. Потом мы подняли LAMP и уже подключили Elastic IP на новый Instance. И после всех манипуляций, создали AMI и бекапы)

В общем, как было сказано на одном известном ресурсе: «Вчера был ппц, но это не конец…»

Не попадайтесь.

Полезно(2)Бесполезно(0)

Добавить комментарий