Хороший архив похож на огнетушитель: о нём не думают месяцами, и всё это время он честно занимает место на стене. Пятьсот гигабайт старых проектов, записей, выгрузок или снимков лежат тихо, пока однажды не приходит день, когда нужно вернуть всё целиком, причём к конкретному часу. И вот тут выясняется, что вопрос «сколько стоит хранить 500 ГБ» был только половиной вопроса. Вторая половина звучит так: сколько стоит и сколько времени занимает достать их обратно.
Разберём задачу по порядку: что именно мы называем архивом, где лежат байты, чем отличается виртуальный диск от объектного хранилища, как посчитать затраты на условном примере и какую роль в этой схеме может играть небольшой VPS.
Сначала разведём две вещи: доступ к архиву и место, где он лежит
Самая частая ошибка в таких расчётах — смешивать «сервер, с которого я работаю с архивом» и «место, где хранятся сами данные». Это разные роли. Первая требует процессора, памяти и сетевого канала на время работы. Вторая требует ёмкости и сохранности, а процессор ей почти не нужен.
Если склеить роли, получается привычная картина: берём VPS, раз уж он есть, и кладём архив на его диск. Пока данных немного, схема работает. Но с 500 ГБ арифметика меняется, и у неё есть жёсткое ограничение, о котором лучше сказать сразу.
Подтверждённая линейка VPS MAATRIX выглядит так: Ba — 1 vCPU, 2 ГБ RAM, 40 ГБ NVMe; Uab — 2 vCPU, 4 ГБ, 80 ГБ; Heka — 4 vCPU, 8 ГБ, 160 ГБ; Maat — 8 vCPU, 16 ГБ, 240 ГБ; Djed — 16 vCPU, 32 ГБ, 320 ГБ. Самый большой диск здесь — 320 ГБ, а архив — 500. Даже на старшем тарифе он не поместится, а ведь на диске ещё живут система, программы и рабочие файлы. Отдельного тарифа на 500 ГБ в подтверждённых данных нет, и придумывать его я не буду: возможность подключить дополнительную ёмкость нужно уточнять у MAATRIX отдельно, до того как строить на ней план.
Отсюда первый вывод: задача «хранить 500 ГБ» не решается выбором одного тарифа из линейки. Нужно либо отдельное подходящее хранилище, либо согласованная дополнительная ёмкость, либо деление архива на части с понятной логикой. VPS при этом остаётся полезным, но как рабочая точка, а не как склад.
Виртуальный диск против объектного хранилища: в чём разница на практике
Диск VPS — это блочное устройство, на котором лежит файловая система. Он быстрый (в предложении MAATRIX это NVMe), с ним удобно работать обычными инструментами: открыть файл, поискать по каталогу, запустить базу. Но он привязан к серверу: ёмкость задаётся тарифом, а когда он заканчивается, приходится менять план или искать обходные пути. Платите вы за весь объём диска сразу, заполнен он или нет.
Объектное хранилище устроено иначе. Данные лежат как объекты в корзинах, обращаться к ним нужно по API или через клиент, а не как к локальной папке. Плата, как правило, складывается из нескольких частей. Для примера возьмём Amazon S3: его документация по ценам указывает, что стоимость зависит от хранения, запросов, извлечения и передачи данных, а также от выбранного класса и дополнительных функций (Amazon S3 pricing). Это очень важная для нашей темы мысль: цена за гигабайт в месяц — лишь одна строка счёта.
Сравним подходы по свойствам, которые влияют на решение именно для редко открываемого архива на 500 ГБ.
| Критерий | Диск VPS | Объектное хранилище |
|---|---|---|
| Вместимость | Ограничена тарифом; в подтверждённой линейке максимум 320 ГБ | Не привязана к размеру сервера, зависит от условий провайдера |
| Модель оплаты | Входит в стоимость тарифа целиком | Хранение, запросы, извлечение, исходящий трафик — отдельные статьи |
| Работа с файлами | Обычная файловая система | Через API или специальный клиент |
| Привязка к серверу | Данные живут вместе с VPS | Данные живут отдельно от сервера |
| Скорость первого доступа | Мгновенный | Зависит от класса хранения |
Последняя строка таблицы заслуживает отдельного разговора, потому что именно она ломает самые аккуратные прикидки.
Холодный архив: дёшево лежать, но не мгновенно читать
Многие объектные сервисы предлагают «холодные» классы хранения для данных, которые трогают редко. Логика проста: чем реже вы читаете, тем дешевле хранение, но тем дороже или медленнее доступ. В документации Amazon S3 сказано, что объекты классов Glacier Flexible Retrieval и Deep Archive требуют восстановления для доступа, то есть читаются не мгновенно (Restoring archived Amazon S3 objects). Там же отмечено, что восстановленная временная копия может оплачиваться одновременно с архивным оригиналом. Правило относится именно к этим классам, а не ко всему объектному хранению вообще.
Для нашего сценария это означает две практические вещи. Первая: если архив понадобится «срочно, сегодня к вечеру», холодный класс может не подойти по сроку, даже если по цене он выигрывает. Вторая: в расчёт восстановления нужно закладывать период, когда вы платите и за оригинал, и за временную копию. Конкретные цены и сроки у каждого провайдера свои и меняются, поэтому в статье я их не называю: их нужно брать с актуальной страницы выбранного сервиса.
Полезно заранее решить, какие у вас бывают два типа обращений. «Достать один файл» и «поднять всё целиком» — это разные операции с разной стоимостью и сроками. Для первой хорошо подходит сравнительно доступный класс, для второй придётся отдельно прикинуть, сколько данных вы вытащите, куда и как быстро.
Считаем на условном примере: хранение, обращения и выдача
Теперь соберём калькуляцию. Цифры ниже вымышленные и нужны только затем, чтобы показать структуру расчёта; подставляйте свои значения из тарифов выбранного провайдера.
Допустим, у нас есть три условные ставки, которые мы обозначим буквами:
- H — цена хранения за гигабайт в месяц;
- R — цена извлечения (восстановления) за гигабайт, если класс её взимает;
- T — цена исходящей передачи за гигабайт.
Месячные затраты на хранение — это 500 × H. Одно полное восстановление с выгрузкой наружу — это 500 × R + 500 × T, плюс небольшая плата за запросы, которая при крупных объектах обычно мала, а при миллионах мелких файлов может заметно вырасти. Последнее важно: тот же архив из 500 ГБ, нарезанный на пять миллионов крошечных файлов, и архив из пятисот объектов по гигабайту — это разные счета за запросы и разное время переноса.
Теперь сценарий. Пусть за год архив лежит двенадцать месяцев и один раз его нужно восстановить целиком. Годовая стоимость равна 12 × 500 × H + одно восстановление. Если выбрать очень дешёвый класс с малым H, но высоким R и T, то разовое восстановление может съесть экономию нескольких месяцев хранения. Если же восстановлений ожидается два-три за год, выгоднее оказывается более дорогой в хранении, но дешёвый в чтении класс. Простая формула помогает увидеть точку безубыточности: сравниваем разницу в месячном хранении двух классов с разницей в цене одного восстановления и смотрим, сколько месяцев нужно, чтобы экономия на хранении перекрыла переплату за чтение.
Здесь же стоит учесть второй вид выдачи — не восстановление, а повседневное скачивание. Если коллеги раз в неделю вытягивают по десять гигабайт, то это 40 гигабайт в месяц исходящего трафика, и они тоже входят в счёт. Именно поэтому сравнение цен хранения без учёта выдачи данных вводит в заблуждение: вариант, который выглядит самым дешёвым на странице «цена за гигабайт», может оказаться самым дорогим в вашем реальном использовании.
Методология AWS Well-Architected связывает оптимизацию затрат с функциональными требованиями, использованием ресурсов и согласованием спроса с мощностью (AWS Well-Architected Cost Optimization Pillar). Переведу на наш случай: сначала выясняем, что от архива требуется (срок восстановления, частота обращений), и только потом выбираем класс и размер. Не наоборот. Рекомендация о постоянной оценке затрат — это совет методологии, а не расчёт для вашего конкретного случая; цены и свойства сервисов она не определяет.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации Россия, США, Франция и Великобритания. Оплата картой РФ и по СБП.
Сколько времени занимает полное восстановление
Деньги — не единственная валюта. У восстановления есть время, и его можно прикинуть простой арифметикой. 500 ГБ — это примерно 4000 гигабит (в десятичных единицах). Если канал реально держит 100 Мбит/с, то на передачу уйдёт около 40 000 секунд, то есть чуть больше 11 часов. На 1 Гбит/с — порядка 67 минут при идеальных условиях. Реальная скорость почти всегда ниже заявленной: сказываются накладные расходы, параллелизм, загрузка канала на обеих сторонах. Поэтому берите измеренную скорость, а не ту, что написана в рекламе.
К времени передачи добавляется время подготовки. Если архив лежит в холодном классе и требует восстановления, то часы или более долгий срок ожидания идут до начала скачивания, а не вместо него. Полная картина получается такой: ожидание восстановления из архивного класса, затем передача, затем распаковка и проверка. Для плана аварийного возврата нужно складывать все эти этапы, а не смотреть на самый приятный.
Есть и ограничение на принимающей стороне. Раз на диски MAATRIX до 320 ГБ полный архив не помещается, «восстановить всё на VPS» просто невозможно в одном месте без отдельной дополнительной ёмкости. Значит, нужно заранее решить, куда именно вы разворачиваете копию: на другой сервер с достаточным диском, на отдельное согласованное хранилище или по частям. Это важнее, чем кажется: многие планы восстановления рушатся не на скачивании, а на том, что места для результата не хватает.
Восстанавливать всё необязательно: частичное извлечение из снимков
Хорошая новость в том, что «полное восстановление» нужно реже, чем кажется. Если архив ведётся инструментом резервного копирования со снимками, например restic, вернуть можно только нужное. Документация restic описывает, что команда restore извлекает выбранный снимок в отдельный целевой каталог, причём параметр --path фильтрует выбор снимка, а --include и --exclude ограничивают извлекаемые файлы, и это разные действия (Restic: восстановление). Также есть фильтры для выбора последнего снимка конкретного хоста и пути, а восстановление в отдельную директорию позволяет сначала проверить результат.
Для архива на 500 ГБ это очень практичный приём. Допустим, нужны только документы одного проекта за прошлый год. Вместо того чтобы поднимать всё и платить за извлечение всех 500 ГБ, вы выбираете нужный снимок и ограничиваете состав файлов. Объём выдачи падает, вместе с ним падают и деньги, и время. Восстановление в отдельную папку добавляет безопасности: вы смотрите на результат, не затирая рабочие данные. Точные ключи и синтаксис берите из актуальной документации той версии, которую используете, — я не привожу команды, чтобы не выдавать их за проверенные для вашей сборки.
Заодно это влияет на выбор хранилища. Если вы работаете с инструментом, который читает данные крупными блоками и умеет вытягивать только нужное, то холодный класс будет болезненнее, чем с обычными файлами: инструменту может понадобиться обратиться к служебным данным репозитория, а они должны быть доступны сразу. Поэтому служебную часть и сами данные иногда разумно размещать по-разному, но это нужно проверять на небольшом тестовом объёме, а не решать на глаз.
Вторая копия: зачем она и что с ней делать
Одна копия — это ещё не архив, а надежда. Если единственный экземпляр лежит на диске того же сервера, с которого вы им пользуетесь, то поломка, ошибочное удаление или компрометация затрагивают всё сразу. Вторая копия должна жить отдельно: у другого провайдера, в другой локации или хотя бы в другом хранилище с отдельными учётными данными.
Стоимость при этом удваивается не обязательно. Рабочую копию можно держать в более доступном месте (где вы чаще читаете), а резервную — в более холодном и дешёвом, куда вы заглядываете только в беде. Но тогда сроки аварийного восстановления определяются именно холодной копией, и это нужно честно записать в план. Если резервная копия возвращается трое суток, а бизнесу нужен ответ в тот же день, схема не выдерживает проверки — лучше узнать об этом сейчас.
Отдельно о том, чего я не буду обещать. В подтверждённых данных MAATRIX нет утверждений об автоматических резервных копиях во всех тарифах, поэтому полагаться на них нельзя: копирование вы настраиваете сами и сами проверяете, что из него можно вернуть данные. Проверка восстановления — не формальность: хотя бы раз попробуйте поднять небольшую часть, сверьте результат и засеките время, чтобы в плане стояли измеренные значения, а не желаемые.
Какую работу оставить небольшому VPS
Теперь вернёмся к исходному разделению ролей. Если сами данные живут в объектном хранилище или на отдельной согласованной ёмкости, то VPS становится тем, чем он хорош: удобной точкой входа. На нём можно разместить каталог архива, веб-интерфейс для поиска и выдачи, скрипты, которые запускают резервное копирование по расписанию и проверяют его, и обработчик, который по запросу достаёт нужный фрагмент.
Для такой роли не нужен большой диск. Хватит конфигурации, где есть место под систему, индекс или каталог и временный рабочий каталог под частичные восстановления. Например, тариф Ba с 40 ГБ NVMe или Uab с 80 ГБ могут быть отправной точкой для теста, но не обещанием, что этого хватит: ресурсы из плана — это стартовая точка, и реальную потребность определяет замер на ваших данных. Размер временного каталога стоит прикидывать от самого крупного фрагмента, который вы собираетесь поднимать за раз, плюс запас на распаковку.
Если нужен готовый интерфейс для файлов, в публичном каталоге MAATRIX предложены Nextcloud и n8n с установкой; наличие и операционная система уточняются в форме заказа. Nextcloud может служить окном к файлам, а n8n — автоматизировать уведомления и регулярные задачи вроде проверки свежести копий. Но подчеркну: это лишь удобные надстройки, а не решение проблемы ёмкости. Сколько данных можно подключить к такому интерфейсу и какими способами, нужно проверять отдельно.
Преимущества у VPS в такой схеме вполне земные: root-доступ позволяет поставить нужные инструменты, NVMe быстро справляется с индексами и временными файлами, а выбор локации (в предложении перечислены UK, US, RU и FR) помогает приблизить интерфейс к тем, кто им пользуется. Иными словами, VPS отвечает за удобство, хранилище — за объём, и каждый занимается своим.
Как это выглядит в сборе
Итоговая архитектура получается довольно спокойной. Основной архив на 500 ГБ лежит там, где ему действительно хватает места: в объектном хранилище подходящего класса либо на отдельной ёмкости, наличие и условия которой согласованы заранее. Класс выбран по расчёту из трёх величин: сколько стоит хранение, как часто и в каком объёме вы читаете, насколько срочным бывает возврат. Вторая копия лежит независимо от первой, и её срок возврата записан в плане числами, которые вы проверили.
Небольшой VPS стоит перед всем этим как проходная: ведёт каталог, запускает копирование, достаёт нужные фрагменты в отдельный каталог, а при необходимости разворачивает полную копию — но только если для неё подготовлено место, превышающее 500 ГБ. Если вы собираетесь поднимать архив целиком, заранее определите принимающий сервер с достаточным диском, ведь 320 ГБ старшего подтверждённого тарифа для этого мало.
Если ваш случай похож на запись больших объёмов ежемесячно, посмотрите соседний разбор — Стример пишет 500 ГБ эфиров в месяц: куда девать архив. Там та же проблема с другой стороны: данные не просто лежат, а постоянно прибывают.
Напоследок короткая проверка вашего плана, из трёх вопросов. Помещается ли архив туда, где он лежит? Известно ли, сколько стоит и сколько длится его возврат, если считать выдачу данных вместе с хранением? И есть ли куда его вернуть? Если на все три ответ «да», 500 гигабайт можно хранить спокойно и достать вовремя, когда они наконец понадобятся.