rPman

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

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

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

Если есть возможность, закладывать онлайн резервирования и восстановление в само приложение (те самые прогоны логов действий пользователей), как ещё один способ а не единственный.

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

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

Криптовалюта siacoin, оплата в криптовалюте, хранение дешевле amazon glacier (большая часть цены - трафик download уже сохраненного себе назад)
https://siascan.com/

Average storage price	Average download price	Average upload price
$1.33/TB	$3.72/TB	$0.11/TB

Цены приблизительные в месяц.

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

Интерфейс на уровне типовых пользовательских приложений dropbox/onedrive (по умолчанию без веб интерфейса), есть api провайдеры (все локально без единой точки отказа) совместимого s3, есть драйвер файловой системы linux fuse и куча всего, дольше изучать...

p.s. с точки зрения майнеров проект не привлекательный, из-за странного поведения разработчиков, но так как у него есть использование, цены на эту криптовалюту не манипулятивные трейдерами. Проект живет почти 9 лет уже, так что имеет смысл для рассмотрения.

Не смотрите в сторону малинок почти что никогда (хотя они хороши в робототехнике, там хороший набор карт расширений) - отстойнейшая поддержка ОС и всего вокруг.

Выбирайте интелевские x86 SoC, J серия с mitx платами очень хороша, и по ценам, и по производительности на ват. На их основе собирать маломощные (хотя J5xxx очень не плохи да еще и с 16gb ram) домашние сервера и рабочие машинки.

Что бы выбрать хранилище, нужно сначала померить, какой объем даннх необходимо сохранять.. не приблизительно, а на практике, попробовав часть из камер попробовать сохранить на любой десктопной машине с ssd (что бы уж наверняка)... и это будет трафик только на запись. У hdd есть неприятная особенность, ронять скорость работы при одновременной работе нескольких приложений... если одновременная запись с нескольких камер может считаться одним потоком (и будет работать на максимуме возможностей устройства, а это порядка 150мбайт/с даже для дешевейших toshiba 3tb 5400rpm) то достаточно одному пользователю начать считывать видео из истории, скорость может упасть от 2х до 10х раз (зависит от софта, если данные будут считывать большими кусками порядка десятков/сотен мегабайт, то только уронит скорость в половину).

p.s. твои камеры навряд ли дадут больше 2мбит/с, а 19 таких - от силы 5мбайт/с, т.е. такой трафик потянет любой диск даже в худшем

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

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

Самое простое - это текстовый лог в формате jsonl, это сериализованный в json по строчно на каждое событие (а атрибуты события - атрибуты объекта json). В некоторых случая json не поддерживается, например какой-нибудь fail2ban его не умеет, но умеет с помощью регулярных выражений извлекать данные из текста, тогда данные можно собирать и разделять в виде, удобным для последующей обработке регулярными выражениями.

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

Важнейший вопрос тут - для каких задач будет использоваться NAS.

1гбит будет давать до 110мбайт/сек, для hdd особого смысла выше нет (только если это будет бесплатно, что обычно не так, так как 2.5Gb коммутаторы все еще дорогие), так как высокие скорости (200мб/с) достигаются только при линейном копировании больших файлов и при отсутствии фрагментации... во всех остальных случаях скорость может упасть 10кратно... и не утилизирует сетевой канал.

Второе - по какому сетевому протоколу будет обеспечиваться доступ к файлам... Например самые быстрые - iscsi/nbd/aoe (потому что позволяют кешировать локально даже записи, ОС знает до каких пор), но они только блочные устройства транслируют... дальше идет linux nfs и где то в конце майкрософтовский smb (он на мелких файлах может чуть ли не кратно ронять скорость)

Теперь важный ответ про RAID, никогда не используйте дешевые 'аппаратные' raid контроллеры (не серверные, те что с кешем записи и батарейкой), пользы они вам не принесут никакой а вот гемороя административного добавят (например вендорлок, при смене материнки/контроллера пересобирать рейд). Пользуйтесь программным рейдом, он есть как в windows штатно (даже в десктопных ОС если pro версия) так и конечно в linux (mdadm или штатная фича файловых систем btrfs/zfs).

По поводу конфигурации... подбирайте корпус mini pc что бы диски были внутри и подключались по своему штатному коннектору, в вашем случае sata, так как внешние usb контроллеры могут добавить багов (например не будет виден smart дисков или уберут поддержку trim для ssd) и главное, конструктивно эти наружу торчащие провода можно задеть и сбросить диски 'со стола'... NAS должен быть удобным и монолитным, и 'с ручкой для переноса'.

p.s. покупать аппаратный raid с корпусом (домашние ревизии) имеет смысл когда есть желание получить готовый результат без усилий, за это и идет доплата в цене, по сравнению со своей сборкой, выбирайте либо вы собираете либо за вас. Ну и функционал готового рейда обычно лимитирован софтом, который там запущен, когда как свой linux - максимально полнофункционален но конечно не так удобен, плюс никто не мешает и тут такой же софт поставить с UI.

Мне кажется вы перечислили самые дешёвые варианты, amazon s3 glacier deep будет тоже уровня цены.

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

Не представляю что то дешевле чем хранить данные там (порядка 2..5$/м за терабайт +-)... Когда-то по тестам скорость там получалась сотни мегабит, но логично лучше тестировать в своей локации, это ведь как торренты.

https://siascan.com/ смотреть на цену тут с осторожностью, так как могут не учесть x3 резервирование по умолчанию, лучше поставить клиент и смотреть цены там.

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

Удаленное управление.
Дома или на сервере настраиваешь свое рабочее окружение, а затем подключаешься к терминалу этого сервера каким-либо инструментом удаленного управления. Для этого потребуется наличие интернета/подключения до сервера (вырожденный случай - сервер в багажнике автомобиля на парковке под окнами, связь по wifi).

Если сервер linux и низкого качества связь - то настоятельно рекомендую x2go (нет нативного клиента только под смартфоны, и то можно использовать debia-no-root или аналоги)
Если сервер windows и так же некачественная связь - rdp (с оговорками, нормальная версия сервера только в серверных ревизиях и при использовании серверного оборудования)

Так же, при наличии широкого канала в десятки мегабит и низких пингах, есть реализации удаленного управления типа vnc/anydesk/teamviewer/rustdesk и особняком steam link (эта технология невероятно эффективно передает данные и в наличии реализации даже под очень слабое и почти не поддерживаемое железо (у меня есть старый планшет android с очень слабым процессором, на нем youtube работает но запускается по минуте, так вот только steam link как инструмент удаленного управления на нем работает без единого лага, запущенный youtube в браузере на компьютере транслируется без каких либо задержек и искажений картинки в гигабитной локальной сети)

Достаточно открыть ssh доступ (можно сменить порт с дефолтного 22 на что то другое, меньше будут беспокоить сканеры ботов), все остальное (большая часть инструментов) будут работать через него.

scp - штатный от ssh, возможности как у обычного cp, не возобновляет прерванное копирование
rsync - умеет работать через ssh, ключ --partial автоматически дозагрузит прерванное копирование, простой скрипт будет перезапускать процесс копирования пока он не завешится корректно

while ! rsync -avz --partial --progress --inplace --append-verify --rsh=ssh /путь/к/локальному/файлу пользователь@удаленный_хост:/путь/к/удаленному/файлу; do
  echo "Переподключение через 10 секунд..."
  sleep 10
done

Браузеры поддерживают проигрывание DRM контента, это не дает 100% гарантию но создает некоторые трудности для скачивания
p.s. я не нашел красивого примера, стандарты на это дело еще не стабилизировались

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

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

Ну и само собой, даже DRM защищенный контент можно будет записать, запустив браузер в виртуальной машине.

raid бывают разные, под разные задачи. И да, резервировать данные можно и без raid, например простым копированием.

Первое что нужно помнить, единственное от чего защищает raid1/3/5/6 - это от одного класса поломок оконечных устройств (в твоем случае жестких дисков) но не защитит от поломки контролера (или материнской платы) проблем с софтом или кривых рук пользователя (нажавшим удалить все).

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

Теперь как - не важно, постоянно включен у тебя массив или эпизодически, делать его можно одинаково. Либо с помощью аппаратного контроллера (или целого nas или устройства в компютер raid controller), либо с помощью програмной настройки ОС

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

В linux есть mdadm либо специализированные файловые системы типа btrfs или zfs.

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

p.s. постоянное включение/выключение hdd вредит ему сильнее чем постоянная работа.

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

Хз как тот проект zfsin я про него впервые слышу, а так да zfs и btrfs это две файловые системы из *nix-like систем (solaris и linux соответственно) которые умеют raid функционал на файловом уровне. Не советую использовать это в windows.

Веб приложения максимально оптимизированы при работе с файлами на диске.
Никакой другой метод не позволит дать такую производительность.

Поэтому - авторизацию доступа делай на уровне веб сервера (вот пример с нормальным oauth)

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

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

Тупой пример - числовой идентификатор переводи в hex, дели на группы по 4 символа и создавай соответствующие каталоги: /images/0d4f/3b00/a841/0d88, тут 0d88 это файл, остальные части - каталоги. Идентификатор соответственно 64-битное число 0x0d4f3b00a8410d88

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

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

Нужно разделять оптимизацию доступа к данным и их хранение.

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

Один из способов - считать агрегированную информацию в триггере на изменение и добавление данных.

Поэтому ответ на твой вопрос может стать - первый вариант, но исходные данные хранить в неагрегированном виде в любом случае.

Как и любой другой системе - с оговорками, если ошибка не обнаружена, не значит что ее нет, но совокупность действий, типа регулярные тесты и мониторинг smart значительно повышает вероятность не просто обнаружить проблему до того как она навредит, но и получить прогноз на будущий сбой (тоже кстати с некоторой вероятностью)