Как стать автором
Обновить

Выбираем систему хранения файлов для командной работы

Время на прочтение5 мин
Количество просмотров48K
Всего голосов 35: ↑33 и ↓2+31
Комментарии30

Комментарии 30

Регулярно сталкиваюсь с отказом компаний обмениваться файлами через dropbox, иногда даже в договорах явно прописывается. В личной беседе сотрудники говорят, что у них dropbox под запретом. Может знает кто, в чем причина? Это такие антисанкции, или есть доказательства что dropbox сливает данные?
В статье, кстати, не упоминаются p2p и selfhosted решения, а их много и они довольно интересные, как мне кажется.

Сами используем Resilio (бывший btsync), но он порядком надоел. Каждые пару месяцев у них выходит новая версия которая ломает серверную часть на линуксе. Смена названия тоже вносит путаницу, потому что кое-где еще старые версии пакетов с названием btsync. В общем ищем замену. Думаем попробовать открытый owncloud, но есть опасения, что это очередная красноглазая поделка.
Любые selfhosted решения требуют поддержания собственной инфраструктуры серверов, пускай даже облачных. Которые нужно администрировать, бекапить, обновлять когда выходят уязвимости, а это целая отдельная работа, которой кто-то должен заниматься. Содержать для этого системного администратора выходит сильно дороже. Да и попробуй сравнить сколько будет стоить сервер с 10ТБ хранилищем по сравнению с облачными решениями из статьи.
Да и попробуй сравнить сколько будет стоить сервер с 10ТБ хранилищем

Можно поднять «подкроватный» сервер в который вставить пять HDD по 2ТБ и развернуть там какой-нибудь owncloud/btsync. Но в целом согласен, администрировать это дело придется.
НЛО прилетело и опубликовало эту надпись здесь
onwсloud — не надо. Не просто так проект разветвился на еще и nextcloud.
seafile попробуйте. Умеет всё из этой статьи.
seafile попробуйте

Я так понимаю оно полностью selfhosted?
Да, именно так.
Важное дополнение: это решение под никсы, под виндой — только посмотреть.
У гугл драйва есть весьма неочевидные грабли, на которые рано или поздно придется наступить:
1. Самопроизвольное переименование ваших файлов. Заливаете в облако «файл (2019).docx», получаете, например, «файл (1).docx».
2. Сбои синхронизации при больших объемах данных. Т. е. клиент вам показывает, что все синхронизировано, а на деле большинства файлов — нет.
3. Иногда возникают конфликты синхронизации — причем даже тогда, когда одновременного изменения файла не было.
4. Иногда файлы дублируются (часто это следствие глюка №1). Вместо одной версии файла появляется несколько, отличающиеся циферками («файл (1).docx», «файл (2).docx» и т.п.).

А еще бывали глюки при одновременном обновлении нескольких файлов в синхронизируемом каталоге. Например, бухгалтер обновляет несколько файлов (копирует новые версии поверх старых). Клиент google drive просыпается и начинает сканировать файлы на предмет изменений. В результате бухгалтер получает ошибку записи в файл, т.к. он открыт клиентом.
Это глюки клиента гугл драйва, а не его самого.
Неоднократно ловил баги с клиентом Google drive при синхронизации большого количества файлов, например проект с папкой .git внутри.
Решил использовать его исключительно для крупных файлов.
Спасибо за статью! Полезный обзор командных, а не личных облачных сервисов.

Дополнение про OneDrive — 15 ГБ ограничение на размер файла — это в командной подписке, в персональной — вообще 10 ГБ — просто смешно; насколько я знаю, в других сервисах по этому параметру персональные и командные подписки не различаются.

Вопросы к автору:

1) Насчет версионности — в каком ресурсе чем измеряется — кол-вом версий или длительностью хранения предыдущих версий?
У Dropbox — 120-дневный журнал www.dropbox.com/plans?trigger=nr.
А как у других? А сколько времени хранится файл в корзине (просто удаленный, а не замененный новой версией)? Это я к тому, что и 120 дней — это не очень много (в конце текущего квартала вполне может потребоваться предыдущая (не последняя) версия отчета за предыдущий квартал); и еще наверное неспроста появилось много софта (в т.ч. СХД-сервисов) для локальных вечно-инкрементных бэкапов из облачных хранилищ, почт и порталов.

2) Если не затруднит — просьба дополнить про анонимную загрузку "… и сервис создаст анонимную ссылку, по которой можно залить файлы через браузер..." — а таким способом какого размера файлы можно зааплоадить через браузер?

Спасибо!
Насчет версионности — в каком ресурсе чем измеряется — кол-вом версий или длительностью хранения предыдущих версий?
У Dropbox — 120-дневный журнал


Отличный вопрос, забыл об этом упомянуть. У ShareFile на корпоративном тарифе безлимитное число версий. Вот выдержка из описания: By default, file versioning will save unlimited versions of a given file to allow you to see the entire history of any files on your account.

"… и сервис создаст анонимную ссылку, по которой можно залить файлы через браузер..." — а таким способом какого размера файлы можно зааплоадить через браузер?

Конкретно этот лимит проверить не удалось. Могу сказать что через такую ссылку удавалось успешно загрузить несколько файлов по 20ГБ. Так что полагаю, у ShareFile лимит здесь такой же как на общий размер файлов 100ГБ.
Однако приложение Google Drive позволяет отметить только папки в корне диска, то есть нельзя включить синхронизацию только для Бухгалтерия --> Отчеты --> 2018, можно только для всей папки Бухгалтерия.

У Google Drive уже достаточно давно появился новый клиент Google Drive File Stream, в нем выборочная синхронизация на уровне файлов, прямо из контекстного меню файла.
НЛО прилетело и опубликовало эту надпись здесь
Гм, ну если завязалась дискуссия про негативный опыт… то думаю можно поделиться некоторыми результатами несколько-летнего тестирования ПЕРСОНАЛЬНЫХ (не командных) подписок OneDrive, Google Drive, Яндекс.Диск.

1) По скорости загрузки (с компа или СХД-агентом) OneDrive в 20-80 раз медленнее, чем Google Drive, Яндекс.Диск — проверял много раз, на одинаковых объемах, на одном и том же интернете.

2) В OneDrive очень плохо работает копирование приличных (десятки и сотни гигабайт) данных между учетками; эта операция необходима при переносе данных между учетками — когда учетка предоставила другой папку только на чтение, в целевой учетке можно запустить копирование из этой предоставленной папки в свою папку. Пытался-тужился много раз — ни разу не успешно — процессы просто прекращались с сообщением-издевкой «что-то пошло не так». Такие операции очень удобно делать чтобы не гонять трафик между компом и ресурсом (т.е. чтобы все происходило только на стороне ресурса) при перераспределении файлов между личными и семейными учетками и т.п. — этим часто приходилось заниматься когда по объемам и стоимости ресурсы стали интересны обычным пользователям. В Google Drive, Яндекс.Диск такие операции выполнялись стабильно, а в Яндекс.Диск — как-то удивительно быстро — полТЕРАБАЙТА за несколько часов. Повторюсь — здесь идет речь именно о получении КОПИЙ файлов в другой учетке.

3) Связано с предыдущим пунктом — нормальная выполняемость такого процесса в Google Drive, Яндекс.Диск дополняется (относительным) удобством интерфейса — знакомым неискушенным пользователям как-то легко получается растолковать, что нужно дать доступ просто на просмотр папки — тогда нормально получается сделать копию в свою учетку (чтобы уже потом файлы регламентно синхронизировались в комп или СХД). В OneDrive — как-то сложнее — все время расшаривают полный доступ, и операция копирования недоступна.

4) Нельзя и не похвалить OneDrive — во-первых стоимость — в рамках подписки Office 365 примерно за 3 тыс. руб. в год (общая стоимость «на семью») по 1 терабайту доступно каждому из 5 пользователей (а вот здесь написано про 6 пользователей products.office.com/ru-ru/compare-all-microsoft-office-products?tab=1&OCID=AID679471_OO_Hero_mscomrefreshhome ); во-вторых — OneDrive в веб-интерфейсе показывает размеры папок — причем в представлении списка. Это очень удобно чтобы быстро понимать, например, объемы, которые нужно скачать или синхронизировать. В яндексе и гугле такой возможности пока нет.

Тоже выбираем решение для компании, пока выбор пал на nextcloud. Гоняю его на тестовом сервере, пока все устраивает. Работает в паре с OnlyOffice и ещё несколькими плагинами.

MS OneDrive на самом деле тоже умеет WebDav, просто они к нему сбоку прилепили внешнюю авторизацию через Microsoft Account. С некоторыми танцами и бубном оно запускалось и работало и не на MS платформах.
Syncthing и рулитие сами. Потому как отдать все самое ценное в облако и не иметь собственной копии — это риск какой-то неправильный для серьезного бизнеса.
Никто не ползуется Яндексом Диском и Мейлом?

В OneDrive ограничение не заметил. Неделю назад переливал 70гиговые файлы — загрузил через web-клиент, сливал через виндовый клиент

Немного не то, но для других целей интересно.
Rclone is a command line program to sync files and directories to and from:
Заголовок спойлера
Alibaba Cloud (Aliyun) Object Storage System (OSS)
Amazon Drive (See note)
Amazon S3
Backblaze B2
Box
Ceph
DigitalOcean Spaces
Dreamhost
Dropbox
FTP
Google Cloud Storage
Google Drive
HTTP
Hubic
Jottacloud
IBM COS S3
Memset Memstore
Mega
Microsoft Azure Blob Storage
Microsoft OneDrive
Minio
Nextcloud
OVH
OpenDrive
Openstack Swift
Oracle Cloud Storage
ownCloud
pCloud
put.io
QingStor
Rackspace Cloud Files
Scaleway
SFTP
Wasabi
WebDAV
Yandex Disk
The local filesystem

Features

MD5/SHA1 hashes checked at all times for file integrity
Timestamps preserved on files
Partial syncs supported on a whole file basis
Copy mode to just copy new/changed files
Sync (one way) mode to make a directory identical
Check mode to check for file hash equality
Can sync to and from network, eg two different cloud accounts
(Encryption) backend
(Cache) backend
(Union) backend
Optional FUSE mount (rclone mount)


Вот что мне в данном случае не нравится от слова вообще — бесплатные 3rd party tools, которые неизвестно куда и когда сольют пароли от эккаунтов. Возможно это паранойя, но клиент должен быть от провайдера облака или в крайнем случае от операционки.

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

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


Выбрал Google Drive, так как у меня уже вся фирма сидит на ихней почте и мы просто увеличили подписку с 5 баксов до 10 баксов.


Какие нюансы возникли:


  • как уже сказали, что у них есть новый клиент — Google File stream, но стоит отметить, что он не ставится на Windows Server. Почему этот клиент нужен — ниже
  • google позволяет создавать командные диски — т.е. диск принадлежит команде, а не человеку. Это позволяет легко настраивать доступ к ним, но проблема в том, что они поддерживаются только в Google File Stream и с сервера на такой диск не зайти.
  • Бекап у Google только на 30 дней или 100 версий, причем восстановить можно только один файл за раз. Если вирус перепишет папку на 1000 файлов, то будет, наверное хреново все восстанавливать. Как восстановить все файлы на какую-то дату, я не нашел, поэтому после Petya выход у меня такой:
  • дома стоит NAS на Synology. На нем настроил синхронизацию со всеми эккаунтами Google Drive и он с них делает снимки с помощью своей встроенной системы бекапов. Вот с него легко восстановить и папки и файлы и бекапов там на 20 лет и больше. Но опять же проблема — он не видит командные диски.
1) Да, судя по всему, применение NAS для получения «вечных» локальных бэкапов для облачных ресурсов — основной способ обретения душевного спокойствия от возможных глюков ресурса и ошибок сотрудников; основной, но не единственный — в принципе можно бэкапить локальную копию, синхронизированную из облачного ресурса на локальный комп — но с NAS это проще автоматизировать, удобнее контролировать. Душевное спокойствие относится только к аспекту «в случае чего — сможем восстановить» — локальная копия всегда рядом (доступность не зависит от интернета); а вот собственно удобство и трудозатратность восстановления — это уже другая тема, зависит от инструмента;
Параноики (и я такой) средствами NAS бекапят еще и в другой облачный ресурс. Хотя по мере развития сервисов и возможного снижения цен постепенно станут популярными бэкапы Cloud-to-Cloud (без задействования локальных мощностей, но тут вопрос со спокойствием — доступность резервной копии зависит от доступности и скорости интернета).

2) Полезное уточнение — здесь в комментариях много пишут про проблемы (ресурса или клиента), связанные с «размножением» файлов с похожими (рассинхронизированными) именами (или именами, дополненными разными date-time), с «отставанием» синхронизации переименований папок и т.п. Насчет Synology — штатный агент Hyperbackup (при резервировании на внешний диск, подключенный к NAS) обеспечивает блочную дедупликацию, поэтому появление нескольких/многих разноименных копий множества файлов или перемещение файлов (переименование папок) не приводит к резкому росту размера резервной копии. Более того, т.к. в «командных» ресурсах по объективным причинам хранится большое количество (очень) похожих файлов (например, варианты одной и той же презентации, адаптированные для разных мероприятий или разных групп слушателей), то размер дедуплицированной резервной копии некоторое время (пока не накопится большое количество инкрементных изменений) может быть и (существенно) меньше размера исходной копии, синхронизированной из облачного ресурса. Думаю, что штатные инструменты локального резервирования для NAS других производителей тоже обеспечивают блочную дедупликацию.
НЛО прилетело и опубликовало эту надпись здесь
SFTP и FTPS — разные протоколы.
Google drive не позволяет нормально пользоваться диском без почты на g suite (бывший google apps).

А в чем там проблема? Наблюдал когда то что гугл аккаунт у некоторых пользователей был создан не на гуглпочту, и вроде особых проблем это не составляло.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории