Я ищу рекомендации по резервному копированию моих текущих 6 виртуальных машин (которые скоро вырастут до 20). В настоящее время я использую кластер proxmox с двумя узлами (который является базой debian, использующей kvm для виртуализации с настраиваемым веб-интерфейсом для администрирования). У меня есть две почти одинаковые коробки с материнскими платами amd phenom II x4 и asus. Каждый из них имеет 4 жестких диска sata2 емкостью 500 ГБ, 1 для операционной системы и других данных для установки proxmox и 3 с использованием mdadm + drbd + lvm для совместного использования 1,5 ТБ хранилища между двумя машинами. Я монтирую образы lvm в kvm для всех виртуальных машин. В настоящее время у меня есть возможность выполнять передачу в реальном времени с одной машины на другую, обычно в течение нескольких секунд (это занимает около 2 минут на самой большой виртуальной машине с win2008 с сервером m $ sql). Я использую встроенную утилиту vzdump proxmox, чтобы делать снимки виртуальных машин и сохранять их на внешнем жестком диске в сети. Затем у меня есть служба jungledisk (с использованием rackspace) для синхронизации папки vzdump для удаленного резервного копирования за пределами площадки.
Это все нормально, но не очень масштабируемо. Во-первых, сами резервные копии могут занимать до нескольких часов каждую ночь. При инкрементной передаче на уровне блоков jungledisk синхронизация передает только небольшую часть данных за пределы площадки, но это все равно занимает не менее получаса.
Гораздо лучшим решением, конечно же, было бы что-то, что позволило бы мне мгновенно определить разницу в двух временных точках (скажем, то, что было написано с 6 утра до 7 утра), заархивировать его, а затем отправить этот файл разницы на сервер резервного копирования, который мгновенно перешел бы на удаленное хранилище в стойке. Я немного изучил zfs и его способность отправлять / получать. Это в сочетании с конвейером данных в bzip или чем-то еще может показаться идеальным. Однако кажется, что для реализации сервера nexenta с zfs по существу потребовалось бы по крайней мере один или два дополнительных сервера хранения для обслуживания блочных томов iSCSI (через zvol ???) для серверов proxmox. Я бы предпочел, чтобы настройка была минимальной, насколько это возможно (т. Е. НЕ иметь отдельных серверов хранения), если это вообще возможно.
Я также вкратце прочитал о зумасторе. Похоже, он тоже может делать то, что я хочу, но, похоже, он остановил разработку в 2008 году.
Итак, zfs, zumastor или другой?
Это может быть невозможно в вашей ситуации, поэтому я надеюсь, что в этом случае я не проиграю, но, возможно, было бы более эффективно изменить стратегию резервного копирования. Если вы создадите резервную копию определенных данных вместо моментальных снимков виртуальной машины, ваши резервные копии будут выполняться намного быстрее, и будет легче зафиксировать изменения.
В зависимости от ваших виртуальных машин и того, для чего они используются, вы можете просто сделать резервную копию данных, где вы сейчас храните моментальные снимки, ежедневно (или по любому подходящему расписанию), а затем JungleDisk может выполнять резервное копирование только данных. Это позволит более эффективно передавать измененные файлы, а пространство, необходимое для резервного копирования, а также время, необходимое для этого, уменьшится. Кроме того, вы все равно можете делать снимки для хранения, но делать это гораздо реже (например, еженедельно).
В этом случае вы всегда можете просто запустить новую виртуальную машину и восстановить данные или использовать более старый моментальный снимок для восстановления виртуальной машины, а затем использовать резервную копию данных для восстановления до самой последней точки.
Я не уверен, сколько архитектурных изменений вы планировали внести, чтобы повысить масштабируемость. Однако, если вы готовы переключить платформу виртуальных машин, вы можете взглянуть на VMWare.
Есть много хороших решений для резервного копирования VMWare, я лично использовал VzionCore. Затем вы можете сделать некоторые приятные вещи со снимками и восстановлением на определенный момент времени. Существует даже возможность переключения на удаленный сайт.
вы можете взглянуть на backuppc.
backuppc может работать поверх rsync, который выполняет инкрементное копирование.
Кроме того, вы можете легко написать черный список папок, резервное копирование которых не требуется. Например: temp / / tmp .garbages / ...
http://backuppc.sourceforge.net/
backuppc имеет чистый веб-интерфейс, позволяющий загружать некоторые части резервной копии непосредственно в виде zip-файла. Это можно отслеживать с помощью nagios с помощью check_backuppc.
Если бы я делал резервные копии вне офиса, я бы выбрал следующие варианты:
(a) сценарий оболочки, который копирует SCP на удаленный сервер. Таким образом, вы можете добавить задание cron, которое автоматически запускает сценарий, создающий резервную копию. Кроме того, вы можете сделать так, чтобы он создавал временный файл архива перед фактической передачей файлов, тем самым экономя пропускную способность, не передавая во время gziping.
или
(б) Установите инструмент управления сервером, например Webmin, и заставьте его выполнять автоматическое резервное копирование. В настоящее время я пою это на своих производственных серверах прямо сейчас без каких-либо проблем, он просто работает безупречно. Я также порекомендовал бы cloudmin (платный) для управления множеством виртуальных машин, поскольку он предоставляет комплексное решение.
несколько дополнительных ссылок:
http://www.debianhelp.co.uk/backup.htm
http://ubuntuforums.org/showthread.php?t=35087
Надеюсь, это поможет, RayQuang
zfs отлично справляется с этим, вы уже упоминали, что знаете об этом, а также о недостатке работы в масштабе 2 серверов. Это также не даст вам аварийного переключения DRDB, то есть Nexenta будет единственной точкой отказа.
Вы можете попробовать установить VirtualBox на OpenSolaris или NexentaCore, но не так просто, как ProxMox + DRDB, чтобы вы могли повторно использовать существующие машины.
Если вы измеряете свои изменения и находите их достаточно низкими, вы можете попробовать DRDB с третьим зеркалом за пределами площадки - он будет работать только в том случае, если количество операций записи на ваших виртуальных машинах крайне мало.
Стив Радич - Хостинг для Windows и производительность SQL с 1995 года - http://www.BitShop.com/Blogs.aspx
Я запускаю большой кластер proxmox и должен предложить вам изменить стратегию резервного копирования и отказаться от встроенных резервных копий в стиле моментальных снимков vzdump, которые занимают много времени, всегда полны, поэтому имеют большой размер и делают восстановление отдельных файлов чрезвычайно долгим.
Рассмотрим "гостевое" решение для резервного копирования файлов, которого существует множество. Backuppc, Urbackup, bacula, amanda и т. Д.
Это будет намного быстрее, займет гораздо меньше места и будет намного проще восстанавливать определенные файлы.
Думаю, я нашел окончательный ответ на свой вопрос:
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 !!!