Сколько стоит своё облако для команды: считаем диск, трафик и обслуживание

Смета собственного облака обычно начинается с одной строки: цена VPS за месяц. Строка честная, но неполная. Через месяц выясняется, что у файлов есть версии, у удалённых файлов есть корзина, у сервера должна быть копия где-то в другом месте, а у всей конструкции есть человек, который иногда обновляет систему и отвечает на вопрос «а где мой договор?». Ни одна из этих статей не входит в тариф сервера, но все они входят в стоимость рабочего файлового пространства.

Поэтому давайте собирать смету по слоям, как собирают торт, только менее вкусный. Возьмём условную команду из 15 человек и условные 500 ГБ полезных файлов: документы, макеты, таблицы, архивы проектов. Все числа ниже выдуманы для расчёта и нужны только затем, чтобы показать ход арифметики. Подставьте свои значения, и формулы останутся рабочими.

Слой первый: полезные данные и то, что к ним прилагается

500 ГБ полезных файлов — это то, что люди видят в папках. Диск под них нужен не ровно на 500 ГБ, и дело не только в запасе на рост. Во-первых, операционная система, приложение, база данных и журналы занимают место сами по себе. Во-вторых, у файлов есть история.

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

Важная деталь: старые версии автоматически удаляются по политике хранения и ограничениям места. Это значит, что история не бессрочна. Нельзя заложить в смету «версии за три года» и считать вопрос закрытым: система сама решает, какие версии пора убрать. В той же документации сказано, что именованные версии исключены из автоматического истечения, но применимость стоит проверять на вашей установленной версии. Для сметы вывод такой: версии — это переменный слой, который растёт вместе с интенсивностью правок, а не с количеством файлов.

Как прикинуть его размер без измерений? Разделим файлы на две группы. Первая — редко меняющиеся: сканы, финальные PDF, архивы. Их версий почти нет. Вторая — рабочие: документы, таблицы, проектные файлы, которые правят каждый день. Допустим, условно, что рабочих файлов 100 ГБ, а каждый в среднем хранит историю, равную ещё 50–100% его размера. Тогда версии добавляют 50–100 ГБ. Остальные 400 ГБ почти не прибавляют ничего. Если же команда работает с большими монтажными или графическими проектами, группа «рабочих» файлов разрастается, и множитель надо считать иначе. Реальную цифру даст только наблюдение за своим хранилищем в первые недели.

Корзина — второй скрытый слой. Удалённые файлы не исчезают мгновенно, и это спасает от ошибок, но пока файл лежит в корзине, он занимает место на диске. В смете корзина — это буфер на «крупные чистки»: когда кто-то удаляет старый проектный каталог на 40 ГБ, диск не освобождается, а последовательно заполняется. Условно заложим 10% от полезного объёма, то есть 50 ГБ.

Промежуточный итог: 500 ГБ полезных данных, до 100 ГБ версий, около 50 ГБ корзины. Это уже 650 ГБ, и мы ещё не добавили систему, базу и запас.

Слой второй: рост и временное место при переносе

Данные не стоят на месте. Простейший способ оценить рост — взять объём, который команда добавила за прошлый год в общих папках, мессенджерах и почтовых вложениях, и умножить на запас. Допустим, условно, команда добавляет 120 ГБ в год. Планировать диск на год вперёд означает добавить эти 120 ГБ, а на два года — 240 ГБ. Здесь есть развилка: брать тариф с запасом сразу или расти по мере надобности. Первый вариант проще и спокойнее, второй дешевле на старте, но требует решения о расширении и возможной миграции. Что именно можно расширить и как, проверяйте в форме заказа и в описании тарифа: сам факт «можно» из каталога не следует.

Отдельная история — разовый перенос большого каталога. Когда команда переезжает со старого хранилища, данные нужно где-то принять до того, как они окажутся на своём месте. Если вы загружаете архив на сервер, а потом распаковываете, на диске одновременно живут и архив, и распакованные файлы. То есть для переноса 500 ГБ в виде одного архива потребуется почти 1000 ГБ свободного места на короткое время. Лучше переносить каталоги порциями или напрямую, без промежуточного архива, но тогда важно следить за тем, чтобы прерванная передача не оставила наполовину загруженные файлы и дубликаты.

Практический вывод: временное место при переносе — отдельная строка, а не «как-нибудь влезет». Если диск тарифа в момент миграции заполнен на 90%, запись остановится посреди копирования, и разбираться придётся уже с частично перенесёнными данными.

Слой третий: резервная копия — это не папка рядом

Теперь самое частое заблуждение. Копия, лежащая на том же диске, что и оригинал, защищает от человеческой ошибки, но не от отказа самого диска или потери сервера. Это две разные угрозы, и им нужны разные меры. Версии и корзина закрывают первую. Вторую закрывает только копия в другом месте.

Документация Nextcloud рекомендует копировать резервные данные за пределы окружения Nextcloud, и в перечень резервируемых частей входят config, custom apps при их наличии, data, theme и database (руководство администратора по резервному копированию). Для сметы это означает, что копировать нужно не только каталог с файлами. База данных хранит структуру, пользователей и связи, без неё файлы превращаются в груду безымянных объектов.

Там же описан режим обслуживания: он блокирует сессии и новые входы, чтобы данные не менялись в середине копирования и не получилась несогласованная копия. Для команды это значит окно, когда сервис недоступен. Если у вас пять человек в одном часовом поясе, окно ночью почти незаметно. Если команда работает круглосуточно, придётся договариваться или искать другую схему.

Теперь подсчитаем место. Независимая копия должна вместить данные, базу и конфигурацию, а ещё столько истории копий, сколько вы хотите хранить. Если делать полную копию каждую ночь и хранить семь дней, получится семикратный объём без дедупликации, а с инкрементальными копиями значительно меньше. Условно возьмём самый простой расчёт: одна полная копия плюс 30% на изменения, то есть около 650 ГБ при 500 ГБ полезных данных. Это место где-то стоит денег, и это отдельный счёт или отдельный сервер, а не бонус к основному тарифу.

Здесь важно не додумывать за тариф: в публичных материалах MAATRIX перечислены ресурсы VPS, но автоматические резервные копии во всех тарифах там не заявлены. Поэтому в смете безопаснее считать независимую копию отдельной строкой, пока в форме заказа или у поддержки не подтверждено обратное.

Таблица места: от полезного к тарифному

Сравните с линейкой тарифов: у MAATRIX диски идут от 40 до 320 ГБ NVMe в составе тарифов Ba, Uab, Heka, Maat и Djed. Даже старший из перечисленных не вмещает такой расчёт, и это нормальный результат честной арифметики: 500 ГБ полезных файлов не помещаются в 320 ГБ диска, как ни крути. В таком случае команде придётся либо подключать дополнительное хранилище, либо разделять данные (активные проекты на сервере, архив отдельно), либо смотреть, какие варианты расширения диска доступны в заказе. Заявленный в тарифе объём также не стоит считать полностью свободным: часть всегда занимает система. Ресурсы тарифа — это параметры конфигурации, а не обещание ёмкости под вашу конкретную нагрузку.

Слой четвёртый: трафик, который считают по направлению

Трафик в смете — не одна строка, а как минимум две, потому что входящий и исходящий часто тарифицируются и ограничиваются по-разному. Загрузка файлов на сервер обычно не создаёт проблем. Скачивание — другое дело: каждый раз, когда сотрудник открывает файл, синхронизирует папку или пересылает ссылку клиенту, данные уходят с вашего сервера. Условия по трафику у конкретного тарифа проверяйте до оплаты: здесь мы не подставляем чужих цифр.

Посчитать исходящий поток можно по событиям, а не по людям. Первое событие — первичная синхронизация. Новый сотрудник ставит клиент и скачивает свою часть данных. Если ему доступны 100 ГБ, это 100 ГБ исходящего трафика за первые часы. Пятнадцать человек, пришедших одновременно (например, при переезде), дают до 1,5 ТБ. Второе событие — повседневная работа: правки документов, обновления, просмотр. Здесь поток мал, если команда работает с текстом и таблицами, и велик, если с видео. Третье — внешние ссылки: клиент скачивает архив на 5 ГБ двадцать раз, и это уже 100 ГБ.

Если вы поднимаете серверы в разных странах и гоняете данные между ними, например для резервной копии в другой локации, этот поток тоже считается. О том, как устроена такая стоимость и что с ней можно сделать, подробнее в материале про трафик между своими серверами в разных странах. Для нашей сметы важно одно: копия вне основного окружения создаёт собственный трафик, и его надо внести отдельной строкой. Полная копия 650 ГБ раз в месяц — это 650 ГБ, плюс инкременты каждую ночь.

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

Слой пятый: восстановление как отдельная строка

Резервная копия, из которой ни разу не пробовали восстановиться, — это гипотеза. Проверка восстановления стоит времени и временного места: чтобы убедиться, что копия работает, её нужно развернуть где-то отдельно. Для 650 ГБ копии это ещё столько же свободного места на тестовом сервере или хотя бы на время проверки. Часть команд ограничивается выборочной проверкой: достать несколько каталогов и базу, поднять приложение и убедиться, что файлы открываются. Это дешевле, но и закрывает меньше рисков.

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

Слой шестой: обслуживание через конкретные работы

Фраза «нужен админ» в смете бесполезна, пока не разложена на действия. Вот из чего реально состоит работа, и для каждого пункта можно поставить свои часы:

• Обновления. Система, приложение и база обновляются по расписанию. Условно один час в месяц на подготовку, обновление и проверку, что вход и синхронизация работают.
• Контроль места. Просмотр заполнения диска, разбор крупных каталогов, чистка корзины и старых версий. Условно 30 минут в месяц.
• Управление людьми. Приём и уход сотрудников, права на папки, внешние ссылки. Условно 15 минут на человека при каждом событии и час в квартал на ревизию прав.
• Резервные копии. Проверка, что вчерашняя копия появилась и не пустая. Если оповещения не настроены, это ручная работа; сам механизм событий в SFTPGo существует (Event Manager, события передач), но наличие механизма не значит, что уведомления уже работают.
• Проверка восстановления. Раз в квартал условно три-четыре часа на развёртывание копии и сверку.
• Обращения пользователей. «Не синхронизируется», «потерял файл», «как дать ссылку клиенту». Условно два часа в месяц на команду из пятнадцати человек.

Складываем: около 4–5 часов в обычный месяц плюс квартальные работы. Это не полный рабочий день, но и не ноль. Если эти часы делает штатный сотрудник, они отнимаются от другой работы; если подрядчик, то это строка в счёте. Умножьте на свою ставку, и вы получите самую неопределённую, но часто самую крупную часть сметы. Для небольшой команды именно она нередко превышает стоимость самого сервера.

Теперь про безопасность в смысле расходов, а не регламента. Права на папки и разделение аккаунтов — это не абстрактная гигиена, а способ уменьшить стоимость ошибок. В SFTPGo права различают просмотр списка, загрузку, перезапись, скачивание, удаление и другие операции. Это значит, что подрядчику можно выдать только загрузку в один каталог без права удаления, и случайно потерянная папка перестанет быть вероятным сценарием. Каждая такая настройка экономит часы будущего восстановления.

Два сценария для одной и той же команды

Теперь соберём всё вместе. Возьмём две команды по 15 человек. Цифры по-прежнему условные.

Команда А — бухгалтерия, юристы, менеджеры. Файлы: документы, таблицы, сканы. Полезный объём 300 ГБ, рост 40 ГБ в год. Рабочих файлов мало, версии занимают около 30 ГБ. Скачивание — по необходимости, внешние ссылки редко. Резервная копия — полная раз в неделю плюс ежедневные инкременты, около 400 ГБ в другом месте.

Команда Б — студия с графикой и видео. Полезный объём 500 ГБ, рост 300 ГБ в год. Рабочие файлы тяжёлые, версии могут составлять сотни гигабайт. Клиенты регулярно скачивают сдаваемые материалы. Копия требует не менее 1 ТБ, а перенос при смене сервера займёт сутки передачи.

Команды одного размера получили разные сметы. Различие создали не люди, а то, как они обращаются с файлами. Поэтому вопрос «сколько стоит облако на пятнадцать человек» без уточнения «что они в нём хранят и как правят» не имеет ответа.

Как это соотносится с ресурсами VPS? Для команды А рабочий сервер среднего класса с NVMe-диском и независимая копия в отдельном месте — разумная отправная точка, а проверить, подходит ли конкретный тариф, можно по описанию в каталоге. В публичном каталоге MAATRIX предложены Nextcloud и n8n с установкой, но точное состояние наличия и операционной системы проверяется в форме заказа. Команде Б, скорее всего, придётся разделять хранение: на сервере держать активные проекты, а завершённые вывозить в архив. Такая схема снижает и диск, и копию, и трафик, но добавляет работу по переносу. Оба варианта выбирают, глядя на диск, а не на количество ядер: для файлового сервера процессор редко становится первым ограничением, а место заканчивается раньше.

Что получается в итоговой формуле

Если свести всё к формуле, она выглядит так: цена рабочего сервера + цена места под независимую копию + цена исходящего трафика + часы обслуживания, умноженные на ставку, + разовые затраты на перенос и проверку восстановления. Каждое слагаемое можно оценить, и ни одно не равно цене тарифа на странице заказа.

Есть и приятный побочный эффект такого расчёта: он показывает, какие решения экономят деньги. Политика хранения версий уменьшает слой диска. Квоты и лимиты скорости защищают от неожиданного трафика. Разграничение прав сокращает число восстановлений. Планово проверяемая копия превращает аварию из катастрофы в рабочую задачу. Всё это дешевле, чем объяснять команде, почему папка с договорами исчезла.

Самая пропущенная строка

В большинстве смет есть сервер, нет копии, а в смете с копией почти никогда нет главного: имени. Кто именно вернёт удалённую папку? Не «админ вообще», а конкретный человек, у которого есть доступ к копии и к паролю от неё. За какое время он это сделает: за десять минут из корзины, за час из версий, за полдня из внешней копии? И что будет, если он в отпуске?

Запишите ответ рядом с остальными строками: имя, запасной человек, ожидаемое время для точечного случая и для полной потери сервера. Если после этого цифра в смете выросла, значит, смета наконец стала честной. А если оказалось, что вернуть папку некому, то вы только что нашли самую дорогую строку расчёта, пока она ещё ничего не стоила.