Re: Стратегия поддержания резервных копий. Деградация носителей.
*** Tim Sattarov <stimur@gmail.com> [2017-06-24 01:18]:
>У меня сейчас одна задача с большим количеством (несколько терабайт)
>мелких и уже сжатых файлов: это ElasticSearch
>причём в AWS. где диски можно подобрать разные, но они все "сетевые"
>(EBS), то есть есть некоторая задержка в доступе.
>Там же важна скорость чтения.
Мне кажется что тут стоит попробовать ZFS. С мелкими файлами, как и в
XFS, проблем нет. Если это, кстати, сжатые .gz/whatever файлы, то на ZFS
можно включить прозрачное сжатие zlib и тогда на ФС будут хранится
просто файлы, без архивов, но на самом деле сжатые. Просто удобна
прозрачность.
>А какой смысл держать ZFS на рабочей машине/лаптопе ? Не придираюсь,
>реально интересно.
Ммм, не хочу чтобы ответ показался грубым, но какой смысл не держать ZFS
если есть возможность :-)? Как-минимум:
* snapshot-ы. Если нужно быстренько что-то проверить/сделать, и при этом
откатить назад файлы, то можно сделать snapshot (за секунду
выполняется) а потом его откатить (снова секунда). Знаю что многие
люди говорят что я и без этого жил, но это точно так же как
пользователь CVS или Subversion скажет что ему бранчи не нужны, но
когда он с ними столкнётся в Git-е, то поймёт насколько это удобно.
Или вот например у меня была система где я rsync-ал репозиторий с RPM
пакетами, которые могли ломаться время от времени. Так там каждый день
делался snapshot и я к нему мог обратить по
/path/to/fs/.zfs/2017-04-05/ пути где полная ФС на тот день. Это очень
удобно. С LVM не сравниться, потому-что LVM это блочное устройство
ничего не знающее про ФС на нём, и нужно предпринимать особые действия
чтобы, во-первых, сделать снимок (например xfs_freeze) безопасно,
во-вторых восстановить его, в-третьих, обратиться к предыдущим его
версиям. В ZFS это либо ровно одна команда на всё, либо обращение
просто по особому пути ФС
* удобство backup-ов, которое тут обсуждают. Сделали snapshot, а дальше
zfs send snapshot@name и у вас полная копия всех данных/метаданных со
всеми настройками ФС в удобном stdout-е, который можно на лету сжать,
зашифровать и передать куда надо. Восстановление -- одна команда zfs
recv. Нужны инкрементальные backup-ы? Просто указываете что хотите
дельту вместо полного дампа. Это приятно всё тем, что даже не надо
думать а сохраняться ли все права или флаги на файлах при
использовании tar, а какие опции для этого нужны, итд, итд.
* мне например приходилось работать с большими PostgreSQL и MongoDB
данными. MongoDB хранит всё в JSONB, который очень хорошо сжимается
даже LZ4. БД например должна занимать 60 GiB диска, но с LZ4 сжатием
прозрачным, которое на CPU вообще не заметно, оно сокращалось до 20
GiB. Плюс так как в ZFS свой собственный кэш ФС используется, то и в
памяти будут кэшироваться именно эти 20 GiB, а не разжатые части 60-ти.
А у меня 100 GB SSD, где сэкономленные десятки гигабайт это очень приятно.
* я очень переживаю за целостность данных. ОЧЕНЬ. с ZFS и его zfs scrub,
который мне каждый байтик напротив Skein (раньше напротив SHA256)
проверит -- убирает психологическое напряжение полностью. У меня в
cron стоит раз в 4-часа создание очередного snapshot, генерирование
инкрементального бэкапа и отсылка его в сжатом и зашифрованном виде
(всё красиво через | xz -0 | gpg -r backup -e | nncp-file - делается)
в NNCP который раскидывает на две машины. Когда прихожу домой, то
прозрачно у меня на домашний сервер сбрасываются все недоброшенные
4-часовые слепки всех данных (из них можно *полностью* восстановить
всё состояние диска), когда прихожу домой, то прозрачно добрасываются
на рабочий компьютер. Если внезапно SSD/whatever упадёт, то у меня
мизерной ценой (а не обмазками всюду shell-скриптами) везде полные
компактные копии данных. И не надо думать где размещать
checksum.sha512 или что-то подобное и как его считать. Вся эта
головная боль убрана.
* в домашнем сервере используется зеркало ZFS-ное. Это конечно мелочь,
но приятно что я могу просто взять и достать диск, протереть от пыли,
пропылесосить, вставить, сделать resilvering, который мне покажет что
"ok, синхронизировал 6 MiB данных, зеркало снова *полностью* в строю",
потом достать второй диск и всё то же самое. С RAID/LVM это
невозможно, потому-что они обязаны будут полностью переrebuild-ить все
эти 3 TB данных. Плюс у меня третий диск есть, в шкафчике, который я
раз в месяц добавляю, он делает resilvering (не трёх терабайт, а
только diff-а), убираю снова в шкафчик, зная что там у меня есть
offline архивная копия всех данных
Если коротко, то я бы это мог сравнить со своими ощущения перехода от
Subversion к Git. Я не понимал чем он лучше, пока не попробовал. Сейчас
SVN/CVS я использую только в страшном сне. ZFS на HDD на машине с 4 GB
памяти действительно работает помедленнее, но я бы докупил память -- оно
стоит того.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Reply to: