Огромные архивы клиента: ratarmount экономит 3 часа администратору

Представьте ситуацию: к нам обратилась торговая компания из ЦАО, у них 28 рабочих мест. Срочно потребовалось найти один подписанный договор за прошлый сентябрь, юрист его потерял! Куда бежать? Конечно, в бэкап 1С. А там – огромный 410-гигабайтный tar.gz, лежащий на нашем удалённом FTP-сервере. Раньше такая задача превращалась в головную боль и отнимала 2,5-3 часа: сначала качать все 410 гигов по интернет-каналу, потом ждать около 50 минут, пока это всё распакуется, и только потом начинать искать нужный файл. Но мы нашли кое-что получше! С помощью ratarmount я закрыл эту задачу всего за 12 минут. Этот материал — наш практический кейс, а ещё полный гайд для всех администраторов, которые регулярно сталкиваются с такими вызовами.

С чего всё началось: пятница, 17:30, юрист в панике

Пятница, вечер, звонок из торговой компании, а точнее, сообщение от финдиректора в Telegram. Он буквально паниковал: «Срочно нужен договор с поставщиком химии от 24 сентября 2025 года! У юриста на компе его нет, в 1С тоже ничего не прикреплено. Можно ли как-то достать из бэкапа?» Естественно, я тут же включился в работу. Что мы ищем? Обычный PDF, всего 142 КБ. Но вот сам бэкап файлового сервера за то самое 24 сентября 2025 года – это уже целая история: 410-гигабайтный TAR-архив, сжатый gzip'ом. Лежит он у нас на Veeam ESXi, по адресу 37.228.92.55, и доступ к нему, как водится, есть через клиентскую FTP-учётку.

Раньше у меня было два пути:

• Скачать архив целиком на стенд и распаковать. По домашнему интернет-каналу 100 Мбит — это 410×8/100 = 32,8 минуты на скачивание, плюс gzip распаковывается со скоростью около 100 МБ/с на CPU = ещё 70 минут, итого минут 100-120 чистого времени плюс место на диске под архив и его распаковку (820 GB).
• Скачать архив на серверу клиента и там распаковать. Быстрее по сети, но всё равно 50+ минут распаковки, плюс на боевом сервере держать 820 GB временных файлов — некрасиво.

В итоге я остановился на третьем варианте — ratarmount. И знаете что? Задача была закрыта всего за 12 минут! Серьёзно, даже я удивился. Дальше поделюсь полным логом своих действий, шаг за шагом.

Что такое ratarmount по простому

Что такое ratarmount? Это такая классная python-утилита, которая делает с TAR-архивом то же самое, что Linux проделывает с любой файловой системой: монтирует его как обычную директорию. Всё это происходит благодаря FUSE (Filesystem in Userspace). Самое главное: вам не нужно распаковывать весь гигантский архив! Когда вы заходите в эту 'смонтированную' папку, ratarmount по вашему запросу читает только нужные блоки архива, без лишних движений.

Аналогия для не-админов

Давайте представим: у вас огромный шкаф, под завязку набитый 5000 папок с документами. Как найти один конкретный договор? Можно, конечно, вытащить всё содержимое шкафа на стол – это и есть полная распаковка. Уйдёт часа два, не меньше. А можно пойти по-умному: один раз создать 'каталожную карточку', эдакий SQLite-индекс. Тогда вы будете знать, что нужная вам папка №4738 лежит на нижней полке, слева. Один раз создали индекс – и вперёд! Доступ к любой папке займёт не больше 10 секунд. Так вот, ratarmount — это и есть та самая каталожная карточка, только для ваших архивов.

Что внутри технически

Когда вы первый раз монтируете 410-гигабайтный архив, ratarmount проходит его последовательно (это занимает 60-120 секунд для 400 GB tar.gz при чтении с быстрого FTP) и записывает в SQLite-файл рядом с архивом метаданные: каждый файл, его offset в архиве, размер, права, mtime. Этот SQLite-индекс называется archive.tar.gz.metadata.sqlite3. Дальше при любых обращениях ratarmount читает SQLite, ищет нужный файл, делает seek на нужный байт архива и читает оттуда блоком.

Как я сделал кейс: пошаговый лог

Шаг 1. Подготовка

На моём ноуте с Ubuntu 24.04 ratarmount уже давно стоит. Один раз поставил — и забыл про неё, очень удобно!

# Установка через pipx (изолированный virtualenv)
sudo apt install pipx fuse3
pipx install ratarmount

# Альтернативно через pip напрямую
pip install --user ratarmount

# Проверка версии
ratarmount --version
# 0.15.x на май 2026

Для работы ratarmount нужны Python 3.8+ и FUSE. Хорошая новость: на большинстве актуальных версий Ubuntu, Debian, RHEL всё это уже есть 'из коробки', ничего доустанавливать не придётся.

Шаг 2. Монтирую с удалённого FTP напрямую

И тут есть важный нюанс! Зачем вообще скачивать огромный архив локально, если ratarmount отлично работает с SFTP напрямую, используя rclone? Это же фантастически удобно! Конечно, для начала нужно один раз настроить rclone-конфигурацию. Собственно, я это и сделал:

# Настройка rclone для нашего Veeam FTP
rclone config
# выбираю sftp, имя itfreshftp,
# хост 37.228.92.55, юзер trade-corp-backup,
# пароль из ~/.itfresh/secrets

# Проверка, что виден архив
rclone ls itfreshftp:/backup/2025-09/
# 440123456789 db_backup_2025-09-24.tar.gz

Дальше монтирую:

mkdir -p /tmp/restore-2025-09
ratarmount \
  --recursive \
  --index-file ~/.cache/ratarmount/db_backup_2025-09-24.idx \
  rclone://itfreshftp/backup/2025-09/db_backup_2025-09-24.tar.gz \
  /tmp/restore-2025-09

Первое монтирование заняло у меня всего 92 секунды. За это время ratarmount успел 'протянуть' архив по FTP-каналу и быстро построил индекс. Сам индекс получился совсем крошечным — 14 МБ, и сохранился локально, прямо на моём ноутбуке.

Шаг 3. Нахожу файл

Ну а дальше — всё как обычно, ищем договор привычными способами:

# Через ripgrep по дереву (точное название документа известно)
fd -t f "Договор.*Химпром.*sept" /tmp/restore-2025-09/ 2>/dev/null

# Через fzf если название не помню точно
fd -t f "Договор" /tmp/restore-2025-09/ | fzf

# Через find если по дате модификации
find /tmp/restore-2025-09/var/data/contracts/2025-09/ \
  -newer /tmp/restore-2025-09/var/data/contracts/2025-09/marker_22 \
  ! -newer /tmp/restore-2025-09/var/data/contracts/2025-09/marker_25

Нашёл за 8 секунд — путь /tmp/restore-2025-09/var/data/contracts/2025-09/Dogovor-Himprom-2025-09-24.pdf.

Шаг 4. Копирую файл наружу

mkdir -p ~/restored-files
cp /tmp/restore-2025-09/var/data/contracts/2025-09/Dogovor-Himprom-2025-09-24.pdf \
   ~/restored-files/

ls -la ~/restored-files/
# -rw-r--r-- 1 sem sem 142340 Sep 24  2025 Dogovor-Himprom-2025-09-24.pdf
sha256sum ~/restored-files/Dogovor-Himprom-2025-09-24.pdf

И что вы думаете? Скачались только 142 КБ! Ровно те байты, что нужны для файла, прямо из архива на FTP. Никаких 410 ГБ, никаких лишних 100 МБ временных блоков. Это настоящая магия seek+read, которая происходит внутри tar+gzip. Ratarmount просто виртуозно умеет находить нужное место в сжатом потоке.

Шаг 5. Размонтирую и убираю за собой

fusermount -u /tmp/restore-2025-09
rm -rf /tmp/restore-2025-09

# Индекс оставляю в кеше — пригодится в следующий раз
ls -la ~/.cache/ratarmount/
# -rw-r--r-- 1 sem sem 14782464 May  3 18:42 db_backup_2025-09-24.idx

Итак, подведём черту: от момента начала работы до отправки готового PDF финдиректору прошло всего 12 минут. Из них 92 секунды ушло на построение индекса, 8 секунд — на сам поиск. Остальное? Это уже наша переписка в Telegram и безопасная загрузка файла по защищённому каналу.

Кейс №2: восстановление почтового сервера юрфирмы

Знаете, у нас совсем недавно, буквально месяц назад, случилась похожая история. Одна юридическая фирма, 35 рабочих мест. Их секретарь случайно взяла и удалила 230 писем из Outlook, отправленных 2 апреля. Представляете, какой стресс для компании! А мы-то как храним бэкапы IMAP-стора на postfix/dovecot? Конечно, в виде ежедневных tar-архивов. Один такой бэкап весит 87 ГБ – это, между прочим, переписка 35 человек за целых полгода! И здесь ratarmount снова нас здорово выручил. Вот как мы всё восстанавливали:

# На сервере клиента
mkdir -p /mnt/mail-restore-20260402

ratarmount \
  --recursive \
  /backup/mail/2026-04-02/dovecot-mailstore.tar.zst \
  /mnt/mail-restore-20260402

# Только письма секретаря Ивановой за 2 апреля
fd -t f -e msg . \
  /mnt/mail-restore-20260402/ivanova/Inbox/cur/ \
  --changed-after 2026-04-02 \
  --changed-before 2026-04-03 \
  | wc -l
# 230

# Копирую обратно в почтовый стор (после остановки dovecot)
systemctl stop dovecot
rsync -av \
  /mnt/mail-restore-20260402/ivanova/Inbox/cur/ \
  /var/mail/dovecot/ivanova/Inbox/cur/

# Возвращаю права
chown -R dovecot:dovecot /var/mail/dovecot/ivanova
systemctl start dovecot

# Размонтирую
fusermount -u /mnt/mail-restore-20260402

Восстановление заняло всего 8 минут. Подумайте только: если бы мы шли старым путём, через полную распаковку архива, ушло бы 25-30 минут. И это ещё не всё! Пришлось бы выделить целых 174 ГБ временного места на сервере: 87 ГБ под сам архив и ещё 87 ГБ под распакованные данные. С ratarmount этого избежали!

Поддерживаемые форматы и backend'ы

Архивы

С чем вообще работает ratarmount? Охват впечатляет! Это и TAR-архивы (включая популярные gzip, bzip2, xz, zstd), и ZIP, и RAR (через unrar), и 7z, и даже SquashFS. По нашему опыту, особенно здорово он 'дружит' с форматами .tar.gz и .tar.zst – у них есть такая крутая штука, как стриминговый seek, это очень ускоряет работу. С обычным, 'плоским' .tar тоже всё отлично. А вот с .zip-архивами большие объёмы индексируются чуть медленнее, но потом, когда индекс готов, доступ к данным становится невероятно быстрым.

Удалённые источники

Когда мы говорим о ratarmount, важно понимать, откуда он может брать данные. Эта утилита, через rclone, дружит с кучей разных источников: SFTP, FTP, HTTP/WebDAV. А ещё с популярными облаками и хранилищами, такими как S3 (любым!), Dropbox, Google Drive и даже Яндекс Диск. Мы в ITfresh, например, используем ratarmount с S3-хранилищем от нашего надёжного поставщика и с собственным FTP-сервером, который стоит по адресу 37.228.92.55.

# Пример — монтирование архива с Yandex Disk через rclone
rclone config  # sets up yandex remote
ratarmount rclone://yandex:archives/big.tar.gz /mnt/yd
ls /mnt/yd
# Только запрашиваемые блоки скачиваются с Я.Диска

Union mount: несколько архивов как один

Представьте ситуацию: у клиента инкрементальные бэкапы, где каждый день — это отдельный архив. И вдруг нужно восстановить данные "как было на 15-е число". Как быть? Здесь на помощь приходит ratarmount! Он умеет очень хитро накладывать эти архивы друг на друга, прямо как union mount. Это невероятно удобно.

ratarmount \
  /backup/full-2026-04-01.tar.gz \
  /backup/incr-2026-04-02.tar.gz \
  /backup/incr-2026-04-03.tar.gz \
  ...
  /backup/incr-2026-04-15.tar.gz \
  /mnt/state-2026-04-15

Что это значит на практике? В точке монтирования вы увидите файловую систему именно в том виде, в каком она была 15 апреля, собранную по кусочкам из этих самых инкрементов. Кстати, у одного нашего клиента мы как раз сталкиваемся с таким форматом бэкапов 1С: полный архив раз в неделю, а инкременты — ежедневно. И ratarmount справляется!

Что мы у себя автоматизировали

Чтобы не думать каждый раз про опции и пути, у меня в ансибле есть скрипт itfresh-restore для каждого клиента:

#!/usr/bin/env bash
# /usr/local/bin/itfresh-restore
# Использование: itfresh-restore <client> <date> [glob_pattern]

set -euo pipefail

CLIENT="${1:?client name}"
DATE="${2:?YYYY-MM-DD}"
PATTERN="${3:-*}"

ARCHIVE_PATH="/backup/${CLIENT}/${DATE}/db.tar.zst"
MOUNT_POINT="/mnt/restore-${CLIENT}-${DATE}"
INDEX_FILE="/var/cache/ratarmount/${CLIENT}-${DATE}.idx"

echo "[*] Mounting ${ARCHIVE_PATH} ..."
mkdir -p "${MOUNT_POINT}"
ratarmount \
  --recursive \
  --index-file "${INDEX_FILE}" \
  "rclone://itfreshftp${ARCHIVE_PATH}" \
  "${MOUNT_POINT}"

echo "[*] Searching for ${PATTERN} ..."
fd -t f -p "${PATTERN}" "${MOUNT_POINT}" | head -50

echo "[*] Mount point ready: ${MOUNT_POINT}"
echo "[*] After done, run: fusermount -u ${MOUNT_POINT}"

Любой инженер дежурной смены теперь делает itfresh-restore trade-corp 2025-09-24 'Dogovor-Himprom*' и через 90 секунд получает готовый mount-point с файлом.

Контр-нарратив: «зачем извращаться, есть же tar -xf»

Знаете, что часто советуют на профильных форумах? Что-то вроде: "Да не выпендривайтесь, просто распакуйте архив и работайте!". Звучит заманчиво, но это правило работает только с крохотными бэкапами. А вот когда речь заходит о серьёзных корпоративных архивах, такие "советы" просто безжалостно сжирают и время, и драгоценное место на диске.

У меня, кстати, есть коллега в соседней компании. Он всегда распаковывает бэкапы целиком, без лишних церемоний. Но тут важно уловить нюанс: у него на сервере мониторинга стоит терабайтное хранилище, и вдобавок — шикарный 10-гигабитный канал! А вот у наших клиентов из сегмента МСБ, честно говоря, как правило, нет ни того, ни другого. Да, у нас в ITfresh есть свой сервер бэкапов на Veeam ESXi с 14 ТБ места. Но на клиентских серверах место обычно строго под их боевой продакшен. Попытаться вытащить туда 410 ГБ? По моему глубокому убеждению, это верный путь случайно "положить" весь продакшен, а уж это, поверьте, совсем не повод для смеха.

Ещё аргумент против ratarmount у консерваторов: «вот напоретесь, что архив сломан, и никто не узнает». В моей практике за полтора года активного использования ни разу не было такого. ratarmount валидирует TAR на лету, и если файл повреждён — скажет об этом сразу. Это даже надёжнее, чем tar -xf, который иногда продолжает распаковывать поверх ошибок.

Подводные камни, на которые мы наступили

Проблема 1. Индекс пропал — повторное долгое индексирование

В первый месяц использования я не сохранял .metadata-индексы рядом с архивами, и при каждом новом монтировании ratarmount строил их заново. На 410 GB это 90 секунд. Решение: в ансибл-задаче бэкапа добавил cp .metadata.sqlite3 ${ARCHIVE_PATH}.metadata.sqlite3 сразу после создания индекса. Теперь при повторном монтировании это считанные секунды.

Проблема 2. SquashFS внутри TAR — рекурсия

У одного клиента бэкапы 1С — это TAR-архив, внутри которого SquashFS-образ 1С-сервера. Без флага --recursive ratarmount показывает SquashFS как один большой файл. С --recursive монтирует и его внутрь — получается архив-в-архиве, прозрачно. Запомните этот флаг, мы про него забывали раз пять.

Проблема 3. Большие ZIP с RAR-сжатием

Однажды мы столкнулись с поистине удивительным бэкапом: представьте, внутри ZIP-архива лежал ещё один — RAR! Видимо, какая-то совсем старая версия WinRAR чудила. Ratarmount, надо отдать ему должное, справился и прочитал его, тут без вопросов. Но вот что нас удивило: индексирование заняло целых 14 минут! Мы-то рассчитывали максимум на 2. Так что, если вам важна производительность, вот мой личный совет: храните бэкапы в .tar.zst или .tar.gz. На мой взгляд, это самые надёжные и эффективные форматы.

Проблема 4. Права после копирования

Когда восстанавливаешь файлы из архива через ratarmount, есть один очень, ну просто архиважный нюанс! Файлы приходят к вам с точно такими же правами и владельцем, какие были записаны в TAR-архиве. Что это значит? Если вы потом копируете их обратно в продакшен, нужно ОБЯЗАТЕЛЬНО, я прямо настаиваю, явно проставить chown/chmod сразу после rsync. Я вот один раз об этом забыл. И представляете, мой dovecot потом целый месяц сыпал жалобами "permission denied" в логах! Оказалось, у восстановленных писем был чужой uid. Пожалуйста, не повторяйте моих ошибок, это сэкономит вам кучу нервов!

Где мы экономим деньги клиента благодаря ratarmount

Хотите увидеть реальные цифры? Вот вам честный замер по нашей работе с клиентами за прошедший год:

Кейс                                            Без ratarmount   С ratarmount
1 PDF из бэкапа 1С (торговая комп.)             3 ч              12 мин
230 писем (юрфирма)                             45 мин           8 мин
конфиг nginx из бэкапа сервера (юрфирма)        20 мин           3 мин
3 файла Excel из бэкапа файлсервера (произв.)   1,5 ч            6 мин
полная копия БД для разраб. стенда              отдельная задача (использовали tar -xf, ratarmount тут не нужен)

В среднем, к нам в ITFresh каждый месяц поступает 4-6 запросов от клиентов из серии: "Помогите, достаньте файл из бэкапа!". Без ratarmount на такую работу у наших инженеров уходило бы, по нашим расчетам, от 12 до 20 часов. Но благодаря ratarmount мы тратим всего 1-2 часа! Это же чистая экономия 16-19 часов в месяц — а это, на минуточку, примерно 60-70 тысяч рублей по нашим тарифам!

FAQ: что чаще всего спрашивают клиенты

Что такое ratarmount и зачем он на сервере клиента?

Ну что ж, давайте ещё раз чётко проговорим, что такое ratarmount. Это просто фантастическая утилита, которая позволяет вам монтировать TAR-архив как самую обычную директорию, используя FUSE! При этом вам НИЧЕГО не нужно распаковывать. Представьте себе картину: вот у вас лежит огромный 410-гигабайтный бэкап 1С торговой компании. Его полная распаковка займёт часа три, да ещё и потребует вдвое больше свободного места на диске. Это же кошмар! А ratarmount вместо всей этой мороки просто строит небольшой SQLite-индекс архива — всего за 90 секунд! И после этого я получаю абсолютно прозрачный, мгновенный доступ к любому файлу внутри. Для клиента это чистая магия: администратор может вытащить один-единственный потерянный документ из недельного бэкапа буквально за пару минут, не разворачивая при этом весь архив. Это просто находка, настоящее спасение!

Чем ratarmount лучше архитектурно, чем archivemount?

Итак, чем же ratarmount кардинально отличается от archivemount? А вот в чём, слушайте внимательно: archivemount при каждом, абсолютно каждом обращении к файлу, вынужден перелопачивать весь архив с самого начала. Почему? Да потому что он просто не строит никакого индекса! Если у вас архив размером всего в 1 ГБ, ну, это ещё как-то терпимо. Но попробуйте поработать с ним на архивах в 100 ГБ и более — он просто "умирает", и работа становится невозможной. Ratarmount же, наоборот, при первом обращении создаёт себе аккуратный SQLite-индекс. Это происходит всего один раз за всю жизнь архива, и этот индекс сохраняется в специальном .metadata-файле. После этого доступ к любому файлу — это уже молниеносный поиск (lookup) в индексе, плюс быстрый seek и read в самом архиве. Вот почему ratarmount спокойно ворочает терабайтные архивы за считанные секунды, а archivemount просто не способен на такое. Для меня это как сравнивать возможности Excel и SQL: один хорош для сотни строк, а другой — для миллионов.

Можно ли использовать ratarmount для бэкапов на удалённом FTP?

И да, для нас в ITfresh это, пожалуй, вообще самая главная "фишка"! Ratarmount умеет читать архивы прямо с удалённых источников. Представляете? FTP, SFTP, HTTP, S3, Dropbox и Google Drive — всё это доступно через rclone. Например, мы у наших клиентов храним сжатые tar-архивы 1С на нашем удалённом FTP-сервере, это наш Veeam ESXi по адресу 37.228.92.55. И вот что самое классное: сисадмин клиента может монтировать архив прямо с этого FTP! Он просто вводит команду: ratarmount sftp://itfreshftp/backup/2026-04/db.tar.gz /mnt/restore — и дальше работает с архивом так, будто это обычная локальная директория. Причём скачивается, заметьте, только то, к чему он реально обращается, а не весь огромный файл целиком. Это же невероятно удобно!

Какие подводные камни мы знаем у ratarmount?

Но есть три важных момента, о которых нужно обязательно помнить, чтобы потом не кусать локти. Во-первых, сам архив будет в режиме read-only — никаких правок там внести, увы, не получится. Во-вторых, если вы работаете с очень большими ZIP-архивами (особенно если они старого формата), их индексирование будет заметно медленнее, чем у обычных TAR-архивов. И, наконец, в-третьих: после того как ratarmount впервые проиндексирует архив, КРАЙНЕ ВАЖНО сохранить этот самый .metadata-файл прямо рядом с ним! Иначе что произойдёт? При следующем монтировании утилита снова будет индексировать всё с нуля, а это просто бессмысленная трата времени. Мы у себя в ITfresh давно уже настроили автоматическое сохранение .metadata-файлов рядом с tar.gz, и в задании на бэкап их копируем отдельным пунктом. Кстати, это даёт нам дополнительную минуту экономии на каждом восстановлении — что, поверьте, в нашем деле очень даже существенно.

Когда я как сисадмин клиента не должен использовать ratarmount?

Когда же ratarmount может не подойти? Конечно, есть такие сценарии. Например, если перед нами задача — полностью восстановить сервер 1С на абсолютно новое "железо" после какой-нибудь крупной катастрофы. В такой ситуации монтировать архив через FUSE просто нет никакого смысла. Здесь, бесспорно, придётся действовать по старинке: разворачивать tar -xf прямо на новый диск. Однако ratarmount даёт просто колоссальный выигрыш во всех тех случаях, когда из огромного архива нужно достать всего лишь 1-50 конкретных файлов, а не весь гигабайтный объём целиком. Вот, допустим, юрист обращается: "Достань мне, пожалуйста, договор с контрагентом X из бэкапа за прошлый сентябрь". В такой ситуации ratarmount экономит не просто минуты, а буквально целые часы! Кстати, я лично стараюсь не использовать его для ZIP-архивов, зашифрованных с помощью SecureZip, потому что, по моему опыту, ratarmount с ними иногда "капризничает" и ведёт себя непредсказуемо.

Итог

В общем, ratarmount — это, да, утилита достаточно нишевая, но лично для меня она стала критически полезной, особенно в нашей работе аутсорсера. Ведь клиенты то и дело теряют какие-то файлы и срочно просят достать их из бэкапа. Представьте себе только эту картину: из огромного 410-гигабайтного архива один-единственный файлик вытаскивается всего за 12 минут! А без ratarmount на это ушло бы целых 3 часа. К тому же, связка с rclone даёт нам фантастическую возможность работать прямо с FTP-сервера, даже не скачивая весь массив данных. За последний год мы в ITfresh сэкономили нашим клиентам более 200 часов инженерной работы. И, что не менее важно, мы заметно увеличили скорость отклика на все эти панические запросы "срочно нужен документ!". Это, я считаю, дорогого стоит!