Если я использую современную систему vmware ESXi, я могу добавить статически связанный двоичный файл rsync и файлы rsync в любое место назначения через SSH.
Я пытаюсь понять, почему большинство (всех?) Резервных копий гостей vmware не выполняется таким образом.
Если виртуальная машина запущена, вы можете просто использовать vim-cmd vmsvc / snapshot.create для создания снимка, а затем выполнить синхронизацию этого снимка с удаленным хостом. (есть даже возможность "заморозить" снимок)
ИЛИ, если вам нужна более надежная резервная копия, вы можете аккуратно остановить виртуальную машину и rsync для файла (ов) vmdk.
Итак ... похоже, что я простой сценарий оболочки вдали от всех резервных копий, которые я когда-либо хотел делать, просто и легко, используя простой старый rsync.
Что мне здесь не хватает?
Я делал это несколько лет назад. (править: с VMWare, работающим на хостах CentOS, а не ESXi по общему признанию)
Каждую ночь у меня был сценарий, который приостанавливал виртуальную машину, синхронизировал файлы с диска на сервер резервного копирования, а затем снова запускал виртуальные машины. Это сработало неплохо, за исключением ...
Rsync не очень хорошо работает с файлом размером 2 ГБ.
Дело не в том, что rsync не идеален, а скорее в том, что каждый файл vmdk объемом 2 ГБ изменяется очень непрозрачно для rsync, даже небольшие изменения в закрытой файловой системе приводят к изменениям в vmdk (или во всех vmdk по какой-то причине), на которые я винил Windows, либо автоматически дефрагментирует, либо иным образом выполняет все остальные действия, которые не имеют значения, если вы используете реальную систему, но появляются, когда вы пытаетесь выполнить rsync виртуальной машины!
Я думаю, что механизм rsync для обнаружения изменений не очень хорошо работает с файлом размером 2 ГБ, хотя он довольно часто пропускал фрагменты запуска vmdk, как только он начинал обнаруживать разницу, он просто копировал остальную часть файла. Я не знаю, связана ли это с тем, что rsync не может обнаружить перемещенный фрагмент двоичных данных, или с нехваткой памяти в исходном блоке, или же vmdk только что полностью обновился. Это не имеет значения, результат был одинаковым - большая часть vmdk была скопирована.
В конце концов, я просто скопировал все измененные файлы и перезаписал их, все еще используя rsync. У меня также была лучшая производительность, просто перезаписав файл резервной копии вместо того, чтобы позволить rsync копировать и заменять то, что было там.
Наш сервер резервного копирования тоже не был самым быстрым, и дошло до того, что за ночь не хватило времени для резервного копирования всех работающих виртуальных машин.
Однако когда нам действительно нужно было восстановить виртуальную машину, это было действительно легко и прекрасно работало.
Rsyncing одного файла не является решением для резервного копирования,
что вы делаете, когда что-то случилось с виртуальной машиной и файлы были удалены, но вы заметили это только после того, как ваш rsync снова запустился? Теперь вы замените хорошую «резервную копию» ваших файлов плохим изображением.
Если вам нужна резервная копия, вам нужно где-то хранить старые версии или файлы diff. Rsync будет копировать только различия для вас, но он не будет хранить только различия, но перезапишет предыдущий файл.
Здесь могут быть варианты с rsync и файловой системой копирования при записи с информацией о версиях, которая фактически будет сохранять различия каждый раз, когда запускается ваш сценарий rsync. Эти решения уже начинают немного усложняться, поэтому люди прибегают к известным рабочим решениям imho.
Нет никаких причин, по которым вы не можете использовать Rsync на сервере ESXi. Здесь мы предлагаем статически скомпилированную версию https://33hops.com/rsync-for-vmware-vsphere-esxi.html это работает очень хорошо. Также есть информация о том, как скомпилировать свой собственный.
Тем не менее, любой, кто хочет его использовать, должен учитывать, что Rsync и его алгоритм Delta не предназначены для резервного копирования огромных разреженных файлов фиксированной длины, таких как жесткие диски виртуальных машин, а для синхронизации файлов меньшего размера переменной длины. Итак, это работает, но для вычисления данных diff требуется много времени и ресурсов процессора. Фактически, это просто способ обмена пропускной способностью процессора. В любом случае, это вполне работоспособно, особенно если ваши виртуальные диски имеют порядок нескольких десятков гигабайт.
Я опубликовал полный пост по этой теме здесь, в котором подробно описаны все плюсы и минусы. https://33hops.com/blog_xsibackup-rsync-considerations.html