morfizm (morfizm) wrote,
morfizm
morfizm

Category:

Освобождение от NAS и переход на клауд

Процесс очень активен, но, к сожалению, всё значительно труднее, чем я думал.

1. Консьюмерские клауд-storage-провайдеры не справляются с большим количеством маленьких файлов. Когда у вас миллион файлов и несколько терабайт объёмы:
- raw performance падает на порядок (т.е. вы и близко не можете утилизировать пропускную способность своего интернета),
- появляются разные ошибки и проблемы с синхронизацией (видимо они всегда появляются, но их вероятность завязана на файлы, а когда файлов много, вероятность, что хоть с одним будет что-то не так, поднимается на порядки),
- если добавляется что-то большое - реорганайзинг, бэкап или даже просто "скинул пару десятков гигабайт новых фоточек", то клаудом невозможно пользоваться, пока всё не засинхронизируется (что осложняет вообще пользование компьютером).

Выводы:
- image backup,
- сегрегация данных по разным уровням приватности, по частоте обновления и пр.

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

Выводы:
- либо image backup,
- либо написать какую-то утилиту, которая будет запоминать файловую метадату и, при необходимости, восстанавливать. Кстати, заодно за контрольными суммами можно следить. Возможность bit rot никто не отменял.

3. При image-level backup сталкиваешься с несколькими проблемами:
- ограничение на размер файла, причём у разных клауд-провайдеров оно разное. Я пока остановился на 32 GB, но так как я экспериментирую с разными провайдерами, не факт, что не придётся уменьшить; понятно, backupper'ы должны поддерживать image-level с пропуском свободного места, шифрование и разбивку на многотомные архивы, с поддержкой инкрементальности,
- надо schedule'ить закачку ночью, сразу после создания бэкапа, т.к. во время закачки другие вещи не будут закачиваться (Dropbox - приятное исключение, они приоритезируют файлы меньшего размера),
- проблема с full vs incremental backups: надо либо иметь место на клауде, чтобы сохранить два (!) full backup'а включая какое-то количество инкрементальных (грубо говоря, утроить требования по объёму), либо надо иметь отдельный локальный диск с таким количеством места, и дополнительным скриптом убивать предыдущий full backup и связанные с ним incrementals, прежде, чем синхронизировать эту директорию с другой, которая уже синхронизируется с клаудом (требует 4.5-кратного места на локальном диске - 3-кратный временный буфер и 1.5-кратный cloud storage полностью отражённый на локальном диске),
- проблема со скоростью интернета... full backups не должны занимать больше, чем полдня на закачку. 12 часов со скоростью 1 Gbit/sec это 5.2 терабайта. Реально можно достичь 50% утилизации, это уже 2.6 терабайт. Во-первых, это не так много (т.е. 2.6 терабайтами должен быть ограничен весь массив). Во-вторых, это слишком жёсткая зависимость на гигабитный интернет. Если я уеду из San Francisco, интернет, вероятнее всего, станет 100 мегабитным, поэтому объём информации, которую можно регулярно бэкапить в клауд, станет 250 GB.

У этой проблемы есть решения. Например, вместо бэкапов просто синхронизировать директорию. Но:
- это должны быть большие файлы. Т.е. это можно делать, скажем, с фото и видео, но не с мелкими файлами.
- если это sensitive файлы, которые нужно шифровать, то нужно использовать что-то вроде Cryptomator, а это дополнительная возможность огрести разные глюки. Что делает более важным вопрос регулярных бэкапов локально и их сохранность (чёрт возьми, мы же пытались избавиться от NAS, а теперь, получается, он снова нужен!)

Короче, все эти процессы непростые, и я в процессе экспериментов и исследования. От сервера я уже избавился, но купил дополнительный 12 TB диск, и навтыкал несколько больших дисков в desktop'ный комп, в дополнение к тем новым NVMe дискам, что я купил. Окончательный layout ещё не ясен. Ясно то, что владеть 10 терабайтами говна без полноценного NAS - невероятно дорого и накладно, и клауд на сегодня не спасает, поэтому основной effort надо направить в уменьшение размеров коллекции.
Tags: 1, devices, order, software
Subscribe

  • Дружба vs общество

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

  • Программисты - не боги?

    Мне знакомый сказал, что программисты - не боги. Это прям обидно, потому что с подразумеваемым квантором "всегда" это неверно. Программисты не боги…

  • Свобода слова

    Задумался, что моя позиция в отношении свободы слова - позиция изгоя. Никакой нормальной партией или движением она не поддерживается. Пройдёмся по…

  • 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.
  • 13 comments

  • Дружба vs общество

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

  • Программисты - не боги?

    Мне знакомый сказал, что программисты - не боги. Это прям обидно, потому что с подразумеваемым квантором "всегда" это неверно. Программисты не боги…

  • Свобода слова

    Задумался, что моя позиция в отношении свободы слова - позиция изгоя. Никакой нормальной партией или движением она не поддерживается. Пройдёмся по…