Почему люди просто не используют rsync для резервного копирования гостей vmware?

12

Если я использую современную систему VMware ESXi, я могу добавить статически связанные двоичные файлы rsync и rsync в любое место назначения по SSH.

Я пытаюсь понять, почему большинство (все?) Резервное копирование гостей VMware не выполняется таким образом.

Если виртуальная машина работает, вы можете просто использовать vim-cmd vmsvc / snapshot.create для создания моментального снимка, а затем rsync для моментального снимка с удаленного хоста. (есть даже опция «успокоить» снимок)

ИЛИ, если вы хотите более надежное резервное копирование, вы можете аккуратно остановить VM и rsync через файл (ы) vmdk.

Итак ... кажется, что я простой сценарий оболочки без всех резервных копий, которые я когда-либо хотел, просто и легко, используя простой старый rsync.

Что мне здесь не хватает?

— user227963
источник

1

Потому что, если в ВМ изменяется один файл, вам придется сделать резервную копию всего vmdk?

— Факер

Нет, rsync будет эффективно обновлять один файл с изменениями, внесенными с момента последней передачи. Конечно, операции виртуальной машины могут произвести НАМНОГО больше изменений, чем вы ожидаете, но это не заставит вас переслать весь vmdk ...

— user227963

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

— делают

1

@Rqomey - в ESXi есть разные «снимки». Вы говорите об одном виде, который виден через vSphere Client - но используя API, у вас есть другие варианты, например: полный клон.

— Маси

@MASI Вы имеете в виду клона, а не снимок? ;)

— Rqomey

32

Потому что скорости передачи из консоли ESXi целенаправленно ограничены.
Потому что это никак не масштабируется.
Потому что вам нужно было бы сбросить статически скомпилированный двоичный файл rsync на хост ESXi.
Поскольку виртуальные машины, VMDK, их файлы ramdisk и другие компоненты могут измениться настолько, чтобы rsync стал проигрышным предложением ... Вы действительно хотите повторно синхронизировать виртуальную машину 200 ГБ, которая была перезагружена и изменилось небольшое количество файлов?
Из-за требований к процессору / памяти на источнике или месте назначения. Rsync не является бесплатным.
Потому что на рынке есть и другие продукты, как сторонние, так и VMware. Посмотрите на измененное отслеживание блоков .
Потому что ESXi НЕ является операционной системой общего назначения.

См. Также: Установка rsync на сервере VMware ESX 4.1.

— ewwhite
источник

1

Отличный ответ.

— EEAA

3

Они не ... Я имею в виду, это во имя: ghettoVCB . Есть лучшие решения там. Veeam, vSphere Data Protection и т. Д.

— ewwhite

2

Конечно, вы можете использовать метод rsync, если переключитесь на xen / kvm.

— Zoredache

9

@ user227963 Rsync также довольно неэффективен как для большого количества файлов, так и для больших. И хотя ему может не понадобиться пересылать весь файл по сети, ему придется перечитать его как в исходном, так и в целевом виде. CBT поможет вам здесь, но rsync ничего не знает о CBT.

— the-wabbit

2

@ user227963 копировать файлы просто. Теперь сделайте это быстро и не тратите ресурсы на большие файлы с небольшими постоянными изменениями. rsync неплох, но не сравнится с производительностью чего-либо с инсайдерской информацией о том, какие блоки изменились.

— JamesRyan

4

Я делал это несколько лет назад. (редактировать: VMWare работает на хостах CentOS, а не ESXi)

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

Rsync не очень хорошо работает с файлом 2 ГБ.

Дело не в том, что rsync не блестящий, а в том, что каждый vmdk-файл размером 2 ГБ изменяется очень непрозрачно для rsync, даже небольшие изменения во вложенной файловой системе приводят к изменениям в vmdk (или по каким-то причинам во всех vmdks), которые я обвинил Windows, либо автоматически дефрагментируя, либо иным образом выполняет все остальные действия, которые не имеют значения, если вы работаете в реальной системе, но появляются, когда вы пытаетесь синхронизировать виртуальную машину!

Я думаю, что механизм rsync для обнаружения изменений не очень хорошо работает с файлом 2 ГБ, хотя он довольно часто пропускает фрагменты запуска vmdk, и когда он начинает находить разницу, он просто копирует остальную часть файла. Я не знаю, является ли проблема в том, что rsync не может обнаружить перемещенный фрагмент двоичных данных, или нехватка памяти в окне исходного кода, или только что vmdk только что обновился полностью. Неважно, как результат был тот же - большинство vmdk были скопированы.

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

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

Однако, когда нам нужно было восстановить виртуальную машину, это было действительно легко и прекрасно работало.

— gbjbaanb
источник

Хорошо, это очень полезно. Я немного знаю о том, как работает rsync, и я могу вам сказать, что он не имеет никакого отношения к размеру файла - но вы описываете, что в файле происходит гораздо больше изменений, чем вы ожидаете ... то есть скажем, вы запускаете виртуальную машину в течение дня, и вы делаете с ней только несколько небольших вещей, а затем останавливаете ее ... но файл vmdk изменился на 30-40% (даже если вы сделали очень мало). Так что rsync справится просто, у него много работы ... больше, чем вы ожидали. Благодарность!

— user227963

1

Но тогда ... возникает вопрос: как это делают "профессиональные" инструменты? Какую магию они делают, которая является более оптимальной, чем rsync (или scp, или даже cp)? В конце концов, у вас есть среда Unix (консоль ESXi), и вы хотите переместить файл в него или из него ... какие секреты могут быть связаны с этим?

— user227963

@ user227963 Профессиональные инструменты используют такие функции, как отслеживание измененных блоков или имеют доступ к другим API-интерфейсам vSphere или ESXi.

— ewwhite

2

Rsyncing одного файла не является решением для резервного копирования,

Что вы делаете, когда что-то случилось с виртуальной машиной и файлы были удалены, но вы заметили это только после повторного запуска rsync? Теперь вы перезаписали хорошую «резервную копию» ваших файлов плохим изображением.

Если вы хотите сделать резервную копию, вам нужно где-то сохранить старые версии или различий. Rsync будет копировать только различия для вас, но он не будет хранить только различия, но перезапишет предыдущий файл.

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

— Йенс Тиммерман
источник

Здесь, безусловно, гораздо больше сложностей, чем я думал, но то, что вы упоминаете, не является проблемой. Конечно, если вы слепо запускаете rsync снова и снова, вы столкнетесь с проблемами, как вы предлагаете, но есть множество простых способов клонировать / вращать резервные копии, созданные rsync (даже однофайловые) ... эта проблема решалась долго время назад, к счастью.

— user227963

0

Нет никаких причин, по которым вы не можете использовать Rsync на сервере ESXi. Мы предлагаем статически скомпилированную версию здесь https://33hops.com/rsync-for-vmware-vsphere-esxi.html, которая работает очень хорошо. Там есть информация о том, как собрать свой собственный тоже.

Тем не менее, любой, кто хочет его использовать, должен учитывать, что Rsync и его алгоритм Delta не предназначались для резервного копирования огромных файлов с фиксированной длиной, таких как жесткие диски виртуальных машин, а для синхронизации файлов меньшей длины переменной длины. Итак, это работает, но для вычисления различий требуется много времени и ресурсов процессора. Фактически это просто способ обмена пропускной способностью по процессору. В любом случае, это все еще вполне работоспособно, особенно если размер ваших виртуальных дисков составляет несколько десятков гигабайт.

Я опубликовал полный пост на эту тему, подробно описав все за и против https://33hops.com/blog_xsibackup-rsync-considerations.html

— Даниэль Дж.
источник