Итак, мы успешно прошли процесс установки (ну я надеюсь на это) сервера и агентов для копирования.

Теперь по порядку выполняем подготовительные действия для начала бекапа данных.

Первое — определяем ЧТО мы будем бекапить. Создаём savepack: Backup — What To Backup.

Итак, представим себе задачу. Начальство озадачило админа бекапом. Допустим это пара линуксовых серверов, один из которых с самбой для 1C, а второй веб-сервер с магазином.

Сделать всё нужно:

а) дёшево, а лучше бесплатно,

б) быстро.

Краткая информация:

Тип резервного копирования: полная копия, на уровне гостевой ОС

Гранулярность: образ, файлы (только для агента)

Платформы: Citrix XEN, Opensource XEN

Предположим что у Вас уже установлена система NexentaStor и создан том-другой.

В моём случае это простой небольшой том raidz размером 16ГБ.

Бухарест, Румыния – 3 ноября 2010 – Axigen, производитель профессионального почтового решения (http://www.axigen.com), и Молдтелеком, национальный телеком оператор в Республике Молдова (http://www.moldtelecom.md), объявили запуск портала Webmail.md, бесплатного почтового сервиса на базе решения Axigen. Webmail.md доступен в нового пакета онлайновых услуг и приложений разработанных на платформе My Moldtelecom.

Свыше 7,000 предприятий в 70 странах выбрали Arkeia как решение для резервного копирования. Заказчики заявляют что широкая и глубокая поддержка Linux и открытого кода, поддержка корпоративных стандартов, гибкость архитектуры, доказанная надёжность и поддержка мирового уровня - это главные причины почему они выбрали Arkeia.

Автор: Виталий Сайфуллин

Я помню те времена когда впервые столкнулся с проблемой архивирования своих данных. Помнится, всё начиналось достаточно радужно. Тогда винчестер на 120МБ был запредельным счастьем на которое влазил Turbo C, Borland C++, несколько игрушек, а иногда даже и Windows 3.11 с Word 6.0. Обычно бэкап всего необходимого влазил на одну дискету 1.44МБ и состоял из документов и пары десятков файлов с исходниками. Занимало пять минут времени и не требовало автоматизации, ибо все файлы были наперечёт и отследить что появилось нового не было проблемой.

Потом ситуация стала ухудшаться, количество файлов по делу и просто так росло, появилась клятая Win95 (её как dos с дискетки не восстановишь), начал набирать популярность формат mp3. Бэкап стал проблемой, любимая музыка требовала носителей больше чем 1.44МБ, приходилось клянчить у везунчиков-с приводы cd-rw и покупать весьма дорогие оптические носители. Но и это было не главное. Возникла животрепещущая проблема недостатка жёсткого диска. И проблема возникала независимо от объёма самого диска. На лицо была ситуация когда скорость роста объёмов данных существенно превышал скорость роста объёмов носителей. Привод для оптических дисков стал не роскошью, а суровой необходимостью. Ведение архивов стало рутинной задачей.

NexentaStor легко интегрируется в сети передачи данных (SAN) как хранилище iSCSI или FC. Для такой интеграции используется  объект называемый производителем "zvol". В действительности многие пользователи NexentaStor считают что zvol это мощный инструмент для виртуализации их хранилищ.

Вполне ожидаемое замедление может произойти если на zvol для iSCSI отключен так называемый "writeback cache". Если для LUN отключено кеширование, то каждая запись на устройство будет ожидать фактической записи. Это может отбросить производительность до нескольких десятков МБ в секунду.

Дополнительно почитать: Почему у меня очень плохая скорость записи на тома zvol по iSCSI (COMSTAR)?

Скажу сразу - Syncsort не поддерживает выполнение резервных копий через механизм vStorage. Ему это не нужно. Если на этом моменте Вам ещё интересно, то дальше вы узнаете почему.
Много лет бекап виртуальных машин был головной болью. Инфраструктура есть, а толковых механизмов для снятия копий — нет. Существовало два способа снятия резервных копий:
• через установленного внутрь виртуальной машины агента;
• посредством технологии VCB.

Те кто уже является пользователем системы хранения NexentaStor наверняка знают о двух типах доступа к данным — через сетевые протоколы и через сеть SAN/iSCSI.

Для незнакомых с системой позволю некоторое пояснение.

Для каждого типа доступа используется свой тип контейнера данных.

В частности, для организации доступа пользователей к данным, например, через протокол FTP используется папка (Folder). В этом случае на одном томе данных может лежать множество папок, каждая со своим протоколом доступа и списком ACL.

Если же доступ к данным организуется для сервера через сеть SAN/iSCSI, то хранилищем выступает весь том ZVOL и разграничение прав доступа осуществляется уже операционной системой.

Тесты скорости могут быть полезны по разному. Они особенно эффективны когда хочется проверить архитектурный дизайн. В данном случае имеем SUN X4500 как таргет iSCSI и сервер VMware ESX 3.5 с инициатором QLA4050c. Этот тест не является измерением максимальных возможностей архитектуры X4500 или других компонент, это проверка что вся система работает как и ожидается в контексте текущей конфигурации. В этой конфигурации есть несколько компонент с ожидаемыми ограничениями, как например сетевой коммутатор и его степень буферизации и контроля потока. Так же необходимо понимать что любая конфигурация iSCSI будет иметь характерную точку схлопывания и как следствие задержки в моменты пикового насыщения пакетами. В данной архитектуре мы можем ожидать некоторые специфичные ограничения, такие как эффективность использования 60% канала сетевого контроллера 1Gb до того как проблемы задержек станут ощутимыми. Дополнительно, при использовании дисков с интерфейсом SATA можно ожидать что большое количество мелких операций ввода-вывода приведёт к менее эффективным характеристикам производительности в случае когда такое поведение продолжительно или проявляется слишком часто.