Что такое бэкапы в программировании

Что такое «Бэкап» и как его сделать

Бэкап (backup) — что это за операция

Зачем делать бэкап

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

Как сохранять информацию

Существует несколько разновидностей бэкапов. Один (полный) подразумевает копирование всей ИТ-системы, остальные (дифференцированный, инкрементный, создание образа и т. д.) затрагивают отдельные файлы и директории.

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

Для экономии пространства резервные копии сохраняют в архиве. Сведения сжимают и разархивируют специальными программами.

Где хранить backup

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

Бэкап веб-сайтов

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

Также бэкап исполняют в следующих ситуациях:

Источник

Что такое «backup»?

Очень часто я слышу фразы вроде «зачем мне бэкап, у меня же есть RAID!». Или «я делаю бэкапы на второй HDD в сервере!». Или что-то подобное. Очень часто через несколько месяцев после этого я слышу вопрос «а как мне восстановить убитые данные?». И это печалит.

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

Большинство, думаю, ничего для себя нового не найдет, но если вы все еще относитесь к категории тех, кто бэкапы не делает или делает, но это не бэкапы — добро пожаловать!

Требования?

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

Едем дальше. Если мы делаем копию данных, значит, боимся их потерять. Так? Так. Значит, все резервируемые данные для нас ценны. Так? Снова так. Отсюда второе требование — целостность. Не смысла в копировании без проверки целостности — на выходе мы вполне можем получить битые данные или потерять часть безвозвратно.

Ну и хватит, наверное. Статья ориентирована на SOHO-пользователей, а не на энтерпрайз, поэтому требования к безопасности, скорости disaster recovery, ограниченной избыточности и прочему мы рассматривать не будем.

И что в итоге?

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

Ближе к практике.

Анализируя существующую или придумывая для себя новую СРК — подумайте, соответствует ли она критериям, изложенным выше?
Пересекаются ли в одном месте основная и резервная копия? Обеспечивается ли при этом изолированность резервной? Существует ли возможность одновременно изменять файлы в основном и резервном хранилище? Существует ли значительная (более значительная, чем атомный взрыв) вероятность того, что оба носителя будут одновременно уничтожены или утеряны? Если ответ на любой из этих вопросов «да» — в системе есть ошибка. К примеру, если вы сделали бэкап файлов с ноутбука на usb flash и убрали ее в сейф — вы молодец. Если вы сделали этот бэкап и положили флешку в сумку к ноутбуку — вы не сделали бэкап.

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

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

Проведите «учения» — представьте, что основной носитель утрачен и попытайтесь восстановиться. Уверен, с первого раза у вас ничего не выйдет, или выяснится, что многое на самом деле не совсем так, как вы представляли ранее.

Ответили? Провели? Все прекрасно? Нет, не совсем. Не забывайте о СРК. Поддерживайте ее в актуальном состоянии. Начали использовать новое ПО? Внесите его каталоги в список на бэкап. Подумайте, как его восстанавливать. Следите за состоянием резервного носителя (если это одиночный диск, флешка или NAS — он совсем не вечный). Думайте о своих данных, кроме вас этого не сделает никто.

Мифы и примеры плохих решений

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

Вместо заключения

Берегите свои данные, потратив 15 минут «до» — можно сэкономить 15 часов «после». Не забывайте бородатый анекдот про тех, кто не делает бэкапы и тех, кто их уже делает.

Источник

Что такое бэкап, зачем он нужен и как его делать

Каждый разработчик однажды ЛИШИЛСЯ ВСЕГО, потому что не сделал бэкап.

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

А может быть и так: пишешь диплом, уже на 99-й странице, всё хорошо. Тут кошка запрыгивает на компьютер и лапами своими вонючими нажимает Ctrl + A, а потом Del, а потом Ctrl + S и Alt + F4. В результате у тебя стирается весь текст, документ сохраняется, а «Ворд» закрывается. И теперь, если открыть этот документ, там будет чистый лист, который невозможно восстановить.

Единственное, что может спасти эти ситуации, — бэкапы.

Что такое бэкап

Бэкап (backup) — это резервная копия данных: либо всех подряд, либо каких-то конкретных и особенно важных.

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

🤔 Пример самого элементарного бэкапа — отправить важный файл самому себе на почту Яндекса. Копия файла сохранится в почте, и в случае чего её можно будет восстановить. Минус в том, что это нужно делать вручную, а потом важно случайно не удалить ненужное письмо.

Как его делать

Чтобы бэкапы реально работали, их надо делать заранее — автоматически или вручную. Главная ошибка — начать думать о бэкапах, когда данные уже утеряны. Тогда-то уже поздно.

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

Вот самый простой способ, который вы можете попробовать прямо сейчас:

Теперь в случае чего у вас есть копия на сервере Яндекса. Её видите только вы по своему паролю.

На Яндекс-диске хранятся копии текущих проектов, чисто на всякий случай. Отсюда же этими копиями можно с кем-то поделиться

Ключевые слова

Несколько терминов, связанных с резервным копированием, которые полезно знать.

Облако — компьютер где-то в интернете, на котором хранятся какие-то данные или исполняются какие-то приложения. Применимо к резервному копированию: можно хранить часть своих бэкапов в облаке, то есть на компьютере где-то в интернете. Так делают сервисы типа Dropbox и Яндекс-диск.

Версионирование — это когда вы сохраняете не только самую свежую копию проекта, но и несколько предыдущих его версий. Например:

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

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

Зеркало — полная копия компьютера или сервера. Как правило, делается автоматически: например, каждую ночь ваш компьютер может делать полный «слепок» файловой системы и складывать его на зеркальный жёсткий диск.

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

Если враги вынесут всю технику и жёсткие диски из офиса, у вас останется резервная копия у Яндекса.

Рядом с ноутбуком — небольшой NAS от компании Synology. В прямоугольных отсеках стоят жёсткие диски, на них происходит резервное копирование

NAS — network attached storage, сетевое хранилище. Это коробочка, в которой стоят жёсткие диски. К ней можно подключиться по локальной сети и сливать на неё свои бэкапы, в том числе в автоматическом режиме. Полезно, когда у вас в офисе несколько компьютеров и всем нужно хранить где-то бэкапы.

RAID — система, которая помогает делать избыточные копии данных и защищает от сбоёв жёстких дисков. У вас может быть четыре жёстких диска, объединённых в RAID-массив. Если один из них сломается, его можно будет восстановить по кусочкам данных с других дисков. Всё это автоматически.

Флешка. Самый простой способ сделать бэкап — скопировать важные файлы на флешку и убрать её в шкаф. Шкаф нужен для того, чтобы в случае отказа питания или шумной вечеринки флешка точно осталась нетронутой.

Облачное хранилище Dropbox: в 2020 году автор статьи осознал, что у него там хранятся бэкапы аж с 2010 года. 10 лет работы аккуратно заархивировано и доступно для изучения!

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

А вот архив — это про долгосрочное хранение. Сделал ты проект, сдал и теперь хочешь, чтобы он сохранился лет на 50, чтобы в старости можно было перебирать воспоминания. Вот это архив.

Требования к архиву отличаются от требований к бэкапу. Архив должен быть нерушимым и рассчитанным на десятки лет. Флешки и компакт-диски для архивов не подходят — они деградируют и «сыпятся». Магнитные жёсткие диски нужно периодически «обновлять».

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

Печатные копии особенно актуальны для фотографий: вангуем, что через 20 лет вы уже десять раз смените телефоны, и фотографии из 2020-х у вас не сохранятся. А если дома лежит альбом с распечатанными фотографиями, то он сможет погибнуть только в случае пожара. Осторожнее с кальянными углями!

В следующий раз

В одной из будущих статей сделаем обзор на существующие системы и сервисы бэкапов: что использовать, когда и за какие деньги. Подписывайтесь и приходите снова!

Источник

Резервное копирование, часть 1: Назначение, обзор методов и технологий

Идеальная программа работает быстро, не течет по оперативной памяти, не имеет дыр и не существует.

Поскольку программы все еще пишутся белковыми разработчиками, а процесс тестирования зачастую отсутствует, плюс поставка программ крайне редко происходит с применением «best practices» (которые сами по себе тоже программы, а следовательно, неидеальны), системным администраторам чаще всего приходится решать задачи, которые звучат кратко, но емко: «вернуть, как было», «привести базу к нормальной работе», «медленно работает — откатываем», а также мое любимое «не знаю что, но почини».

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

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

Хорошие художники копируют, великие художники воруют.

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

Например, у птиц и у самолетов есть крылья, однако несмотря на функциональную схожесть — принцип действия в некоторых режимах совпадает, и технические проблемы решаются аналогично: полые кости, использование прочных и легких материалов и т.п., — результаты абсолютно разные, хоть и весьма похожие. Лучшие образцы, которые мы наблюдаем в нашей технике, также по большей части заимствованы у природы: герметичные отсеки у кораблей и подводных лодок — прямая аналогия с кольчатыми червями; построение raid-массивов и проверка целостности данных — дублирование цепочки ДНК; а также парные органы, независимость работы разных органов от ЦНС (автоматия работы сердца) и рефлексы — автономные системы в Интернет. Конечно брать и применять готовые решения «в лоб» чревато проблемами, но кто знает, может, других решений-то и нет.

Знать бы, где упадешь — соломки подстелил бы!

—Белорусская народная пословица

Значит, резервные копии жизненно необходимы тем, кто желает:

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

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

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

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

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

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

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

— Есть два вида системных администраторов, те кто не делает резервные копии, и те, кто УЖЕ делает.
— На самом деле три вида: есть еще те, кто проверяет, что резервные копии можно восстановить.

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

Под форматом хранения следует понимать следующее:

С точки зрения готовности резервной копии по ее прямому назначению — восстановлению работоспособности, — различают «горячие» и «холодные» резервные копии. Горячие от холодных отличаются только одним: они сразу же готовы к работе, в то время как холодные для восстановления требуют некоторых дополнительных действий: расшифровки, извлечения из архива и т.п.

Не стоит путать горячие и холодные копии с online и offline копиями, которые подразумевают физическую изоляцию данных, и по сути, являются другим признаком классификации способов резервного копирования. Так offline копия — не подключенная непосредственно к системе, где ее надо восстановить, — может быть как горячей, так и холодной (с точки зрения готовности к восстановлению). Online копия может быть доступна непосредственно там, где ее надо восстанавливать, и чаще всего является горячей, но бывают и холодные.

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

Разностные инкрементальные копии — попытка сэкономить размер пространства для хранения резервных копий. Таким образом в резервную копию пишутся только измененные данные с прошлой резервной копии.

Разностные декрементальные создаются с той же целью, но немного другим путем: делается полная резервная копия, но реально хранится только разница между свежей копией и предыдущей.

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

(Кто устережет самих сторожей? — лат.)

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

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

Целостность исходных данных можно гарантировать несколькими способами. Наиболее часто используются следующие: а) создание слепков файловой системы на блочном уровне, б) «заморозка» состояния файловой системы, в) особое блочное устройство с хранением версий, г) последовательная запись файлов или блоков. Также применяются контрольные суммы, чтобы обеспечивать проверку данных при восстановлении.

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

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

Знает толк в пряностях не тот, кто добавляет их в каждое блюдо, но тот, кто никогда не добавит в него ничего лишнего.

Практика в части применяемого ПО у системных администраторов может различаться, но общие принципы все равно, так или иначе, те же, в частности:

Для снятия резервных копий с блочных устройств есть следующие распостраненные программы:

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

Итак, для небольшого сервера нужно обеспечить схему резервного копирования, отвечающую следующим требованиям:

В качестве тестового стенда будет применяться виртуальная машина (на базе XenServer) со следующими характеристиками:

Операционная система — Centos 7 x64: разбивка стандартная, дополнительный раздел будет использоваться как источник данных.

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

Prime numbers limit: 20000

Initializing worker threads…

CPU speed:
events per second: 836.69

Throughput:
events/s (eps): 836.6908
time elapsed: 30.0039s
total number of events: 25104

Latency (ms):
min: 2.38
avg: 4.78
max: 22.39
95th percentile: 10.46
sum: 119923.64

Threads fairness:
events (avg/stddev): 6276.0000/13.91
execution time (avg/stddev): 29.9809/0.01

Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global

Initializing worker threads…

Total operations: 50900446 (1696677.10 per second)

49707.47 MiB transferred (1656.91 MiB/sec)

Throughput:
events/s (eps): 1696677.1017
time elapsed: 30.0001s
total number of events: 50900446

Latency (ms):
min: 0.00
avg: 0.00
max: 24.01
95th percentile: 0.00
sum: 39106.74

Threads fairness:
events (avg/stddev): 12725111.5000/137775.15
execution time (avg/stddev): 9.7767/0.10

Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global

Initializing worker threads…

Total operations: 35910413 (1197008.62 per second)

35068.76 MiB transferred (1168.95 MiB/sec)

Throughput:
events/s (eps): 1197008.6179
time elapsed: 30.0001s
total number of events: 35910413

Latency (ms):
min: 0.00
avg: 0.00
max: 16.90
95th percentile: 0.00
sum: 43604.83

Threads fairness:
events (avg/stddev): 8977603.2500/233905.84
execution time (avg/stddev): 10.9012/0.41

Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads…

Throughput:
read: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
write: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

Latency (ms):
min: 0.00
avg: 0.27
max: 18.01
95th percentile: 1.08
sum: 238469.45

Источник