Можно ли скопировать серверы RHEL6?

Моей компании необходимо настроить сервер разработки, и у нас уже есть 2 рабочих сервера RHEL 6, работающих под коммутатором L4.

Одним из решений для настройки сервера dev было простое копирование всех файлов с одного из производственных серверов и его небольшая настройка.

Я никогда не делал этого раньше, но это звучит похоже на воображение ... это можно сделать? Это рекомендуется? Это будет склонно к ошибкам?

Копирование всех файлов может работать. Это будет зависеть от ОС и от того, какой метод копирования.

Одна общая проблема - попытка скопировать систему во время ее работы. Обычно, по крайней мере, некоторые файлы будут заблокированы и, следовательно, не будут правильно копироваться. Использование какого-либо программного обеспечения для обработки изображений при выключенной системе обычно наиболее безопасно (вы упомянули Ghost, который является одним из примеров)

Почему бы не преобразовать работающие системы в виртуальные машины? Большинство гипервизоров, таких как VMware или Hyper-V, имеют инструмент для простого преобразования работающей системы в виртуальную машину.

Затем вы можете работать с непроизводственной системой по своему желанию, прежде чем делать что-либо на рабочем сервере.

Благодаря @WernerCD

Vmware

Hyper-V,

Это можно сделать?

Определенно да. Я скопировал весь сервер Linux, просто упаковав файлы tarи снова распаковав их на целевом сервере. Единственное предостережение, которое я помню, - это необходимость помнить, чтобы использовать --numeric-ownerпри извлечении. Я не могу говорить о других ОС и других инструментах, но я думаю, что это выполнимо со всеми основными операционными системами.

Это должно быть сделано?

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

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

Подход, который я бы порекомендовал для создания клона рабочей системы, заключается в восстановлении из резервной копии. Вы можете избежать влияния на производительность производственной системы, восстановившись из резервной копии, и вы сможете протестировать процедуру восстановления, и это хорошо.

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

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

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

осуществимость

Конечно, это возможно, потому что нетрудно «установить» Linux, используя нетрадиционные средства. Вы можете, например, реплицировать сервер, используя rsync через SSH.

1. Загрузите целевой компьютер в виде «спасательного» образа, будь то с помощью Red Hat DVD, Ubuntu Live Boot, Knoppix и т. Д.
2. Разбейте и отформатируйте целевой компьютер и смонтируйте файловые системы под /target .
3. rsync все соответствующие файловые системы через SSH (пропуск /proc,/sys , своп).
4. Исправить /target/etc/fstab , особенно если на разделы ссылается UUID.
5. Настройте имя хоста и конфигурацию сети в зависимости от ситуации.
6. Установите загрузчик.

Шаг 3 может состоять из нескольких проходов rsync, возможно, с помощью снимков LVM на исходном компьютере, последний этап с остановкой всех служб на исходном компьютере для обеспечения согласованности данных.

Желательность и лучшие практики

То, что ты можешь, не означает, что ты должен. Я рекомендовал описанный выше процесс как один из способов миграции центра обработки данных. Однако ваш вариант использования совсем другой. Использование клонирования подчеркивает некоторые недостатки:

• Было бы неплохо иметь виртуализацию и сделать репликацию простой.
• У вас есть резервные копии ваших производственных серверов? Почему бы просто не восстановить их? Это было бы хорошим тестом вашей процедуры восстановления резервной копии.
• У вас есть документация о том, как воспроизвести все с нуля? В конце концов вам, вероятно, потребуется установить с нуля, возможно, при обновлении операционной системы. Это было бы хорошим подтверждением вашей документации.
• А еще лучше, есть ли у вас автоматизация, которая поможет вам воспроизвести ваши настройки? Сценарий оболочки может работать; решение для управления конфигурацией, такое как CFengine, Puppet, Chef или Ansible, было бы еще лучше.

Если вы слепо клонируете рабочий сервер, вы потеряете ценную возможность уточнить, что именно на нем работает.