рекомендации по эффективному удаленному резервному копированию vm's

Я ищу рекомендации для резервного копирования моих текущих 6 виртуальных машин (и скоро вырастет до 20). В настоящее время я использую кластер Proxmox с двумя узлами (который является базой Debian, использующей kvm для виртуализации с пользовательским веб-интерфейсом для администрирования). У меня есть две почти идентичные коробки с материнскими платами amd phenom II x4 и asus. Каждый из них имеет 4 500 ГБ жестких дисков sata2, 1 для операционной системы и других данных для установки proxmox, и 3 с использованием mdadm + drbd + lvm для разделения 1,5 ТБ хранилища между двумя компьютерами. Я монтирую образы lvm в kvm для всех виртуальных машин. В настоящее время у меня есть возможность выполнять прямой перенос с одной машины на другую, обычно в течение нескольких секунд (это занимает около 2 минут на самой большой виртуальной машине, работающей на win2008 с сервером m $ sql). Я использую встроенную утилиту Proxmox vzdump, чтобы сделать снимки виртуальной машины и хранить их на внешнем жестком диске в сети. Затем у меня есть служба jungledisk (использующая пространство в стойке) для синхронизации папки vzdump для удаленного резервного копирования за пределы площадки.

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

Конечно, гораздо лучшим решением было бы то, что позволило бы мне мгновенно принять разницу в два момента времени (скажем, то, что было написано с 6 утра до 7 утра), сжать ее, а затем отправить этот файл разницы на сервер резервного копирования, который немедленно перенесется на удаленное хранилище на стеллажах. Я немного посмотрел на zfs и его способность делать отправку / получение. Это в сочетании с потоком данных в bzip или что-то вроде бы идеально. Однако, похоже, что для реализации nexenta-сервера с zfs, по сути, потребуется по крайней мере один или два выделенных сервера хранения для обслуживания блочных томов iSCSI (через zvol ???) для серверов proxmox. Я бы предпочел сохранить настройку как можно меньше (т. Е. НЕ иметь отдельных серверов хранения), если это вообще возможно.

Я также вкратце прочитал о зумасторе. Похоже, что он также может делать то, что я хочу, но, похоже, остановил разработку в 2008 году.

Так зфс, зумастор или другой?

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

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

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

Если бы я делал резервные копии вне сайта, я бы выбрал следующие варианты:

(a) сценарий оболочки, который копирует SCP на удаленный сервер. Таким образом, вы можете добавить задание cron, которое автоматически запускает сценарий, который создает резервную копию. Кроме того, вы можете сделать так, чтобы он создавал временный архивный файл перед фактической передачей файлов, тем самым сохраняя пропускную способность, не передавая во время подзарядки подоконника.

или

(b) Установите инструмент управления сервером, такой как Webmin, и получите его для автоматического резервного копирования. В настоящее время я пою это на своих производственных серверах прямо сейчас без каких-либо проблем, это просто работает без нареканий. Я бы также порекомендовал cloudmin (платный) для управления многими виртуальными машинами, поскольку он предоставляет решение «все в одном».

некоторые дополнительные ссылки:

http://www.debianhelp.co.uk/backup.htm

http://ubuntuforums.org/showthread.php?t=35087

Надеюсь, это поможет, RayQuang

Вы могли бы хотеть взглянуть на backuppc.

backuppc может работать поверх rsync, который делает инкрементное копирование.

Более того, вы можете легко написать черный список папок, которые не должны быть зарезервированы. Например: temp / / tmp .garbages / ...

http://backuppc.sourceforge.net/

Backuppc имеет чистый веб-интерфейс, позволяющий загружать некоторые части резервной копии непосредственно в виде zip-файла. Это может быть проверено nagios с помощью check_backuppc.

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

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

zfs делает это замечательно, вы уже упоминали, что знаете об этом, и о недостатке неэффективной работы на уровне 2 серверов. Это также не даст вам аварийного переключения DRDB, то есть Nexenta будет единственной точкой отказа.

Вы можете попытаться получить VirtualBox на OpenSolaris или NexentaCore, но не так просто, как ProxMox + DRDB, чтобы вы могли повторно использовать свои существующие машины.

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

Стив Радич - Хостинг Windows и производительность SQL с 1995 года - http://www.BitShop.com/Blogs.aspx

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

Рассмотрим решение для резервного копирования файлов в гостевой системе, которых существует множество. Backuppc, Urbackup, Bacula, Аманда и т. Д ...

Это будет намного быстрее, займет намного меньше места и будет намного проще восстанавливать определенные файлы.

Я думаю, что, возможно, нашел окончательный ответ на свой вопрос:

BUP https://github.com/bup/bup

Функции:

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

  Он использует формат packfile из git (система контроля версий с открытым исходным кодом), так что вы можете получить доступ к хранимым данным, даже если вам не нравится пользовательский интерфейс bup.

  В отличие от git, он записывает упаковочные файлы напрямую (вместо отдельной стадии сборки / перепаковки мусора), поэтому работает быстро даже с огромными объемами данных. Улучшенные форматы индекса bup также позволяют отслеживать гораздо больше имен файлов, чем git (миллионы), и отслеживать гораздо больше объектов (сотни или тысячи гигабайт).

  Данные «автоматически» распределяются между инкрементными резервными копиями без необходимости знать, какая резервная копия основана на какой другой, даже если резервные копии создаются с двух разных компьютеров, которые даже не знают друг о друге. Вы просто указываете bup для резервного копирования, и он сохраняет только минимальный объем необходимых данных.

  Вы можете выполнить резервное копирование непосредственно на удаленный сервер bup, не требуя тонны временного дискового пространства на резервном компьютере. И если ваша резервная копия будет прервана на полпути, при следующем запуске вы обнаружите, где вы остановились. Также легко настроить сервер bup: просто установите bup на любой компьютер, к которому у вас есть доступ по ssh.

  Bup может использовать избыточность «par2» для восстановления поврежденных резервных копий, даже если на вашем диске обнаружены поврежденные сектора.

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

  Вы можете смонтировать ваш репозиторий bup как файловую систему FUSE и получить к нему доступ таким образом, и даже экспортировать его через Samba.

Изменить: (19 августа 2015 г.) И еще одно отличное решение, которое даже лучше: https://github.com/datto/dattobd

Это позволяет делать моментальные снимки в реальном времени, по существу давая функции, подобные COW, любой обычной старой файловой системе в Linux.

Изменить: (15 июля 2016 г.) И даже еще одно отличное решение, которое дует удар из воды: https://github.com/borgbackup/borg

Это особенно лучше, чем ударить по обрезке. Похоже, что есть отличная поддержка сжатия, шифрования и эффективной дедупликации. dattobd + borg ftw !!!