morfizm (morfizm) wrote,
morfizm
morfizm

Category:

Переход от NAS к Cloud Storage

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

У меня примерно 10 TB "полезной нагрузки", но в них много ненужного. На сервере это было 5 дисков по 5 "TB" (на самом деле, 5+6+6+8+8, но использовались они как 5+5+5+5+5 в RAIDZ-2, т.е. с избыточностью на два диска) плюс два диска на 12 "TB" в ротации для offsite backup'а. На один постоянно реплицируется весь массив, а с другим его можно swap'нуть раз в квартал. Плюс 1 TB данных на быстром storage на самом компьютере, и часть места на сервере занимали клиентские бэкапы - инкрементальные и не очень - этого массива.

Первая оптимизация - клиентские бэкапы. Их количество можно сократить, если в Cloud Storage использовать функцию файловой истории или снапшотов. В частности, Dropbox Professional (который даёт 3 TB за $200/год) имеет фичу полной файловой истории с возможным откатом директории с поддиректориями на любой момент из последних 180-дней, и я рассчитывал, что эта фича позволит мне отказаться от большого количества инкрементальных бэкапов. (Смысл которых, в основном, в том, чтобы найти что-то, что было случайно удалено.)

Вторая: есть вещи, которые можно заново скачать. Я параноик и не верю в доступность интернета, всё хорошее люблю хранить локально. Тем не менее, если есть возможность скачать заново, то это не настолько критичная информация, чтобы платить за её хранение в 5 экземплярах, тратить на неё NAS или Cloud Storage, etc. Вполне достаточно будет поставить два диска в mirror.

Изначальная идея была в том, что для всего оставшегося мне хватит 6-7 TB клауда, и ещё будет запас. Я куплю Dropbox Professional (3 TB), плюс у меня уже есть Office 365 Family, дающий 6 TB, но 6 отдельными кусками по 1 TB, я докуплю быстрого NVMe storage для "кэша" этого Cloud Storage.

Здесь надо сделать небольшое отступление и послать луч ненависти производителям железа для storage, которые за последние 10 лет попытались внедрить стандарт, будто в килобайте 1000 байт и 1 TB = 10^12 байт, а старое общепринятое значение (1 TB = 2^40) переименовать в TiB. У них это частично получилось. В новостях стали писать слово TiB, а также в некоторых утилитах. Но Windows держит оборону и показывает как в Explorer'е, так и во всех дисковых утилитах настоящие терабайты. Клауд-провайдеры тоже заняли Светлую Сторону Силы, и терабайты у них подлинные.

Я категорически отказываюсь использовать TB для фейковых терабайт и TiB для настоящих. Вместо этого фейковые у меня будут в кавычках ("TB", чтобы каждый раз смеяться над ними в местах упоминания объёмов), а настоящие без кавычек. 1 "TB" = 0.91 TB. Другими словами, в диске на 12 "TB" даже 11 настоящих терабайт нет, там 10.91 TB. А аргумент про систему "СИ" засуньте в жопу. Меры объёма памяти в компах всегда были привязаны к двоичной системе, потому что это единственный осмысленный вариант, а читить стали только производители хардов, потому что у них работали хитрожопые маркетологи. А потом подхватили неграмотные журналисты, которые повелись на аргумент про "СИ".

Я докупил NVMe хардов, так что у меня суммарно стало 8 "TB" NVMe, поставил два 8 "TB" харда в mirror для "менее важных" данных, и попробовал добавить в Dropbox какую-то часть файлов, что раньше были на сервере. Не все, конечно, но много - несколько сот тысяч файлов суммарно на 1 TB.

Отдельно исследовал вопрос шифрования на клиенте, чтобы взлом Dropbox account'а не позволил угнать важную инфу. Cryptomator имеет разные недостатки, но вроде неплох, "мышей ловит". Ему даёшь директорию, он её монтирует как "виртуальный диск", на этот диск можно писать файлы, а в физической директории будут появляться файлы в таком же количестве и с такими же размерами, но шифрованные и с изменёнными именами, похожими на случайные.

Какие я узнал интересности:

1. Если потрогать много файлов, Dropbox очень надолго подвисает, и пока он не разберётся с большим массивом, он не будет делать больше ничего полезного. Какой-то возможности приоритезировать апдейты у него нет.

2. Performance Dropbox синхронизации сильно падает, когда много маленьких файлов. Дропбоксу нужны большие файлы (десятки мегабайт и выше) для оптимальной скорости работы.

3. С большим количеством файлов в Windows Explorer'е невозможно работать, если эти файлы под управлением Дропбокса. Например, невозможно работать с фотографиями. Превьюшки не грузятся, всё адски медленно, а когда пытаешься переименовать фото, добавив в имя файла тэг, он делает какой-то странный рефреш, уничтожая выделенное имя файла прямо в процессе, пока я его редактирую.

4. Дропбокс навязчиво рекомендует online-only режим или Smart Sync, и когда играешь с этими сеттингами очень легко случайно перевести файлы в режим Online. После этого Cryptomator, естественно, сходит с ума, а чтобы всё восстановить, надо сутки ждать, пока заново скачается этот весь терабайт, и, конечно же, никакая разумная синхронизация нужных вещей, над которыми ты сейчас работаешь, одновременно с этим процессом работать не будет. Кстати, Дропбокс не сохраняет "created" timestamp, это отдельная проблема, которую надо будет решить. Timestamp'ы будут убиты при переводе файла из offline в online и обратно, а также при воссоздании Dropbox директории на другом железе.

Вывод, который я сделал, такой: Cloud Storage для больших коллекций файлов - полное говно. Надо будет глянуть лет через 5, а лучше 10.
До тех пор клауд можно использовать для малых объёмов (десятки гигабайт), а также, возможно, для бэкапов.

Кстати, это втрое увеличивает необходимость физического места на диске. На первом диске директория с миллионом файлов на несколько терабайт. На второй диск делается (скажем, ночной) partition/image-level бэкап всего - причём без компрессии и без шифрования - так, чтобы при небольшом изменении данных менялась лишь небольшая часть бэкпапа (для differential sync!). Бэкап либо сразу режется на куски от 100 MB до 5 GB, либо отдельным скриптом. Отдельным скриптом шифруется и копируется на третий диск, поверх того, что там было, а третий диск уже синхронизирован с клаудом. Тогда мы получаем сразу всё:

1. Отсутствие проблем с блокирующими обновлениями (это всё можно заскриптовать как ночной job).

2. Быстрое обновление, потому что будет differential backup, даже если бэкап каждый раз 2-терабайтный. Именно для этого он должен изначально делаться без компрессии и без шифрования, а только потом можно накладывать шифрование уже на отдельные куски, а не на весь stream.

3. Возможность делать image level backup любым софтом, и отдельно шифровать тоже любым софтом.

4. Возможность пользования оригинальной коллекцией файлов без какой либо тормозни из-за интеграции с cloud storage.

Собираюсь попробовать этот подход, пока ещё не настроил его. Но уже купил ещё один 12 "TB" диск, который я смогу использовать как дополнительный буфер.

Ещё один отдельный вывод - надо стараться, чтобы файлов было вообще поменьше. Ну там, сканировать документы в худшем качестве и всё такое прочее. Сам факт наличия 10-терабайтного массива - это бардак и безобразие, которое требует куда большего физического железа, чем 10 TB, из-за всяких overhead'ов процесса синхронизации и бэкапа, и все операции требуют уйму времени.
Tags: 1, devices, software
Subscribe

  • Нагуглил свой же солюшен - wow!

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

  • Межсетевое

    Перепощиваю шутку с другого форума. К сожалению, смешно будет только айтишникам. Экстра поинтс, если вы сетевик. 12 лет уже этому ролику, прикиньте!…

  • Трюфели

    Трюфели это такие шоколадные конфеты. Особый сорт шоколада, довольно дорогой, твёрдый и в такой рассыпчатой крошке. Их почему-то делают пирамидальной…

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 26 comments

  • Нагуглил свой же солюшен - wow!

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

  • Межсетевое

    Перепощиваю шутку с другого форума. К сожалению, смешно будет только айтишникам. Экстра поинтс, если вы сетевик. 12 лет уже этому ролику, прикиньте!…

  • Трюфели

    Трюфели это такие шоколадные конфеты. Особый сорт шоколада, довольно дорогой, твёрдый и в такой рассыпчатой крошке. Их почему-то делают пирамидальной…