Рейтинг
0.00

Backblaze Хостинг

1 читатель, 38 топиков

Backblaze 7.0 - История версий и не только



Анонс Backblaze Cloud Backup 7.0: история версий и новые версии!
В этом выпуске для потребителей и предприятий добавлено одно из самых востребованных улучшений для нашей службы Backblaze Cloud Backup: возможность постоянно обновлять, изменять и даже удалять файлы в резервных копиях навсегда, расширяя историю версий. Кроме того, мы сделали наши приложения для Windows и Mac еще лучше, обновили нашу поддержку единого входа (SSO), добавили дополнительные параметры безопасности учетной записи, стали готовыми для Catalina и расширили функциональность наших мобильных приложений для iOS и Android. Эти изменения потрясающие, и мы уверены, что вы их полюбите!

Расширенная версия истории
Вы когда-нибудь удаляли файл по ошибке или случайно сохранили из-за важной работы? Backblaze всегда хранит 30-дневную историю версий ваших резервных копий, чтобы помочь в подобных ситуациях, но сегодня мы даем вам возможность продлить историю версий до одного года или навсегда. Эта новая функция доступна на странице обзора для резервного копирования компьютера и на странице управления группами, если вы используете Backblaze Groups! Backblaze v7.0 требуется для использования истории версий. Узнайте больше о версиях и расширении истории версий.


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

1-летняя история версий
Продление истории версий с 30 дней до одного года означает, что все версии ваших файлов, для которых выполняется резервное копирование — независимо от того, были ли вы обновлены, изменены или полностью удалены с вашего компьютера — останутся в резервной копии Backblaze в течение одного года после изменения или удален с вашего устройства. Продление истории версий до одного года — это дополнительные 2 доллара в месяц, и плата взимается в зависимости от типа вашей лицензии (ежемесячная, годовая или 2-летняя). Как всегда, любые расходы будут пропорционально сопоставлены с датой продления лицензии.

История версий навсегда
Продление истории версий с 30 дней или одного года до бесконечности означает, что Backblaze никогда не удалит файлы из резервной копии Backblaze, независимо от того, обновили ли вы их, изменили или полностью удалили их со своего компьютера или нет. Продление истории версий навсегда аналогично одному году, за дополнительную плату в 2 доллара США в месяц (пропорционально типу вашего лицензионного плана) плюс 0,005 доллара США / ГБ в месяц за версии, измененные на вашем компьютере более года назад.



Это отличная новая функция для людей, которые хотят больше спокойствия. Чтобы узнать больше об истории версий, ценах и примерах восстановления, посетите FAQ по истории версий.
help.backblaze.com/hc/en-us/articles/360035247494

Обновления приложений MacOS и Windows
Более эффективная производительность для загрузки

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

Обновления единого входа для групп Backblaze
Мы добавили поддержку Microsoft Office 365 в Backblaze Groups и сделали SSO-обновления для функции Inherit Backup State, чтобы она поддерживала учетные записи с поддержкой SSO. Это означает, что теперь вы можете войти в Backblaze, используя свои учетные данные Office 365, аналогично использованию единого входа Google.

Более высокое разрешение для более удобного просмотра информации
Мы обновили способ, которым наши установщики и приложения выглядят на дисплеях с более высоким разрешением, чтобы сделать просмотр более приятным!

Только для Windows
Проблема OpenSSL вызывала проблемы на чипсете Intel Apollo Lake, но мы разработали обходной путь. Apollo Lake — это чипсет более низкого уровня, поэтому не многие клиенты сталкивались с проблемами, но теперь компьютеры, использующие Apollo Lake, будут работать как положено.

Только MacOS
Мы добавили поддержку MacOS Catalina и улучшили некоторые системные сообщения MacOS. MacOS предоставляет несколько замечательных новых функций для Mac, и мы изменили некоторые из поведений нашего приложения, чтобы лучше соответствовать Catalina. В Каталине Apple теперь требует, чтобы приложения чаще запрашивали разрешение, а поскольку Backblaze является приложением для резервного копирования, нам требуется много разрешений. Таким образом, вы можете заметить больше системных сообщений при установке Backblaze на новую ОС.

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



Backblaze 7.0 Доступно: 8 октября 2019
Мы будем постепенно автоматически обновлять всех пользователей в ближайшие недели. Чтобы обновить сейчас:
Выполните проверку обновлений (щелкните правой кнопкой мыши значок Backblaze)
Скачать с www.backblaze.com/update.htm
Эта версия теперь является загрузкой по умолчанию на сайте www.backblaze.com

Петабайты на бюджете: 10 лет и счет



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

Прошло 10 лет с тех пор, как Backblaze представила миру наш накопитель. В сентябре 2009 года мы объявили о своем огромном, привлекательном красном сервере хранения 4U, оборудованном 45 жесткими дисками, обеспечивающими 67 терабайт хранилища всего за 7 867 долларов, что составляет около 0,11 доллара за гигабайт. В рамках этого объявления мы разработали дизайн для того, что мы назвали Storage Pod, и рассказали вам и всем, как вы, о том, как его создать, и многие из вас сделали.

Версия Backblaze Storage Pod 1 была анонсирована в нашем блоге с небольшой помпой. Мы подумали, что это будет интересно горстке людей — таких как ты. На самом деле, он даже не назывался версией 1, так как никто никогда не думал, что будет версия 2, а тем более версия 3, 4, 4.5, 5 или 6. Мы ошиблись. Модуль Backblaze Storage Pod покорил многих ИТ-специалистов и специалистов по хранению данных, которые были оскорблены необходимостью заплатить королевский выкуп за систему хранения высокой плотности. «Я могу построить это за десятую часть цены», — почти слышно, как они бормочут себе под нос. Бормоча или нет, мы думали то же самое, и версия 1 родилась.

Podfather
Тим, «Подфазер», как мы его знаем, был лидером Backblaze в создании первого хранилища. Он получил помощь в разработке от наших друзей из Protocase, которые создали первые три поколения модулей хранения для Backblaze, а также создали компанию под названием 45 Drives для продажи своих собственных версий модулей хранения — это открытый исходный код в лучшем виде. Прежде чем мы определились с дизайном версии 1, было несколько экспериментов:


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

Octopod был быстрым и грязным ответом на неправильные кабели SATA — слишком длинные и светящиеся. Да, в нижней части стручка просверлены отверстия.


Оригинальная лицевая панель, показанная выше, использовалась на 10 бочках для хранения до 1.0. Он был обновлен до трех кругового дизайна непосредственно перед Storage Pod 1.0.

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

Еще в 2007 году, когда мы запустили Backblaze, не было большого количества доступных вариантов для хранения больших объемов данных. Нашей целью было взимать $ 5 / месяц за неограниченное хранение данных на одном компьютере. Мы решили создать наши собственные серверы хранения, когда стало очевидно, что, если бы нам пришлось использовать другие доступные решения, нам пришлось бы брать гораздо больше денег. Storage Pod 1.0 позволил нам хранить один петабайт данных примерно за 81 000 долларов. Сегодня мы снизили это до 35 000 долларов с помощью Storage Pod 6.0. Если принять во внимание, что средний объем данных на пользователя почти утроился за тот же период времени, и наша цена теперь составляет $ 6 / месяц за неограниченное хранилище, математика сегодня работает примерно так же, как и в 2009 году.

Мы должны были сделать что-то правильно
Модуль Backblaze Storage Pod — это больше, чем просто доступное хранилище данных. Версия 1.0 представила или популяризировала три фундаментальных изменения в дизайне хранилища: 1) Вы могли бы построить систему из обычных компонентов, и она работала бы, 2) Вы могли бы монтировать жесткие диски вертикально, и они все еще вращались бы, и 3) Вы могли бы использовать жесткий потребитель диски в системе. Трудно определить, какая из этих трех функций обидела и / или взволновала больше людей. Справедливо сказать, что через десять лет все пошло нам на пользу, поскольку в настоящее время у нас на платформе имеется около 900 петабайт хранилища.

За последние 10 лет люди подогрели наш дизайн или хотя бы элементы дизайна. Начиная с 45 накопителей, многие компании работали над созданием систем хранения высокой плотности, от 45 до 102 жестких дисков в корпусе 4U, и представили различные конструкции, поэтому сегодня список систем хранения высокой плотности, в которых используются вертикально установленные накопители, впечатляет:


Другой движущей силой в разработке некоторых из этих систем является Open Compute Project (OCP). Созданные в 2011 году, они собирают и обмениваются идеями и проектами для хранения данных, конструкций стоек и связанных с ними технологий. Группой управляет The Open Compute Project Foundation как 501 © (6), и в ее состав входят многие светилы отрасли в сфере хранения данных.

Что мы сделали в последнее время?
В технологической стране 10 лет чего-либо — это много. То, что было захватывающим тогда, ожидается сейчас. И то же самое произошло с нашим любимым хранилищем. В течение многих лет мы вводили обновления и обновления, скручивая обычные циферблаты: снижение стоимости, ускорение, увеличение емкости, снижение вибрации и так далее. Все хорошее. Но мы не можем обмануть вас, особенно если вы читали это далеко. Вы знаете, что Storage Pod 6.0 был представлен в апреле 2016 года, и, откровенно говоря, это были сверчки с тех пор, как он относится к Storage Pod.

Три с лишним года без инноваций. Почему?
  1. Если это не сломано, не исправляйте это. Storage Pod 6.0 построен в США компанией Equus Compute Solutions, нашим контрактным производителем, и он отлично работает. Затраты на производство понятны, производительность хороша, а новые диски более высокой плотности работают достаточно хорошо в корпусе 6.0.
  2. Дисковые миграции заставляли нас быть занятыми. Со второго квартала 2016 года по второй квартал 2019 года мы перенесли более 53 000 дисков. Мы заменили диски емкостью 2, 3 и 4 терабайта на диски емкостью 8, 10 и 12 терабайт, удвоив, утроив и иногда увеличивая в четыре раза плотность хранения модуля хранения.
  3. Модернизация стручка заставляла нас быть занятыми. Со второго квартала 2016 года по первый квартал 2019 года мы обновили наши старые модули хранения V2, V3 и V4.5 до V6.0. Затем мы раздавили несколько старых с помощью MegaBot и отдали больше. Сегодня уже нет автономных контейнеров для хранения; все они являются членами Хранилища Backblaze.
  4. Много данных занимало нас. Во втором квартале 2016 года у нас было 250 петабайт хранения данных в производстве. Сегодня у нас есть 900 петабайт. Это много данных, которые вы, ребята, дали нам (спасибо, кстати), и множество новых систем для развертывания. На приведенной ниже диаграмме показана проблема, с которой столкнулись наши специалисты ЦОД.

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

Storage Pod Version 7.0 — Почти
Да, на чертежной доске есть Backblaze Storage Pod 7.0. Вот краткий список некоторых функций, которые мы рассматриваем:
  • Обновление материнской платы
  • Обновите процессор и рассмотрите возможность использования процессора AMD
  • Обновление блоков питания, возможно, переход на один блок
  • Обновление с 10Gbase-T до 10GbE SFP + оптическая сеть
  • Обновление карт SATA
  • Изменение конструкции крышки без инструментов
Сроки еще не определены, но самое подходящее время, чтобы спросить нас об этом, — начало 2020 года.

«Это хорошо», — говорите вы вслух, но на самом деле вы думаете: «Это так? Где Backblaze во всем этом? »И вот где вы входите.

Блок хранения Backblaze следующего поколения
Мы не из идей, но одна из вещей, которые мы поняли за эти годы, — то, что многие из вас действительно умны. С момента открытия проекта Storage Pod в 2009 году мы получили бесчисленное множество интересных, продуманных и иногда странных идей по улучшению дизайна. Когда мы смотрим в будущее, мы были бы глупы не спрашивать ваши мысли. Кроме того, вы все равно сообщите нам об этом в Reddit, HackerNews или о том, где вы читаете этот пост, так что давайте просто перейдем к поиску.

Построить или купить
Два основных варианта: мы проектируем и создаем свои собственные серверы хранения или покупаем их у кого-то другого. Вот некоторые из критериев, как мы думаем об этом:
  • Стоимость. Нам хотелось бы, чтобы стоимость сервера хранения составляла около 0,030–0,035 долл. На гигабайт хранилища (или меньше, конечно). Это включает в себя сервер и диски внутри. Например, использование готовых жестких дисков Seagate объемом 12 ТБ (модель: ST12000NM0007) в модуле хранения 6.0 стоит около 0,032–0,034 долл. / Гигабайт в зависимости от цены накопителей в данный день.
  • Международный: Теперь, когда у нас есть дата-центр в Амстердаме, мы должны иметь возможность доставлять эти серверы куда угодно.
  • Техническое обслуживание: все должно быть легко починить или заменить, особенно приводы.
  • Товарные части: везде, где это возможно, запчасти должны легко приобретаться, в идеале у нескольких поставщиков.
  • Стойки: Мы бы предпочли продолжать использовать 42-дюймовые шкафы, но придумали что-то более глубокое и рассмотрим это.
  • Возможно сегодня: нет ДНК-накопителей или других задумчивых технологий. Нам нужно хранить данные сегодня, а не в 2061 году.
  • Масштабирование. Ничто в решении не должно ограничивать возможности масштабирования систем. Например, мы должны быть в состоянии обновить диски до более высокой плотности в течение следующих 5-7 лет.

Кроме этого нет никаких ограничений. Любые из следующих аббревиатур, слов и фраз могут быть частью предложенного вами решения, и мы не будем обижаться: SAS, JBOD, IOPS, SSD, резервирование, вычислительный узел, шасси 2U, шасси 3U, горизонтальные жесткие диски, прямой провод, уровни кэширования, устройство, пограничные устройства хранения, PCIe, оптоволоконный канал, SDS и т. д.

Решение не обязательно должно быть Backblaze. Как видно из списка, приведенного ранее в этом посте, Dell, HP и многие другие делают платформы хранения высокой плотности, которые мы могли бы использовать. Сделайте хороший пример для любого из этих подразделений, или любого другого, который вам нравится, и мы рассмотрим.

Что мы будем делать со всем вашим вкладом?
Мы уже начали с запуска Backblaze Labs и провели несколько экспериментов. В ближайшие месяцы мы поделимся с вами тем, что происходит, по мере продвижения этого проекта. Может быть, мы представим Storage Pod X или возьмем некоторые из подделок Storage Pod за спин. В любом случае, мы будем держать вас в курсе. Заранее благодарим за ваши идеи и спасибо за вашу поддержку в течение последних десяти лет.

www.backblaze.com

Логистика поиска подходящего дата-центра: большие европейские



Неделя Европы в Backblaze! Во вторник мы объявили об открытии нашего первого европейского дата-центра. Вчера мы обсуждали процесс поиска источников данных. Сегодня мы сосредоточимся на том, как мы сузили список до небольшой группы финалистов. А завтра мы поделимся тем, как мы в конечном итоге выбрали нашего нового партнера.

Десять локаций, три страны, три дня. Даже самый трудолюбивый человек в шоу-бизнесе не справится с такими проблемами. Но для нашего главного операционного директора Джона Трана и генерального директора UpStack Криса Траппа именно это они и решили сделать.

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

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

Крис взял на себя инициативу по бронированию встреч. Большая часть короткого списка сгруппирована в Нидерландах и Ирландии. Остальные были в Бельгии, и с помощью магии Google Maps можно было представить эффективную поездку во все три страны. Такое ощущение, что все это можно сделать всего за три дня в Европе. Войдя, они знали, что это будет сжатый график и что они будут в движении. Как опытные путешественники, они приносили небольшие сумки, которые легко помещались в накладные и подходящие адаптеры питания.

По дороге
23 июля 2018 года Джон покинул международный аэропорт Сан-Франциско (SFO) в 7:40 утра по безостановочному маршруту в Амстердам. Принимая во внимание 5448 миль между двумя городами и изменение времени, Джон приземлился в Амстердамском аэропорту Схипхол (AMS) в 7:35 утра 24 июля. Он приземлится домой 27 июля в 6:45 вечера.

Вторник (день первый)
Первый день официально начался, когда в 7:35 утра по местному времени в Амстердаме приземлился перевод Джона в Амстердам. К счастью, перелет Криса из нью-йоркской La Guardia также был вовремя. Благодаря обоим полетам вовремя они смогли встретиться в аэропорту: буквально, потому что никогда раньше не встречались.

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

В тот день они закончили гастроли по четырем DC. Одним из самых больших результатов поездки было то, что посещение дата-центров похоже на дегустацию вин. В то время как некоторые из различий можно предугадать из спецификаций на бумаге, при попытке выяснить разницу между A и B очень полезно сравнивать бок о бок. Также как и дегустация вин, есть тонкая грань между пониманием нюансов между несколькими вещами, и все это начинает смешиваться. В обоих случаях, после полного рабочего дня, вы чувствуете, что, вероятно, вам не следует использовать тяжелую технику.

В первый день наша команда увидела широкий спектр вариантов. Физическое растение само по себе является одной из областей дифференциации. Несмотря на то, что у нас есть требования к таким параметрам, как мощность, пропускная способность и безопасность, все еще остается много возможностей для компромиссов между теми DC, которые превышают это требование. И это только физическое пространство. Первый этап успешного скрининга (обсуждаемый в нашем предыдущем посте) — это эффективная проверка неэмоциональных переменных решения — спецификации, цены, репутации — но не людей. Каждый ДЦ укомплектован людьми, и культурные связи важны для любого партнерства. В течение дня одним из самых больших отличий, которое мы заметили, была культура каждого конкретного ДК.

Третьей остановкой дня стал Interxion Amsterdam. Хотя мы не знали этого в то время, они в конечном итоге стали нашим партнером по выбору. На бумаге было ясно, что Interxion будет претендентом. Его впечатляющее оборудование отвечает всем нашим требованиям, и, случайно, у него есть доступная площадь, которая почти соответствует спецификации того, что мы искали. Во время нашего визита объект был впечатляющим, как и ожидалось. Но связь, которую мы чувствовали с командой, оказалась бы той вещью, которая в конечном счете имела бы значение.

Покинув последний тур DC около 19:00, наша команда поехала из Амстердама в Брюссель. Второй день станет еще одним утренним стартом, и после прибытия в Брюссель чуть позже 9 вечера они заработали немного отдыха!

Совет посвященного лица: Гран-Плас, Брюссель В начале своей карьеры Джон провел много времени в Европе и, в частности, в Брюсселе. Одним из его любимых мест является Grand Place (Центральный рынок Брюсселя). Если вы по соседству, он рекомендует вам пойти и насладиться бельгийским пивом, сидя в одном из ресторанов на рынке. Умный ход — принять совет. Крис, новичок в Брюсселе, дал туру Джона благоприятный рейтинг TripAdvisor.

Среда (день второй)
Получив заслуженную пару часов сна, день официально начался с встречи в 8:30 утра для первого DC дня. Крупные операторы постоянного тока, как правило, имеют несколько мест, а постоянные пять и шесть управляются компаниями, которые также управляют участками, посещенными в первый день. Культурно было замечательно сравнить команды и операционную изменчивость в разных местах. Даже внутри одной и той же компании команды в разных местах обладают уникальными личностями и стилями работы, и все это служит для того, чтобы усилить необходимость физического посещения ваших предполагаемых партнеров перед принятием решения.

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

Сам полет прошел без происшествий. Когда они приземлились, они добрались до места проката, и их машина ждала их. О, кстати, мелкие детали, но руль оказался не с той стороны машины! Крис крепко согнулся, и у Джона всплыли воспоминания о водительском праве, так как он никогда не ехал по правой стороне автомобиля. Вскоре после выхода из аэропорта выяснилось, что в Ирландии также едут по левой стороне дороги. Смартфоны и подключение не были необходимы для этого открытия. К счастью, поездка прошла без происшествий, и до отеля можно было добраться без происшествий. После работы и семейных проверок, еще один день был записан на книги.

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

Четверг (день третий)
День снова начался с отъезда в 8:30 утра. Имейте в виду, что во время всего этого у Джона и Криса была своя дневная работа, и семьи возвращались домой, чтобы оставаться на связи. Сегодня будет четыре тура DC. Одно интересное замечание о поездке: для эксплуатации центра обработки данных требуется достаточное количество инфраструктуры. В идеальном мире мощность и пропускная способность поступают в разных местах от разных поставщиков. Это часто приводит к тому, что контроллеры домена объединяются вокруг узлов инфраструктуры. Первые два сегодняшних ДК были через дорогу друг от друга. Мы предполагаем, но не можем проверить, жесткое соперничество между компаниями по футболу.

Хотя прогулка по улице была интересной, в случае двух последних ДК они буквально делили одно и то же пространство; меньший провайдер субарендует пространство от большего. Здесь, опять же, действующие лица дифференцировали компании. Не обязательно, чтобы одно было хуже другого, вопрос в том, кого вы считаете лучшим партнерским партнером для вашего собственного стиля. В этом случае меньший из двух провайдеров выделялся из-за страсти и энтузиазма, которые мы испытывали от команды, и не повредило, что они давние энтузиасты Hard Drive Stats (лесть поможет вам везде!).

Хотя поездка и этот пост были сосредоточены на поиске нашего нового местоположения в Вашингтоне, открытие наших первых физических операций за пределами США имело ряд деловых последствий. Таким образом, Джон позаботился о том, чтобы зайти в местный офис нашей международной бухгалтерской фирмы, чтобы воспользоваться возможностью, чтобы узнать их.

Встреча завершилась как раз к тому времени, когда Крис и Джон добрались до фабрики Гиннеса к 6:15 вечера. По прибытии выяснилось, что последний вход на фабрику Гиннеса — 6 часов вечера. Смартфоны и связь действительно могут быть преобразующими в таких поездках. Все это говорит о том, что нашим бесстрашным путешественникам, не затрагивая каких-либо конкретных действующих лиц, удалось найти свой путь, и они могли подать домой отчет о том, что им удалось взять одну или две пинты в месте Сент-Джеймса.




Команда уезжала в свои дома рано утром следующего дня. Джон вернулся в Калифорнию как раз на поздний ужин со своей семьей и хорошо заработанные выходные.

После долгой продуктивной поездки у нас был список трех финалистов. Завтра мы обсудим, как мы сократили его с трех до одного. До тех пор, убей (ура)!

Backblaze Hard Drive Stats Q2 2019



На 30 июня 2019 года у Backblaze было 110 640 вращающихся жестких дисков в нашей постоянно расширяющейся экосистеме облачных хранилищ. Из этого числа было 1 980 загрузочных дисков и 108 660 дисков с данными. В этом обзоре рассматриваются Q2 2019 и коэффициенты отказов жестких дисков в течение срока службы моделей накопителей данных, которые в настоящее время используются в наших центрах обработки данных. Мы также попрощаемся с несколькими моделями накопителей, которые существуют уже несколько лет, посмотрим, как работают наши накопители Toshiba емкостью 14 ТБ (предупреждение о спойлере: отлично), и по пути мы предоставим несколько идеи и наблюдения внутри нашего хранилища. Как всегда, мы опубликуем данные, которые мы используем в этих отчетах, на нашей веб-странице с данными о тестировании жесткого диска, и мы с нетерпением ждем ваших комментариев.

Статистика отказов жесткого диска за Q2 2019
В конце второго квартала 2019 года Backblaze использовала 108 660 жестких дисков для хранения данных. Для нашей оценки мы исключаем из рассмотрения те диски, которые использовались в целях тестирования, и модели, для которых у нас не было как минимум 60 дисков (см. Почему ниже). Это оставляет нам 108 461 жестких дисков. В таблице ниже показано, что произошло во втором квартале 2019 года.


Примечания и наблюдения
Если в модели накопителя частота отказов составляет 0 процентов, это означает, что в течение второго квартала 2019 г. отказы накопителей этой модели отсутствовали — показатели отказов на весь срок службы приведены ниже в этом отчете. Два диска, перечисленные с нулевым количеством сбоев во втором квартале, были моделями Toshiba на 4 ТБ и 14 ТБ. В накопителе Toshiba 4 ТБ недостаточно большого количества накопителей или дней, чтобы быть статистически надежным, но за последние три года вышел из строя только один накопитель этой модели. Мы рассмотрим статистику накопителей Toshiba на 14 ТБ чуть позже в отчете.

Было 199 дисков (108 660 минус 108 461), которые не были включены в приведенный выше список, потому что они использовались в качестве тестовых дисков, или у нас не было по крайней мере 60 из данной модели дисков. Теперь мы используем 60 накопителей той же модели, что и минимальное количество, когда мы публикуем статистику накопителей за квартал, год и за весь срок службы, поскольку во всех вновь развернутых накопительных блоках имеется 60 накопителей — в старых моделях накопительных накопителей было минимум 45.

2000 стручков для хранения Backblaze?
В настоящее время у нас работает 1 980 накопительных контейнеров. Все они являются версией 5 или версией 6, поскольку недавно мы раздавали почти все более старые стручки для хранения людям, которые остановились у нашего хранилища в Сакраменто. Почти все, как у нас есть пара в нашем музее хранения Pod. В настоящее время существует 544 модуля версии 5, каждый из которых содержит 45 дисков данных, и существует 1436 модулей версии 6, каждый из которых содержит 60 дисков данных. В следующий раз, когда мы добавим Backblaze Vault, который состоит из 20 модулей хранения, у нас будет 2000 работающих модулей хранения Backblaze.

До свидания Western Digital
Во втором квартале 2019 года последний из накопителей Western Digital объемом 6 ТБ был снят с эксплуатации. Средний возраст дисков составлял 50 месяцев. Это были последние из наших дисков данных под маркой Western Digital. Когда Backblaze только начинался, первыми дисками данных, которые мы развернули в массовом порядке, были диски Western Digital Green 1 ТБ. Так что, с некоторой грустью, мы видим, что количество накопителей данных Western Digital обнуляется. Мы надеемся увидеть их снова в будущем.

WD Ultrastar 14 ТБ DC HC530


Привет Western Digital
Несмотря на то, что бренд Western Digital исчез, бренд HGST (принадлежащий Western Digital) становится все более сильным, поскольку у нас еще есть много фирменных накопителей HGST, около 20 процентов нашей фермы, размером от 4 до 12 ТБ. Фактически, в этом квартале мы добавили более 4700 HGST 12 ТБ накопителей.

Это только в; Ходят слухи, что двадцать один накопитель Western Digital Ultrastar по 14 ТБ готовятся к развертыванию и тестированию в одном из наших центров обработки данных. Похоже, Western Digital вернулся: следите за обновлениями.

Прощай, 5 ТБ дисков
Еще в первом квартале 2015 года мы развернули 45 накопителей Toshiba объемом 5 ТБ. Они были единственными накопителями на 5 ТБ, которые мы развернули, поскольку производители быстро перешли на диски большей емкости, и мы тоже. Тем не менее, в течение четырех с лишним лет развертывания отказали только два, без сбоев со второго квартала 2016 года — три года назад. Это затрудняло прощание, но покупка, хранение и отслеживание пары запасных дисков емкостью 5 ТБ не были оптимальными, тем более что эти запчасти нельзя было использовать где-либо еще. Так что да, диски Toshiba объемом 5 ТБ были странными утками на нашей ферме, но они были настолько хороши, что смогли остаться на четыре года.

Привет снова Toshiba 14 ТБ Диски Toshiba
Мы упоминали диски Toshiba 14 ТБ в предыдущих отчетах, и теперь мы можем углубиться в них, учитывая, что они были развернуты почти девять месяцев, и у нас есть некоторый опыт работы с ними. Эти накопители начали своеобразное начало: шесть неудач за первые три месяца использования. С тех пор произошел только один дополнительный сбой, о котором во втором квартале 2019 года не было зарегистрировано ни одного сбоя. В результате годовая частота отказов в течение срока службы накопителей Toshiba 14 ТБ снизилась до весьма приемлемых 0,78%, как показано в таблице времени жизни в следующий раздел.

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


Данные о жестком диске
Полный набор данных, использованный для создания информации, использованной в этом обзоре, доступен на нашей веб-странице с данными испытаний жесткого диска. Вы можете скачать и использовать эти данные бесплатно в своих целях. Все, что мы просим, — это три вещи: 1) вы цитируете Backblaze в качестве источника, если вы используете данные, 2) вы соглашаетесь с тем, что несете единоличную ответственность за то, как вы используете данные, и 3) вы не продаете эти данные кому-либо; это свободно. Удачи и дайте нам знать, если найдете что-нибудь интересное.

Если вам нужны таблицы, которые мы использовали для создания диаграмм в этом сообщении, вы можете скачать ZIP-файл, содержащий электронную таблицу MS Excel.

Backblaze B2 Copy File Beta is Now Public



Внедряя B2 Cloud Storage почти четыре года назад, мы были заняты добавлением улучшений и новых функций в сервис. Мы постоянно ищем способы сделать В2 более полезным для наших клиентов, будь то за счет повышения уровня обслуживания, партнерских отношений с ведущими поставщиками вычислений или снижения самой низкой в ​​отрасли цены на скачивание до 1 GB / ГБ. Сегодня мы рады объявить о выпуске бета-версии нашей новейшей функциональности: Копировать файл.
www.backblaze.com/b2/cloud-storage.html
www.backblaze.com/b2/solutions/compute.html
www.backblaze.com/b2/docs/b2_copy_file.html

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

Это была одна из наших самых востребованных функций, поскольку она разблокирует:
  • Переименовать / реорганизовать. Новые возможности дают клиентам возможность реорганизовывать свои файлы без необходимости загрузки и повторной загрузки. Это особенно полезно при попытке отразить содержимое файловой системы на B2.
  • Синтетическая резервная копия. Благодаря возможности копирования диапазонов файла пользователи теперь могут использовать B2 для синтетического резервного копирования, который загружает полную резервную копию, но затем загружает только добавочные изменения (в отличие от повторной загрузки всего файла с каждым изменением). Это особенно полезно для таких применений, как резервное копирование виртуальных машин, где повторная загрузка файла целиком при каждом его изменении создает неэффективность для пользователя.

Где узнать больше о B2 Copy File
Документацию по конечной точке можно найти здесь:
b2_copy_file: www.backblaze.com/b2/docs/b2_copy_file.html
b2_copy_part: www.backblaze.com/b2/docs/b2_copy_part.html

Подробнее о бета-программе
Мы представляем эти конечные точки в виде бета-версии, чтобы разработчики могли предоставить нам обратную связь до того, как конечные точки будут запущены в производство. В частности, это означает, что API могут развиваться в результате обратной связи, которую мы получаем. Мы рекомендуем вам попробовать Copy File и, если у вас есть какие-либо комментарии, вы можете написать нашей бета-команде B2 по адресу b2beta@backblaze.com. Спасибо!

Миграция 23 ТБ из Amazon S3 в Backblaze B2 всего за семь часов



Как и многие клиенты Backblaze, Nodecraft поняла, что может сэкономить целое состояние, переместив свое облачное хранилище на Backblaze и инвестировав его в другое место для развития своего бизнеса. В этом посте, который первоначально появился в блоге Nodecraft, Грегори Р. Суддерт, старший инженер по разработке приложений для Nodecraft, рассказывает о шагах, которые они предприняли, чтобы сначала проанализировать, протестировать, а затем переместить это хранилище.
Левенс

Nodecraft.com — это многопользовательская облачная платформа, где геймеры могут арендовать и использовать наши серверы для создания и обмена уникальными многопользовательскими онлайн-серверами со своими друзьями и / или публикой. Владельцы серверов, использующие свои игровые серверы, создают резервные копии, включая файлы серверов, игровые резервные копии и другие файлы. Само собой разумеется, что надежность резервного копирования важна для владельцев серверов.

В ноябре 2018 года нам в Nodecraft стало ясно, что мы можем улучшить наши расходы, если пересмотрим нашу стратегию облачного резервного копирования. Изучив текущие предложения, мы решили перенести наши резервные копии с Amazon S3 на сервис Backblaze B2. В этой статье описывается, как наша команда подошла к этому, почему и что произошло, в частности, чтобы мы могли поделиться своим опытом.

Выгоды
Из-за того, что S3 и B2, по крайней мере, в равной степени * доступны, надежны, доступны, а также многих других провайдеров, нашей основной причиной для переноса наших резервных копий стала цена. Когда мы начали работу, начали появляться другие факторы, такие как разнообразие API, качество API, реальная работоспособность и обслуживание клиентов.

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

Ценовой разрыв между двумя системами хранения объектов обусловлен альянсом Bandwidth между Backblaze и Cloudflare, группой провайдеров, которые согласились не взимать (или сильно снижать) плату за данные, оставленные в альянсе сетей («выходные» сборы). Мы в Nodecraft интенсивно используем Cloudflare, и поэтому оставалось беспокоиться только об исходящих затратах от Amazon до Cloudflare.

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

Соображения
Как и в случае любых изменений в поставщиках, переход должен быть продуман с большим вниманием к деталям. Когда ранее не было проблем с качеством, и обстоятельства таковы, что можно рассмотреть широкое поле новых поставщиков, окончательный выбор должен быть тщательно оценен. Наш список проблем включал эти:
  • Безопасность: нам нужно было переместить наши файлы и обеспечить их сохранность, избыточным способом
  • Доступность: служба должна быть надежной, но и широко доступной ** (что означает, что нам нужно было «указать» на нужный файл после его перемещения в течение всего процесса перемещения всех файлов: у разных компаний разные стратегии, одна корзина, много ведер, областей, зон и т. д.)
  • API: у нас есть опыт, поэтому мы не помешаны на проприетарных инструментах передачи файлов
  • Скорость: нам нужно было перемещать файлы навалом, а не тормозить ограничения скорости, и
  • Неправильная настройка может превратить операцию в нашу собственную DDoS.

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

Настройка: не отказывайтесь от собственных услуг и не вредите соседям
Что это означает для непрофессионала:
У нас много устройств в нашей сети, мы можем сделать это параллельно. Если мы сделаем это на полной скорости, мы сможем сделать так, чтобы наши поставщики услуг не очень-то нравились нам… может быть, мы должны сделать это не на полной скорости

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

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

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

Мы развернули каждый рабочий узел в виде контейнера Docker, распределенного по всему нашему Docker Swarm. Используя параметры в файле стека докеров, мы смогли определить, сколько рабочих на узел присоединилось к задаче. Это также гарантировало, что более дорогие регионы пропускной способности, такие как Азиатско-Тихоокеанский регион, не присоединились к рабочему пулу.

Тактический
У Nodecraft есть несколько парков серверов, охватывающих несколько центров обработки данных, и мы планировали использовать запасные ресурсы на большинстве из них для перемещения файлов резервных копий. Мы испытывали постоянный порядок доступа к нашим серверам со стороны наших пользователей в различных дата-центрах по всему миру, и мы знали, что будет доступность для наших целей перемещения файлов.

Наши цели в этой части операции также просты, но имеют больше шагов:
  • Получить имя / идентификатор / URL-адрес файла для перемещения, который блокирует файл и запускает таймер сбоя
  • Получить информацию о файле, включая размер
  • СКАЧАТЬ: Скопировать файл на локальный узел (без ограничения доступности узла сети)
  • Проверьте файл (размер, целостность ZIP, хэш)
  • ЗАГРУЗИТЬ: скопировать файл в новый сервис (опять же, не влияя на узел)
  • Сообщите «готово» с новой информацией о местоположении ID / URL на стратегическом уровне, который
  • Снимает блокировку в веб-сервисе, отменяет таймер и помечает файл как DONE



Переключатель убийства
В случае потенциального побега, когда даже внутриполосный Docker Swarm командует сами, мы решили убедиться, что у нас есть удобный переключатель. В нашем случае это был наш маленький бесстрашный веб-сервис — мы позаботились о том, чтобы приостановить его. Оглядываясь назад, было бы лучше, если бы он использовал расходуемый ресурс, такой как счетчик, или значение в ячейке базы данных. Если бы мы не обновили счетчик, он остановился бы сам по себе. Подробнее о «побегах» позже.

Тюнинг Реальной Жизни
Наш бизнес имеет ежедневные, еженедельные и другие циклы деятельности, которые предсказуемы. Наиболее важным является наш ежедневный цикл, который тянется после Солнца. Мы решили использовать наши узлы, которые находились в областях с низкой активностью, для выполнения работы, и после тестирования мы обнаружили, что, если мы настроимся правильно, это не повлияет на относительно небольшие нагрузки на серверы в этой области с низкой активностью. Это было подтверждено проверкой отсутствия изменений в нагрузке обслуживания клиентов с использованием наших показателей и инструментов CRM. Вернуться к настройке.

Первоначально мы настроили скорость передачи файла DOWN, эквивалентную 3/4 от того, что мог сделать wget (1). Мы подумали: «Ох, сетевой трафик к узлу будет соответствовать этому, так что все в порядке». Это в основном верно, но только в основном. Это проблема в двух отношениях. Причиной проблем является то, что тесты изолированного узла являются просто изолированными. Когда большое количество узлов в центре обработки данных выполняет фактическую передачу рабочих файлов, возникает пропорциональное воздействие, поскольку трафик концентрируется в направлении выходных точек.

Проблема 1: вы плохой сосед на пути к выходным пунктам. Хорошо, вы говорите «хорошо, мы платим за доступ к сети, давайте использовать его», но, конечно, есть только так много всего, но также очевидно, что «все порты коммутатора имеют большую пропускную способность, чем порты восходящей линии связи», поэтому, конечно, будет быть ограниченным, чтобы быть пораженным.

Проблема 2: ты сам себе плохой сосед. Опять же, если в конечном итоге ваши машины будут находиться рядом друг с другом в сети с помощью сетевых координат, ваши попытки «использовать всю пропускную способность, за которую мы заплатили», будут подавлены ближайшей точкой подавления, воздействуя только на почти только ты. Если вы собираетесь использовать большую часть полосы пропускания, которую МОЖЕТЕ использовать, вы должны также помнить об этом и выбирать, куда вы поместите точку засорения, которую создаст вся операция. Если кто-то не знает об этой проблеме, он может снять целые стойки вашего собственного оборудования, подавив коммутатор в верхней части стойки, или другие сетевые устройства.

Уменьшая нашу настройку 3 / 4ths-wget (1) до 50% от того, что wget могла сделать для передачи одного файла, мы увидели, что наши узлы по-прежнему функционируют должным образом. Ваш пробег будет совершенно разным, и есть скрытые проблемы в деталях того, как ваши узлы могут или не могут быть рядом друг с другом, и их влияние на оборудование между ними и Интернетом.

Старые привычки
Возможно, это досадная деталь: основываясь на предыдущем жизненном опыте, я привел некоторые задержки. Мы написали эти инструменты на Python, с помощью оболочки оболочки Bourne для обнаружения сбоев (были), а также потому, что на нашем этапе загрузки мы пошли вразрез с нашей ДНК и использовали утилиту загрузки Backblaze. Кстати, он многопоточный и действительно быстрый. Но в сценарии оболочки оболочки, как само собой разумеющемся, в главном цикле, который впервые говорил с нашим API, я поместил оператор sleep 2. Это создает небольшую паузу «вверху» между файлами.

Это оказалось ключевым, как мы увидим через мгновение.
Как это (служба, почти) все пошли вниз
То, что в прошлом, иногда не является прологом. Независимое тестирование в одном узле или даже в нескольких узлах не было полностью поучительным для того, что действительно должно было произойти, когда мы удушили тест. Теперь, когда я говорю «тест», я действительно имею в виду «операция».

Наше первоначальное тестирование было завершено «Тактически», как и выше, для которого мы использовали тестовые файлы, и были очень осторожны при их проверке. В общем, мы были уверены, что сможем справиться с копированием файла (цикл Python) и проверкой (unzip -T) и работать с утилитой Backblaze b2 без особых проблем… но это стратегический уровень, который научил нас нескольким вещам.

Вспоминая туманное прошлое, когда «6% коллизий в сети 10-BASE-T и ее игра окончена»… да, 6%. Мы сократили количество реплик в Docker Swarm, и у нас не было никаких проблем. Хорошо. “Хорошо.” Тогда мы переместили дроссель, так сказать, к последней задержке.

Мы почти достигли самообороны DDoS.
Это было не так уж и плохо, но мы внезапно были очень, очень довольны нашей настройкой 50% -го-wget (1) и нашими 2-секундными задержками между передачами, и, самое главное, нашим переключателем уничтожения.

Анализ
TL; DR — Все прошло отлично.

Было несколько файлов, которые просто не хотелось передавать (их не было на S3, хм). Были некоторые DDoS-тревоги, которые на мгновение сработали. Было много трафика… и, затем, счет за пропускную способность.

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


Как показано на диаграмме выше, перемещение файла может привести к многократной загрузке полосы пропускания, особенно когда наши клиенты начали загружать файлы из B2 для развертывания экземпляров и т. Д. В нашем случае у нас теперь был только счет за выход S3. Вот почему это работает:

У нас есть групповые (узловые) дисконтные соглашения о пропускной способности с нашими провайдерами.
B2 является членом Bandwidth Alliance и Cloudflare тоже
Мы обращались к нашему контенту S3 через наши (не бесплатные!) Публичные URL-адреса учетной записи Cloudflare, а не через (частные) S3 URL.
Не говоря уже о наших конфиденциальных договоренностях с нашими партнерами по обслуживанию, в целом верно и следующее: вы можете поговорить с поставщиками, а иногда и договориться о сокращениях. Кроме того, им особенно нравится, когда вы звоните им (заранее) и обсуждаете свои планы по усиленному управлению своей экипировкой. Например, при другом перемещении данных один из провайдеров дал нам способ «пометить» наш трафик определенным образом, и он будет проходить через тихую, но не часто посещаемую часть своей сети; победа победа!

Хочу больше?
Прочитайте пример использования Nodecraft в блоге Cloudflare.
Мы также выпустили наш собственный модуль JavaScript NPM B2-Cloud-Storage, который мы сейчас используем в производстве, чтобы упростить процесс загрузки.
Спасибо за ваше внимание, и удачи с вашим собственным байтовым стропом.

Грегори Р. Sudderth
Nodecraft Старший инженер DevOps
Наука сложна, синие клавиши на калькуляторах хитры, и у нас нет лет, чтобы изучать вещи, прежде чем делать их

Backblaze Hard Drive Stats Q1 2019



По состоянию на 31 марта 2019 года у Backblaze было 106 238 вращающихся жестких дисков в нашей экосистеме облачных хранилищ, распределенных по трем центрам обработки данных. Из этого числа было 1913 загрузочных дисков и 104 325 дисков данных. В этом обзоре рассматриваются показатели первого квартала 2019 года и частоты отказов жестких дисков на моделях накопителей данных, которые в настоящее время используются в наших центрах обработки данных, и приводится несколько полезных идей и наблюдений. Кроме того, у нас есть несколько вопросов для размышления ближе к концу поста. Как всегда, мы с нетерпением ждем ваших комментариев.

Статистика отказов жесткого диска за первый квартал 2019 года
В конце первого квартала 2019 года Backblaze использовала 104 325 жестких дисков для хранения данных. Для нашей оценки мы исключаем из рассмотрения те диски, которые использовались в целях тестирования, и модели, для которых у нас не было как минимум 45 дисков (см. Почему ниже). Это оставляет нам 104 130 жестких дисков. В таблице ниже показано, что произошло в первом квартале 2019 года.


Таблица коэффициентов отказов жесткого диска Q1 2019

Примечания и наблюдения
Если в модели накопителя частота отказов составляет 0%, это означает, что в течение первого квартала 2019 года отказы накопителей этой модели отсутствовали. В первом квартале в списке приводов с нулевыми отказами были модели Toshiba объемом 4 ТБ и 5 ТБ. Ни один из них не имеет достаточно большого количества дней вождения, чтобы быть статистически значимым, но в случае модели объемом 5 ТБ вы должны вернуться ко второму кварталу 2016 года, чтобы найти последний сбой накопителя в этой модели.

Было 195 накопителей (104 325 минус 104 130), которые не были включены в приведенный выше список, поскольку они использовались в качестве тестируемых накопителей или у нас не было по крайней мере 45 данной модели накопителей. Мы используем 45 накопителей той же модели, что и минимальное количество, при составлении квартальной, годовой и пожизненной статистики накопителей. Использование 45 накопителей носит исторический характер, поскольку это было количество накопителей в наших оригинальных накопителях. В следующем квартале этот порог изменится; мы скоро к этому вернемся.

Годовой процент отказов (AFR) за 1 квартал составляет 1,56%. Это столь же высоко, как квартальная ставка с 4 квартала 2017 года, и это часть общей тенденции к повышению, которую мы наблюдаем в квартальных показателях отказов за последние несколько кварталов. Давайте посмотрим поближе.

Квартальные тенденции
В предыдущих отчетах мы отмечали, что использование ежеквартальных отчетов полезно для выявления тенденций в отношении конкретного диска или даже производителя. Тем не менее, вам необходимо иметь достаточно данных (количество и количество дней в году) за каждый наблюдаемый период (квартал), чтобы сделать любой анализ действительным. С этой целью в приведенной ниже таблице используются квартальные данные с дисков Seagate и HGST, но при этом не учитываются диски Toshiba и WDC, поскольку в течение последних трех лет у нас не было достаточно дисков от этих производителей.


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

За последние три года тенденция к ежегодным показателям отказов Seagate и HGST улучшилась, то есть уменьшилась. В то время как Seagate снизил частоту отказов более чем на 50% за это время, тенденция к росту за последние три квартала требует некоторого рассмотрения. Мы рассмотрим это и сообщим, найдем ли мы что-нибудь интересное в следующем посте.

Изменение порога квалификации
Как сообщалось за последние несколько кварталов, мы перешли с дисков с низкой плотностью, дисков на 2, 3 и 4 ТБ на жесткие диски на 10, 12 и 14 ТБ. В то же время мы заменили наши автономные модули хранения с 45 дисками на блоки хранения с 60 дисками, расположенные в конфигурации Backblaze Vault из 20 блоков хранения на хранилище. В первом квартале последний автономный 45-дисковый накопитель был удален. Поэтому использование 45 накопителей в качестве порога для квалификации в нашем ежеквартальном отчете выглядит устаревшим. Это хорошее время, чтобы перейти к использованию Дней в качестве критериев квалификации. При рассмотрении наших данных мы решили использовать 5000 дней в качестве порога в будущем. Исключение составляют все текущие накопители, о которых мы сообщаем, такие как модель Toshiba 5 ТБ с продолжительностью около 4000 часов в квартал, которые будут по-прежнему включаться в наши отчеты о состоянии жестких дисков.

Меньше дисков = больше данных
Те из вас, кто следит за нашими ежеквартальными отчетами, возможно, заметили, что общее количество жестких дисков в обслуживании сократилось в 1 квартале на 648 дисков по сравнению с 4 кварталом 2018 года, но мы добавили почти 60 петабайт хранилища. Вы можете увидеть, что изменилось на графике ниже.


Backblaze Cloud Storage: количество накопителей и дисковое пространство в таблице Q1 2019

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


Таблица показателей отказоустойчивости жесткого диска Backblaze

Прогнозы на остаток 2019 года
В 2019 году, вот несколько предположений относительно того, что может произойти в течение года. Давайте посмотрим, что вы думаете.

К концу 2019 года, что, если таковое произойдет, произойдет следующее? Дайте нам знать об этом в комментариях.
  • Backblaze будет продолжать переносить диски емкостью 4 ТБ, и к концу 2019 года их будет менее 15 000: у нас сейчас около 35 000.
  • Для тестирования мы установим как минимум двадцать 20 ТБ накопителей.
  • Backblaze превысит 1 эксабайт (1000 петабайт) доступного облачного хранилища. В настоящее время мы имеем около 850 петабайт доступного хранилища.
  • Для целей тестирования мы установим как минимум 1 накопитель на основе HAMR от Seagate и / или 1 накопитель MAMR от Western Digital.

Данные о жестком диске
Полный набор данных, использованный для создания информации, использованной в этом обзоре, доступен на нашей веб-странице с данными испытаний жесткого диска. Вы можете скачать и использовать эти данные бесплатно в своих целях. Все, о чем мы просим, ​​это три вещи: 1) Вы цитируете Backblaze в качестве источника, если вы используете данные, 2) Вы соглашаетесь с тем, что несете единоличную ответственность за то, как вы используете эти данные, и, 3) Вы не продаете эти данные кому-либо — это свободно.

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

Удачи и дайте нам знать, если найдете что-нибудь интересное.

Вы спросили нас что-нибудь на Reddit!



Когда вы открываете дверь в Интернет, вы абсолютно не представляете, что произойдет. Это особенно верно для Reddit — главной страницы Интернета и одного из самых популярных в мире веб-сайтов. Поскольку Backblaze гордится прозрачностью нашего бизнеса, решение об участии в IAmA на Reddit было простым. Это была захватывающая возможность рассказать людям о Backblaze и начать разговор с кем-либо в мире, который мог бы привести куда угодно.

Если вы не знакомы с Reddit IAmA (I Am a), это субреддит (/r/IAmA) для интерактивных интервью с вопросами и ответами. Реддиторы могут задавать темы по своему желанию, по этой причине она называется АМА, сокращенно «Спроси меня что-нибудь». Результирующая цепочка комментариев сохраняется в Reddit. Backblaze сделали наш первый AMA в 2012 году, поэтому мы подумали, что пришло время для второго.

Как мы оказались на Reddit?
Двенадцать лет назад, Backblaze была сформирована после того, как друг нашего основателя позвонил, чтобы сказать ему, что ее компьютер сломался. У нее не было резервных копий, и ее данные исчезли. В результате Backblaze была создана, чтобы помочь потребителям и предприятиям создавать резервные копии своих данных самым простым способом, чтобы избежать потери данных.

Всемирный день резервного копирования начался аналогичным образом, когда пользователь Reddit потерял свой жесткий диск и пожелал, чтобы кто-то напомнил им о необходимости его резервного копирования. Небольшая группа в сообществе Reddit осознала важность резервного копирования и растущей тенденции потери данных. В целях повышения осведомленности они создали Всемирный день резервного копирования. С учетом наших целей, в сотрудничестве с World Backup Day и Reddit, Backblaze решила создать IAmA.

В 2012 году Backblaze была небольшой компанией с всего лишь 25 петабайтами данных под управлением и 15 сотрудниками. Большинство из нас участвовали в IAmA в этом году. В то время люди хотели знать о будущем Backblaze и возможности выхода нашей компании из бизнеса. Наш технический директор Брайан Уилсон ответил:
Мы никуда не денемся. Мы счастливы и прибыльны

Семь лет спустя оба эти утверждения все еще остаются в силе.
Конечно, за почти десятилетие многое изменилось. Мы храним более 750 ПБ данных клиентов от клиентов в более чем 150 странах. Наша команда из 15 человек выросла почти до 100. Но некоторые вещи остаются прежними — менее 6% владельцев компьютеров резервируют свои данные один раз в день или больше. Поэтому Backblaze решила вернуться в Reddit, чтобы рекламировать Всемирный день резервного копирования и зарегистрироваться в Интернете.

Еще раз, наиболее одобренный комментарий пришел от нашего технического директора, Брайана. Когда его спросили, почему Backblaze заставляет пользователей делать резервные копии своего диска C, Брайан объяснил, что он написал клиент так, чтобы «решить очень реальную проблему».

Эта проблема
Изначально Backblaze позволяла пользователям отменять выбор своего основного диска. И ужасная проблема появилась почти сразу. Клиенты начали отменять выбор своего диска, потому что они не знали, что диск C содержит данные, которые им могут понадобиться, или просто по ошибке. Затем они обратились бы в нашу службу поддержки и обнаружили, что не смогли восстановить свои данные. Это включало в себя фотографии детей, которые уже скончались (у нас было два случая этой точной ситуации), и другие незаменимые данные, которые теперь ушли навсегда.

Решение
В этот момент Брайан переписал клиент, чтобы принудительно включить основной диск. Это было решение, которое некоторым не нравилось. Однако, по словам Брайана, «исправление сработало потрясающе», и у нас больше нет клиентов, случайно теряющих данные, потому что они отменяют выбор своего накопителя. Основываясь на многочисленных ответах людей, работающих в IT, Брайан понял это правильно. «Программное обеспечение должно быть написано для конечного пользователя», — ответил один из ИТ-специалистов. «Все лучшее и самое популярное программное обеспечение (и оборудование) просты и легки в освоении».

Какие были еще вопросы?
В то время как мы изначально запланировали два часа для IAmA, мы закончили тем, что ушли на пять (наш социальный парень, Yev, может все еще быть там прямо сейчас).

Среди вопросов была пара просьб показать наши хранилища. Мы поговорили о спонсорстве подкастов, прояснили процесс заказа жестких дисков и ответили на сотни вопросов и комментариев. На момент публикации этого поста у нас было более 1300 комментариев.


Интересно было то, как Backblaze продолжает предоставлять действительно неограниченное решение для резервного копирования компьютеров. В нашей отрасли практически все безграничные решения исчезли с рынка. Но Backblaze удвоился за последние несколько лет. Это вызывает вопрос о том, как мы продолжаем устойчиво поддерживать продуктовую линейку. В настоящее время у нас есть один клиент, поддерживающий 430 терабайт за 6 долларов в месяц. По этой цене мы явно теряем деньги на этом клиенте. Тем не менее, большинство наших клиентов имеют гораздо меньше данных. Таким образом, в то время как мы теряем деньги на этом одном клиенте, мы в среднем прибыльны. Есть и другие причины для поддержки выбросов — эти клиенты демонстрируют, что мы действительно безграничны. Ни один сервис, который ограничивал или выборочно создавал резервные копии файлов, не позволил бы создать резервную копию 430 ТБ. Да, это в конечном итоге приводит к издержкам бизнеса, но эти отдаленные клиенты тоже становятся большими евангелистами. Вы не получаете столько данных, не будучи энтузиастом хранилища. Наш технический директор, Брайан, выдвинул еще одну вескую причину: когда продукт работает на действительно большие выбросы, тогда «он будет работать очень гладко для среднего клиента».

Если вы хотите больше узнать о нашей беседе с IAmA, вы можете сделать это на Reddit. Или, если вы хотите сделать резервную копию всех данных ваших конечных пользователей самым простым и надежным способом, мы приглашаем вас попробовать Backblaze Business Backup.

Google+ is Shutting Down: Save Your Content By March 31


Если вы являетесь пользователем Google+, интернет-социальной сети, вы недавно получили уведомление о том, что служба закрывается 2 апреля. Если у вас есть контент в Google+, который вы хотите сохранить, вам нужно получить это к воскресенью, 31 марта.

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

Никакие другие продукты Google (такие как Gmail, Google Фото, Google Диск, YouTube) не затрагиваются. Все фотографии и видео, уже сохраненные в Google Фото, не будут удалены.

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

Если у вас есть данные в Google+, вот как их получить
Как скачать ваши данные.


Больше информации от Google на Google+ Closure
Для получения дополнительной информации см. Полный FAQ по отключению Google+.
support.google.com/plus/answer/9217723

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

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

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

Пять лучших практик для обеспечения безопасности ваших цифровых медиа
1 — Храните несколько копий ваших медиа файлов
К настоящему времени каждый, вероятно, знаком со стратегией 3-2-1 для поддержки нескольких копий ваших данных (видео, фотографии, каталоги управления цифровыми активами и т. Д.). Следование стратегии 3-2-1 просто означает, что у вас всегда должно быть как минимум три копии активных данных, две из которых являются локальными, и как минимум одна находится в другом месте.


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

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

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

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

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

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

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

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

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

5 — Будьте внимательны к безопасности в вашем рабочем процессе
Никто не хочет постоянно беспокоиться о безопасности, но если ее игнорировать, рано или поздно это невнимание настигнет вас. Лучший способ повысить безопасность ваших данных и уменьшить стресс в вашей жизни — это разработать план и реализовать его.

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

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

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