• Как начать использовать аппаратное шифрование SSD-диска на примере Samsung EVO 850 и программы sedutil
    0
    Рад, если смог помочь.
    Не могу отделаться от ощущения, что вы уже начали шифровать («как завадался...»).
  • Как начать использовать аппаратное шифрование SSD-диска на примере Samsung EVO 850 и программы sedutil
    0
    Вы правы. Но статья не о том, как правильно зашифровать данные, а скорее из разряда: «Вот прикупил себе SSD. Чего это у него там такое? Встроенное шифрование? А как его включить? В инструкции нет ничего. Это что же, я за это заплатил, а оно лежит мёртвым грузом и не работает? Непорядок!».
    По крайней мере, у меня это так было.
  • Как начать использовать аппаратное шифрование SSD-диска на примере Samsung EVO 850 и программы sedutil
    0
    Лично для меня это означало бы необходимость апгрейда с Windows 7 Professional до Ultimate. Поэтому я его не рассматривал, и особо ничего рассказать про него не могу. Может, кто другой напишет.
  • “А шо эта ваш бэкап такой уставший?”*
    0
    Хорошо, сдаюсь. Если у вас 50 серверов и вы хотите одним махом настроить на всех пятидесяти репликацию данных, то 50 раз «кликать «next, next, next»», а в конце понять, что один из параметров был задан неверно — очень непрактично и тоскливо.

    К счастью, кроме обвязки для PowerShell, у нас есть ещё Web API, который позволяет выполнить такое. См., например:
    arcserve RHA Control Service Web API Reference Index: https://arcserve.zendesk.com/hc/en-us/articles/202810715
    arcserve RHA Control Service API User Guide: Lesson 1 Environment Setup/Requirements and Creating a Session: https://arcserve.zendesk.com/hc/en-us/articles/202041319

    Кроме того есть возможность экспорта/импорта сценариев в/из XML-файлы. То есть можно этот файл генерировать в вашем средстве автоматизации, а потом закачивать в Arcserve RHA.
  • “А шо эта ваш бэкап такой уставший?”*
    +1
    Я сейчас одну вещь скажу, Вы только не обижайтесь. Мне кажется, что у Вас индустриальное означает брутальное. То есть если софт суровый, с командной строкой, то он индустриальный. А если с картинками — то игрушка.
    Вот как по вашему, если у ленточной библиотеки есть веб-интерфейс с графикой — это уже несерьёзно?
    А если у маршрутизатора надо писать «wr mem» то это индустриально, а если нажать на кнопку «Сохранить» на веб-интерфейсе, то это пошло?
    Мне тоже нравится многое делать в командной строке. Но вот файл «sendmail.cf» считаю лично для себя неудобным. Предпочитаю заполнить формы какие-нибудь.
    Короче говоря, каждый выбирает для себя, и всё хорошо в меру.
  • “А шо эта ваш бэкап такой уставший?”*
    +1
    Не вводите людей в заблуждение. Seafile и ownCloud – это программы той же категории, что и DropBox, OneDrive, Google Drive и т.д. То есть предназначены, главным образом, для периодической синхронизации данных на клиентской машине/телефоне с хранилищем на сервере.

    Это накладывает отпечаток на их способ работы. В частности, ownCloud периодически сканирует локальные файлы, чтобы понять, кого их них нужно отправить на сервер.

    А Seafile, хоть и использует inotify для мгновенного оповещения о том, что с файлами что-то произошло, должен потом этот файл просканировать и определить, что же это было. Кроме того, он вносит дополнительное звено – репозитарий (как у Git), который должен сначала обновиться локально, а уж потом синхронизироваться с серверным.

    Сравните это с модулем ядра (linux) или filter-driver в Windows, используемые Arcserve RHA, которые СРАЗУ знают, какие данные в файле изменились, а не пересканируют его, чтобы понять, что же произошло.

    И скажите, как могут Seafile или ownCloud при их подходе в реальном времени реплицировать один большой файл, в который постоянно вносятся изменения (базу Exchange или Oracle или SQL, как в примере 3.2 из статьи?
  • “А шо эта ваш бэкап такой уставший?”*
    0
    Пообщался с разработчиками. Они говорят следующее:

    После того, как на UNIX/Linux запускается сценарий репликации, мы монтируем файловую систему XOFS поверх существующей файловой системы. Команда ‘mount’ будет показывать 2 файловых системы: старую и новую (XOFS).

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

    Мы перехватываем всё, что касается создания, удаления, записи, mkdir, rmdir, change attr, mklink и т.д. Мы сбрасываем все эти события в журнал, вместе с данными, которые пишутся. Затем процесс в пользовательском режиме подхватывает этот журнал, переформатирует и пересылает на удлённую машину-реплику. Реплика получает, обрабатывает и повторяет действия из журнала.

    Работа XOFS не зависит от того, какого типа файловая система находится под ней. XOFS просто транслирует вызовы и возвращает коды возврата. Но если появится новый тип файловой системы, для которой появятся новые системные вызовы, то XOFS также потребует доработки.
  • “А шо эта ваш бэкап такой уставший?”*
    +1
    Вместе с продуктом поставляется оснастка для PowerShell. Многие вещи удобно выполнять из командной строки, например:

    Set-Bookmark — установить закладку, на которую потом можно будет откатиться во времени

    Suspend-Scenario / Resume-Scenario — приостановить/продолжить работу сценария (для выполнения сервисных работ, например)

    Но я не сторонник радикальных мер. Что-то удобнее делать в командной строке, а что-то — в графическом интерфейсе. Поиск точки на временной оси, на которую нужно откатиться, мне однозначно удобнее делать в графическом интерфейсе.
  • “А шо эта ваш бэкап такой уставший?”*
    0
    Поторопился я. Имеется в виду загружаемый модуль ядра, который служит прослойкой при обращении к файловой системе.
    Находится в RedHat и SUSE вот здесь:
    /opt/CA/ARCserveRHA/kernel/fs/xofs.*
    Подробнее см. http://documentation.arcserve.com/Arcserve-RHA/Available/R16-5/ENU/Bookshelf_Files/HTML/UL/Files_Installed_on_Red_Hat_and_Novell_SUSE_Linux_Enterprise.html
  • “А шо эта ваш бэкап такой уставший?”*
    0
    Есть возможность оценить, с какой скоростью нужно будет передавать данные с одной системы на другую. Это так называемый «Assessment Mode» — реальная репликация не производится, но собирается статистика (например, в течение суток). Если вы видите, что скорости не запредельные, что их потянет и сеть, и система ввода-вывода, то можно запускать репликацию.
    Но, конечно, всё хорошо в меру. Всегда найдётся какая-то система, которая может ввести в ступор. Приходит в голову игра «жизнь» на всех блоках данных диска…
  • “А шо эта ваш бэкап такой уставший?”*
    –3
    Навскидку: больше поддерживаемых платформ (windows, linux, aix, solaris) + возможность копировать отдельные файлы, а не тома целиком.
  • “А шо эта ваш бэкап такой уставший?”*
    –2
    В документации указано: filter driver для Windows и filtering file system для linux.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    Конечно, Вы правы. В 500 миллионах блоков вероятность коллизии значительно выше, но всё равно остаётся в пределах допустимого риска по мнению производителя. Я попробую запросить расчётные значения у разработчиков.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    | Т.е. на вашей практике, еще на сталкивались с какими-то проблемами из-за sha-1 коллизий, насколько я понял.

    Верно, не сталкивались.

    Тут бы мне тихо и мирно закончить дебаты, но всё-таки не могу оставить без комментариев некоторые Ваши утверждения:

    1. «В случае с ядерными ракетами, пример не корректный, так как там не проверяют миллиард раз в день сработает защита или нет.»

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

    2. По поволу лотереи Powerball.
    Думаю, что в расчет вероятности выигрыша джекпота вкралась ошибка.
    Действительно, вероятность совпадения выигрышных чисел ДЛЯ ОДНОГО КОНКРЕТНОГО ЧЕЛОВЕКА равна 1/2^28 ( точнее, говорят, 1 к 292 201 338).
    Но если купили миллион билетов, то вероятность выигрыша для одного человека не изменится, а вот вероятность того, что джекпот в принципе случится, станет больше в миллион раз, то есть будет равна… 1/292
    То есть вероятность того, что я, мой сосед и мой племянник (то есть конкретные три человека) выиграют джекпот, действительно супер-низкая: 1/2^84, как Вы и сказали.
    Но то, что джекпот выиграют три ПРОИЗВОЛЬНЫХ человека из миллиона купивших билеты, всего лишь 1/292^3.
    Если куплено больше билетов, то вероятность ещё выше.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    1. Дедупликация в таком виде используется во многих продуктах известных производителей программного и аппаратного обеспечения. Не кажется ли Вам, что если бы коллизия хэшей имела бы коль сколько-нибудь серьёзную вероятность возникновения, давно бы появилась обоснованная критика этого метода со стороны серьёзных специалистов, а не только дискуссии на форумах?

    2. В вконце концов, дедупликация — это инструмент, который вы можете использовать, а можете и не использовать. Всё зависит от вашей собственной оценки рисков. Вы когда-нибудь ездили на автомобиле? Вы знаете, что погибнуть в автокатастрофе отлична от нуля и вовсе не ничтожна? Например, в России вероятность погибнуть в ДТП в течение года составляет около 0.00019.
    Но вы всё-равно ездите. Оцениваете риск, но удобства от езды на автомобиле перевешивают опасность.

    Так же и при дедупликации. Разница только в том, что риск автомобильной аварии осязаем, а риск коллизии миллиарда хешей ежедневно — ничтожен.

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

    Но известно ли Вам, что вероятность того, что ошибочно будет произведён пуск ядерной ракеты также отлична от нуля? Это Вас не беспокоит? Вы просто уверены, что вероятность такого события ничтожна, хотя последствия чудовищны. А ничтожна — это насколько мала? когда для Вас число будет столь малым, что не будет вызывать беспокойства? 2^-80 достаточна? А 2^-160? А какая достаточна? Давайте выберем такой размер хеша, который будет соответствовать Вашим понятиям ничтожной вероятности.

    Просто до нас уже кто-то прикинул вероятность коллизии для SHA-1 и решил, что это весьма небольшая вероятность, позволяющая использовать основанную на ней дедупликацию в промышленных системах.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    Боюсь, что мои знания слишком поверхностны, чтобы обсуждать эту тему так глубоко, выступая в то же время адвокатом целой индустрии, основанной на дедупликации.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    Или вот такое (мрачное) сопоставление.
    В практикуме по страхованию жизни (легко ищется в интернете) можно прочитать, что вероятность прожить ещё один год для взрослого человека составляет около 0.99
    Допустим, в вашем ИТ-департаменте работает 10 человек
    Вероятность того, что в течение года все они дружно переплывут через реку Стикс, составляет
    (1-0.99)^10 ~= 1/(2^7)^10 ~= 2^-70
    То есть встретить коллизию SHA-1 вероятность гораздо меньше, чем всему департаменту ломануться на вечеринку к Одину.
    Не кажется ли вам, что настолько маловероятное событие не заслуживает беспокойства о нём?
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    «Государь Гелон!
    Есть люди, думающие, что число песчинок бесконечно. Я не говорю о песке в окрестности Сиракуз и других местах Сицилии, но о всём его количестве как в странах населённых, так и необитаемых.»
    Архимед. Исчисление песчинок в пространстве равном шару неподвижных звёзд (Псаммит).

    А, есть люди, которые считают, что 1/2^80 (вероятность коллизии SHA-1) – это обычное такое число, ничего особенного. И что встретить коллизию SHA-1 – обычное дело.

    Сравнить же с этим числом можно (если не ошибаюсь) количество элементарных частиц в нашей галактике. А это куда больше, чем количество песчинок, подсчитанных Архимедом (2^80 против 10^63 – тысячи мириад чисел «восьмых»).

    И вероятность коллизии меньше, чем вероятность того, что данные на жёстком диске случайно переманитятся, но CRC останется прежним! Представляете? Было «Я к вам пишу — чего же боле?» а стало «А теперь Горбатый! Я сказал – Горбатый!» только за счёт случайного перемагничивания.

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

    В общем, всё зависит от вашего доверия/недоверия к тому, может ли возникнуть событие с ничтожно низкой вероятностью. И «ничтожно» — это куда меньше, чем найти две одинаковых песчинки не просто в окрестностях Сиракуз, но и во всей нашей галактике.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    Любая технология резервного копирования подразумевает, что должна проводиться периодическая проверка восстановимости. И дело не только в дедупликации.

    Лично мне приходилось сталкиваться с такими двумя случаями:
    1. Копирование на ленточный привод годами проходило без ошибок. Ленты подписывались и складывались в шкафчик. Когда возникла необходимость восстановить данные, оказалось что ленты пусты. Ни разу никто не проверил, действительно ли на лентах что-то записано или нет.
    2. Снова лента. Долгое время проводилось ежедневное резервное копирование сервера с базой данных Oracle. Операционная система стояла на диске C:, база данных — на диске D:. Когда сервер рухнул, оказалось, что копировался только бесполезный диск C:, про диск D: забыли при создании задания на резервное копирование.

    Что я хочу этим сказать? Если бы люди хоть раз провели бы тестовое восстановление, то ошибки всплыли бы.

    Точно также и с дедупликацией. Если есть регламент проверки восстановимости, то можно положиться на такую систему.

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

    А уж если бы коллизия SHA-1 кому-то попалась (необязательно нам), то такая новость сразу бы наводнила Интернет, и мы тут же увидели бы её на Хабре, да и во всяких википедиях тоже.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    — Максимально использовать инкрементные копии. Проверку на повторяемость будут проходить не все блоки диска, а только те, что помечены, как изменённые.

    — Если сервер виртуальный, то копировать его без установки агента (брать снапшот с гипервизора) и проводить дедупликацию на машине, установленной рядом.

    — «Душить» скорость копирования (network throttling) встроенными средствами, «размазывая» нагрузку на процессор по времени.

    Но необходимость в этом возникает нечасто. В реальной жизни инкрементные копии на уровне блоков могут проскакивать за считанные минуты глубокой ночью.
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    1. Принципиальное отличие в том, что встроенная в ОС дедупликация выполняется в офлайне.
    То есть:
    — Оставляйте свои данные, мы ими займёмся.
    — А когда будут готовы?
    — Мы вам позвоним.
    Вы (а) не можете предсказать, когда занятое место на диске уменьшится, (б) успеет ли оно уменьшится к тому моменту, когда нужно будет делать следующую копию, следующую за следующей…, (в) не можете предсказать заранее, НАСКОЛЬКО уменьшится занятое место.

    В то же время онлайн-дедупликация в Arcserve UDP сразу же выдаёт данные в дедуплицированном виде. Правда, цена за это — повышенные требования к быстрой памяти (оперативной или SSD), где должна помещаться вся таблица хэшей.

    2. Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
  • Примеряем дедупликацию и компрессию к резервным копиям
    0
    (удалено, промахнулся)
  • Примеряем дедупликацию и компрессию к резервным копиям
    +1
    Вы можете выбрать, какой размер блока использовать при дедупликации: 4,8,16 или 32 Килобайта. На последней картинке видно, как размер блока влияет на эффективность дедупликации и потребность в быстрой памяти (оперативной или SSD).

    В предыдущих версиях программы резервного копирования Arcserve UDP по умолчанию предлагали использовать блок данных в 4 Килобайта. Теперь стали рекомендовать 16 Килобайт.

    Используемый хэш — SHA1.
  • Профессор информатики «нанял» IBM Watson в качестве своего помощника
    –5
    А пресс-секретарь госдепа… это… тоже ваша работа?
  • 20 самых заметных событий в истории резервирования и восстановления
    +1
    Ну конечно же, это ироничная статья!
  • Конструкция и принципы работы Arcserve UDP – программного продукта для резервного копирования и восстановления данных
    0
    Мне просто нужно время, чтобы разобраться с незнакомыми мне вопросами. А пока спорное содержимое уберу. Вот если бы Вы технические вопросы задавали, я бы постарался на них сразу ответить.
  • Конструкция и принципы работы Arcserve UDP – программного продукта для резервного копирования и восстановления данных
    0
    Спасибо за конструктивную критику. Расчёт спецификаций с сайта удалён. Продажи осуществляются только через партнёров.

    Лицензии за сокеты и за серверы взаимоисключающие. Либо одно, либо другое.
    Просто выгоднее для гипервизора взять лицензию на его физические процессоры (и копировать все его виртуальные машины), а для остальных физических серверов (не гипервизоров) — лицензию на сервер.
  • Конструкция и принципы работы Arcserve UDP – программного продукта для резервного копирования и восстановления данных
    0
    Для простых случаев — вот здесь: http://arcserve.su/skoka.php
  • Конструкция и принципы работы Arcserve UDP – программного продукта для резервного копирования и восстановления данных
    0
    Спасибо, исправил.
  • Восстановить за 60 секунд (или как ускорить восстановление данных при помощи Arcserve UDP)
    0
    Прикинуть масштаб затрат можно при помощи простой формы:

    http://arcserve.su/skoka.php

    (правда, в эту спецификацию не войдёт модуль непрерывного резервного копирования)

    Что касается сравнения с Hyper-V Replica, то, во-первых, как уже упоминали выше, всё равно нужно хранить данные в исторической перспективе, а одна лишь репликация этого не даст. Во-вторых, это решение, заточенное только для виртуальных машин Hyper-V, и если требуется что-то универсальное, например, для репликации ещё и физических машин, то оно уже не подойдёт.

    Если говорить о «Veeam c переключением источника данных на саму резервную копию в процессе восстановления», то функционал очень похож на функционал Arcserve UDP, с той лишь разницей, что Arcserve UDP позволяет выполнить кроссплатформенное восстановление, например, моментально восстановить физическую машину в виртуальную среду. Или (хотя это уже экзотика) виртуальную машину из Hyper-V в среду vSphere.
  • Восстановить за 60 секунд (или как ускорить восстановление данных при помощи Arcserve UDP)
    0
    Вы правы, репликация резервному копированию не замена. Но может хорошо его дополнить.
    И ещё, программная репликация, о которой я лишь вскользь здесь упомянул, позволяет в некоторых случаях вести журнал, то есть позволяет при восстановлении откатиться на заданную точку во времени. Обычно не очень давнюю, например, не более, чем на неделю назад. Но это уже хороший задел, чтобы можно было использовать её в качестве средства оперативного резервного копирования.
    Репликация на уровне блоков тоже не безупречна. В частности, она делает идентичными основную и резервную машины. В то время, как программная репликация может копировать лишь отдельные файлы. Например, копируя базу данных, но не трогая файлы операционной системы.
    Надеюсь, что смогу более подробно описать эту технологию в отдельной статье.