Что было бы лучшим способом взять регулярный копировать / изображение / что угодно на живом (Ubuntu LTS Hardy) сервере, чтобы я мог запускать его как локальную среду тестирования и резервного копирования в Parallels.
Более детально:
Я хотел бы иметь как можно более точную копию действующей машины, работающую в Parallels для тестирования и как можно более надежного резервного копирования.
Я предполагаю, что нетехнологичный способ - установить Ununtu в Parallels, а затем использовать обычные sftp / scp копии структуры каталогов сервера.
Однако мне было интересно, есть ли более «умный» способ сделать это, например, некоторая форма автоматического создания виртуальной машины из существующей системы - например, привидение.
Я не знаю об автомате для создания ВМ; Я просто хотел подробно рассказать о вашем низкотехнологичном методе.
Чтобы быть конкретным, есть два «низкотехнологичных» способа, в зависимости от того, можете ли вы позволить серверу быть отключенным на некоторое время.
Отключить сервер, подключите резервный диск, запустите dd над / и любых других основных разделов системы для создания точных образов на резервном диске, отсоединения резервного диска, возврата сервера в эксплуатацию. Резервный диск теперь содержит полный образ сервера на момент резервного копирования. (Это, вероятно, не то, что вы хотели бы делать каждые пару недель, но вы можете постепенно обновлять такое изображение с помощью rsync или похожие.)
Не переводите сервер в автономный режим; вместо этого возьмите список всех пакетов и версий, установленных в системе (например, dpkg -l > server.packages.list); установить базовую систему в Parallels; установить пакеты, соответствующие списку с сервера; резервное копирование сервера /etc, любые другие основные файлы конфигурации и любые основные источники данных (например, /var/www) и скопируйте их в свою систему Parallels.
В отсутствие инструмента виртуализации было бы проще выбрать вариант №2. Первоначальное создание виртуальной машины займет некоторое время, но вы можете легко создать и сделать резервную копию образа этой системы непосредственно перед применением изменений, взятых с живого сервера. Затем у вас есть мгновенный образ для новой установки, а для резервного копирования с сервера с последующим восстановлением на виртуальную машину можно создать сценарий, так что его будет довольно легко повторить с нуля (или из свежей резервной копии. install) время от времени.
Фактически, вы в любом случае можете выбрать №2 и рассматривать его как возможность периодически проверять свое решение для резервного копирования: если вы можете восстановить из резервных копий образ после новой установки, вы знаете, что ваше решение для резервного копирования хорошее. Если не можешь, значит, тебе есть над чем поработать.
То, как я бы сделал это для себя, как-то связано с ответом №2 от ~ quack.
Я бы изначально установил ту же базовую систему, которая находится на вашем живом сервере в вашей виртуальной машине (это для того, чтобы ваше оборудование распознавалось, работало grub и т. Д.). Затем я бы синхронизировал все соответствующие файловые деревья (например, не / proc, / dev или / tmp) с рабочего сервера на сервер разработки.
Поскольку rsync основан на идее, что копируются только измененные данные, после начальной настройки было бы довольно быстро повторно синхронизировать сервер разработки с действующим.
Сложность, которую я могу предвидеть (но я уверен, что еще много не за горами!), Заключается в том, что некоторые файлы конфигурации могут действительно нужно быть другим в двух системах (например, в тех, которые содержат UUID устройств), и может быть трудно понять, какие именно, и исключить их из процесса rsync.
В качестве примечания два наблюдения:
HTH.