?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Про бэкапы и домашний сервак - работает ли, доволен ли - morfizm

Nov. 28th, 2015 01:47 am Про бэкапы и домашний сервак - работает ли, доволен ли

В целом я доволен полученным опытом - это было интересно, прикольно, узнал много нового. Это был опыт из разряда "создай работающую модель реактивного самолёта из лего". Да, в результате кропотливой работы таки получается реактивный самолёт, и он даже летает, если очень аккуратно его запускать, и чинить когда ломается. Но при этом куда более cost-effective купить box solution с воздушным змеем или вертолётиком на радиоуправлении. В общем, те, кому не нужен реактивный самолёт, или кто не любит кропотливо собирать поделки из лего и потом их чинить, когда ломаются, не советую. В качестве забавного хобби-проекта - наоборот, рекомендую.

Что получилось в результате:

1. Сервер Lenovo Thinkserver TS140 70A4001LUX (такой или такой). Удачная и недорогая модель: он очень тихий. С кучей хардов в режиме "always on" он тише моего десктопа, даже когда он непрерывно делает random seek'и по хардам. В корпус легко влезают 5 хардов на 3.5" и 3x SSD. Я использую SAS card - IBM M1015 / 9220-8i SAS RAID Card - Flashed to LSI-9211-8i IT MODE.

2. 5 хардов на 3.5", модель WD Red (раньше были других моделей, но они постепенно умирали и я их заменял на WD Red, которые лучше), сейчас объёмы 2+3+3+5+5, с файловой системой ZFS в режиме RAID-Z2, т.е. два диска на избыточность, и три на данные. Используется только минимальный одинакового размера кусок с каждого диска, т.е. 2+2+2+2+2, т.е. 6 T на данные + 4 T избыточности. ZFS начинает сильно тормозить если заполнение выше 80%, поэтому реально полезного места под данные чуть меньше 5 T.

3. 3 SSD-диска, 2 на 120 GB (mirror configuration for ZIL, это transaction log, для ускорения записи), 1 на 160 GB (L2ARC, это read-кэш, для ускорения чтения). Специально выбирал Intel SSD 320 Series - SSDSA2BW12 (firmw 0362) - они надёжнее на случай отрубания питания, т.к. имеют конденсатор, дающий несколько миллисекунд работы, чтобы сбросить кэш на диск и не запороть данные. Более новые модели консьюмерских Intel дисков этого не имеют :) Забавно. Правда, я ещё использую UPS: CyberPower EC650LCD Ecologic 650VA/390-Watts.

4. Один канал гигабитного ethernet. При чтении не из кэша, эффективные IOPS примерно 400, и для больших файлов скорость передачи около 110 MB/sec. Это близко к максимально полной утилизации гигабитного канала. Почитайте форумы, там разный overhead из-за которого максимум несколько ниже 119 MB/sec, и всего 7.5% overhead'а это очень удачный результат. Кстати, "гигабитный канал" это 10^9 бит, а скорость копирования обычно в мегабайтах, которые 1 MiB = 2^20. Кстати, полученная скорость с учётом полного шифрования данных на дисках.

5. USB 3.0 docking station, к которой подключён бэкапный диск. Второй бэкапный диск off-site. Раз в два месяца rotation. Бэкапы, разумеется, тоже зашифрованные. Сейчас в rotation диски на 6 T и на 5 T. Эти диски тоже WD Red, в целях удобства upgrade. Например, когда 5 T мне будет мало, я куплю второй бэкапный диск на 6, а старый на 5 уйдёт внутрь вместо самого маленького, который там на 2. Тогда минимум станет 3, а не 2, т.е. 9 T на данные и 6 T на избыточность, 80% от 9 T - чуть меньше 8 T. Но теперь узкое место будут бэкапы, т.е. максимум 6 T. По сути, заплатил за 6-терабайтный диск, и увеличил объём полезного места на 1 T. Следующий апгрейд - подождать, пока появятся WD Red-ы на 8 T и заменить оба бэкапных диска (потратив деньги на 2 диска по 8 T, и приобретя ещё 2 T полезного места).

Я делал моделирование постепенных апгрейдов, с учётом всех избыточностей, а так же с учётом того, что покупать нужно самые большие диски, для которых цена за терабайт не оптимальна, там получается в среднем порядка 12:1 (платишь как за 12, приобретаешь 1). Радует только то, что пользователи, которые думают, что для получения +1 T свободного места достаточно заплатить за 1 T, это те пользователи, которые потом уныло разводят руками в случае сбоев и "потери всего". Я последний раз "терял всё" очень много лет назад, когда умерла моя единственная (на тот момент) 5-дюймовая дискета, мне было лет 11. После этого я научился записывать на 3 дискеты. Со временем я научился на каждую писать в нескольких копиях. Потом я научился записывать большие пустые файлы между копиями, чтобы при повреждении соседних дорожек, одна из копий всё ещё читалась. Я научился пользоваться ключом -rr в rar - добавление recovery record (на самом деле, сначала я научился ключу -hk в arj :)). Короче, сегодняшний setup это логическое продолжение давно начатого.


В 2015, по сравнению с 1995, появились новые проблемы сохранности данных:

1. Большие объёмы. На "одну дискету" (один жёсткий диск) всё уже не влезает. Несколько это сразу сложность. Я очень надеюсь, что в обозримом будущем появятся доступные SSD-диски большого размера (вроде 8 TB), и тогда можно будет опять упрощать и сводить к "одной дискете", возможно, повторенной несколько раз, не жертвуя скоростью доступа.

2. Объёмы настолько большие, что сбой чтения сектора на жёстком диске - не просто редкая неудача, а, скажем так, весьма вероятное и весьма ожидаемое событие при чтении всего диска подряд от начала до конца всего лишь один раз. Мне вначале казалось, что конфигурация Raid-Z2 (два избыточных диска из набора) делается для того, чтобы избежать проблем, когда второй диск "полетит" вскоре вслед за первым. Это действительно валидная проблема, особенно когда диски одной модели и из одной серии (есть корреляция сбоев, лучше покупать разные/отдельно, а не сразу несколько), но только для автоматической защиты от этой проблемы делают Raid-Z3. Raid-Z2 обычно делают для защиты от случайных сбоев чтения во время процесса "resilvering"-а. Raid-конфигурации предполагает последовательное чтение всех дисков для воссоздания избыточного диска. В этом процессе есть довольно значительный шанс ошибок чтения. Настолько значительный, что Raid-Z никто не советует использовать, даже дома. Минимум Raid-Z2. На самом деле, Raid-Z использовать можно, если не лень потом вручную восстанавливать побитые файлы из долгосрочного бэкапа, но это дополнительная ручная работа, плюс больше зависимостей на сохранность бэкапа (куда безопаснее минимизировать такие зависимости). Raid-Z3 пока используют только для производственных систем, не для дома.

3. Объёмы настолько большие, что "альфа-частица, попавшая в оперативную память, и вызвавшая bit flip" (случайную замену бита 0 на 1 или наоборот) - уже довольно вероятное событие. Я регулярно проверяю контрольные суммы на своих старых архивах, и наблюдал своими глазами файл, побитый в одном отдельном бите одного отдельного байта. Многие из современных форматов файлов, особенно не исполняемых, а "данные" (видео, фото, музыка) могут поглотить ошибку в одном бите - будет незаметный неправильный пиксель или вроде того. Но если этот бит попадёт в управляющие структуры, или в сжатый поток, то файл может вообще не открываться из-за такой ошибки. Если bit flip произойдёт при сбросе кэша метаданных файловой системы, то можно испортить не один файл, а много. В общем, bit flip-ы - реальная проблема даже для домашнего файлового сервера. Решение с FreeNAS + ZFS защищает от этого, потому что на всех операциях end-to-end checksumming, главное при этом использовать ECC-RAM (оперативную память, в которой не 8 бит на байт, а 9, один идёт на чётность). От одновременно двух bit-flip'ов оно не защитит (это всё ещё почти невероятное событие), но защитит от одного. ECC-RAM уже требует серверного билда, чтобы материнская плата и процессор её поддерживали. Многие NAS-девайсы, вроде Synology, дают ECC только для дорогих энтерпрайз-сборок. По этой причине они были мной забракованы при рассмотрении.

4. Эволюция форматов файлов. Файлы, сделанные очень давно, могут в какой-то момент просто перестать открываться. Или нужно будет ставить виртуальную машину, чтобы запускать OS 10-летней давности, в ней запускать вложенную виртуальную машину, чтобы запускать OS и приложение 20-летней давности, но вторая вложенная сама по себе не запустится, потому что она настолько устарела, что её можно запускать только из первой :) Ну и искать приложения 20-летней давности, к которым уже давно нет лицензионных версий, ключей, саппорта и прочего. По этому фронту я сделал довольно мало, но ещё лет через 10 эта проблема может стать актуальнее. Письма из разных систем я уже давно объединил в Outlook PST-файле, и там их храню. Но вот чаты нет. У меня куча логов от IRC/ICQ. С ними проще, это текстовые файлы. Но вот, скажем, логи Miranda это один ".dat"-файл, для которого когда-нибудь придётся писать парсер, если я захочу развлечения ради поднять эти логи. Файлы я, на всякий случай, храню, а парсер писать лениво :) Но надвигающаяся проблема чувствуется. Будет очень неприятно, если когда-нибудь перестанут открываться MHT/MHTML файлы - это файлы, содержащие всю страницу, включая CSS, JS и картинки в виде MIME-stream'а, как аттачменты в письмах. В этом формате я сохраняю понравившиеся мне веб-страницы, а также даже записи своего блога, потому что материал в интернете сегодня есть, а завтра нет, а если что-то понравилось, хочется иметь возможность, к этому вернуться. Надеюсь, есть люди, которые меня понимают :)

FreeNAS + ZFS решает первые три проблемы, плюс даёт performance и encryption.
К сожалению, он создаёт ряд новых проблем:

- FreeNAS вообще-то производственная система, требующая человека на обслуживании. Да, для домашних энтузиастов она годится, но только для энтузиастов, не для "нормальных людей". Нормальные люди должны были бы нанять обслуживающего человека, и это непропорционально дорого для домашних целей. Например, чтобы банально сделать rotation бэкапных дисков, я трачу минут 10 и исполняю сложную последовательность шагов, в которую входит SSH на сервер и запуск custom-script'а, чтобы изменить метки всех snapshot'ов так, чтобы FreeNAS репликация их заново копировала на новый диск.

- У FreeNAS сильно недоработана поддержка encryption. Один неровный шаг и что-то не работает, нужно заново создавать массив и восстанавливать данные из бэкапа. Таких шагов я сделал больше десятка. Уже научился "обходить все мины", но это дорого стоило. Опять же, в производственных системах encryption на уровне файловой системы, видимо, слишком редко нужен, а что непроизводственный сценарий, то плохо поддерживается.

- ZFS отличная файловая система, пока она работает. А когда возникает сбой, восстановление это мегагемор. Я умею идентифицировать и восстанавливать лишь некоторые изолированные проблемы, вроде битых файлов после corruption'а, но это настолько геморно, что я давно уже перестал это делать, считаю датасет убитым, и восстанавливаю его целиком из свежего бэкапа. За год я раз пять восстанавливал рабочий датасет, и раз в месяц пересоздаю бэкапный датасет (из-за сбоев, о которых ниже).

- USB 3.0 поддерживается плохо, а eSATA слишком чувствительный к reset'у, возникающему от малейших движений вокруг сервера. В свою очередь, ZFS уже слишком чувствительный к таким reset'ам, и, как правило, портит dataset. Самое дешёвое - считать его мёртвым и восстанавливать из бэкапа, или же, если это и есть бэкап, удалять его и заново создавать, а пока это происходит (скажем, сутки) - жить лишь с одним полным бэкапом 1-2 месячной давности. Что есть стрёмно, когда такое происходит регулярно. Я предпочитаю иметь рабочий датасет + два бэкапа, а ситуацию, когда из 3 живы только 2, это либо внештатная ситуация (что-то сломалось), либо крайне редкая и тщательно контролируемая, и при этом я заранее освежу все бэкапы, чтобы они не были застарелыми.

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

Для тех, кто захочет повторить мой путь и выбрать новое решение для домашнего файлового сервера, рекомендую против варианта с FreeNAS. Несколько общих советов:
- Старайтесь избегать любых Raid конфигураций кроме mirror из двух дисков. Для дополнительной избыточности лучше использовать софтварные решения по синхронизации. Хорошие Raid-контроллеры могут делать mirror (Raid-1) с удвоением IOPS на чтение, что будет good enough для домашних целей. Write-кэши и read-кэши можно реализовать через SSD + специальные директории и скрипты, которые будут копировать/переносить. Мне кажется, это было бы дешевле по обслуживанию, чем использование all-in-one "автоматических" решений, не важно, hardware-ных или software-ных. Ну или вообще отказаться от кэшей и терпеть тормозню.
- Старайтесь избегать нестандартных файловых систем. Выбор файловой системы должен быть такой, чтобы можно было вставить диск в другой компьютер, и на нём запустить инструменты для восстановления.
- Я не уверен, что вообще существует хорошее решение "для дома", дающее полный гигабит скорости и низкий latency, при этом дающий encryption, redundancy и защиту от bit flip'ов. FreeNAS + ZFS как бы всё это даёт, но очень большой кровью. От чего-то из требований надо отказаться, и, скорее всего, это будет performance.
- Для защиты от bit flip'ов нужно искать какое-то софтварное решение для checksumming'а, которое в нужный момент скажет, что файл требуется восстановить из бэкапа.

13 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:gineer
Date:November 28th, 2015 11:32 am (UTC)
(Link)
Интересно. Спасибо.
From:morfizm
Date:November 29th, 2015 01:45 am (UTC)
(Link)
Пожалуйста! Если вам интересно, вот предыдущие мои посты по теме (большинство, правда, на английском):

FreeNAS + ZFS: Raid-Z or RaidZ2
Want FreeNAS+ZFS as a home server? Think twice.
Storage explorations
Home Storage
Идея для внешнего бэкапа
Storage system at home
From:archaicos
Date:November 28th, 2015 04:55 pm (UTC)
(Link)
Спасибо!
From:morfizm
Date:November 29th, 2015 01:45 am (UTC)
(Link)
Пожалуйста!
From:soloviewoff
Date:November 29th, 2015 04:33 am (UTC)
(Link)
Интересно, спасибо!

> Но при этом куда более cost-effective купить box solution с воздушным змеем или вертолётиком на радиоуправлении.

Какие есть достойные box solutions?

From:morfizm
Date:November 29th, 2015 04:57 am (UTC)
(Link)
В том-то и дело, что достойных таки нет. Я не спроста использовал метафору с реактивным самолётом и воздушным змеем или вертолётиком на радиоуправлении. Box solution с вертолётиком будет на порядки дешевле, но он тебе подойдёт только если тебя устроит range & performance вертолётика :)

На мой взгляд, "разумное" для дома решение не будет одновременно удовлетворять всем требованиям. А когда ты решишь, какими требованиями ты готов поступиться, будет понятнее, что из имеющегося тебе подойдёт. Моя рекомендация по общим впечатлениям - в качестве отдельного файлового сервера не покупать ничего сложнее тривиального NAS-а, делающего RAID-1 с какими-нибудь известными файловыми системами (NTFS или ext4), и, возможно, дающего ethernet/wifi без больших требований по performance. Далее - стараться минимизировать сценарии, когда нужно из центрального места напрямую стримить важные файлы. Стараться использовать этот внешний storage только для бэкапов, а файлы держать на desktop node. В нём уже балансировать комбинацией из SSD для скорости и internal HDD для места, но redundancy не нужен, если есть регулярные бэкапы с 2x redundancy (mirror). Можно ещё подумать над вариантами. Я не вижу хорошего решения :) Я могу только рассказать, чем плохи те решения, что я пробовал. В своё время WHS подавал надежды. Он умер, но вроде как заменён на "Storage Spaces" (available in Win8+ и в серверных OS начиная с какой-то). Я не пробовал. Ещё альтернатива - вообще "забить" на redundancy in one box, вместо этого настроить rsync/robocopy или несколько backup-ов в разные места. Тогда картинка тоже упрощается. Любой вариант оптимизации, где используется софтварный или хардварный RAID не в mirror, должен включать workflow, когда ты вообще никогда не разбираешься в проблемах, а просто пересоздаёшь весь массив (иначе будет много гемора). Но если рассчитывать на пересоздание массива, нужна система со свежими бэкапами - регулярными, инкрементальными, надёжными. Лучше всего вообще continues, типа time machine. Если делать регулярные бэкапы, нужен автоматический space management, garbage collection, и т.п. - уже опять усложнение. Короче, there is no silver bullet. Ждём SSD на 8TB :)
From:soloviewoff
Date:November 29th, 2015 07:34 am (UTC)
(Link)
А простые NAS-ы из коробки делают скраббинг, или это как настроишь? Без скраббинга страшно.
From:morfizm
Date:November 29th, 2015 07:59 am (UTC)
(Link)
Нет ничего проще настройки скраббинга.

1.
Windows: xcopy /E F:\*.* nul
Task Scheduler -> создаёшь task

2.
*nix: cp -r /mnt/server/* /dev/null
Редактируешь crontab :)
From:morfizm
Date:November 29th, 2015 08:08 am (UTC)
(Link)
(С клиента, конечно)
From:morfizm
Date:November 29th, 2015 08:09 am (UTC)
(Link)
Но вообще скраббинг у тебя будет автоматом, если ты настроишь внешний бэкап. Без внешнего бэкапа намного страшнее, чем без скраббинга.
From:soloviewoff
Date:November 29th, 2015 08:32 am (UTC)
(Link)
Бэкап сейчас на старом добром Google Drive, кроме чего-то совсем приватного. Вопрос в том, отдать ли совсем все в клауд и не морочиться, или есть не сильно геморройные / дорогие решения домашнего характера.

> *nix: cp -r /mnt/server/* /dev/null

Хотелось бы, чтобы скраббинг в случае ошибок сам восстанавливал данные (т.е. должна быть избыточность) на новое, хорошее место на сбойнувшем носителе. А меня уведомлял только, если уже совсем перелоцировать некуда, т.е. диск надо менять. Наверное, правда, современный винчестер при регулярном чтении это сделает и в одиночку, почуяв, что сектор читается не с первого раза и его пора переносить, но не знаю, насколько этому можно доверять.
From:morfizm
Date:November 29th, 2015 09:19 am (UTC)
(Link)
Если тебе хватает места на Google Drive, ты можешь сделать простой скрипт, реплицирующий локальный каталог в encrypted архив, тогда вопрос доверия клауду тебя не будет волновать.

Достаточно, чтобы была инфа о нечитаемом файле - его можно восстановить из бэкапов. (Если ты не считаешь нужными регулярные бэкапы для common storage, то у нас с тобой совсем разные приоритеты, тут разговаривать будет больше не о чем :)). Дальше: имея хорошие бэкапы с возможностью удобного пофайлового восстановления, если ты как-то решишь проблему битфлипов, то автоматически решишь проблему accidental failed reads. Решать только второе без первого - вещь сомнительной нужности.
From:livejournal
Date:December 1st, 2015 02:40 am (UTC)

Backup

(Link)
User metaller referenced to your post from Backup saying: [...] Прочитав пост товарища о бекапе [...]