Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 856 сообщений
Cообщения с меткой

резервное копирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[recovery mode] Примеряем дедупликацию и компрессию к резервным копиям

Четверг, 16 Июня 2016 г. 05:09 (ссылка)



Заморские купцы говаривали, что дедупликация может существенно сэкономить место, необходимое для хранения резервных копий. Что есть в заморских землях такие, кто годовую историю резервных копий хранят в том же объёме, что занят на рабочих серверах. Вроде как копируешь 10 Терабайт данных изо дня в день цельный год, а на устройстве хранения резервных копий те же 10 Терабайт и заняты. Брешут, наверное.



Однако, есть хороший способ проверить, как же данные многочисленных резервных копий конкретно наших серверов могут быть упакованы в хранилище с дедупликацией и компрессией. При этом не нужно разворачивать целую систему резервного копирования, а достаточно скачать одну маленькую (4 Мегабайта) утилиту, которая выдаст нам не только картину того, как можно пожать данные прямо сейчас, но и построит прогноз того, сколько памяти нам потребуется в будущем.







Для начала – качаем утилиту вот отсюда:



http://downloads.arcserve.com/tools/RPSPlanning/unsupported/DeduplicationPlanningTool/V1.0/ArcserveUDPDataStoreCapacityPlanningTool.zip



Хоть архив и небольшой, но утилита требовательная:


  • для работы нужна 64-битная система Windows (желательно, серверная. У меня на Windows 7 отработала нормально, всё посчитала и нарисовала, но при выходе свалилась).

  • каждые 100 Гигабайт сканированных данных могут потребовать при обработке статистики до 1 Гигабайта оперативной памяти на компьютере, где мы запускаем утилиту (это можно обойти, если использовать SSD вместо оперативной памяти).

  • должны быть открыты порты 10000 и 135 (какие — не уточняется, предположу, что TCP)

  • запускать её нужно из-под администратора





Если всё необходимое у нас есть, разворачиваем архив куда угодно и запускаем ArcserveDeduplicationAssessment.exe



Затем добавляем интересующие нас сервера в список обследуемых, нажав на кнопку “Add Node”:







После этого на указанный нами сервер будет удалённо установлена программа-пробник, которую можно увидеть в списке сервисов:







Кстати, по завершению работы с утилитой программу-пробник предложат удалить:







А пока запустим сбор статистики, нажав на кнопку “Scan Nodes”.



Кстати, сколько ресурсов у рабочего сервера отъедает сбор статистики?
В документации приведён пример, согласно которому сервер с процессором i7-4790, 3601 МГц, 4 ядра был загружен на 25-30% в течение 22 минут для обработки данных с диска в 199 Гигабайт.



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



Это можно изменить, если сбор статистики слишком затягивается.





На экране отображается процент выполненных работ на каждом из исследуемых серверов:







По завершению сбора статистики переходим на закладку 2 и строим отчёт. Имеет смысл отметить галочками все даты, когда была собрана статистика. Это позволит увидеть данные в динамике:







Теперь на закладке 3 мы можем воспользоваться полученными данными и, поиграв параметрами, определить потребность в объёмах хранилища резервных копий и конфигурацию сервера хранения резервных копий Arcserve UDP.



На примере ниже мы видим следующее:


  • Полные резервные копии двух исследуемых машин занимают 35,54 Гигабайта

  • Мы хотим хранить историю из 31 резервной копии

  • Каждая новая резервная копия отличается от предыдущей на 17%

  • Размер блока данных при дедупликации выбираем 4 Килобайта

  • Используем стандартную компрессию (без фанатизма, дли минимизации загрузки процессора)





На выходе получаем, что для хранения 31 резервной копии этих машин нам потребуется 76,85 Гигабайт памяти, что означает экономию в 94%:



(Также можно увидеть, какие требования будут к оперативной памяти сервера хранения резервных копий Arcserve UDP. В данном случае будет необходимо 1,19 Гб опративной памяти либо 0,06 Гб оперативной памяти в сочетании с 1,19Гб места на SSD-диске).







Нажав на “Show Details” увидим более подробную информацию.



Если мы делаем только полные резервные копии (“Full Always”), то дедупликация сократит их общий объём (1282,99 Гигабайт) на 91% до 118,90 Гигабайт.



Компрессия сократит этот объём ещё на 35%, то есть до 78,85 Гигабайт.







Если мы используем резервное копирование в режиме “Incremental Forever” (только инкрементные копии вслед за одной полной), то требуемое место для хранения резервных копий не изменится и также составит 78,85 Гигабайт. Просто нам придётся выполнить меньше вычислений для дедупликации, а следовательно, меньше будут загружены рабочие серверы:







Теперь посмотрим на закладку с графиками.



Выберем тип графика “Disk and Memory Usage Trend”.



Хорошо видно, что добавив к первой резервной копии в 35 Гигабайт вторую (тоже 35 Гигабайт), мы нуждаемся в 70 Гигабайтах памяти, как показано слева синим графиком.



Однако, если мы используем дедупликацию, потребности в памяти для резервных копий существенно сокращаются. Зелёный, оранжевый и фиолетовый графики показывают нам необходимые объёмы в зависимости от уровня компрессии, применяемой вместе с дедупликацией.



На правом графике видно, как растёт потребность в оперативной памяти (или оперативной памяти в сочетании с SSD-диском) на сервере хранения резервных копий Arcserve UDP.







Если мы выберем тип графика “Disk and Memory Usage”, то увидим, как влияет на потребность в памяти размер блока, применяемый при дедупликации. Видно, что увеличение размера блока несколько снижает эффективность дедупликации, но также уменьшает требования к быстрой памяти (оперативной или SSD) на сервере хранения резервных копий Arcserve UDP:







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



Описанная утилита включена в дистрибутив продукта Arcserve UDP, устанавливается вместе с ним в каталог “…\Program Files\Arcserve\Unified Data Protection\Engine\BIN\Tools\RPS Planning”, но может быть загружена и сама по себе, как указано выше.



Утилита не является поддерживаемым продуктом, то есть официально обратиться в техподдержку вы не сможете. Но это компенсируется её необычайной простотой и бесплатностью.



Больше узнать о продуктах Arcserve вы сможете, почитывая наш блог, и посетив ссылки, приведённые в правой колонке,
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303404/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] 20 самых заметных событий в истории резервирования и восстановления

Четверг, 09 Июня 2016 г. 05:04 (ссылка)





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



Впрочем, начнём с самого начала.



13.7 миллиардов лет до нашей эры – Вселенная возникла из сингулярности; те, кто верят в теорию «большого взрыва», предсказывают грядущую катастрофу…



3.8 миллиарда лет до нашей эры – Начало жизни на Земле. Считается, что первая клетка возникла из само-реплицирующейся РНК, позднее развившейся в ДНК. ДНК – это хранилище биологических данных, генетическая информация, которая позволяет всем современных живым существам функционировать, расти и воспроизводить себя. Или по-другому, мы – резервная копия наших родителей. Привет терапевту от меня.



65 миллионов лет до нашей эры – Динозавры, резервная копия не была сделана.







3200 лет до нашей эры – Изобретение письменности. Чтобы не забывать разные вещи, древние шумеры начали их записывать. Книги дают хороший показатель точки восстановления [RPO] (если у вас хороший летописец), но время восстановления [RTO] ужасно: средний взрослый человек читает со скоростью 300 слов в минуту, слишком медленно.



552 лет до нашей эры – Кир Великий помнил имена всех солдат своей армии, около 10 000 персов. Впечатляющее достижение для человеческой памяти, но и горький урок о единой-точке-отказа. Он был убит в 530 году до нашей эры, и информация исчезла вместе с ним.







48 лет до нашей эры – Пожар в Александрийской библиотеке. Среди прочих книг из «списка 10 самых примечательных утерянных книг за все времена», превратился в дым второй том поэтики Аристотеля, и человечество заподозрило существенный просчёт в своём хитром плане резервного копирования: бумага весьма легко воспламеняема.



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



1436 – Иоганн Гутенберг, бывший ювелир, создал первый печатный станок в Германии. Он воспользовался своими навыками в металлообработке для изготовления букв из металла, смачивал их в чернилах и создавал копию на бумаге. Это существенно ускорило создание копий, серьёзный шаг к восстановимости данных.



1539 – Копирование на основе образов, первые шаги. Генрих VIII, король Англии, для того чтобы решить, на ком жениться в следующий раз, послал художника Ганса Гольбейна сделать достоверную копию того, как выглядят европейские принцессы из его списка. На основе полученных образов Генри сделал выбор и предложил замужество Анне Клевской, но увидев её лично, понял, что представлял её совсем по-другому. Недостоверная / испорченная копия.







1937 – Изобретение фотокопировальной машины. Успешно и точно копирует документы с начала 20 столетия. Эй, что это за серые пятна на бумаге? И как насчет аварийного восстановления тропических лесов?



1949 – «Манчестерский Марк I» открыл эру компьютеров с хранимой в оперативной памяти программой, леса амазонского бассейна получили шанс на выживание.







1964 – Компьютеры выходят на массовый рынок. На Всемирной Ярмарке в Нью-Йорке публике был продемонстрирован компьютер «Programma 101». Один из таких компьютеров использовался на «Аполлон 11», и был, по сути… калькулятором. «Один маленький шаг...» (в то время!)



1972 – Мейнфреймы делают приложения и быструю обработку данных доступными сотням людей, встроенная аппаратная избыточность обеспечивает выдающиеся показатели восстановления (RPO и RTO). Древним Шумерам это бы дико понравилось.



1990 – Arcserve 1.0 выпущен компанией Cheyenne software. Эпоха распределённых вычислений находится на подъёме, главное – не забывать про резервное копирование на эти маленькие прямоугольные штучки, именуемые «ленты».



1998 – компания VMware основана в городе Пало Альто, штат Калифорния. Хотя концепция гипервизоров берёт начало из 1960-х, именно VMware вывела виртуализацию на массовый рынок. Виртуализация перевернёт резервное копирование и аварийное восстановление.







2006 – Технология WANsync компании XOsoft интегрирована в Arcserve. Впервые на рынке для средних компаний появилось единое решение для резервного копирования и мгновенного переключения на резервную систему.



2008 – Microsoft выпускает продукт, конкурирующий с VMware, и называет его Hyper-V. Если вы ещё не были виртуализованы, то сейчас будете. Специфическое программное обеспечение для резервного копирования виртуальных систем существует, но слабо интегрировано с физическими серверами, копированием на ленту и не является кроссплатформенным для Microsoft/Linux.







2014 – Продукт Unified Data Protection (UDP) выпущен компанией Arcserve. Он был специально разработан для виртуальных сред, VMware, Hyper V и Xen, оставаясь удобным и функциональным и на физических серверах. UDP предоставляет возможность копировать образы дисков и файлы, выполнять репликацию данных приложений и горячую замену на резервный сервер. UDP предоставляет расширенную функциональность при работе с лентами; совместим с Windows и Linux, физическими и виртуальными; копирует и выполняет аварийное восстановление с дисков, лент и из облака при помощи единой консоли; RPO = 0. RTO = 0.



2015 – Arcserve UDP завоёвывает три награды на VMWorld 2015, включая «золотую награду за аварийное восстановление и резервное копирование в виртуализованных средах », “лучший проект аварийного восстановления” и “лучшие на шоу”.







2016 – Вы находитесь здесь.



Марсоход NASA «Кьюриосити» находит подтверждение существования древней цивилизации на Марсе:







Зарегистрируйтесь здесь, чтобы увидеть демонстрацию работы продукта Arcserve UDP.



Или скачайте Arcserve UDP здесь.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/302952/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ОГОЛЬ

Урок: "Резервное копирование в 1 клик (видео)"

Пятница, 27 Мая 2016 г. 16:50 (ссылка)

Это цитата сообщения EFACHKA Оригинальное сообщение

Урок: "Резервное копирование в 1 клик (видео)"




3424885_ (684x433, 61Kb)



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



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



Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Конструкция и принципы работы Arcserve UDP – программного продукта для резервного копирования и восстановления данных

Четверг, 26 Мая 2016 г. 15:52 (ссылка)




Эта статья написана для тех, кто хочет познакомиться, а возможно и попробовать в действии современный продукт для резервного копирования и восстановления данных Arcserve Unified Data Protection, или коротко, Arcserve UDP. Продукт можно без проблем загрузить с сайта разработчика – www.arcserve.com и спокойно гонять в течение месяца без всяких лицензионных ключей. Но не всё в нём лежит на поверхности, поэтому позвольте мне разъяснить некоторые тонкости архитектуры и функционирования Arcserve UDP.



Читать дальше →

https://habrahabr.ru/post/301854/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Veeam Backup & Replication: workaround для одной проблемы с метаданными backup job

Вторник, 10 Мая 2016 г. 23:36 (ссылка)

Disclaimer практически

При написании сего текста автор руководствовался следующими ключевыми моментами:

0. Большому количеству уважаемых многоопытных коллег всё это покажется мелким и не заслуживающим внимания. Facil omnes, cum valemus, recta consilia aegrotis damus.

1. Какому-то — пусть и небольшому — количеству уважаемых менее опытных коллег будет полезно/нужно/небезынтересно.

2. Намёки на приспособление для поддержания веса тела пациента при стоянии и ходьбе имеют право на существование, поскольку workaround он потому и workaround.

3. Гугль не знает или я плохо искал. Но честно старался.

4. Опыт в написании чего-то подобного первый, отсюда и комки в текстуре.



Приветствую, уважаемое сообщество.



Преамбула



В инфраструктуре нашей компании существует три параллельных ветви серверов Veeam B&R. Ветви, как у нас любят объяснять практически любые казусы, «исторически сложились».



Одна обслуживает backup job'ы медленно сходящей на нет фермы виртуализации, оставшейся после слияния компаний.

Вторая была опытно-промышленным внедрением Veeam B&R, плавно ставшим решением промышленным и на данный момент обслуживает backup и replication job фермы виртуализации vSphere 4.1 (да, всё ещё в эксплуатации, извините) и backup job фермы виртуализации vSphere 5.5.

Третья обслуживает исключительно replication job' и failover plan'ы фермы виртуализации vSphere 5.5.

Всё это находится в процессе живой и непрекращающейся миграции.

Честь и счастье администрировать всё это богатство в течение последних ~5 лет выпала мне, как основному администратору виртуализации VMware vSphere, Veeam B&R и серверов Wintel.

+ Есть коллега на роли администратора запасного.







В ходе недавней подготовки к тестированию DR-решения, основанного на репликации виртуальных серверов средствами Veeam B&R, было выявлено непонятное нам несоответствие между количеством виртуальных серверов, входящих в состав backup и replication job'ов и сведениями о количестве точек восстановления у этих серверов.

Сведения о количестве точек получались через powershell с использованием Veeam Backup & Replication Powershell snapin.

Выборочная проверка количества точек запросом через веб-интерфейс Veeam Backup Enterprise Manager показала аналогичное расхождение с реальностью.

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

Да и беспокоит, зудит — ну не аккуратненько же. Надо починить.



Запасной администратор в данный момент тренируется с ТП Veeam по открытому кейсу, исследуя проблему в рамках replication job'ов.

Я решил покопаться в части backup job'ов на другой ветви Veeam B&R дабы не искажать картину, исследуемую ТП вендора.



Момент возникновения расхождений и их причины пока для нас неясны. При точном ответе от ТП Veeam внесу апдейт в текст.



Пока я для себя принял рабочую гипотезу, что неоднократные in-place upgrad'ы Veeam B&R начиная с версии 7 до текущей версии 9 update 1, неоднократные изменения настроек существующих job'ов и т.п. процессы не прошли даром и, предположительно, БД Veeam B&R накопила «мусора», дублирующихся записей в таблицах.

В качестве СУБД используется MS SQL, теоретически можно порыться в структуре базы, но, перефразируя Арамиса, "… но, право, я не DBA...".



Выборочная проверка серверов из состава backup job'ов показала, что с данными о точках восстановления всё столь же запущено.

Приведу пример:

Некий виртуальный сервер имярек входит в состав задания Veeam Backup & Replication. Согласно сведениям, отдаваемым Veeam Backup Enterprise Manager’ом, имеет 36 точек восстановления.





При этом свойства backup job'а в части количества хранимых точек не изменялись никогда – т.е. от момента создания job’а ещё в версии Veeam B&R 7 – и всегда было равно 7 для описываемого задания.

Раскрываемый список 36 restore point’ов выглядит вполне «рабочим» — никаких fail'ов, unaccessible-частей или чего-то ещё, наводящего на мысли о порче проблемах с точками, не видно:








Восстанавливать виртуальные машины из точек с датами, явно выходящими за обозначенное в свойствах задания количество хранимых, не пробовал. В основном из-за отсутствия времени на эксперименты. Отсутствие времени вообще было решающим фактором при поиске выхода из ситуации — сразу после невозможности останавливать выполнение backup job'ов на неопределённый срок для экспериментов.

КМК, при попытке восстановления был бы fail, поскольку физически в репозитории лежит 1 full backup, 6 incremental backup’ов и файл метаданных — то есть в наличии реально 7 точек, отсчитывая от текущего дня. Для 10 мая самая ранняя хранимая точка была бы создана 3 мая. А всё, что по датам создано раньше, реально не существует и живёт только в БД Veeam B&R.

Вот содержимое репозитория для рассматриваемого backup job'а:





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





Большинство заданий имеют файлы бекапа такого размера, что переносить их просто некуда + N ТБ архивов копироваться будут длительное время, задание на это время нужно остановить, а простой бекапов недопустим. Поэтому вариант с переносом файлов бекапа на другой репозиторий с последующим выполнением rescan repository и map backup в настройках задания не был принят как лучший выход из положения. По той же причине нельзя всё удалить, поставить заново, восстановив настройки Veeam B&R из регулярно создаваемой резервной копии.



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



И, пусть не слишком изящный, но он был нащупан.

Алгоритм примерно следующий:



1. В репозитории, содержащем файлы бекапа, меняем расширение в имени файлов

— full backup

— backup chain metadata file

Note. Переименование / перенос на другой репозиторий одного backup chain metadata file с последующим rescan'ом репозитория не помогает.





2. Выполняем Rescan для репозитория, содержащего файлы бекапа. Видим, что один бекап был удалён из базы.





3. Возвращаем расширение в имени файлов full backup и метаданных в репозитории на исходную позицию.



4. Выполняем повторный Rescan для репозитория, содержащего файлы бекапа. Видим, что один бекап был добавлен в базу.





5. Проверяем виртуальный сервер имярек ещё раз и видим количество точек восстановления, соответствующее настройкам задания и количеству файлов в репозитории.





Повторюсь, что решение далеко от изящества. При большом количестве job’ов существенно большем от примерно 70 в моём случае пришлось бы искать иной способ — от скриптов до переустановки сервера Veeam B&R.



Приветствуется тыкание носом в не найденные решения, kb, мнения, предложения так далее — fas est et ab hoste doceri.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/283276/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Установка CrashPlan в Docker-контейнер на NAS Synology

Среда, 27 Апреля 2016 г. 15:37 (ссылка)





Те, кто любит устройства от Synology и отличный сервис резервного копирования CrashPlan уже много лет кувыркаются, пытаясь настроить его надежную и бесперебойную работу на хранилище. С приходом Docker на Synology появился свет в конце тоннеля.



Прелюдия



Большие домашние хранилища от Synology усыпляют бдительность. Они кажутся надежными и безотказными. Там есть RAID, который защищает от сбойных дисков. Там есть «Time Backup», который отлично сохраняет версии файлов и позволяет их легко восстанавливать. Однако, настоящие параноики, чтущие Нассима Талеба, всегда помнят о редких, но неприятных событиях, которые могут случится с вашими данными, да и самим хранилищем:




  • Пожар или кража. Хранилище пропадает целиком, вместе с вашими оригиналами и их резервными копиями на соседнем разделе;

  • Шифрующие вирусы. Живой пример — вирус SynoLocker, доставивший пользователям много страданий. Он проникал через дыру в DSM (ОС от Synology, под управлением которой работает это сетевое хранилище). Шифровал там все файлы и вымогал деньги. Ну, всё как обычно.

  • Что-то ещё.



Исходя из этого, каждому здравомыслящему параноику понятно, что нужно прятать резервные копии всех важных данных (детские фотографии, например) подальше в облака. Разработчики это тоже понимают. В DSM есть пакет «Cloud Sync», который позволяет копировать ваши данные в удаленные облачные хранилища. К настоящему времени поддерживается много облачных сервисов:




  • Облачное хранилище Amazon, Amazon S3, Облачные сервисы, совместимые с Amazon S3, Baidu Cloud, Box, Dropbox (в том числе Dropbox for Business), Google Cloud Storage, Google Диск (в том числе Google Drive for Work), hicloud S3, HiDrive, hubiC, IBM SoftLayer, Megafon Megadisk, Microsoft OneDrive (в том числе Office 365 и OneDrive for Business), Облачные сервисы, совместимые с OpenStack Swift, Rackspace, Резервное копирование SFR NAS, WebDAV, Яндекс Диск.



Однако, по непонятной мне и многим пользователям причине, не поддерживается облачный сервис специально заточенный под резервное копирование — CrashPlan. Он любим за свою надежность, безлимитность и недорогие тарифы. Поэтому, долгое время сообщество прикручивает этот сервис к Synology скотчем и степлером. Так, Patrick Moore (мой герой!) с 2012 года поддерживал и постоянно допиливал свой пакет CrashPlan, работающий на хранилище. Но, похоже, в 2015 году он окончательно устал.



Шаги по спасению мира и запуску CrashPlan в Docker-контейнере на Synology



Пришлось поднять голову и оглядеться вокруг. К этому времени, на Synology появился Docker (не на всех версиях) и теперь есть возможность запустить CrashPlan в Docker-контейнере, где он будет успешно жить и самостоятельно обновляться. Его установка и настройка не вполне очевидны. Надеюсь, что короткая инструкция ниже поможет вам набить чуть меньше шишек, чем мне. Она скорее для чайников, ибо профессиональные linux-админы уже у себя дома давно всё настроили.



Итак, следующая последовательность действий, позволит вам запустить и управлять своим клиентом CrashPlan в Docker-контейнере, который бежит на Synology:



1. Создаем на своем хранилище новую папку общего доступа. Например: «crashplan-symlink». Именно эту папку будет видеть CrashPlan из контейнера. Она одна должна содержать все данные, которые будет обрабатывать CrashPlan. Можно переложить все важные данные непосредственно в неё, но лучше создать там подпапки «music-symlink», «photo-symlink», «homes-symlink» и определить их как симлинки на реальные папки хранилища. Это тоже работает.







2. Создаем на хранилище новый файл /etc/rc.local и прописываем в него команды для монтирования симлинков с настоящих папок (фото, видео, и пр.) на вложенные папки в нашей новой папке общего доступа. Файл «rc.local» нужно использовать потому, что иначе симлинки не выживают при перезагрузке хранилища. Если есть затруднения, см. ниже «Удобное управление файлами на хранилище». Вот, что у меня сейчас в этом файле:



mount --bind /volume1/bittorrentsync /volume1/crashplan-symlink/bittorrentsync-symlink
mount --bind /volume1/homes /volume1/crashplan-symlink/homes-symlink
mount --bind /volume1/music /volume1/crashplan-symlink/music-symlink
mount --bind /volume1/photo /volume1/crashplan-symlink/photo-symlink
mount --bind /volume1/public /volume1/crashplan-symlink/public-symlink


3. Ставим на Synology пакет «Docker». Далее запускаем его после установки, ищем в реестре контейнер crashplan («jrcs/crashplan» — hub.docker.com/r/jrcs/crashplan) и также устанавливаем его.







4. При начальном конфигурировании контейнера «jrcs/crashplan» важно запомнить предложенное соответствие портов (если выберем автонастройку) или вручную задать соответствие двух портов необходимых для работы и управления CrashPlan. Например, вот так: порт «4243» назначить на «32774», а «4242» на «32773». Открываем дополнительные настройки контейнера и там прикрепляем нашу созданную на первом шаге папку общего доступа «crashplan-symlink». Ставим ей в соответствие значение "/storage", так она будет доступна из докер-контейнера.





5. Перегружаем хранилище. Убеждаемся, что наши симлинки в папке «crashplan-symlink» выжили и работают. Запускаем в докере пакет «jrcs/crashplan». Если все правильно, то к данному моменту мы имеем запущенный и работающий докер-контейнер внутри которого уже успешно запущен и работает клиент CrashPlan. Однако, сам клиент ещё не настроен. Ему нужно сказать, что и откуда брать и куда копировать, а для этого нужно подключиться к клиенту, через специальное приложение CrashPlan (есть и для Win и для Linux). Однако, просто так подключиться к клиенту приложение не сможет, там все шибко безопасно, поэтому квест продолжается.







6. Для того, чтобы иметь возможность подключиться к клиенту CrashPlan, нужно вытащить из специального файла в докер-контейнере строку содержащую секретный ключ. Для этого, подключаемся к хранилищу через SSH (например, клиентом PuTTY). Находим файл ".ui_info". Он лежит где-то по этому пути "/var/packages/Docker/target/docker/volumes/464...../_data/id". В этом файле есть текстовая строка с секретом (сначала идёт адрес порта, потом нужный нам секрет, потом ip-адрес). Так в примере ниже, нам нужно взять строку: «05bv99x3-36f8-43e6-92c7-4b8776f2edb2».



4243,05bv99x3-36f8-43e6-92c7-4b8776f2edb2,0.0.0.0


7. На локальном компьютере ставим управляющее ПО от CrashPlan. Затем ищем там файл ".ui_info" (для Windows он лежит в папке «C:\ProgramData\CrashPlan») и редактируем его руководствуясь следующими правилами:

— На первой позиции в строке идёт порт, который в контейнере «jrcs/crashplan» поставлен в соответствие порту «4243». Так, если настройки были указаны как на шаге 4, то пишем «32774».

— Далее идет секретный ключ, который мы вытащили из контейнера на шаге 6.

— Последнее значение ip-адрес нашего хранилища, где запущен и работает клиент CrashPlan, т.е. которым мы хотим управлять. Если на Synology запущен QuickConnect, то в его настройках можно посмотреть внешний ip-адрес хранилища («Панель управления» — «Внешний доступ»).



В результате, строка в локальном файле ".ui_info" должна стать примерно такой:



32774,05bv99x3-36f8-43e6-92c7-4b8776f2edb2,192.168.1.100


8. Если всё сделано верно, то при запуске управляющего ПО от CrashPlan на локальном компьютере, он обращается по заданному ip-адресу на заданных порт хранилища (в нашем примере на 192.168.1.100 на порт 32774). Хранилище переадресует запросы на порт 4243 в контейнер «jrcs/crashplan», где бежит headless-клиент CrashPlan. Если секретный ключ совпадает, то всё ОК и подключение выполняется.



9. В приложении мы должны увидеть папку «storage» внутри которой будут созданные ранее подпапки-симлинки, а в них все наши данные. Вводим нашу лицензию, выбираем необходимые данные и начинаем их резервное копирование в облако CrashPlan. Кстати, у CrashPlan есть хорошие мобильные приложения, которые позволяют следить за этим процессом.







Полезные советы





1. При первоначальной установке и при переустановке клиента CrashPlan на хранилище у него меняется GUID. Если у вас уже есть резервная копия данных на серверах CrashPlan, то для того, чтобы прикрепиться к уже существующему бекапу, нужно использовать функцию «ADOPT» (такое предложение появится в клиентском приложении после успешного подключения). В противном случае, создание резервных копий начнётся заново и при больших объемах это занимает кучу времени.



2. Удобное управление файлами на хранилище. Проще всего управлять файлами на Synology через «Midnight Commander», его можно поставить на хранилище. Для этого необходимо:

— В «Центре пакетов» перейти в «Настройки» и добавить новый источник пакетов. Название: «synocommunity». Местоположение: «packages.synocommunity.com».

— Перейти в «Центре пакетов» в категорию «Сообщество», найти там «Midnight Commander» и установить его.

— Скачать и установить PuTTY.

— Включить SSH на Synology («Панель управления» — «Терминал и SNMP» — «Включить службу SSH»).

— Получить IP-адрес своего хранилища. Если на Synology запущен QuickConnect, то в его настройках можно посмотреть внешний ip-адрес — хранилища («Панель управления» — «Внешний доступ»).

— Выполнить вход на хранилище через PuTTY указав логин 'admin' и текущий пароль. Если требуются права 'root' и расширенный доступ к файловой системе (наш случай), то нужно ввести в терминале команду 'sudo -i' и повторить пароль (инструкция от Synology).

— Поскольку мы ранее установили пакет Midnight Commander, то команда 'mc' в терминале запустит его. В результате получаем доступ ко всем файлам на устройстве.



Полезные ссылки:





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282580/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сетевой протокол для резервного копирования данных в сетях с задержками и потерями пакетов

Понедельник, 25 Апреля 2016 г. 14:00 (ссылка)

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

Передача данных на расстояния в тысячи километров занимает несколько сотен миллисекунд, а часть пакетов просто не доходит до адресата — теряется по пути. Задержки и потери пакетов губительно сказываются на производительности транспортного протокола TCP, который обычно используется в сети Интернет. К примеру, вы находитесь в Москве и хотите создать резервную копию файла размером 3ГБ. Передача этого файла на сервер, который находится в пределах города, займет 10-15 минут. Теперь, если вы захотите восстановить этот файл, находясь вдали от дома, скажем в Китае, передача этого же файла по сети с задержкой порядка сотен миллисекунд займет уже несколько часов.







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



Давайте рассмотрим существующие способы решения нашей проблемы. Во-первых, это использование сетей передачи и дистрибуции контента (CDN). При этом данные размещаются на нескольких территориально распределенных серверах, что сокращает сетевои

https://habrahabr.ru/post/282157/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Разделение конфигурации хоста и пользователей в 3CX Phone System v14

Суббота, 24 Апреля 2016 г. 00:29 (ссылка)

В 3CX Phone System v14 в целях обеспечения отказоустойчивости и легкой миграции пользовательских АТС было сделано разделение между конфигурацией сервера (хоста и сети), на котором работает система и конфигурацией конкретной пользовательской АТС. Это позволяет решить ряд важных задач:




  • В случае системного сбоя быстро перенести конфигурацию АТС организации на другой подготовленный сервер.

  • Легкая миграция АТС организации с локального сервера в облако (на виртуальную АТС) и обратно.

  • Удобство предварительного тестирования обновлений системы благодаря простому переносу рабочей конфигурации на тестовый сервер.



Перенос конфигурации АТС между серверами можно сравнить с миграцией виртуальных машин между супервизорами. Конфигурация пользовательской АТС — параметры добавочных номеров, IP телефонов, правила маршрутизации и т.п., теперь не зависит от сетевого окружения сервера, на который переносится АТС. Используя автоматическое обновление DNS, можно восстановить или перенести систему практически незаметно для пользователей.



Возможны следующие типы миграции АТС организации (см. рис.)




  • С хоста А на хост B

  • C хоста B на хост А

  • С хоста А или B на 3CX Virtual PBX (в любой свободный слот)

  • С 3CX Virtual PBX на хост A или B



Рассмотрим подробнее, что включает в себя конфигурация хоста и конфигурация пользовательской АТС.

Конфигурация хоста



Конфигурация хоста содержит информацию, которую вы указали при первой установке 3CX Phone System на сервер, и некоторые параметры, указанные после инсталляции сервера в консоли управления 3CX. Параметры хоста разделяются на статические и динамические.

Статические параметры



Статические параметры хоста не могут быть изменены после установки сервера 3CX. Для их изменения необходима переустановка сервера.




  • Режим установки – Split DNS / внутренний внешний FQDN / внутренний IP

  • Используемый веб сервер (IIS или Abyss)

  • Порты веб сервера

  • FQDN имя

  • Самоподписанный SSL сертификат безопасности



Динамические параметры



Динамические, т.е. изменяемые параметры хоста, могут быть изменены администратором после установки сервера. Однако, в некоторых случаях потребуется изменение настроек сетевого экрана или повторная автонастройка IP телефонов.




  • Внешний IP адрес

  • SIP и RTP порты

  • Порт и пароль 3CX туннеля

  • Параметры почтового сервера

  • E-mail адрес администратора



Конфигурация пользовательской АТС



Конфигурация пользовательской АТС содержит все параметры конкретной системы 3CX, включая имя пользователя и пароль администратора. Поэтому учетные данные администратора АТС также переносятся на другой хост. В конфигурацию входят:




  • Пользователи (добавочные номера)

  • Группы и права пользователей

  • Данные об IP телефонах и параметры автонастройки

  • Системные добавочные номера – очереди и группы вызовов, голосовые меню и голосовая почта

  • Общие параметры системы (раздел АТС интерфейса)

  • Адресные книги

  • Конфигурация SIP транков и ТфОП шлюзов

  • Настройки входящих и исходящих правил

  • Имя пользователя и пароль администратора АТС



Пример переноса конфигурации



Как было сказано, при переносе конфигурации АТС на новый сервер конфигурация хоста не переносится. Поэтому, если вам необходимо перенести АТС на хост, использующий SIP порт 6060, действуйте следующим образом:




  • Установите АТС и пройдите мастер первоначальной настройки

  • Войдите в консоль управления и в разделе Параметры – Сеть – Порты укажите новый SIP порт

  • Восстановите резервную копию системы, в соответствии с документацией



Дополнительная информация







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282287/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<резервное копирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda